Subject: RE: [nfsv4] Global namespace for v4.1?

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 22 Dec 2003 11:21:50 -0800

> First off I agree that we have the mechanisms to make
> LOOKUP work right, but I don't think the current RFC
> is worded in a way that allows it.

So we agree on one and disagree on another.

[Deleted a whole bunch of text, since you didn't find it 
convincing.  Will try again]

> Unlike GETATTR, the ambiguity arises from what is the cfh. In the
> description of LOOKUP (14.2.13) it says clearly that if an
> error occurs the the cfh will not be changed.

It clearly says that if there is an error the cfh will not be changed.
What we disagree on is whether there is an error, in this case.  Your
position is not only that you can return MOVED here (and I disagree
with that also) but the stronger claim that the spec does not allow
you to do anything else.  That strong a claim should be backed up by
some strong evidence.  Where is it? 

> But it will return back MOVED.

You keep asserting that.  Where does the spec say it?

> What do I lookup the fs_locations on?  The cfh is that of the directory
> that contains the directory (or file) that was moved.

It can't possibly be that when you do the GETATTR for FS_LOCATIONS.
If the LOOKUP returns MOVED, then you are not executing the GETATTR.
It it doesn't, as I believe is the case, then you are executing GETATTR
with the cfh being the result of a successful LOOKUP, which is the
root directory of the fs that moved.

> The cfh is a
> valid filehandle of the directory and the directory may contain
> other entries that have not moved, or have moved to other places.
> Also by reading the above quote, the current filehandle object has
> not moved, it is still a valid directory that exists on the server.

> I think the correct way to specify this is that when any operation
> returns MOVED, it must set the cfh to a value that a GETATTR
> fs_locations can be performed on.
 
If you return MOVED, it doesn't matter what the cfh is.  You can't
use it because you can't execute any operation that depends on it
since an error stops the request and the cfh vanishes into thin
air.  It's the ultimate volatile file handle :-) 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Mon, 22 Dec 2003 11:35:09 -0800

I'm not really up to speed enough to chime in
on this. But I'm not going to let that stop me :)

What happens when a request with multiple lookups
encounters a symlink? Isn't a referal/redirect/moved/whatever
a funny kind of symlink? Wouldn't path name
reduction handle a redirect much like a symlink?
Perhaps another file system object type, farsymlink,
is justified? Could this possibly leverage existing APIs?

Regards,
   -gww

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Noveck, Dave
> Sent: Monday, December 22, 2003 11:22 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [nfsv4] Global namespace for v4.1?
> 
> 
>