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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 03 Mar 2013 15:56:03 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, 13807@debbugs.gnu.org
> 
> > 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.

Like it or not, it's out there, and others might bump into it.

> > 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.

I meant what you wrote here:

> 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.

These issues are unrelated to whether Emacs on Windows does or doesn't
lock files.  They existed before, as did the issue with FAT32 volumes
being used from Posix hosts.

And I think you exaggerate the probability of having Emacs running on
Windows to access via NFS files shared with Posix systems.  In my
experience, this is quite rare (as is having people use Emacs on
Windows in general).

> +      if (fd < 0)
> +	err = errno;
> +      else
> +	{
> +	  ptrdiff_t lock_info_len = strlen (lock_info_str);
> +	  err = 0;
> +	  if (emacs_write (fd, lock_info_str, lock_info_len) != lock_info_len
> +	      || fchmod (fd, S_IRUSR | S_IRGRP | S_IROTH) != 0)
> +	    err = errno;

This will need a no-op emulation of fchmod for Windows (since a file
created here will be world-writable anyway).  Other than that, I don't
see any problems with your changes (but I didn't try to build with
them, I only read them).

Thanks.