[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 <moritz@duesseldorf.ccc.de> writes:
> tb@becket.net (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.
- Unionfs, looking up links and translators, Moritz Schulte, 2002/12/17
- Re: Unionfs, looking up links and translators, Thomas Bushnell, BSG, 2002/12/17
- Re: Unionfs, looking up links and translators, Roland McGrath, 2002/12/17
- Re: Unionfs, looking up links and translators, Moritz Schulte, 2002/12/19
- Message not available
- Re: Unionfs, looking up links and translators, Moritz Schulte, 2002/12/19
- Re: Unionfs, looking up links and translators, Thomas Bushnell, BSG, 2002/12/19
- Re: Unionfs, looking up links and translators, Moritz Schulte, 2002/12/19
- Re: Unionfs, looking up links and translators, Thomas Bushnell, BSG, 2002/12/19
- Re: Unionfs, looking up links and translators, Moritz Schulte, 2002/12/19
- Re: Unionfs, looking up links and translators,
Thomas Bushnell, BSG <=
- Re: Unionfs, looking up links and translators, Moritz Schulte, 2002/12/20
- Re: Unionfs, looking up links and translators, Thomas Bushnell, BSG, 2002/12/20
- Re: Unionfs, looking up links and translators, Moritz Schulte, 2002/12/20
- Re: Unionfs, looking up links and translators, Thomas Bushnell, BSG, 2002/12/20
- Re: Unionfs, looking up links and translators, Moritz Schulte, 2002/12/21