maybe the symbolic link implementation for fusefs is not correct?

[ckhung]

Hi @osnr, thanks for this wonderful work! Conclusion first: I think I found the source of quite a few glitches but I don't know how to fix it. Looking at this SO Q/A: symbolic links in FUSE I guess that your implementation of symbolic link is on the wrong side. The c function implementing fuse_operations.getattr should know the semantics of different paths. In particular, it should know that by_title/* and by_window/* are symlinks and therefore should do point 2 that Craig McQueen suggested in the highest score answer. On the browser extension side, setting st_mode to "writable" looks dubious, which I suspect is a workaround you found?

The symptoms that lead me to the investigation and the above suggestions are the following. I am running tabfs on chromium 113 on linux mint LMDE 5 (elsie) on btrfs. Things work fine inside fs/mnt/tabs/by-id/ . It also works fine if the current working directory is fs/mnt/tabs/ and I do ls -l by-title/ . After I do cd by-title, however, almost every command I give generates an "error while loading shared libraries". Each command (ls, cat, python3, ...) complains about a different library. I think that's because the first thing the system tries to do when it needs to resolve the symlinks for each command's required dll, is to call getattr() on the current directory, which does not implement the above suggestions properly.

What do you think?