Re: Locking files for CLASH_DETECTION now supported on MS-Windows

[Paul Eggert <eggert@cs.ucla.edu>]

>>> We could avoid this by teaching Emacs on Posix systems to
>>> read lock files created by Emacs running on Windows.
>>
>> I don't see how to do this without introducing race
>> conditions that are not present in the current GNU/Linux
>> implementation.
> 
> Can you describe those race conditions?  I'm talking only about
> _reading_ those files, not about creating them.

Sorry, I must have misunderstood you.
There are no races if access is read-only.  We need at least one
writer (i.e., one process that's either creating or removing a
lock file) in order to have a race.  I thought the original
scenario involved an MS-Windows Emacs locking a file at about
the same time that a GNU/Linux Emacs locks the same file.

> The changes you are promoting cause Emacs to take control of any
> file whose name matches the pattern .#FILE, where FILE is the file we edit.

No, under that proposal, if there's an existing non-symlink
.#FILE then Emacs doesn't lock FILE; it simply bypasses
locking for FILE for entirely and it doesn't modify .#FILE
at all.  This should be relatively rare.

It is true that if there's an existing symlink .#FILE then Emacs
will take control of it when it edits FILE, but that should be OK.

>>> Another possibility would be to make Emacs running on Windows avoid
>>> locking files on remote filesystems.
>>
>> Won't there still be a problem if the local file system is
>> exported?
> 
> No, because such exported systems will not support symlinks from Posix
> hosts.

I thought that such symlinks were supported: the lock would appear to be a regular file
on the MS-Windows server side, but as exported over the network it would
appear to be a symbolic link on the GNU/Linux client side, as that's
how the Microsoft server software works.  If the MS-Windows
and GNU/Linux locks have the same name, they'd collide
I presume.

>> To move things forward, I propose that the MS-Windows
>> implementation use a different lock file name .#-FOO.
> 
> I don't mind, but I thought we could do better.

It's possible that we can do better, but I'm afraid that'll
take some work.  In the meantime I plan to go ahead with that
proposal as it's better than what we have now.