NFS is notable for not supporting atomic rename.
Where do you get this? Lots of versions of rename,2 say
If newpath already exists it will be atomically replaced (subject to a few conditions; see ERRORS below), so that there is no point at which another process attempting to access newpath will find it missing.
Which covers exactly the race that was discussed. And the "ERRORS" section mentions nothing of NFS. Yet NFS is specifically covered in the "BUGS" section:
On NFS file systems, you can not assume that if the operation failed the file was not renamed. If the server does the rename operation and then crashes, the retransmitted RPC which will be processed when the server is up again causes a failure. The application is expected to deal with this. See link(2) for a similar problem.
Which says nothing about the rename not happening atomically. It just means that ENOENT might result not because somebody else (re)moved the "old" name before you could call rename(2) but also because you renamed it before retrying the operation due to remote server failure.
- tye
In reply to Re^6: locking over the network (NFS)
by tye
in thread locking over the network
by rovf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |