bug#13807: updated version to avoid MS-Windows vs non-MS-Windows clashes

[Paul Eggert]

On 03/03/2013 08:39 AM, Eli Zaretskii wrote:

> the primitives you used in your suggested patch have problems on Windows:
> 'rename' is not atomic when it needs to delete the target ...
> and hard links are only supported on NTFS

Thanks for mentioning these problems.  The latter issue
affects GNU/Linux, too, since it also can mount FAT32 file
systems.  Attached is a revised patch that tries to address
these problems.

> My testing indicates that 'readdir' does return the file's name, but
> every other system call I tried, including even 'lstat', fails with
> EPERM.  (I don't know whether all NFS servers behave that way.)

They don't.  Traditional NFS servers are stateless, and do
not have a state where a file exists and its parent
directory is accessible but you cannot stat the file.  I'd
even call that behavior a bug: file servers with that
behavior will cause problems with many GNU programs,
including Emacs.  It would not be wise for Emacs to rely on
or encourage that behavior.

> with the changes you installed, I think even if .#FILE
> _can_ be accessed, Emacs on a Posix host will refrain from
> locking it, because 'readlink' will fail for it, right?

That's correct: the existence of a regular-file .#FILE
prevents Emacs from locking FILE, and Emacs goes ahead and
accesses FILE without bothering to lock it.  The assumption
is that .#FILE was created for some other reason and should
not be messed with.

> these issues are unrelated to the MS-Windows build of Emacs.

I don't see why they're unrelated.  If an MS-Windows Emacs
uses regular files for locks, these files get in the way of
GNU/Linux Emacs lock files, and that makes these issues pop up.

> They existed since about forever, and we never cared.
> Why is it suddenly so important that this feature works

It's important because the MS-Windows code was recently
changed to create lock files, the existence of which could
break GNU/Linux Emacs's locking.

> with 110% reliability, something it never did?

Even with the attached patch, lock files are not 100%
reliable.  The main point of my patches have been to prevent
lock files from being significantly less reliable than they
already were.  If we easily can make them more
reliable, so much the better, but that's not the main goal.

filelock2.txt
Description: Text document