write(2) is usually atomic as long as you are writing less data than the
block size. POSIX specifies this for writes to pipes or FIFOs. It
apparently doesn't say anything about writing to files but it works on
most Unix-like systems. I guess that means that the APR cannot depend
on it.
My copy of the POSIX.1 spec (1003.1, 1996 Edition) SS 5.3.1.2 (covering
function 'open') says:
: O_APPEND
: If set, the file offset shall be set to the end of the file prior to
: each write.
I believe that ANSI C and C99 both specify the same, though I don't
own a copy of either so can't confirm that.
esm@logic.net writes:
open(2) on Linux 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.
I think that what the linux manpage is making unclear here is that
O_APPEND may lead to corrupted files on NFS file systems if more than
one process _on different systems_ tries to append data to a file at
once. NFS doesnt have file-append semantics, but the local vfs layer
does, so as long as all writers are on the same system, you won't have
a race that can result in corrupted files.
... besides, anyone that's trying to write to a file on an NFS server with
multiple processes on multiple systems, without good locking, is insane
anyhow.
So, end translation: O_APPEND rocks, and guarantees non-corruption on any
POSIXly compliant system, with the possible exception of NFS filesystems
with multiple client systems writing to the same file. As long as APR
requires a system to be POSIXly compliant, it can rely on O_APPEND to
be able to append to the end of a file without corruption.
-jay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:13:44 2006