Messages in this thread | | | Date | Sun, 23 Feb 2014 12:18:06 +1100 | From | Kevin Easton <> | Subject | Re: Update of file offset on write() etc. is non-atomic with I/O |
| |
On Fri, Feb 21, 2014 at 07:01:31AM +0100, Michael Kerrisk (man-pages) wrote: > Here's the fulll list from POSIX.1-2008/SUSv4 Section XSI 2.9.7: > > [[ > 2.9.7 Thread Interactions with Regular File Operations > > All of the following functions shall be atomic with respect to each > other in the effects specified in > POSIX.1-2008 when they operate on regular files or symbolic links: > > chmod( ) > chown( ) > close( ) > creat( ) > dup2( ) > fchmod( ) > fchmodat( ) > fchown( ) > fchownat( ) > fcntl( ) > fstat( ) > fstatat( ) > ftruncate( ) > lchown( ) > link( ) > linkat( ) > lseek( ) > lstat( ) > open( ) > openat( ) > pread( ) > read( ) > readlink( ) > readlinkat( ) > readv( ) > pwrite( ) > rename( ) > renameat( ) > stat( ) > symlink( ) > symlinkat( ) > truncate( ) > unlink( ) > unlinkat( ) > utime( ) > utimensat( ) > utimes( ) > write( ) > writev( ) > > If two threads each call one of these functions, each call shall > either see all of the specified effects > of the other call, or none of them. > ]] > > I'd bet that there's a bunch of violations to be found, but the > read/write f_pos case is one of the most egregious. > > For example, I got curious about stat() versus rename(). If one > stat()s a directory() while a subdirectory is being renamed to a new > name within that directory, does the link count of the parent > directory ever change--that is, could stat() ever see a changed link > count in the middle of the rename()? My experiments suggest that it > can. I suppose it would have to be a very unusual application that > would be troubled by that, but it does appear to be a violation of > 2.9.7.
A directory isn't a regular file or symlink, though, so the warranty would seem to be void in that case.
If you {f}stat() a regular file that is being concurrently renamed() then the link count shouldn't vary, though.
- Kevin
| |