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

[Eli Zaretskii]

> Date: Sat, 02 Mar 2013 14:37:29 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 13807@debbugs.gnu.org
> 
> On 03/02/2013 01:17 PM, Eli Zaretskii wrote:
> > Can you describe your testing
> > in more details, and what versions of NFS and Windows did you use?
> 
> Sure, I created a MS-Windows style lock file .#FILE by hand, then
> edited FILE with a GNU/Linux Emacs.

But this is not a faithful reproduction of what happens when .#FILE is
created by Emacs running on Windows.  Because of the way Emacs on
Windows creates/opens this file, it is effectively inaccessible to any
other process, even _after_ the file is written and its handle closed.
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.)  And
that caused Emacs on GNU/Linux to refrain from locking the file.

In addition, 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?  There are no more
.#FILE.0 alternative names.

So I still don't see the reason for using different names on Windows
and Posix hosts.

> There's another issue: a GNU/Linux Emacs might be using an
> MS-Windows file system that does not support symbolic links.  Such
> an Emacs should use a regular-file lock, just as MS-Windows Emacs does,
> which means that the code to create regular-file locks should be implementable
> in POSIXish primitives.  Also, locking should work even if the Emacs
> instance that created a lock uses a symlink whereas the Emacs instance
> trying to get the lock would use a regular file, or vice versa.

But these issues are unrelated to the MS-Windows build of Emacs.  They
existed since about forever, and we never cared.  Why is it suddenly
so important that this feature works with 110% reliability, something
it never did?  Am I the only one who thinks we are way past the point
of diminishing returns here1?  Stefan?  Anyone?

> It'll take some thinking to get all this to work well.  I've written
> a first cut for this and have attached it.  I have not tested this
> on MS-Windows at all, and haven't tested it as much as I'd like on
> GNU/Linux, but it should give a feel for the sort of changes that
> need to be made.  Unfortunately the patch is a bit complicated,
> but to some extent this is inherent in such a complicated area.

I think we are wasting our time and energy here.  Nothing terrible
will happen if locking silently fails from time to time, as it always
did.  If we want, we could even optionally make these failures be
announced, by looking at the value lock_file returns, which we
currently ignore.

But if we do go in the direction you suggest, I think we will need to
provide two completely separate implementations for create_lock_file,
one for Posix, the other for MS-Windows.  This is because the
primitives you used in your suggested patch have problems on Windows:
'rename' is not atomic when it needs to delete the target (this is not
supported by the MS 'rename', so we emulate this in w32.c:sys_rename),
and hard links are only supported on NTFS, so editing files on FAT32
volumes (flash drives are normally formatted this way) will be unable
to lock files.  By contrast, using '_sopen', like I did in the current
code, really does make creation of the lock file atomic, and works
with any filesystem supported by Windows, including NFS-mounted
volumes.

So, unless there's a way to do on Posix platforms what '_sopen' does
on Windows (perhaps some file-locking feature? I don't know enough
about that), I think having 2 completely separate implementations will
be cleaner and more maintainable.  (Assuming, that is, that we really
do want to make file locking so bulletproof.)