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?
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:22 UTC