> > False. This is impossible because we never know where the cwd of a > > translator will be; this is up to the underlying filesystem. > > Can you elaborate on this? > > PS. When thinking some more, I realize that I don't know if a > translator is installed on an inode or on a filename. But in any > case, as startup of translators happens at open time, it should > still make sense to talk about "the directory in which the > translator setting was found"). Passive translator are connected to the inode. Thus, if we have two hard links to a translator, what is the current working directory? We just do not know. You could (and do) argue that we should handle this case. So, what does this involve. Well, let us take a look at libdiskfs/dir-lookup.c and libdiskfs/fsys-getroot.c. Here we see that we start passive translators using the fshelp_fetch_root function. Now, let us look in libfshelp/fetch-root.c and we see that when fshelp_fetch_root goes to invoke the translator, it needs to set the standard port and it uses the current working directory of the parent translator. This usually means that the current working directory will be set to /. So, in conclusion to fix this, you need to change the interface to fshelp_fetch_root to pass a port to the current working directory and change a few callers. Personally, I would welcome this change. > PPS: Why are you addressing mail to Niels@walfield.org, > M@walfield.org, rather than to nisse@lysator.liu.se? You have one of those weird characters in your name and it is messing my mutt up. I always realize after I send a message to you.
Attachment:
pgpkPAw65Yoyk.pgp
Description: PGP signature