I'm working on the design of a Subversion filesystem back end which
maps directly to the underlying filesystem, instead of going through a
key/value or SQL database. (I don't want to actually discuss the
design here until after Subversion 1.0 is close to finished, to avoid
taking time away from people working on more important stuff. Also,
it might take me a while to complete the design, or I might lose
steam.) It would be nice if the back end could work and be robust
under Windows as well as Unix. I need some information about
atomicity under Windows to inform the design in this respect.
On Unix, you have some basic tools available for local filesystems:
* fsync() provides the basics of failure atomicity by guaranteeing
that a file's contents have been flushed to disk. (With some
fileystems, you may also have to fsync() directories in order to
make sure that directory entries are flushed to disk; with others,
fsync()ing a file guarantees that all paths referencing the file
have been flushed.)
* 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.)
* open() with the O_CREAT|O_EXCL flags will fail if the file already
exists; you can use this to create unique files or do rudimentary
locking.
* 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.)
My question is: which of these tools have equivalents or analogs under
Windows, and which don't? And are there fundamentally different tools
you have to use instead?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 8 21:35:01 2002