bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unionfs, looking up links and translators


From: Thomas Bushnell, BSG
Subject: Re: Unionfs, looking up links and translators
Date: 19 Dec 2002 15:50:46 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Moritz Schulte <address@hidden> writes:

> address@hidden (Thomas Bushnell, BSG) writes:
> 
> > What exactly would the problem be there?  Maybe I've missed a beat
> > in the conversation.
> 
> Maybe I am overlooking something, I am not that familiar with
> libdiskfs.
> 
> My question is: given the situation that dir_lookup is called to
> re-open a node, which is a symbolic link, the target that link points
> to has to be read out and needs to be resolved.
> 
> Reading out the link target is not a problem, but how should the path
> name resolving process continue without a start directory?

Oh, that.  Blech blech blech.

And, of course, this matters in just this case!  Because it's a union,
and so the node is found in *two* directories and it's not at all
clear which one is right.

Ok, so that explains why the code is as it is.  The problem isn't
specific to relative symlinks; translator interchange also needs to
know what ".." is supposed to mean--which is the same "parent
directory" as for the relative symlink case.

So ignore what I said before; here is some new excogitation:

Assuming we want ".." to go to the *union*, then the union filesystem
should be doing translator startup itself.  This would work as
follows:
  Union fs opens the node with O_NOTRANS and no permissions.
  If it's a translator (of any kind, including symlink) then it
    does the translator linkage *itself*, just as diskfs/netfs does it.
  If it's not a translator, then it returns it to the user with 
    FS_RETRY_REAUTH.

  [Note that in the translated case, it will ultimately end up doing a
  reauth as well.]

Assuming we want ".." *not* to go to the union, then the union
filesystem has a race condition, I think, as you had earlier noted,
because it will be looking it up, and then doing a retry to tell the
user to look up the file in its "real" directory.

Because of this difficulty, I think clearly (heh heh) the right thing
is the first case.


 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]