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: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
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, 4 May 2024 13:46:33 -0400

On 5/4/2024 1:26 PM, Eli Zaretskii wrote:
>> 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?

Not only was the system's page file deemed to be a directory, but it was 
deemed to have a negative modification time.  I think that's where the 
dash came from.  But I don't know why that prevented the lock file from 
being deleted.  I fully expected to have to debug that problem after 
applying Bruno's patches, and it seemed like a miracle that I didn't 
have to.  I might still have to debug further if Katsumi reports that 
the problem isn't fixed for him.

Ken

Previous Next

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