Re: FAQ 5.20 Why can't I just open(FH, ">file.lock")?

Purl Gurl wrote:

> Lars Kellogg-Stedman wrote:

> > Semaphore locking is certainly useful, but there are ways of
> > implementing it that are less prone to race conditions (for example,
> > using a "flag directory" instead of a "flag file", since in many cases
> > directory creation is atomic -- unlike touching a file, which will
> > happily succeed for multiple processes).

Which reminds me.

Your directory method is a little known method. It has been a longtime
since I read comments about employing a directory as a file lock.

My personal reminder is two or three years back I afforded this group
two methods for Win32 file locking, other than semaphore. However,
semaphore is the easiest to implement.

One method of Win32 file locking employs a compiled C binary,
the other is a hack which assigns a read only attribute to allow
reading but not writing. While locked, DOS xcopy can be used
to defeat the read only attribute. When finished, the read only
attribute is removed.

Again, semaphore locking should be the first choice being simple
and efficient. For "mission critical" locking, then a binary or a
secure read only method should be used, for Win32.

I am sitting in front of new XP Pro dual processor machine and
am wondering if extensive XP security could be used as a hack
for yet another way to lock a Win32 file; change the file owner
or turn off file sharing for web applications.

For those interested, about middle of that page for Win32 lock hacks.

Purl Gurl