Greg Hudson wrote:
>
> 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.)
The dwFlagsAndAttributes parameter in CreateFile() can have a value of
FILE_FLAG_WRITE_THROUGH which urges the system to go directly to disk.
Note that CreateFile() does much more things than _creating_ files. :)
HANDLE CreateFile(
LPCTSTR lpFileName, // file name
DWORD dwDesiredAccess, // access mode
DWORD dwShareMode, // share mode
LPSECURITY_ATTRIBUTES lpSecurityAttributes, // SD
DWORD dwCreationDisposition, // how to create
DWORD dwFlagsAndAttributes, // file attributes
HANDLE hTemplateFile // handle to template file
);
>
> * 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.)
BOOL MoveFileEx(
LPCTSTR lpExistingFileName, // file name
LPCTSTR lpNewFileName, // new file name
DWORD dwFlags // move options
);
If you specify MOVEFILE_REPLACE_EXISTING in the flags, this function
will act like the UNIX rename().
MOVEFILE_WRITE_THROUGH - the function will return only after the file
has actually been moved on the disk.
However there is a rename() function under Windows too, but I couldn't
find anything about its atomicity in MSDN.
>
> * 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.
CreateFile has a tone of options and flags and dwCreationDisposition can
have the following values:
CREATE_NEW
CREATE_ALWAYS
OPEN_EXISTING
OPEN_ALWAYS
TRUNCATE_EXISTING.
>
> * 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.
From MSDN:
LockFile function locks a region in an open file.
BOOL LockFile(
HANDLE hFile, // handle to file
DWORD dwFileOffsetLow, // low-order word of offset
DWORD dwFileOffsetHigh, // high-order word of offset
DWORD nNumberOfBytesToLockLow, // low-order word of length
DWORD nNumberOfBytesToLockHigh // high-order word of length
);
LockFileEx function locks a region in an open file for shared or
exclusive access.
BOOL LockFileEx(
HANDLE hFile, // handle to file
DWORD dwFlags, // lock options
DWORD dwReserved, // reserved
DWORD nNumberOfBytesToLockLow, // low-order word of length
DWORD nNumberOfBytesToLockHigh, // high-order word of length
LPOVERLAPPED lpOverlapped // contains starting offset
);
Of course, there are also UnlockFile() and UnlockFileEx().
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 8 22:51:21 2002