Re: [nfsv4] FYI: Readdir not allowed on NFS pseudo root

[Stevan Steve Allen <[e-mail]>]

It may be helpful to point out that the server READDIR restriction on the 
v4 root can be detected by the client.  Both read mode bits will be off. 

I'm not client savvy, but if the client creates a name space cache, the v4 
pseudo root may appear as a hidden or restrictive access dir (r+w mode 
permission bits off, DOS hidden attr not supported). 

In contrast, client apps may still have r+w access to the objects 
contained in the v4 root dir (determined from lookup).  It will be likely 
that lookup will return a 2nd level dir object with the read mode bits on, 
allowing READDIR from this point on. 

Initially empty (no READDIR from the root) an ideal client may build a 
name space cache from the restrictive root via lookup and readdirs (when 
read mode bits are on).  Hopefully, no special treatment is needed by the 
client.

Thanks,
Stevan C. Allen


On May 17, 2004, at 6:15 AM, Jim Rees wrote:

>   Seems like the server would return an "empty" response for READDIR
>   on this special server.
>
> But that would be wrong too.  That would imply the directory is empty. 
>  I
> can imagine a client that would get very confused by this.  Suppose, 
> for
> example, the client caches directory contents after a successful 
> READDIR,
> and uses the cached copy for subsequent lookups.  I think 
> NFS4ERR_ACCESS is
> the only acceptable response.

I don't have a strong opinion.  Either response will likely be a call
generator for the interactive user: "I don't see the files I expect to 
see"
or "I get an error when I try to 'ls' the directory".

With tongue firmly planted in cheek, the server could respond to
the READDIR response with a single entry with a name of:
                 "This server does not support the READDIR operation"

>
>   This also implies that clients must use LOOKUP to traverse the
>   server's namespace on things like traditional mount operations that
>   a client would do.
>
> Yes.  The client must be prepared for this anyway.  In fact, the client
> probably can't tell and doesn't care whether it's in a pseudo-fs or a 
> real
> one.
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nfsv4


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