Hi,
I was thinking about what unionfs should do with symbolic links and
translators on the underlying filesystems; i think if unionfs's
_S_dir_lookup would return retry names in that case, that would be
reasonable.
It would create some problems if unionfs would simply use
file_name_lookup (without O_NOTRANS/O_NOLINK/O_NOFOLLOW) to search for
files on the underlying filesystems: if a link points back into the
(absolute path of the) unionfs, this would create a dir_lookup-loop,
since unionfs has no way to distinguish between a dir_lookup call from
the user and a dir_lookup call from the unionfs itself. The same
problem - in a more general way - is present with nodes, on which a
translator is installed; unionfs cannot predict it.
Therefore, unionfs should try to lookup the underlying node for each
node first. If it is a directory, fine, a virtual directory is
created. If it is a normal file, also fine; the file port is returned
to the user. If it is a symbolic link or a translator root, unionfs
could return an according retry port (the directory, in which the node
was found) and a retry name. In that case, unionfs would have
finished it's work for that dir_lookup (also: glibc would take care of
ELOOP conditions).
But there is one basic problem: the node can be modified after
unionfs' dir_lookup returned the retry port/name but before glibc
continued resolving the path name.
One example for the problem: If the node, for which a retry
port/retry name was returned by unionfs' dir_lookup, is deleted before
glibc looked it up itself, ENOENT will be returned. This means:
although there might be other files with the same name in the unionfs,
the user _could_ receive ENOENT.
My conclusion: unionfs cannot safely do all lookups on it's own,
this could lead to infinite loops. But on the other hand, it has to
lookup the underlying node to decide what to do.
Does anyone know of a better solutions?
Thanks,
moritz
--
[EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
