link() not increasing link count on NFS server

[Timo Sirainen]

On 15.11.2007, at 16.05, Robert Watson wrote:

> Indeed, and inspection of nfs_vnops.c:nfs_link(): finds:
>
> 1772         /*
> 1773          * Kludge: Map EEXIST => 0 assuming that it is a reply  
> to a retry.
> 1774          */
> 1775         if (error == EEXIST)
> 1776                 error = 0;
> 1777         return (error);
>
> Neither Linux nor Solaris appears to have this logic in the  
> client.  I assume this is, as suggested, to work around UDP  
> retransmissions where the reply is lost rather than the request.   
> It appears to exist in revision 1.1 of nfs_vnops.c, so came in with  
> 4.4BSD in the initial import, but doesn't appear in NetBSD so I'm  
> guessing they've removed it.  It could well be we should be doing  
> the same.  I've added Mohan to the CC line in case he has any input  
> on this point.

A couple of arguments for its removal:

It's somewhat well known that link() can fail with EEXIST even though  
it had succeeded (e.g. link(2) man page in Linux mentions it), but I  
hadn't before heard that link() could return success even though it  
failed.

Since link() is often used for creating lock files, it's a lot safer  
to fail occationally than to think that the locking succeeded and  
cause data corruption.

I've anyway changed my code to work around both problems now (return  
0 check in #ifdef __FreeBSD__).

BTW. Another problem I have is that it seems the only way to make  
sure open() opens the latest file with the given name is to rmdir()  
its parent directory. This isn't very nice to do for directories that  
might be empty, so could the code be changed to flush the cache also  
when chown()ing the directory or something?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071115/9d61c677/PGP.pgp