Hi,
On Sat, Jun 08, 2002 at 03:34:29PM -0400, Greg Hudson wrote:
> On Unix, you have some basic tools available for local filesystems:
> * rename() is both failure-atomic and concurrency-atomic; either the
> rename has happened or it hasn't. There is no in-between state
> where the target doesn't exist. (You can't get this for
> directories, incidentally.)
Unix does not guarantee this failure atomicity. Concurrency-atomicity
is guaranteed, though.
BSD-style Unixen do guarantee that a crash will never leave the inode
in a deleted state --- ie. a crash at an inopportune moment may leave
both the old and the new directory entry present, but the disk will
never see the old entry deleted before the new one is created.
Further, only on older Unix systems is the rename synchronous; you
can't rely on that these days.
ext3 does happen to guarantee that renames are 100% atomic, and they
can be made synchronous using either a sync attribute on the directory
or fsymc, but that's a special case and you can't rely on completely
atomic renames on Unix in general. You have to be able to cope with
both the old and new dirents existing after a crash.
Also, some of the more async Unix filesystems don't even guarantee
that relaxed form of failure atomicity, but you can always simulate
that by using a combination of link(2) and fsync(2).
> * fcntl() can create advisory locks on files, when the above two
> approaches aren't sufficient for concurrency atomicity. fcntl()
> locks are convenient because they are automatically cleaned up if
> the locking process dies or the machine reboots. You can also use
> it to do locking over subranges of a file.
> (Some of these guarantees degrade or disappear for remote filesystems,
> particularly some vintages of NFS. I don't know all the details
> there.)
I can help on the details if you want. Most NFS systems will offer
decent fcntl() locking these days, for example, and there are already
libraries in existance (used for things like mailbox locking) to
emulate NFS locking via atomic creation of temporary lock files on
those systems where fcntl() does not work.
Cheers,
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 8 23:47:18 2002