Moritz Schulte <[EMAIL PROTECTED]> writes: > 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.
Yes, that's right. It needs to do it with O_NOTRANS. > 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. Yes, quite right. It needs to do it with O_NOTRANS. > 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. unionfs should probably not be looking anything up, I think. > 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. Then you're doing the wrong retry. Look up the node with O_NOTRANS, and then return *that* to the user, with FS_RETRY_REAUTH and a retry name of ".". You have to do this *anyway* in order to get the right permissions set on the node. You don't tell the user what directory and name to look up; that has races (as you note)! Instead, you fetch the actual node, and then tell the user to reauth *that* node. This has no races. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
