hansmu at xs4all
Jul 12, 2012, 6:19 AM
Post #20 of 38
On 12/07/12 14:30:41, Laszlo Nagy wrote:
>> You are contradicting yourself. Either the OS is providing a fully
>> atomic rename or it doesn't. All POSIX compatible OS provide an atomic
>> rename functionality that renames the file atomically or fails without
>> loosing the target side. On POSIX OS it doesn't matter if the target
> This is not a contradiction. Although the rename operation is atomic,
> the whole "change status" process is not. It is because there are two
> operations: #1 delete old status file and #2. rename the new status
> file. And because there are two operations, there is still a race
> condition. I see no contradiction here.
On Posix systems, you can avoid the race condition. The trick is to
skip step #1. The rename will implicitly delete the old file, and
it will still be atomic. The whole process now consists of a single
stop, so the whole process is now atomic.
>> You don't need locks or any other fancy stuff. You just need to make
>> sure that you flush the data and metadata correctly to the disk and
>> force a re-write of the directory inode, too. It's a standard pattern on
>> POSIX platforms and well documented in e.g. the maildir RFC.
> It is not entirely true. We are talking about two processes. One is
> reading a file, another one is writting it. They can run at the same
> time, so flushing disk cache forcedly won't help.
On Posix systems, it will work, and be atomic, even if one process is
reading the old status file while another process is writing the new
one. The old file will be atomically removed from the directory by
the rename operation; it will continue to exists on the hard drive, so
that the reading process can continue reading it. The old file will
be deleted when the reader closes it. Or, if the system crashed before
the old file is closed, it will deleted when the system is restarted.
On Windows, things are very different.
Hope this helps,