[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> That's actually not a problem, because each walk through the union
> fs requires a retry. The library is supposed to keep track of how
> many retries it gets, and handle ELOOP itself.
Still, if you imagine many that users create a unionfs based
Moritz Schulte <[EMAIL PROTECTED]> writes:
> After I did the O_NOTRANS lookup in unionfs, I check if the resulting
> node is the same as the one returned by netfs_startup. If it is, I
> return ELOOP to make it impossible to reach the unionfs inside of the
> unionfs again, which would lead to infi
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What we really want is for the user to do a retry of the name as it
> exists in the "real" location, and then if that results in ENOENT,
> we want the user to return back to the filesystem for another name
> to try.
Well, here you are only consid
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Actually I was not thinking about making ".." go to the unionfs, but
> this surely seems like a good idea.
>
> > If it's a translator (of any kind, including symlink) then it does
> > the translator linkage *itself*, just as diskfs/netfs does it.
>
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Oh, that. Blech blech blech.
Blech is also corking.
> 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.
I'm not sure wether I
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (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: give
[EMAIL PROTECTED] (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, w
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > I think the right fix is to have lookups for "" do all the normal
> > processing when you open a file.
>
> Well, yes, but the problem of relative symbolic links is not yet
> solved, is it?
What e
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think the right fix is to have lookups for "" do all the normal
> processing when you open a file.
Well, yes, but the problem of relative symbolic links is not yet
solved, is it?
moritz
--
[EMAIL PROTECTED] - http://duesseldor
Moritz Schulte <[EMAIL PROTECTED]> writes:
> > It might well be that we have a hole in the interface here. Blech.
>
> So... fs interface change - anyone? =)
I think the right fix is to have lookups for "" do all the normal
processing when you open a file.
That is, it should do the translator s
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think that's why I originally stated "." which Roland corrected to
> "".
Well, "." would not work for non-directories, of course.
> It might well be that we have a hole in the interface here. Blech.
So... fs interface change - anyone? =)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Instead, you fetch the actual node, and then tell the user to reauth
> *that* node.
Are you sure the needed functionality is implemented?
I tried that, it does not work (with a retry name of ""); the user
keeps the underlying node, he doesn't ge
> Look up the node with O_NOTRANS, and then return *that* to the user,
> with FS_RETRY_REAUTH and a retry name of ".".
Empty string, actually.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
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 d
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 (wi
15 matches
Mail list logo
