Subject: Re: LINK a symbolic link?

From: Erez Zadok <[email-masked]>
Date: Tue, 4 Dec 2001 13:36:12 -0500

In message <[email-masked]>, Spencer Shepler writes:
> On Tue, Neil Brown wrote:
> > On Monday November 26, [email-masked] wrote:
[...]
> > I think the server should be able to fail hardlinks on symlinks much
> > as it can on directories.  Maybe NFS4ERR_NOTSUPP or similar would be
> > appropriate.
> 
> NFS4ERR_NOTSUPP is most appropriate if the server does not allow LINK
> on a particular type (unless it is a directory and NFS4ERR_ISDIR
> should be returned).
> 
> -- 
> Spencer

How does a "smart" client know what _types_ of hard-links are supported by
the server?  (And a related question: can we think of a reason why a client
might want to know this per type?)

Looking at 5.3 "Named Attributes", I only see a link_support boolean that
describes if the remote f/s supports hard-links or not.  But that may not be
enough for a client that wants to know if the server supports hard-links on

- directories
- regular files
- symlinks
- char/block devices
- other?

The NFS4ERR_ISDIR for LINK will help the client to know that it can't
hard-link directories.  But if it gets back a NFS4ERR_NOTSUPP, would it be
able to tell easily if this was b/c the server doesn't support hard-links or
b/c a particular type hard-link isn't supported?

I have two concerns:

(1) A semi-aesthetic one relating to having a consistent API: on one hand
    you define a capabilities-like query type for finding if the server
    supports hardlinks (link_support boolean type).  I like that.  On the
    other hand, you're providing incidental information about specific
    hard-link support by returning certain NFS4ERR_* errors but only for
    certain file types.  It just feels like we should stick to one method of
    determining hardlink support, not split it in two.

    This is a minor issue, perhaps left for 4.<N+1>

(2) Since named attributes are not mandatory, a bad server implementation
    might simply return NOTSUPP for LINK if it doesn't support hardlinks at
    all (even for directories); a bad client implementation might infer from
    getting any kind of NOTSUPP back from LINK that the server doesn't
    support any hardlinks at all (even if supports them for certain types).

    Perhaps the implementation RFC should clarify that clients should not
    infer more about NOTSUPP back from LINK than the server is really
    capable; and that those clients should check the link_support named
    attr.

    If you agree with me, then perhaps the implementation RFC might specify
    in general that clients should prefer to discover server-side support by
    querying for attributes and not by inferring it from various errors they
    get back.

Cheers,
Erez.

PS. it's been a while since I read rfc3010; my apologies if the above had
been discussed already.