preload-file + LZ4 causes EPERM errors with readlink

[arsnyder16]

When combining --preload-file with -LZ4 compression, readlink calls will produce EPERM error causing upstream calls like readpath to produce corrupt output.

Not clear to me if one issue(readlink ) is exposing another(readpath) here or not.

To reproduce:

#include <unistd.h>
#include <iostream>

int main() {
    char buffer[128]{};
    std::cout << "readlink: "  << readlink("/a/file.txt", buffer, sizeof(buffer)) << std::endl;
    std::cout << buffer << std::endl;
    std::cout << errno << std::endl;
    buffer[0] = 0;
    std::cout << "realpath: "  << realpath("/a/file.txt", buffer) << std::endl;
    std::cout << buffer << std::endl;
    std::cout << errno << std::endl;
    return 0;
}

Beside the cpp file above create a directory with a file. In my example

a/file.txt

this is a test file

Running any of the following 3 will give you the expected results

em++ -sSINGLE_FILE --embed-file=a@a readlink.cpp -o readlink.js && node readlink.js
em++ -sSINGLE_FILE --preload-file=a@a readlink.cpp -o readlink.js && node readlink.js
em++ -sSINGLE_FILE  -sLZ4 --embed-file=a@a readlink.cpp -o readlink.js && node readlink.js

readlink: -1

28
realpath: /a/file.txt
/a/file.txt
28

Running with LZ4 and preload produces the following:

# em++ -sSINGLE_FILE  -sLZ4 --preload-file=a@a readlink.cpp -o readlink.js && node readlink.js
compressing package of size 20
compressed package into 4116
compressed in 3 ms
readlink: -1

63
warning: Invalid UTF-8 leading byte 0x000000-2 encountered when deserializing a UTF-8 string in wasm memory to a JS string!
realpath: emscgT��

63

Please include the following in your bug report:

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.28 (f11d6196dd4e8748a726f19895c859b40ff6a4f3)
clang version 16.0.0 (https://github.com/llvm/llvm-project ea4be70cea8509520db8638bb17bcd7b5d8d60ac)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /root/emsdk/upstream/bin

[arsnyder16]

appears this specific issue is related to this implementation in library_lz4.js.

        readlink:function(node) {
          throw new FS.ErrnoError(63);

Simply not defining the function seems like a potential solution based on library_fs.js

readlink: (path) => {
      var lookup = FS.lookupPath(path);
      var link = lookup.node;
      if (!link) {
        throw new FS.ErrnoError({{{ cDefine('ENOENT') }}});
      }
      if (!link.node_ops.readlink) {
        throw new FS.ErrnoError({{{ cDefine('EINVAL') }}});
      }
      return PATH_FS.resolve(FS.getPath(link.parent), link.node_ops.readlink(link));
    },

based on a quick scane the issue may be present in library_workerfs.js as well

      readlink: function(node) {
        throw new FS.ErrnoError({{{ cDefine('EPERM') }}});
      },