Re^5: Writing to a log file without colliding

syswrite might be atomic, but that doesn't buy you anything, because open is still a separate step. Another process may have appended data to the file between your opening it and appending to it. Your file pointer will not advance to reflect the new end of the file, so you will overwrite that processes' data.

The only safe way to append to a file is to open it, obtain an exclusive lock, seek to its end, and then write. That seeking step is necessary exactly because of the above issue: between opening the file and getting a lock on it, someone else may have appended data to it.

What I said still stands: there is no way around locking.

Makeshifts last the longest.

Comment on Re^5: Writing to a log file without colliding

Replies are listed 'Best First'.
Re^6: Writing to a log file without colliding by dave_the_m (Monsignor) on Aug 17, 2004 at 12:52 UTC
open is still a separate step. Another process may have appended data to the file between your opening it and appending to it. Your file pointer will not advance to reflect the new end of the file, so you will overwrite that processes' data. From the Solaris write(2) manpage: If the O_APPEND flag of the file status flags is set, the file offset will be set to the end of the file prior to each write and no intervening file modification operation will occur between changing the file offset and the write operation. This is for example how multiple apache processes all manage to append to the same log file without explicit locking. Dave.	[reply]
Re^7: Writing to a log file without colliding by Aristotle (Chancellor) on Aug 17, 2004 at 15:06 UTC
Interesting. `man 2 open` on FreeBSD says Opening a file with `O_APPEND` set causes each write on the file to be appended to the end. That is somewhat ambiguous, though it can be interpreted to mean the same as the Solaris manpage says about `O_APPEND`. On Linux, `man 2 open` says `O_APPEND` The file is opened in append mode. Before each write, the file pointer is positioned at the end of the file, as if with `lseek`. `O_APPEND` may lead to corrupted files on NFS file systems if more than one process appends data to a file at once. This is because NFS does not support appending to a file, so the client kernel has to simulate it, which can't be done without a race condition. So this seems to be a portable assumption. (The cautionary note about files on NFS mounted filesystems found in the Linux manpage is probably applicable across the board, as well.) I wonder since when this has been the case; it hasn't always been. Makeshifts last the longest.	[reply]