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

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

[Katsumi Yamaoka]

Hi,

As you know, Emacs creates a lock file when start editing a FILE
by default, it is a symbolic link that is linked to a name
looking like this:

.#FILE -> username@hostname.1234

Where 1234 is Emacs' pid.  It will be removed after saving
the FILE.  Even if the lock file is left, Emacs will remove it
when opening the FILE for the next time.  However, recently lock
files no longer got deleted on at least the latest Cygwin on
Windows 11.  It is (probably) because Emacs came to create lock
files with a funny name like this:

.#FILE -> username@hostname.1234:-11644473599

For that case `(unlock-file "FILE")' issues this warning:

Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored

I don't know what ":-11644473599" is, but I did the bisection
and found that it started with this change:

,----
| commit 393f58c85aeb78f814866ccaad9ae7efd3fa6766
| Author: Adam Porter <adam@alphapapa.net>
| Date:   Fri Mar 8 23:43:14 2024 -0600
|
|     'vtable-update-object' can now be called with one argument
|
|     It's often necessary to update the representation of a single
|     object in a table (e.g a struct, whose identity does not change
|     when its slots'
|     values are changed).  To do so, now the function may be called
|     like this:
|
|       (vtable-update-object table object)
|
|     Instead of like this:
|
|       (vtable-update-object table object object)
|
|     This also documents the behavior of the just-discovered limitation filed
|     as bug#69837.
|     * lisp/emacs-lisp/vtable.el (vtable-update-object): Make 'old-object'
|     argument optional.  (Bug#69666)
|
|     * doc/misc/vtable.texi (Interface Functions): Update documentation.
|
|     * etc/NEWS: Add news entry.
|
| commit 689f04a2ddfae856153bed762cc1461d66ec88de
| [...]
`----

Though it doesn't seem helpful since `git diff 689f04a..393f58c'
reports a huge amount of diff.  Hmm.

Thanks in advance.
Regards,


In GNU Emacs 30.0.50 (build 1, x86_64-pc-cygwin, GTK+ Version
 3.24.41, cairo version 1.17.4) of 2024-04-15 built on localhost
Windowing system distributor 'The Cygwin/X Project', version 11.0.12101012

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

[Eli Zaretskii]

> Date: Tue, 16 Apr 2024 21:33:07 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> 
> As you know, Emacs creates a lock file when start editing a FILE
> by default, it is a symbolic link that is linked to a name
> looking like this:
> 
> .#FILE -> username@hostname.1234
> 
> Where 1234 is Emacs' pid.  It will be removed after saving
> the FILE.  Even if the lock file is left, Emacs will remove it
> when opening the FILE for the next time.  However, recently lock
> files no longer got deleted on at least the latest Cygwin on
> Windows 11.  It is (probably) because Emacs came to create lock
> files with a funny name like this:
> 
> .#FILE -> username@hostname.1234:-11644473599
> 
> For that case `(unlock-file "FILE")' issues this warning:
> 
> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored

Does Cygwin support file names with a colon, such as the above?

The part after the colon is the system boot time, and is used on all
Posix hosts.  I don't know why it prints as a negative value on
Cygwin, but the question is: does Cygwin support such file names?  If
not, what are the restrictions on Cygwin file names that we need to
observe when we create lock files?  This is likely a question for the
Cygwin mailing list, or maybe you already know the answer.

Several internal functions in filelock.c know about the
USER@HOST.PID:BOOT_TIME format of the lock file names, so if there are
any Cygwin-specific restrictions, they will all need to be patched
accordingly.

> I don't know what ":-11644473599" is, but I did the bisection
> and found that it started with this change:
> 
> ,----
> | commit 393f58c85aeb78f814866ccaad9ae7efd3fa6766
> | Author: Adam Porter <adam@alphapapa.net>
> | Date:   Fri Mar 8 23:43:14 2024 -0600
> |
> |     'vtable-update-object' can now be called with one argument

This is extremely unlikely to have caused the problem.  It is more
likely that some change in Cygwin and/or in the Gnulib's boot-time
module causes this now.

Also, do you see this in "emacs -Q"?  If not, perhaps some local
customizations cause this?

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

[Pierre Téchoueyres]

Le mardi 16 avril 2024 à 16:32, Eli Zaretskii <eliz@gnu.org> a écrit :

>> Date: Tue, 16 Apr 2024 21:33:07 +0900
>> From: Katsumi Yamaoka <yamaoka@jpl.org>
>> 
>> As you know, Emacs creates a lock file when start editing a FILE
>> by default, it is a symbolic link that is linked to a name
>> looking like this:
>> 
>> .#FILE -> username@hostname.1234
>> 
>> Where 1234 is Emacs' pid.  It will be removed after saving
>> the FILE.  Even if the lock file is left, Emacs will remove it
>> when opening the FILE for the next time.  However, recently lock
>> files no longer got deleted on at least the latest Cygwin on
>> Windows 11.  It is (probably) because Emacs came to create lock
>> files with a funny name like this:
>> 
>> .#FILE -> username@hostname.1234:-11644473599
>> 
>> For that case `(unlock-file "FILE")' issues this warning:
>> 
>> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored
>
> Does Cygwin support file names with a colon, such as the above?
>
> The part after the colon is the system boot time, and is used on all
> Posix hosts.  I don't know why it prints as a negative value on
> Cygwin, but the question is: does Cygwin support such file names?  If
> not, what are the restrictions on Cygwin file names that we need to
> observe when we create lock files?  This is likely a question for the
> Cygwin mailing list, or maybe you already know the answer.
>
> Several internal functions in filelock.c know about the
> USER@HOST.PID:BOOT_TIME format of the lock file names, so if there are
> any Cygwin-specific restrictions, they will all need to be patched
> accordingly.
>

May be this has something to do with NTFS Streams ?
See : https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3

Disregard if not relevant.

>> I don't know what ":-11644473599" is, but I did the bisection
>> and found that it started with this change:
>> 
>> ,----
>> | commit 393f58c85aeb78f814866ccaad9ae7efd3fa6766
>> | Author: Adam Porter <adam@alphapapa.net>
>> | Date:   Fri Mar 8 23:43:14 2024 -0600
>> |
>> |     'vtable-update-object' can now be called with one argument
>
> This is extremely unlikely to have caused the problem.  It is more
> likely that some change in Cygwin and/or in the Gnulib's boot-time
> module causes this now.
>
> Also, do you see this in "emacs -Q"?  If not, perhaps some local
> customizations cause this?
>

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

[Ken Brown]

On 4/16/2024 9:32 AM, Eli Zaretskii wrote:
>> Date: Tue, 16 Apr 2024 21:33:07 +0900
>> From: Katsumi Yamaoka <yamaoka@jpl.org>
>>
>> As you know, Emacs creates a lock file when start editing a FILE
>> by default, it is a symbolic link that is linked to a name
>> looking like this:
>>
>> .#FILE -> username@hostname.1234
>>
>> Where 1234 is Emacs' pid.  It will be removed after saving
>> the FILE.  Even if the lock file is left, Emacs will remove it
>> when opening the FILE for the next time.  However, recently lock
>> files no longer got deleted on at least the latest Cygwin on
>> Windows 11.  It is (probably) because Emacs came to create lock
>> files with a funny name like this:
>>
>> .#FILE -> username@hostname.1234:-11644473599
>>
>> For that case `(unlock-file "FILE")' issues this warning:
>>
>> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored
> 
> Does Cygwin support file names with a colon, such as the above?

I'm traveling at the moment, and it will be a while until I have a 
chance to look at this report closely or try to reproduce it.  But I can 
answer your question: Cygwin does support file names with a colon.  This 
is documented at

   https://cygwin.com/cygwin-ug-net/using-specialnames.html

Ken

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

[Eli Zaretskii]

> Date: Tue, 16 Apr 2024 18:57:21 -0400
> Cc: 70415@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> 
> On 4/16/2024 9:32 AM, Eli Zaretskii wrote:
> >> Date: Tue, 16 Apr 2024 21:33:07 +0900
> >> From: Katsumi Yamaoka <yamaoka@jpl.org>
> >>
> >> As you know, Emacs creates a lock file when start editing a FILE
> >> by default, it is a symbolic link that is linked to a name
> >> looking like this:
> >>
> >> .#FILE -> username@hostname.1234
> >>
> >> Where 1234 is Emacs' pid.  It will be removed after saving
> >> the FILE.  Even if the lock file is left, Emacs will remove it
> >> when opening the FILE for the next time.  However, recently lock
> >> files no longer got deleted on at least the latest Cygwin on
> >> Windows 11.  It is (probably) because Emacs came to create lock
> >> files with a funny name like this:
> >>
> >> .#FILE -> username@hostname.1234:-11644473599
> >>
> >> For that case `(unlock-file "FILE")' issues this warning:
> >>
> >> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored
> > 
> > Does Cygwin support file names with a colon, such as the above?
> 
> I'm traveling at the moment, and it will be a while until I have a 
> chance to look at this report closely or try to reproduce it.  But I can 
> answer your question: Cygwin does support file names with a colon.  This 
> is documented at
> 
>    https://cygwin.com/cygwin-ug-net/using-specialnames.html

That's what I thought.  But in that case, someone will have to step
through the code in filelock.c and tell why removing these lock files
fails in the Cygwin build of Emacs.

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

[Katsumi Yamaoka]

On Tue, 16 Apr 2024 16:32:17 +0300, Eli Zaretskii wrote:
>> .#FILE -> username@hostname.1234:-11644473599
>> For that case `(unlock-file "FILE")' issues this warning:
>> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored

> The part after the colon is the system boot time, and is used on all
> Posix hosts.

Oh, I had never seen it until recently.  Thanks.

[...]

>>| commit 393f58c85aeb78f814866ccaad9ae7efd3fa6766
>>| Author: Adam Porter <adam@alphapapa.net>
>>| Date:   Fri Mar 8 23:43:14 2024 -0600

> This is extremely unlikely to have caused the problem.  It is more
> likely that some change in Cygwin and/or in the Gnulib's boot-time
> module causes this now.

Indeed.  But the fact is that Emacs built with that revno adds
a colon and a negative number to a link name and the one built
with just before it does not.  No problem on 29.3.50 and earlier,
either (i.e., not add a colon and numbers).

> Also, do you see this in "emacs -Q"?  If not, perhaps some local
> customizations cause this?

Yes, I use -Q for the test.

;; I need to alter the default value of `create-lockfiles' in
;; src/filelock.c to build Emacs from git master nowadays.

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

[Eli Zaretskii]

> Date: Wed, 17 Apr 2024 08:58:42 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: 70415@debbugs.gnu.org
> 
> On Tue, 16 Apr 2024 16:32:17 +0300, Eli Zaretskii wrote:
> >> .#FILE -> username@hostname.1234:-11644473599
> >> For that case `(unlock-file "FILE")' issues this warning:
> >> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored
> 
> > The part after the colon is the system boot time, and is used on all
> > Posix hosts.
> 
> Oh, I had never seen it until recently.  Thanks.

The question is: why it started appearing only recently?  The code in
filelock.c hasn't changed since last December, if not earlier, so if
this started happening recently, it could only be because Gnulib's
get_boot_time or its Cygwin implementation changed, such that it was
previously returning zero whereas now it returns non-zero (which
triggers the addition of the ":BOOT_TIME" part to the file name).

> >>| commit 393f58c85aeb78f814866ccaad9ae7efd3fa6766
> >>| Author: Adam Porter <adam@alphapapa.net>
> >>| Date:   Fri Mar 8 23:43:14 2024 -0600
> 
> > This is extremely unlikely to have caused the problem.  It is more
> > likely that some change in Cygwin and/or in the Gnulib's boot-time
> > module causes this now.
> 
> Indeed.  But the fact is that Emacs built with that revno adds
> a colon and a negative number to a link name and the one built
> with just before it does not.  No problem on 29.3.50 and earlier,
> either (i.e., not add a colon and numbers).

Then please step with a debugger through the relevant code in
filelock.c, before and after that change, and see why they are
different.  I cannot explain that, even after doing "git log -L" on
all of filelock.c: the most recent change of the related code was in
Aug 2023, AFAICT, which is a very far cry from Mar 2024.

And even if we understand why you now get the ":BOOT_TIME" part,
there's still the question why it cannot be unlinked, if Cygwin
supports file names with a colon.  Maybe it's because Emacs creates a
symlink, and symlinks with such names are not supported by Cygwin?

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

[Ken Brown]

On 4/17/2024 8:21 AM, Eli Zaretskii wrote:
>> Date: Wed, 17 Apr 2024 08:58:42 +0900
>> From: Katsumi Yamaoka <yamaoka@jpl.org>
>> Cc: 70415@debbugs.gnu.org
>>
>> On Tue, 16 Apr 2024 16:32:17 +0300, Eli Zaretskii wrote:
>>>> .#FILE -> username@hostname.1234:-11644473599
>>>> For that case `(unlock-file "FILE")' issues this warning:
>>>> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored
>>
>>> The part after the colon is the system boot time, and is used on all
>>> Posix hosts.
>>
>> Oh, I had never seen it until recently.  Thanks.
> 
> The question is: why it started appearing only recently?  The code in
> filelock.c hasn't changed since last December, if not earlier, so if
> this started happening recently, it could only be because Gnulib's
> get_boot_time or its Cygwin implementation changed, such that it was
> previously returning zero whereas now it returns non-zero (which
> triggers the addition of the ":BOOT_TIME" part to the file name).
> 
>>>> | commit 393f58c85aeb78f814866ccaad9ae7efd3fa6766
>>>> | Author: Adam Porter <adam@alphapapa.net>
>>>> | Date:   Fri Mar 8 23:43:14 2024 -0600
>>
>>> This is extremely unlikely to have caused the problem.  It is more
>>> likely that some change in Cygwin and/or in the Gnulib's boot-time
>>> module causes this now.
>>
>> Indeed.  But the fact is that Emacs built with that revno adds
>> a colon and a negative number to a link name and the one built
>> with just before it does not.  No problem on 29.3.50 and earlier,
>> either (i.e., not add a colon and numbers).
> 
> Then please step with a debugger through the relevant code in
> filelock.c, before and after that change, and see why they are
> different.  I cannot explain that, even after doing "git log -L" on
> all of filelock.c: the most recent change of the related code was in
> Aug 2023, AFAICT, which is a very far cry from Mar 2024.
> 
> And even if we understand why you now get the ":BOOT_TIME" part,
> there's still the question why it cannot be unlinked, if Cygwin
> supports file names with a colon.  Maybe it's because Emacs creates a
> symlink, and symlinks with such names are not supported by Cygwin?

I'm still traveling for another week and won't have time to try to 
reproduce and debug this until I return.  But I did do one quick test in 
a Cygwin shell.  I created a symlink

   .#FILE -> username@hostname.1234:-11644473599

and deleted it with rm.  So symlinks like this are indeed supported by 
Cygwin.

To be continued...

Ken

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

[Ken Brown]

On 4/22/2024 12:15 PM, Ken Brown wrote:
> On 4/17/2024 8:21 AM, Eli Zaretskii wrote:
>>> Date: Wed, 17 Apr 2024 08:58:42 +0900
>>> From: Katsumi Yamaoka <yamaoka@jpl.org>
>>> Cc: 70415@debbugs.gnu.org
>>>
>>> On Tue, 16 Apr 2024 16:32:17 +0300, Eli Zaretskii wrote:
>>>>> .#FILE -> username@hostname.1234:-11644473599
>>>>> For that case `(unlock-file "FILE")' issues this warning:
>>>>> Warning (unlock-file): Unlocking file: Invalid argument, FILE, ignored
>>>
>>>> The part after the colon is the system boot time, and is used on all
>>>> Posix hosts.
>>>
>>> Oh, I had never seen it until recently.  Thanks.
>>
>> The question is: why it started appearing only recently?  The code in
>> filelock.c hasn't changed since last December, if not earlier, so if
>> this started happening recently, it could only be because Gnulib's
>> get_boot_time or its Cygwin implementation changed, such that it was
>> previously returning zero whereas now it returns non-zero (which
>> triggers the addition of the ":BOOT_TIME" part to the file name).
>>
>>>>> | commit 393f58c85aeb78f814866ccaad9ae7efd3fa6766
>>>>> | Author: Adam Porter <adam@alphapapa.net>
>>>>> | Date:   Fri Mar 8 23:43:14 2024 -0600
>>>
>>>> This is extremely unlikely to have caused the problem.  It is more
>>>> likely that some change in Cygwin and/or in the Gnulib's boot-time
>>>> module causes this now.
>>>
>>> Indeed.  But the fact is that Emacs built with that revno adds
>>> a colon and a negative number to a link name and the one built
>>> with just before it does not.  No problem on 29.3.50 and earlier,
>>> either (i.e., not add a colon and numbers).
>>
>> Then please step with a debugger through the relevant code in
>> filelock.c, before and after that change, and see why they are
>> different.  I cannot explain that, even after doing "git log -L" on
>> all of filelock.c: the most recent change of the related code was in
>> Aug 2023, AFAICT, which is a very far cry from Mar 2024.
>>
>> And even if we understand why you now get the ":BOOT_TIME" part,
>> there's still the question why it cannot be unlinked, if Cygwin
>> supports file names with a colon.  Maybe it's because Emacs creates a
>> symlink, and symlinks with such names are not supported by Cygwin?
> 
> I'm still traveling for another week and won't have time to try to 
> reproduce and debug this until I return.  But I did do one quick test in 
> a Cygwin shell.  I created a symlink
> 
>    .#FILE -> username@hostname.1234:-11644473599
> 
> and deleted it with rm.  So symlinks like this are indeed supported by 
> Cygwin.
> 
> To be continued...

I finally had a chance to look at this, and I can't reproduce the 
problem.  The autosave file does not have the ":BOOT_TIME" part, and it 
gets deleted properly when the file is saved.  I'm running the latest 
stable release of Cygwin (3.5.3) on Windows 11 (version 23H2, build 
22631.3447).

Ken

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

[Eli Zaretskii]

> Date: Mon, 29 Apr 2024 19:05:35 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: 70415@debbugs.gnu.org
> 
> I finally had a chance to look at this, and I can't reproduce the 
> problem.  The autosave file does not have the ":BOOT_TIME" part, and it 
> gets deleted properly when the file is saved.  I'm running the latest 
> stable release of Cygwin (3.5.3) on Windows 11 (version 23H2, build 
> 22631.3447).

This is not about autosave files, this is about lock files.  Those are
created once you modify a file-visiting buffer.

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

[Katsumi Yamaoka]

On Tue, 30 Apr 2024 05:34:25 +0300, Eli Zaretskii wrote:
>> Date: Mon, 29 Apr 2024 19:05:35 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> Cc: 70415@debbugs.gnu.org

>> I finally had a chance to look at this, and I can't reproduce the 
>> problem.  The autosave file does not have the ":BOOT_TIME" part, and it 
>> gets deleted properly when the file is saved.  I'm running the latest 
>> stable release of Cygwin (3.5.3) on Windows 11 (version 23H2, build 
>> 22631.3447).

> This is not about autosave files, this is about lock files.  Those are
> created once you modify a file-visiting buffer.

Thank you for following this up.  I also found another PC in which
Emacs that was built there has no problem (i.e., the boot-time
part does not appear in a lock file symlink name).
Both that PC [B] and the PC I normally use [A] run the latest Cygwin
3.5.3-1 on Windows 11 23H2.  Though I haven't found out the cause
of [A] yet, I should check the differences between them one by one.

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

[Ken Brown]

On 4/29/2024 10:34 PM, Eli Zaretskii wrote:
>> Date: Mon, 29 Apr 2024 19:05:35 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> Cc: 70415@debbugs.gnu.org
>>
>> I finally had a chance to look at this, and I can't reproduce the
>> problem.  The autosave file does not have the ":BOOT_TIME" part, and it
>> gets deleted properly when the file is saved.  I'm running the latest
>> stable release of Cygwin (3.5.3) on Windows 11 (version 23H2, build
>> 22631.3447).
> 
> This is not about autosave files, this is about lock files.  Those are
> created once you modify a file-visiting buffer.

Sorry, I didn't write what I meant.  I meant to refer to the lock file.

Ken

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

[Eli Zaretskii]

> Date: Tue, 30 Apr 2024 11:23:21 -0400
> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> 
> On 4/29/2024 10:34 PM, Eli Zaretskii wrote:
> >> Date: Mon, 29 Apr 2024 19:05:35 -0400
> >> From: Ken Brown <kbrown@cornell.edu>
> >> Cc: 70415@debbugs.gnu.org
> >>
> >> I finally had a chance to look at this, and I can't reproduce the
> >> problem.  The autosave file does not have the ":BOOT_TIME" part, and it
> >> gets deleted properly when the file is saved.  I'm running the latest
> >> stable release of Cygwin (3.5.3) on Windows 11 (version 23H2, build
> >> 22631.3447).
> > 
> > This is not about autosave files, this is about lock files.  Those are
> > created once you modify a file-visiting buffer.
> 
> Sorry, I didn't write what I meant.  I meant to refer to the lock file.

OK.  So it sounds like on some Cygwin systems this call in filelock.c:

  static int
  lock_file_1 (Lisp_Object lfname, bool force)
  {
    intmax_t boot = get_boot_sec ();

yields a non-zero (and negative!) value of 'boot', and on other Cygwin
systems it yields zero.  Because that's how Emacs decides whether to
append that ":-NNNN" part:

    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.

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

[Ken Brown]

On 4/30/2024 12:20 PM, Eli Zaretskii wrote:
>> Date: Tue, 30 Apr 2024 11:23:21 -0400
>> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>>
>> On 4/29/2024 10:34 PM, Eli Zaretskii wrote:
>>>> Date: Mon, 29 Apr 2024 19:05:35 -0400
>>>> From: Ken Brown <kbrown@cornell.edu>
>>>> Cc: 70415@debbugs.gnu.org
>>>>
>>>> I finally had a chance to look at this, and I can't reproduce the
>>>> problem.  The autosave file does not have the ":BOOT_TIME" part, and it
>>>> gets deleted properly when the file is saved.  I'm running the latest
>>>> stable release of Cygwin (3.5.3) on Windows 11 (version 23H2, build
>>>> 22631.3447).
>>>
>>> This is not about autosave files, this is about lock files.  Those are
>>> created once you modify a file-visiting buffer.
>>
>> Sorry, I didn't write what I meant.  I meant to refer to the lock file.
> 
> OK.  So it sounds like on some Cygwin systems this call in filelock.c:
> 
>    static int
>    lock_file_1 (Lisp_Object lfname, bool force)
>    {
>      intmax_t boot = get_boot_sec ();
> 
> yields a non-zero (and negative!) value of 'boot', and on other Cygwin
> systems it yields zero.  Because that's how Emacs decides whether to
> append that ":-NNNN" part:
> 
>      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

Ken

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

[Eli Zaretskii]

> Date: Wed, 1 May 2024 17:20:20 -0400
> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
> From: Ken Brown <kbrown@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?

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

[Ken Brown]

On 5/2/2024 2:21 AM, Eli Zaretskii wrote:
>> Date: Wed, 1 May 2024 17:20:20 -0400
>> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
>> From: Ken Brown <kbrown@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.

Ken

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

[Ken Brown]

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@jpl.org, 70415@debbugs.gnu.org
>>> From: Ken Brown <kbrown@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.

Katsumi, can you apply Bruno's two patches and confirm that the bug is 
fixed?

Ken

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

[Eli Zaretskii]

> Date: Sat, 4 May 2024 13:15:19 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: yamaoka@jpl.org, 70415@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@jpl.org, 70415@debbugs.gnu.org
> >>> From: Ken Brown <kbrown@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?

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

[Ken Brown]

On 5/4/2024 1:26 PM, Eli Zaretskii wrote:
>> Date: Sat, 4 May 2024 13:15:19 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> Cc: yamaoka@jpl.org, 70415@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@jpl.org, 70415@debbugs.gnu.org
>>>>> From: Ken Brown <kbrown@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

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

[Ken Brown]

On 5/4/2024 1:46 PM, Ken Brown wrote:
> On 5/4/2024 1:26 PM, Eli Zaretskii wrote:
>> 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 found the answer: filelock.c:current_lock_owner returns an error if 
the colon exists and is not followed by a digit.  See filelock.c:421.

Ken

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

[Eli Zaretskii]

> Date: Sat, 4 May 2024 18:01:25 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
> 
> > 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 found the answer: filelock.c:current_lock_owner returns an error if 
> the colon exists and is not followed by a digit.  See filelock.c:421.

Right.  Does the below look like the right change to support such
weird cases?

diff --git a/src/filelock.c b/src/filelock.c
index 01d35c4..86c6eeb 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -419,7 +419,9 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
       boot += 2;
       FALLTHROUGH;
     case ':':
-      if (! c_isdigit (boot[0]))
+      if (! c_isdigit (boot[0])
+	  /* A negative number.  */
+	  || (boot[0] == '-' && c_isdigit (boot[1])))
 	return EINVAL;
       boot_time = strtoimax (boot, &lfinfo_end, 10);
       break;

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

[Ken Brown]

On 5/5/2024 1:40 AM, Eli Zaretskii wrote:
> Right.  Does the below look like the right change to support such
> weird cases?
> 
> diff --git a/src/filelock.c b/src/filelock.c
> index 01d35c4..86c6eeb 100644
> --- a/src/filelock.c
> +++ b/src/filelock.c
> @@ -419,7 +419,9 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
>         boot += 2;
>         FALLTHROUGH;
>       case ':':
> -      if (! c_isdigit (boot[0]))
> +      if (! c_isdigit (boot[0])
> +	  /* A negative number.  */
> +	  || (boot[0] == '-' && c_isdigit (boot[1])))
>   	return EINVAL;
>         boot_time = strtoimax (boot, &lfinfo_end, 10);
>         break;

Not quite.  I think it should be

diff --git a/src/filelock.c b/src/filelock.c
index 01d35c46726a..faa85a56628b 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -419,7 +419,9 @@ current_lock_owner (lock_info_type *owner, 
Lisp_Object lfname)
        boot += 2;
        FALLTHROUGH;
      case ':':
-      if (! c_isdigit (boot[0]))
+      if (! (c_isdigit (boot[0])
+             /* A negative number.  */
+             || (boot[0] == '-' && c_isdigit (boot[1]))))
         return EINVAL;
        boot_time = strtoimax (boot, &lfinfo_end, 10);
        break;

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

[Eli Zaretskii]

> Date: Sun, 5 May 2024 12:21:03 -0400
> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> 
> On 5/5/2024 1:40 AM, Eli Zaretskii wrote:
> > Right.  Does the below look like the right change to support such
> > weird cases?
> > 
> > diff --git a/src/filelock.c b/src/filelock.c
> > index 01d35c4..86c6eeb 100644
> > --- a/src/filelock.c
> > +++ b/src/filelock.c
> > @@ -419,7 +419,9 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
> >         boot += 2;
> >         FALLTHROUGH;
> >       case ':':
> > -      if (! c_isdigit (boot[0]))
> > +      if (! c_isdigit (boot[0])
> > +	  /* A negative number.  */
> > +	  || (boot[0] == '-' && c_isdigit (boot[1])))
> >   	return EINVAL;
> >         boot_time = strtoimax (boot, &lfinfo_end, 10);
> >         break;
> 
> Not quite.  I think it should be

Right, thanks.  Now installed on master, and I think we can close this
bug?

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

[Ken Brown]

On 5/5/2024 12:32 PM, Eli Zaretskii wrote:
> Right, thanks.  Now installed on master, and I think we can close this
> bug?

Yes, closing.

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

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Ken Brown <kbrown@cornell.edu> writes:

> On 5/5/2024 12:32 PM, Eli Zaretskii wrote:
>> Right, thanks.  Now installed on master, and I think we can close this
>> bug?
>
> Yes, closing.

FTR, I've fixed this also in Tramp. Commit 6f16ef1c04c.

Best regards, Michael.

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

[Katsumi Yamaoka]

On Sun, 05 May 2024 13:02:27 -0400, Ken Brown wrote:
> Yes, closing.

Sorry for my late response but Emacs now works with a lock file
symlink of which the name contains a negative boot-time value.
Thanks a lot!

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

[Ken Brown]

On 5/4/2024 1:15 PM, Ken Brown wrote:
> 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@jpl.org, 70415@debbugs.gnu.org
>>>> From: Ken Brown <kbrown@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.
> 
> Katsumi, can you apply Bruno's two patches and confirm that the bug is 
> fixed?

By the way, you'll have to touch lib/boot-time.c before rebuilding, 
because the dependence of the latter on lib/boot-time-aux.h is not 
detected by the build system.

Ken

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

[Eli Zaretskii]

> Date: Sat, 4 May 2024 13:30:12 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
> 
> By the way, you'll have to touch lib/boot-time.c before rebuilding, 
> because the dependence of the latter on lib/boot-time-aux.h is not 
> detected by the build system.

It is detected here, I see it in lib/deps/boot-time.d, FWIW.

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

[Ken Brown]

On 5/4/2024 1:37 PM, Eli Zaretskii wrote:
>> Date: Sat, 4 May 2024 13:30:12 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> Cc: yamaoka@jpl.org, 70415@debbugs.gnu.org
>>
>> By the way, you'll have to touch lib/boot-time.c before rebuilding,
>> because the dependence of the latter on lib/boot-time-aux.h is not
>> detected by the build system.
> 
> It is detected here, I see it in lib/deps/boot-time.d, FWIW.

I see it here too.  But for some reason I didn't see boot-time.o rebuilt 
after I modified boot-time-aux.h.  Maybe I just missed it.

Ken