GNU bug report logs - #70415
30.0.50; [Cygwin] `lock-file' creates a symlink with funny name

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: yamaoka <at> jpl.org, 70415 <at> debbugs.gnu.org
Subject: bug#70415: 30.0.50; [Cygwin] `lock-file' creates a symlink with funny name
Date: Sat, 04 May 2024 20:25:56 +0300

> Date: Sat, 4 May 2024 13:15:19 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> Cc: yamaoka <at> jpl.org, 70415 <at> debbugs.gnu.org
> 
> On 5/2/2024 10:26 AM, Ken Brown wrote:
> > On 5/2/2024 2:21 AM, Eli Zaretskii wrote:
> >>> Date: Wed, 1 May 2024 17:20:20 -0400
> >>> Cc: yamaoka <at> jpl.org, 70415 <at> debbugs.gnu.org
> >>> From: Ken Brown <kbrown <at> cornell.edu>
> >>>
> >>>>       char const *lock_info_fmt = (boot
> >>>>                  ? "%s@%s.%"PRIdMAX":%"PRIdMAX
> >>>>                  : "%s@%s.%"PRIdMAX);
> >>>>       int len = snprintf (lock_info_str, sizeof lock_info_str,
> >>>>             lock_info_fmt, user_name, host_name, pid, boot);
> >>>>
> >>>> get_boot_sec calls get_boot_time, which is a Gnulib function (see
> >>>> lib/boot-time.c).  So I guess the key to unlock this puzzle is
> >>>> somewhere there.
> >>>
> >>> I took a quick look at get_boot_time and found a bug, which may explain
> >>> why some Cygwin systems behave differently from others.  I've reported
> >>> it here:
> >>>
> >>>     https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00008.html
> >>
> >> Thanks.  This probably explains why the ":-NNNN" part sometimes
> >> appears and sometimes doesn't appear in Cygwin builds of Emacs, but
> >> AFAIU it does NOT explain why unlinking the symlink (when the file is
> >> unlocked) fails when the lock file name includes the ":-NNNN" part.
> >> Right?
> > 
> > Yes, that's right.  I still need to look into that.
> 
> It turns out that there was a Cygwin bug (already fixed in the Cygwin 
> development sources) that affected only version 3.5.3, and Bruno added a 
> workaround to Gnulib.  I now see the ":NNNN" part on my system, without 
> a minus sign, and the lock file is deleted properly.

Would you mind explaining for posterity (and for my personal
curiosity) how what Bruno changed affects the deletion of the lock
file?  Is that because the ":-NNNN" suffix had the dash (because the
system's page file was deemed to eb a directory)?  If so, how did the
presence of the dash cause the failure to delete the file?

Previous Next

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