Messages in this thread | | | From | "Michael Kerrisk (man-pages)" <> | Date | Sun, 23 Feb 2014 08:38:07 +0100 | Subject | Re: Update of file offset on write() etc. is non-atomic with I/O |
| |
On Sun, Feb 23, 2014 at 2:18 AM, Kevin Easton <kevin@guarana.org> wrote: > 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.
Oops -- yes, of course.
> If you {f}stat() a regular file that is being concurrently renamed() then > the link count shouldn't vary, though.
Yes. (I haven't tested that though.)
Cheers,
Michael
-- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
| |