GNU bug report logs - #49261
28.0.50; File Locking Breaks Presumptuous Toolchains

Previous Next

Full log

Message #74 received at 49261 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains
Date: Wed, 07 Jul 2021 20:08:48 +0200

[Message part 1 (text/plain, inline)]

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.

So I think I'll wait to push this patch until Eli has given it a
once-over.  I've included the current state of the patch below as an
attachment.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

[lock.patch (text/x-diff, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.