bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  ncaprisunfan@gmail.com,
>   49261@debbugs.gnu.org
> Date: Wed, 07 Jul 2021 20:08:48 +0200
> 
> While looking at this code, I'm puzzled by:
> 
> -  orig_fn = fn;
> -  fn = Fexpand_file_name (fn, Qnil);
> -#ifdef WINDOWSNT
> -  /* Ensure we have only '/' separators, to avoid problems with
> -     looking (inside fill_in_lock_file_name) for backslashes in file
> -     names encoded by some DBCS codepage.  */
> -  dostounix_filename (SSDATA (fn));
> -#endif
> -  encoded_fn = ENCODE_FILE (fn);
> -  if (create_lockfiles)
> -    /* Create the name of the lock-file for file fn */
> -    MAKE_LOCK_NAME (lfname, encoded_fn);
> -
> 
> So here we (possibly destructively) alter the data in the fn string on
> WINDOWSNT, because we want to avoid problems in fill_in_lock_file_name.
> OK, but we call MAKE_LOCK_NAME (which calls fill_in_lock_file_name) in
> two other places, and in those places the call isn't guarded by a call
> to dostounix_filename.
> 
> This is moot after my patch, since MAKE_LOCK_NAME is gone, but I'm still
> worried that there's something I don't understand here...  The
> dostounix_filename call was added by Eli in 2013.

It's a bug.  Or maybe it was a bug, back then, because I think
nowadays expand-file-name always converts backslashes to forward
slashes.  And actually the fact that MAKE_LOCK_NAME looks for slashes
in encoded file names is also a subtle bug (or at least unsafe code):
some coding-systems don't guarantee that a '/' byte can never be part
of a multibyte sequence.