bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 9058 bytes --]

While editing the ~/.emacs file in emacs, the machine rebooted (kernel
panic I believe). This left a lock file behind.

The ~/.emacs file is actually a softlink:
.emacs -> /Users/<username>/Dropbox/Documents/Projects/emacs/dotemacs
The fact that it's a softlink may or may not be relevant.

In ~/Dropbox/Documents/Projects/emacs/, there was a file: .#dotemacs

After the reboot, I started emacs, and continued with further edits to
.emacs. Upon saving .emacs, had the following warning:
⛔ Warning (unlock-file): Unlocking file: Invalid
argument, ~/Dropbox/Documents/Projects/emacs/dotemacs, ignored

As per the warning, the save was nonetheless successful.

Invoking file-locked-p directly, I saw the same error, and the following
debug info:
Debugger entered--Lisp error: (file-error "Testing file lock" "Invalid
argument" "~/Dropbox/Documents/Projects/emacs/dotemacs")
  file-locked-p("~/Dropbox/Documents/Projects/emacs/dotemacs")
  eval((file-locked-p "~/Dropbox/Documents/Projects/emacs/dotemacs") t)
  eval-expression((file-locked-p
"~/Dropbox/Documents/Projects/emacs/dotemacs") nil nil 127)
  funcall-interactively(eval-expression (file-locked-p
"~/Dropbox/Documents/Projects/emacs/dotemacs") nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

After removing the lock file manually, the warning on save goes away:
rm ~/Dropbox/Documents/Projects/emacs/.#dotemacs

Access flags on dotemacs file are as follows:
-rw-r--r--@  1 dgreatwood  staff  133806 May 15 16:01 dotemacs
lrwxr-xr-x  1 dgreatwood  staff  59 Dec  6  2015 .emacs -> ...

Thanks.
----
In GNU Emacs 29.1 (build 1, aarch64-apple-darwin21.6.0, NS
 appkit-2113.60 Version 12.6.6 (Build 21G646)) of 2023-08-16 built on
 armbob.lan
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.5

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=10000
 -DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'

Configured features:
ACL GLIB GMP GNUTLS JPEG JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER
PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  server-mode: t
  override-global-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/username/.emacs.d/lisp/dash hides
/Users/username/.emacs.d/elpa/dash-20221013.836/dash
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package-jump
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-jump
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package-ensure
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-ensure
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package-core
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-core
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package-delight
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-delight
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package-diminish
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-diminish
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package-bind-key
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-bind-key
/Users/username/.emacs.d/elpa/bind-key-20221028.1858/bind-key hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/bind-key
/Users/username/.emacs.d/elpa/use-package-20221029.1857/use-package-lint
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-lint
/Users/username/.emacs.d/lisp/linum hides
/Applications/Emacs.app/Contents/Resources/lisp/obsolete/linum

Features:
(shadow mail-extr emacsbug misearch multi-isearch help-fns radix-tree
cl-print debug backtrace warnings company-oddmuse company-keywords
company-etags company-gtags company-dabbrev-code company-dabbrev
company-files company-clang company-capf company-cmake company-semantic
company-template company-bbdb company mm-archive message sendmail
yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived epg
rfc6068 gnus-util mailabbrev gmm-utils mailheader mm-decode mm-bodies
mm-encode mail-utils sort autorevert filenotify tango-theme server
cmake-mode rst persistent-todo todotxt rustic-spellcheck rustic-expand
rustic-lsp rustic-playpen rustic-rustfix rustic-racer etags fileloop
xref rustic-babel rustic-rustfmt project org-element org-persist org-id
org-refile avl-tree generator org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-src ob-comint org-pcomplete pcomplete org-list
org-footnote org-faces org-entities time-date ob-emacs-lisp ob-core
ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec rustic-comint rustic-clippy rustic-doc
xdg f f-shortdoc shortdoc rustic-popup rustic-cargo rustic-compile
spinner s xterm-color markdown-mode color noutline outline icons
rustic-interaction rustic dash pcase use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core rust-utils thingatpt rust-mode rx
rust-rustfmt rust-playpen rust-compile compile text-property-search
comint ansi-osc ansi-color ring rust-cargo gnutls network-stream
url-cache url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr url-gw nsm puny epg-config finder-inf
special-scratch kmacro advice string-inflection cl-extra help-mode
desktop frameset unbound cl delsel auto-complete-autoloads
cmake-font-lock-autoloads cmake-mode-autoloads company-autoloads
fuzzy-autoloads popup-complete-autoloads popup-autoloads info package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 407012 134522)
 (symbols 48 26631 1)
 (strings 32 138327 48200)
 (string-bytes 1 3541370)
 (vectors 16 50914)
 (vector-slots 8 1424473 208168)
 (floats 8 298 443)
 (intervals 56 1081 0)
 (buffers 984 16))

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 10280 bytes --]

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Eli Zaretskii]

> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Wed, 15 May 2024 17:53:05 -0700
> 
> While editing the ~/.emacs file in emacs, the machine rebooted (kernel panic I believe). This left a lock file
> behind.
> 
> The ~/.emacs file is actually a softlink:
> .emacs -> /Users/<username>/Dropbox/Documents/Projects/emacs/dotemacs
> The fact that it's a softlink may or may not be relevant.
> 
> In ~/Dropbox/Documents/Projects/emacs/, there was a file: .#dotemacs
> 
> After the reboot, I started emacs, and continued with further edits to .emacs. Upon saving .emacs, had the
> following warning:
> ⛔ Warning (unlock-file): Unlocking file: Invalid argument, ~/Dropbox/Documents/Projects/emacs/dotemacs,
> ignored
> 
> As per the warning, the save was nonetheless successful.
> 
> Invoking file-locked-p directly, I saw the same error, and the following debug info:
> Debugger entered--Lisp error: (file-error "Testing file lock" "Invalid argument"
> "~/Dropbox/Documents/Projects/emacs/dotemacs")
>   file-locked-p("~/Dropbox/Documents/Projects/emacs/dotemacs")
>   eval((file-locked-p "~/Dropbox/Documents/Projects/emacs/dotemacs") t)
>   eval-expression((file-locked-p "~/Dropbox/Documents/Projects/emacs/dotemacs") nil nil 127)
>   funcall-interactively(eval-expression (file-locked-p "~/Dropbox/Documents/Projects/emacs/dotemacs") nil nil
> 127)
>   call-interactively(eval-expression nil nil)
>   command-execute(eval-expression)
> 
> After removing the lock file manually, the warning on save goes away:
> rm ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> 
> Access flags on dotemacs file are as follows:
> -rw-r--r--@  1 dgreatwood  staff  133806 May 15 16:01 dotemacs
> lrwxr-xr-x  1 dgreatwood  staff  59 Dec  6  2015 .emacs -> ...

Thanks.

However, this doesn't provide enough information to investigate the
issue and its causes.  If you can reproduce the problem, please tell
what does

  ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs

produce when you see the warnings, because that is the immediate
trigger for the "invalid argument".

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 3432 bytes --]

> If you can reproduce the problem, please tell what does
>
>   ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
>
> produce when you see the warnings

As follows:
$ ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
-rw-r--r--@ 1 username  staff  0 May 16 07:13
/Users/username/Dropbox/Documents/Projects/emacs/.#dotemacs


On Thu, May 16, 2024 at 1:43 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood@gmail.com>
> > Date: Wed, 15 May 2024 17:53:05 -0700
> >
> > While editing the ~/.emacs file in emacs, the machine rebooted (kernel
> panic I believe). This left a lock file
> > behind.
> >
> > The ~/.emacs file is actually a softlink:
> > .emacs -> /Users/<username>/Dropbox/Documents/Projects/emacs/dotemacs
> > The fact that it's a softlink may or may not be relevant.
> >
> > In ~/Dropbox/Documents/Projects/emacs/, there was a file: .#dotemacs
> >
> > After the reboot, I started emacs, and continued with further edits to
> .emacs. Upon saving .emacs, had the
> > following warning:
> > ⛔ Warning (unlock-file): Unlocking file: Invalid argument,
> ~/Dropbox/Documents/Projects/emacs/dotemacs,
> > ignored
> >
> > As per the warning, the save was nonetheless successful.
> >
> > Invoking file-locked-p directly, I saw the same error, and the following
> debug info:
> > Debugger entered--Lisp error: (file-error "Testing file lock" "Invalid
> argument"
> > "~/Dropbox/Documents/Projects/emacs/dotemacs")
> >   file-locked-p("~/Dropbox/Documents/Projects/emacs/dotemacs")
> >   eval((file-locked-p "~/Dropbox/Documents/Projects/emacs/dotemacs") t)
> >   eval-expression((file-locked-p
> "~/Dropbox/Documents/Projects/emacs/dotemacs") nil nil 127)
> >   funcall-interactively(eval-expression (file-locked-p
> "~/Dropbox/Documents/Projects/emacs/dotemacs") nil nil
> > 127)
> >   call-interactively(eval-expression nil nil)
> >   command-execute(eval-expression)
> >
> > After removing the lock file manually, the warning on save goes away:
> > rm ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> >
> > Access flags on dotemacs file are as follows:
> > -rw-r--r--@  1 dgreatwood  staff  133806 May 15 16:01 dotemacs
> > lrwxr-xr-x  1 dgreatwood  staff  59 Dec  6  2015 .emacs -> ...
>
> Thanks.
>
> However, this doesn't provide enough information to investigate the
> issue and its causes.  If you can reproduce the problem, please tell
> what does
>
>   ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
>
> produce when you see the warnings, because that is the immediate
> trigger for the "invalid argument".
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 4733 bytes --]

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Eli Zaretskii]

> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Thu, 16 May 2024 07:17:59 -0700
> Cc: 70973@debbugs.gnu.org
> 
> > If you can reproduce the problem, please tell what does
> > 
> >   ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> > 
> > produce when you see the warnings
> 
> As follows:
> $ ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> -rw-r--r--@ 1 username  staff  0 May 16 07:13
> /Users/username/Dropbox/Documents/Projects/emacs/.#dotemacs

Sorry, that doesn't help.  I thought "ls -l" will show the target of
the symlink, but maybe it doesn't on macOS?  In that case, you should
be able to use the Emacs function file-symlink-p: when called with the
lock file as its argument, it should return the target of the symlink
as a string.

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

> I thought "ls -l" will show the target of
> the symlink, but maybe it doesn't on macOS?
It does indeed do that, even on macOS

However, it is the .emacs that is a symlink.

$ ls -l ~/.emacs
lrwxr-xr-x  1 username  staff  59 Dec  6  2015 .emacs ->
/Users/username/Dropbox/Documents/Projects/emacs/dotemacs

The lock file is not a link.

On Thu, May 16, 2024 at 8:47 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood@gmail.com>
> > Date: Thu, 16 May 2024 07:17:59 -0700
> > Cc: 70973@debbugs.gnu.org
> >
> > > If you can reproduce the problem, please tell what does
> > >
> > >   ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> > >
> > > produce when you see the warnings
> >
> > As follows:
> > $ ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> > -rw-r--r--@ 1 username  staff  0 May 16 07:13
> > /Users/username/Dropbox/Documents/Projects/emacs/.#dotemacs
>
> Sorry, that doesn't help.  I thought "ls -l" will show the target of
> the symlink, but maybe it doesn't on macOS?  In that case, you should
> be able to use the Emacs function file-symlink-p: when called with the
> lock file as its argument, it should return the target of the symlink
> as a string.
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 3244 bytes --]

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Eli Zaretskii]

> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Thu, 16 May 2024 08:55:17 -0700
> Cc: 70973@debbugs.gnu.org
> 
> > I thought "ls -l" will show the target of
> > the symlink, but maybe it doesn't on macOS?
> It does indeed do that, even on macOS
> 
> However, it is the .emacs that is a symlink.
> 
> $ ls -l ~/.emacs
> lrwxr-xr-x  1 username  staff  59 Dec  6  2015 .emacs ->
> /Users/username/Dropbox/Documents/Projects/emacs/dotemacs
> 
> The lock file is not a link.

Is that normal on macOS?  Or is that something specific to DropBox?
If you edit a file elsewhere on your system, does Emacs create lock
files that are symlinks?

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

AFAIK, there is nothing about the symlink that is macOS or DropBox specific.

Again, ~/.emacs is a symlink to the file in the subfolder of ~/Dropbox.

The lock file is not a symlink.

Emacs does not create lock files that are symlinks AFAIK.

On Thu, May 16, 2024 at 9:09 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood@gmail.com>
> > Date: Thu, 16 May 2024 08:55:17 -0700
> > Cc: 70973@debbugs.gnu.org
> >
> > > I thought "ls -l" will show the target of
> > > the symlink, but maybe it doesn't on macOS?
> > It does indeed do that, even on macOS
> >
> > However, it is the .emacs that is a symlink.
> >
> > $ ls -l ~/.emacs
> > lrwxr-xr-x  1 username  staff  59 Dec  6  2015 .emacs ->
> > /Users/username/Dropbox/Documents/Projects/emacs/dotemacs
> >
> > The lock file is not a link.
>
> Is that normal on macOS?  Or is that something specific to DropBox?
> If you edit a file elsewhere on your system, does Emacs create lock
> files that are symlinks?
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 2959 bytes --]

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Eli Zaretskii]

> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Thu, 16 May 2024 09:20:46 -0700
> Cc: 70973@debbugs.gnu.org
> 
> AFAIK, there is nothing about the symlink that is macOS or DropBox specific.
> 
> Again, ~/.emacs is a symlink to the file in the subfolder of ~/Dropbox.
> 
> The lock file is not a symlink.
> 
> Emacs does not create lock files that are symlinks AFAIK.

That is not true.  lock files are normally dangling symlinks,
i.e. their target does not exist.  On a few systems where lock files
are not symlinks (I knew about only one: MS-Windows), lock files are
regular files, but then they are not empty.  And your reports indicate
that it is a regular and empty file:

> As follows:
> $ ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> -rw-r--r--@ 1 username  staff  0 May 16 07:13 /Users/username/Dropbox/Documents/Projects/emacs/.#dotemacs

This is unusual, because it means the information that a lock file
should record: the user and the process ID that locked the file -- is
not recorded anywhere.  It is usually recorded either in the name of
the symlink's target or (if the lock file is a regular file) in the
file's contents.

So something here is not "normal".  If indeed on macOS lock files are
not symlinks, they should be regular files which are not empty.  If
you could step with a debugger through the code of the C function
create_lock_file and see what happens there when Emacs locks a file
you edit, we could make some progress in investigating this bug.

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 4432 bytes --]

>> Emacs does not create lock files that are symlinks AFAIK.
>That is not true.  lock files are normally dangling symlinks,
>i.e. their target does not exist.

Ah, I see.

I just tried editing a different file, client.cc, causing a lockfile to be
created. Sure enough, just as you say, that lockfile is a dangling symlink:
ls -al .#client.cc
lrwxr-xr-x@ 1 username  staff  40 May 16 11:39 .#client.cc ->
username@DMG-MB-Air-15-2024.local.3071

Then, returning to editing ~/.emacs (which, being a symlink, is actually
editing ~/Dropbox/Documents/Projects/emacs/dotemacs).
Again, this creates a dangling symlink as you would expect:
ls -l .#dotemacs
lrwxr-xr-x@ 1 username  staff  40 May 16 11:43 .#dotemacs ->
username@DMG-MB-Air-15-2024.local.3071

At this point, I tried doing a hard reboot (power cycle) to simulate the
kernel crash I mentioned before. But (not surprisingly) after the reboot
the lock file still looks as you would expect.
ls -l .#dotemacs
lrwxr-xr-x@ 1 username  staff  40 May 16 11:43 .#dotemacs ->
username@DMG-MB-Air-15-2024.local.3071

Noting that, in the bad case, the lock file was not only *not* a dangling
symlink as it should be, but was also of zero size, I would speculate that
the kernel crash happened right as emacs was part way through writing the
lockfile to disk.

Taking a quick look at the emacs source, the C function create_lock_file
calls emacs_symlink which in turn calls the OS function symlink.

The OS function symlink is commonly assumed to be atomic I believe (e.g.
see https://rcrowley.org/2010/01/06/things-unix-can-do-atomically.html).
However in this case I would suspect that *the kernel crash terminated the
symlink write before it could fully complete*.

To fix, perhaps emacs needs to check purported lock files and handle the
case where they are not symlinks and/or are of zero size, avoiding the need
to remove the partially-written lock file manually.




On Thu, May 16, 2024 at 11:18 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood@gmail.com>
> > Date: Thu, 16 May 2024 09:20:46 -0700
> > Cc: 70973@debbugs.gnu.org
> >
> > AFAIK, there is nothing about the symlink that is macOS or DropBox
> specific.
> >
> > Again, ~/.emacs is a symlink to the file in the subfolder of ~/Dropbox.
> >
> > The lock file is not a symlink.
> >
> > Emacs does not create lock files that are symlinks AFAIK.
>
> That is not true.  lock files are normally dangling symlinks,
> i.e. their target does not exist.  On a few systems where lock files
> are not symlinks (I knew about only one: MS-Windows), lock files are
> regular files, but then they are not empty.  And your reports indicate
> that it is a regular and empty file:
>
> > As follows:
> > $ ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> > -rw-r--r--@ 1 username  staff  0 May 16 07:13
> /Users/username/Dropbox/Documents/Projects/emacs/.#dotemacs
>
> This is unusual, because it means the information that a lock file
> should record: the user and the process ID that locked the file -- is
> not recorded anywhere.  It is usually recorded either in the name of
> the symlink's target or (if the lock file is a regular file) in the
> file's contents.
>
> So something here is not "normal".  If indeed on macOS lock files are
> not symlinks, they should be regular files which are not empty.  If
> you could step with a debugger through the code of the C function
> create_lock_file and see what happens there when Emacs locks a file
> you edit, we could make some progress in investigating this bug.
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 5963 bytes --]

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Eli Zaretskii]

> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Thu, 16 May 2024 12:27:05 -0700
> Cc: 70973@debbugs.gnu.org
> 
> I just tried editing a different file, client.cc, causing a lockfile to be created. Sure enough, just as you say, that
> lockfile is a dangling symlink:
> ls -al .#client.cc
> lrwxr-xr-x@ 1 username  staff  40 May 16 11:39 .#client.cc -> username@DMG-MB-Air-15-2024.local.3071
> 
> Then, returning to editing ~/.emacs (which, being a symlink, is actually editing ~
> /Dropbox/Documents/Projects/emacs/dotemacs).
> Again, this creates a dangling symlink as you would expect:
> ls -l .#dotemacs
> lrwxr-xr-x@ 1 username  staff  40 May 16 11:43 .#dotemacs -> username@DMG-MB-Air-15-2024.local.3071
> 
> At this point, I tried doing a hard reboot (power cycle) to simulate the kernel crash I mentioned before. But
> (not surprisingly) after the reboot the lock file still looks as you would expect.
> ls -l .#dotemacs
> lrwxr-xr-x@ 1 username  staff  40 May 16 11:43 .#dotemacs -> username@DMG-MB-Air-15-2024.local.3071
> 
> Noting that, in the bad case, the lock file was not only not a dangling symlink as it should be, but was also of
> zero size, I would speculate that the kernel crash happened right as emacs was part way through writing the
> lockfile to disk.
> 
> Taking a quick look at the emacs source, the C function create_lock_file calls emacs_symlink which in turn
> calls the OS function symlink. 
> 
> The OS function symlink is commonly assumed to be atomic I believe (e.g. see
> https://rcrowley.org/2010/01/06/things-unix-can-do-atomically.html). However in this case I would suspect that
> the kernel crash terminated the symlink write before it could fully complete.
> 
> To fix, perhaps emacs needs to check purported lock files and handle the case where they are not symlinks
> and/or are of zero size, avoiding the need to remove the partially-written lock file manually.

I'm not sure we should silently sweep these rare and special cases
under the carpet.  The warning is just a warning, and manually
deleting the lock file fixes even that.

So I'm not sure we should do anything here, as long as the conclusion
is that this happened due to a system crash in an opportune moment.

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 3689 bytes --]

I would agree that the issue was likely due to a system crash at an
inopportune moment.

Of course, if emacs did detect a bad lock file, it could prompt the user
for confirmation before removing / replacing it. No need to be silent.

The status quo, requiring a user to find and remove the lock file manually,
seems burdensome to my eye, albeit the issue is presumably rare. But
certainly it is a matter of taste.



On Thu, May 16, 2024 at 12:52 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood@gmail.com>
> > Date: Thu, 16 May 2024 12:27:05 -0700
> > Cc: 70973@debbugs.gnu.org
> >
> > I just tried editing a different file, client.cc, causing a lockfile to
> be created. Sure enough, just as you say, that
> > lockfile is a dangling symlink:
> > ls -al .#client.cc
> > lrwxr-xr-x@ 1 username  staff  40 May 16 11:39 .#client.cc ->
> username@DMG-MB-Air-15-2024.local.3071
> >
> > Then, returning to editing ~/.emacs (which, being a symlink, is actually
> editing ~
> > /Dropbox/Documents/Projects/emacs/dotemacs).
> > Again, this creates a dangling symlink as you would expect:
> > ls -l .#dotemacs
> > lrwxr-xr-x@ 1 username  staff  40 May 16 11:43 .#dotemacs ->
> username@DMG-MB-Air-15-2024.local.3071
> >
> > At this point, I tried doing a hard reboot (power cycle) to simulate the
> kernel crash I mentioned before. But
> > (not surprisingly) after the reboot the lock file still looks as you
> would expect.
> > ls -l .#dotemacs
> > lrwxr-xr-x@ 1 username  staff  40 May 16 11:43 .#dotemacs ->
> username@DMG-MB-Air-15-2024.local.3071
> >
> > Noting that, in the bad case, the lock file was not only not a dangling
> symlink as it should be, but was also of
> > zero size, I would speculate that the kernel crash happened right as
> emacs was part way through writing the
> > lockfile to disk.
> >
> > Taking a quick look at the emacs source, the C function create_lock_file
> calls emacs_symlink which in turn
> > calls the OS function symlink.
> >
> > The OS function symlink is commonly assumed to be atomic I believe (e.g.
> see
> > https://rcrowley.org/2010/01/06/things-unix-can-do-atomically.html).
> However in this case I would suspect that
> > the kernel crash terminated the symlink write before it could fully
> complete.
> >
> > To fix, perhaps emacs needs to check purported lock files and handle the
> case where they are not symlinks
> > and/or are of zero size, avoiding the need to remove the
> partially-written lock file manually.
>
> I'm not sure we should silently sweep these rare and special cases
> under the carpet.  The warning is just a warning, and manually
> deleting the lock file fixes even that.
>
> So I'm not sure we should do anything here, as long as the conclusion
> is that this happened due to a system crash in an opportune moment.
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 4991 bytes --]

bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock

[Eli Zaretskii]

> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Thu, 16 May 2024 14:36:37 -0700
> Cc: 70973@debbugs.gnu.org
> 
> I would agree that the issue was likely due to a system crash at an inopportune moment.
> 
> Of course, if emacs did detect a bad lock file, it could prompt the user for confirmation before removing /
> replacing it. No need to be silent.
> 
> The status quo, requiring a user to find and remove the lock file manually, seems burdensome to my eye,
> albeit the issue is presumably rare. But certainly it is a matter of taste.

No further comments, so I'm now closing this bug.

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Michal Nazarewicz]

[Sending this again as a new bug report since #70973 is archived].

On Thu, May 16 2024, Eli Zaretskii wrote:
> I'm not sure we should silently sweep these rare and special cases
> under the carpet.  The warning is just a warning, and manually
> deleting the lock file fixes even that.
>
> So I'm not sure we should do anything here, as long as the conclusion
> is that this happened due to a system crash in an opportune moment.

I’m getting the same warning on Linux with Emacs 31.0.50 and it’s not
caused by a crash.

    emacs> M-x find-file RET /o/foo RET blah RET
    cli> $ ls -l /o/.#foo 
    cli> -rw------- 1 mpn mpn 0 2024-08-15 16:30 /o/.#foo
    emacs> M-x save-buffer RET
    emacs> ⛔ Warning (unlock-file): Unlocking file: Invalid argument, /o/foo, ignored
    cli> $ ls -l /o/.#foo /o/foo
    cli> -rw------- 1 mpn mpn 5 2024-08-15 16:31 /o/foo
    cli> -rw------- 1 mpn mpn 0 2024-08-15 16:30 /o/.#foo

The problem appears to be that /o is a network file-system which does
not support symbolic links:

    $ mount |grep /o
    //192.168.x.x/data on /o type cifs (rw,relatime,vers=3.0,cache=strict,username=mpn,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.x.x,file_mode=0600,dir_mode=0700,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1,_netdev)
    $ ln -s /o/foo /o/f
    ln: failed to create symbolic link '/o/f': Input/output error

I guess Emacs notices that when it tries to create a lock file and falls
back to creating a file, but then it assumes it’s a symlink when trying
to remove it.


---------- >8 ------------------------------------------------------
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.0) of 2024-08-12 built on erwin
Repository revision: 5d69e2916458148159d7f21257f3c4863b868690
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --prefix=/usr/local --disable-acl
 --enable-link-time-optimization --with-native-compilation=aot
 --without-dbus --without-gconf --without-gpm --without-gsettings
 --without-pop --without-selinux --without-systemd
 --without-toolkit-scroll-bars --with-x --with-x-toolkit=gtk3
 --with-xinput2 --with-xml2 'CFLAGS=-O2 -mtune=native -march=native
 -fstack-protector' 'CPPFLAGS=-O2 -mtune=native -march=native
 -fstack-protector' 'CXXFLAGS=-O2 -mtune=native -march=native
 -fstack-protector''

Configured features:
CAIRO FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND THREADS TIFF WEBP
X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_GB.utf8
  locale-coding-system: utf-8-unix

Major mode: Rust

Minor modes in effect:
  server-mode: t
  flyspell-mode: t
  auto-dim-other-buffers-mode: t
  global-auto-revert-mode: t
  icomplete-mode: t
  global-num3-mode: t
  num3-mode: t
  global-whitespace-mode: t
  whitespace-mode: t
  global-flyspell-mode: t
  delete-selection-mode: t
  windmove-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/mpn/.config/emacs/elpa/transient-20210525.1141/transient hides /usr/local/share/emacs/31.0.50/lisp/transient
~/.config/emacs/custom hides /usr/local/share/emacs/31.0.50/lisp/custom

Features:
(shadow emacsbug mm-archive parse-time iso8601 mule-util image-mode exif
wdired dired-aux pp network-stream nsm mailalias smtpmail textsec
uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check qp
sort mail-extr notmuch notmuch-tree notmuch-jump notmuch-hello wid-edit
notmuch-show notmuch-print notmuch-crypto notmuch-mua notmuch-message
notmuch-draft notmuch-maildir-fcc notmuch-address notmuch-company
notmuch-parser format-spec notmuch-wash diff-mode track-changes coolj
goto-addr icalendar notmuch-tag crm notmuch-lib notmuch-compat pcase
hl-line mm-view mml-smime smime gnutls dig gnus-alias rot13 message
sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader calc-alg calc-ext calc-menu
calc calc-loaddefs calc-macs project dabbrev auto-package-update
easy-mmode dash rust-utils rust-mode rust-rustfmt rust-playpen
rust-compile rust-cargo time-date mc-hide-unmatched-lines-mode
mc-mark-more mc-cycle-cursors multiple-cursors-core rect misearch
multi-isearch conf-mode pulse color descr-text server flyspell form-feed
init sgml-mode facemenu dom auto-dim-other-buffers face-remap autorevert
filenotify comp comp-cstr cl-extra help-mode warnings comp-run
comp-common rx icomplete num3-mode disp-table whitespace compile
text-property-search comint ansi-osc ansi-color ring ispell remember
advice browse-kill-ring delsel ffap thingatpt windmove diary-lib
diary-loaddefs cal-menu calendar cal-loaddefs
auto-dim-other-buffers-autoloads avy-autoloads
browse-kill-ring-autoloads csv-mode-autoloads evil-autoloads
gnu-elpa-keyring-update-autoloads gnus-alias-autoloads finder-inf
markdown-mode-autoloads notmuch-autoloads protobuf-mode-autoloads
sed-mode-autoloads info vterm-autoloads package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
early-init rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads inotify dynamic-setting font-render-setting cairo gtk x-toolkit
xinput2 x multi-tty move-toolbar make-network-process native-compile
emacs)

Memory information:
((conses 16 667368 1514832) (symbols 48 33066 15)
 (strings 32 118043 64516) (string-bytes 1 3468194) (vectors 16 66157)
 (vector-slots 8 1624733 757680) (floats 8 247 2757)
 (intervals 56 57621 24687) (buffers 984 58))
---------- 8< ------------------------------------------------------

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Michal Nazarewicz]

>> From: Michal Nazarewicz <mina86@mina86.com>
>> Date: Thu, 15 Aug 2024 17:41:03 +0200
>> 
>> I’m getting the same warning on Linux with Emacs 31.0.50 and it’s not
>> caused by a crash.
>> 
>>     emacs> M-x find-file RET /o/foo RET blah RET
>>     cli> $ ls -l /o/.#foo 
>>     cli> -rw------- 1 mpn mpn 0 2024-08-15 16:30 /o/.#foo
>>     emacs> M-x save-buffer RET
>>     emacs> ⛔ Warning (unlock-file): Unlocking file: Invalid argument, /o/foo, ignored
>>     cli> $ $ ls -l /o/.#foo /o/foo
>>     cli> -rw------- 1 mpn mpn 5 2024-08-15 16:31 /o/foo
>>     cli> -rw------- 1 mpn mpn 0 2024-08-15 16:30 /o/.#foo
>> 
>> The problem appears to be that /o is a network file-system which does
>> not support symbolic links:
>> 
>>     $ mount |grep /o
>>     //192.168.x.x/data on /o type cifs (rw,relatime,vers=3.0,cache=strict,username=mpn,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.x.x,file_mode=0600,dir_mode=0700,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1,_netdev)
>>     $ ln -s /o/foo /o/f
>>     ln: failed to create symbolic link '/o/f': Input/output error
>> 
>> I guess Emacs notices that when it tries to create a lock file and falls
>> back to creating a file, but then it assumes it’s a symlink when trying
>> to remove it.

On Thu, Aug 15 2024, Eli Zaretskii wrote:
> I'm not sure we need to do anything here, either, but maybe Paul
> (CC'ed) has other suggestions or ideas.

The way I see it, Emacs has created those files so Emacs should clean
after itself.  Though I’ve looked at it a bit more closely and it’s
weirder than my original guess.

symlink(2) creates the file (as in it creates a regular file rather than
a symbolic link) and returns EIO.  create_lock_file reports an error and
does not go into its fallback.  This is why the lock file is empty.  In
the end, the error comes from current_lock_owner as it tries to parse
the empty file.

The *Warnings* buffer constantly popping up is annoying so I’d love this
to be addressed though to be honest I’m not sure what would be a good
solution.  Though I guess you can also argue this is CIFS bug.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

On 2024-08-15 10:44, Michal Nazarewicz wrote:
> The*Warnings* buffer constantly popping up is annoying so I’d love this
> to be addressed though to be honest I’m not sure what would be a good
> solution.  Though I guess you can also argue this is CIFS bug.

It's definitely a file system bug. The symlink syscall should never 
create a regular file. I suggest reporting the bug to whoever maintains 
your file system code.

I don't see any good way to prevent Emacs from creating these 
zero-length files on buggy file systems.

That being said, I think Emacs can ignore and remove bad lock files 
without introducing more races. I installed the attached into the master 
branch and it works for me on your test case (which I introduced 
artificially on GNU/Linux). Please give it a try.

The first patches in this series are just setup. The last patch is the 
real workaround.

[-- Attachment #2: 0001-Fix-unlikely-lock-file-integer-overflow.patch --]
[-- Type: text/x-patch, Size: 1556 bytes --]

From cbacdca9e3f6dcf9b88704391f06daf7301608b0 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 15 Aug 2024 11:29:16 -0700
Subject: [PATCH 1/4] Fix unlikely lock file integer overflow

* src/filelock.c (within_one_second): Accept intmax_t first arg.
Avoid undefined behavior on integer overflow.
(current_lock_owner): Simplify based on within_one_second change.
---
 src/filelock.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/filelock.c b/src/filelock.c
index 69bd0322d4c..55ab15feb8d 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -298,9 +298,10 @@ lock_file_1 (Lisp_Object lfname, bool force)
 /* Return true if times A and B are no more than one second apart.  */
 
 static bool
-within_one_second (time_t a, time_t b)
+within_one_second (intmax_t a, time_t b)
 {
-  return (a - b >= -1 && a - b <= 1);
+  intmax_t diff;
+  return !ckd_sub (&diff, a, b) && -1 <= diff && diff <= 1;
 }
 \f
 /* On systems lacking ELOOP, test for an errno value that shouldn't occur.  */
@@ -469,8 +470,7 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
       else if (VALID_PROCESS_ID (pid)
                && (kill (pid, 0) >= 0 || errno == EPERM)
 	       && (boot_time == 0
-		   || (boot_time <= TYPE_MAXIMUM (time_t)
-		       && within_one_second (boot_time, get_boot_sec ()))))
+		   || within_one_second (boot_time, get_boot_sec ())))
         return ANOTHER_OWNS_IT;
       /* The owner process is dead or has a strange pid, so try to
          zap the lockfile.  */
-- 
2.43.0


[-- Attachment #3: 0002-Avoid-some-GC-when-locking-unlocking-files.patch --]
[-- Type: text/x-patch, Size: 4048 bytes --]

From 4b6b9a7acdc4f7d0594caaaa382e2e633f8f1225 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 15 Aug 2024 12:58:19 -0700
Subject: [PATCH 2/4] Avoid some GC when locking/unlocking files
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/filelock.c (lock_file_1, current_lock_owner):
Don’t possibly invoke the garbage collector when
comparing lock file contents to host names.
---
 src/filelock.c | 62 ++++++++++++++++++++++++++++++--------------------
 1 file changed, 37 insertions(+), 25 deletions(-)

diff --git a/src/filelock.c b/src/filelock.c
index 55ab15feb8d..cdf9e6f0ffc 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -271,27 +271,29 @@ lock_file_1 (Lisp_Object lfname, bool force)
   intmax_t boot = get_boot_sec ();
   Lisp_Object luser_name = Fuser_login_name (Qnil);
   Lisp_Object lhost_name = Fsystem_name ();
-
-  /* Protect against the extremely unlikely case of the host name
-     containing an @ character.  */
-  if (!NILP (lhost_name) && strchr (SSDATA (lhost_name), '@'))
-    lhost_name = CALLN (Ffuncall, Qstring_replace,
-			build_string ("@"), build_string ("-"),
-			lhost_name);
-
   char const *user_name = STRINGP (luser_name) ? SSDATA (luser_name) : "";
   char const *host_name = STRINGP (lhost_name) ? SSDATA (lhost_name) : "";
   char lock_info_str[MAX_LFINFO + 1];
   intmax_t pid = getpid ();
 
-  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);
+  int room = sizeof lock_info_str;
+  int len = snprintf (lock_info_str, room, "%s@", user_name);
   if (! (0 <= len && len < sizeof lock_info_str))
     return ENAMETOOLONG;
-
+  /* Protect against the extremely unlikely case of the host name
+     containing an @ character.  */
+  for (; *host_name; len++, host_name++)
+    {
+      if (! (len < sizeof lock_info_str - 1))
+	return ENAMETOOLONG;
+      lock_info_str[len] = *host_name == '@' ? '-' : *host_name;
+    }
+  char const *lock_info_fmt = boot ? ".%"PRIdMAX":%"PRIdMAX : ".%"PRIdMAX;
+  room = sizeof lock_info_str - len;
+  int suffixlen = snprintf (lock_info_str + len, room,
+			    lock_info_fmt, pid, boot);
+  if (! (0 <= suffixlen && suffixlen < room))
+    return ENAMETOOLONG;
   return create_lock_file (SSDATA (lfname), lock_info_str, force);
 }
 
@@ -448,22 +450,32 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
   if (lfinfo_end != owner->user + lfinfolen)
     return EINVAL;
 
+  char *linkhost = at + 1;
+  ptrdiff_t linkhostlen = dot - linkhost;
   Lisp_Object system_name = Fsystem_name ();
   /* If `system-name' returns nil, that means we're in a
      --no-build-details Emacs, and the name part of the link (e.g.,
      .#test.txt -> larsi@.118961:1646577954) is an empty string.  */
+  bool on_current_host;
   if (NILP (system_name))
-    system_name = build_string ("");
-  /* Protect against the extremely unlikely case of the host name
-     containing an @ character.  */
-  else if (strchr (SSDATA (system_name), '@'))
-    system_name = CALLN (Ffuncall, intern ("string-replace"),
-			 build_string ("@"), build_string ("-"),
-			 system_name);
-  /* On current host?  */
-  if (STRINGP (system_name)
-      && dot - (at + 1) == SBYTES (system_name)
-      && memcmp (at + 1, SSDATA (system_name), SBYTES (system_name)) == 0)
+    on_current_host = linkhostlen == 0;
+  else
+    {
+      on_current_host = linkhostlen == SBYTES (system_name);
+      if (on_current_host)
+	{
+	  /* Protect against the extremely unlikely case of the host
+	     name containing '@'.  */
+	  char *sysname = SSDATA (system_name);
+	  for (ptrdiff_t i = 0; i < linkhostlen; i++)
+	    if (linkhost[i] != (sysname[i] == '@' ? '-' : sysname[i]))
+	      {
+		on_current_host = false;
+		break;
+	      }
+	}
+    }
+  if (on_current_host)
     {
       if (pid == getpid ())
         return I_OWN_IT;
-- 
2.43.0


[-- Attachment #4: 0003-Refactor-current_lock_owner.patch --]
[-- Type: text/x-patch, Size: 7388 bytes --]

From 775fa8443faa3d7f5ce7f7d0aa6e6fb53321715a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 15 Aug 2024 13:17:24 -0700
Subject: [PATCH 3/4] Refactor current_lock_owner

* src/filelock.c (current_lock_owner): Refactor to make further
changes easier.  This should not affect behavior.
---
 src/filelock.c | 185 +++++++++++++++++++++++++------------------------
 1 file changed, 95 insertions(+), 90 deletions(-)

diff --git a/src/filelock.c b/src/filelock.c
index cdf9e6f0ffc..c68aacc46fb 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -386,9 +386,6 @@ integer_prefixed (char const *s)
 current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
 {
   lock_info_type local_owner;
-  ptrdiff_t lfinfolen;
-  intmax_t pid, boot_time;
-  char *at, *dot, *lfinfo_end;
 
   /* Even if the caller doesn't want the owner info, we still have to
      read it to determine return value.  */
@@ -396,104 +393,112 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
     owner = &local_owner;
 
   /* If nonexistent lock file, all is well; otherwise, got strange error. */
-  lfinfolen = read_lock_data (SSDATA (lfname), owner->user);
+  ptrdiff_t lfinfolen = read_lock_data (SSDATA (lfname), owner->user);
   if (lfinfolen < 0)
     return errno == ENOENT || errno == ENOTDIR ? 0 : errno;
-  if (MAX_LFINFO < lfinfolen)
-    return ENAMETOOLONG;
-  owner->user[lfinfolen] = 0;
-
-  /* Parse USER@HOST.PID:BOOT_TIME.  If can't parse, return EINVAL.  */
-  /* The USER is everything before the last @.  */
-  owner->at = at = memrchr (owner->user, '@', lfinfolen);
-  if (!at)
-    return EINVAL;
-  owner->dot = dot = strrchr (at, '.');
-  if (!dot)
-    return EINVAL;
-
-  /* The PID is everything from the last '.' to the ':' or equivalent.  */
-  if (! integer_prefixed (dot + 1))
-    return EINVAL;
-  errno = 0;
-  pid = strtoimax (dot + 1, &owner->colon, 10);
-  if (errno == ERANGE)
-    pid = -1;
-
-  /* After the ':' or equivalent, if there is one, comes the boot time.  */
-  char *boot = owner->colon + 1;
-  switch (owner->colon[0])
+
+  /* Examine lock file contents.  */
+  if (true)
     {
-    case 0:
-      boot_time = 0;
-      lfinfo_end = owner->colon;
-      break;
+      if (MAX_LFINFO < lfinfolen)
+	return ENAMETOOLONG;
+      owner->user[lfinfolen] = 0;
 
-    case '\357':
-      /* Treat "\357\200\242" (U+F022 in UTF-8) as if it were ":" (Bug#24656).
-	 This works around a bug in the Linux CIFS kernel client, which can
-	 mistakenly transliterate ':' to U+F022 in symlink contents.
-	 See <https://bugzilla.redhat.com/show_bug.cgi?id=1384153>.  */
-      if (! (boot[0] == '\200' && boot[1] == '\242'))
+      /* Parse USER@HOST.PID:BOOT_TIME.  If can't parse, return EINVAL.  */
+      /* The USER is everything before the last @.  */
+      char *at = memrchr (owner->user, '@', lfinfolen);
+      if (!at)
 	return EINVAL;
-      boot += 2;
-      FALLTHROUGH;
-    case ':':
-      if (! integer_prefixed (boot))
+      owner->at = at;
+      char *dot = strrchr (at, '.');
+      if (!dot)
 	return EINVAL;
-      boot_time = strtoimax (boot, &lfinfo_end, 10);
-      break;
+      owner->dot = dot;
 
-    default:
-      return EINVAL;
-    }
-  if (lfinfo_end != owner->user + lfinfolen)
-    return EINVAL;
-
-  char *linkhost = at + 1;
-  ptrdiff_t linkhostlen = dot - linkhost;
-  Lisp_Object system_name = Fsystem_name ();
-  /* If `system-name' returns nil, that means we're in a
-     --no-build-details Emacs, and the name part of the link (e.g.,
-     .#test.txt -> larsi@.118961:1646577954) is an empty string.  */
-  bool on_current_host;
-  if (NILP (system_name))
-    on_current_host = linkhostlen == 0;
-  else
-    {
-      on_current_host = linkhostlen == SBYTES (system_name);
-      if (on_current_host)
+      /* The PID is everything from the last '.' to the ':' or equivalent.  */
+      if (! integer_prefixed (dot + 1))
+	return EINVAL;
+      errno = 0;
+      intmax_t pid = strtoimax (dot + 1, &owner->colon, 10);
+      if (errno == ERANGE)
+	pid = -1;
+
+      /* After the ':' or equivalent, if there is one, comes the boot time.  */
+      intmax_t boot_time;
+      char *boot = owner->colon + 1, *lfinfo_end;
+      switch (owner->colon[0])
 	{
-	  /* Protect against the extremely unlikely case of the host
-	     name containing '@'.  */
-	  char *sysname = SSDATA (system_name);
-	  for (ptrdiff_t i = 0; i < linkhostlen; i++)
-	    if (linkhost[i] != (sysname[i] == '@' ? '-' : sysname[i]))
-	      {
-		on_current_host = false;
-		break;
-	      }
+	case 0:
+	  boot_time = 0;
+	  lfinfo_end = owner->colon;
+	  break;
+
+	case '\357':
+	  /* Treat "\357\200\242" (U+F022 in UTF-8) like ":" (Bug#24656).
+	     This works around a bug in the Linux CIFS kernel client, which can
+	     mistakenly transliterate ':' to U+F022 in symlink contents.
+	     See <https://bugzilla.redhat.com/show_bug.cgi?id=1384153>.  */
+	  if (! (boot[0] == '\200' && boot[1] == '\242'))
+	    return EINVAL;
+	  boot += 2;
+	  FALLTHROUGH;
+	case ':':
+	  if (! integer_prefixed (boot))
+	    return EINVAL;
+	  boot_time = strtoimax (boot, &lfinfo_end, 10);
+	  break;
+
+	default:
+	  return EINVAL;
 	}
-    }
-  if (on_current_host)
-    {
-      if (pid == getpid ())
-        return I_OWN_IT;
-      else if (VALID_PROCESS_ID (pid)
-               && (kill (pid, 0) >= 0 || errno == EPERM)
-	       && (boot_time == 0
-		   || within_one_second (boot_time, get_boot_sec ())))
-        return ANOTHER_OWNS_IT;
-      /* The owner process is dead or has a strange pid, so try to
-         zap the lockfile.  */
+      if (lfinfo_end != owner->user + lfinfolen)
+	return EINVAL;
+
+      char *linkhost = at + 1;
+      ptrdiff_t linkhostlen = dot - linkhost;
+      Lisp_Object system_name = Fsystem_name ();
+      /* If `system-name' returns nil, that means we're in a
+	 --no-build-details Emacs, and the name part of the link (e.g.,
+	 .#test.txt -> larsi@.118961:1646577954) is an empty string.  */
+      bool on_current_host;
+      if (NILP (system_name))
+	on_current_host = linkhostlen == 0;
       else
-        return emacs_unlink (SSDATA (lfname)) < 0 ? errno : 0;
-    }
-  else
-    { /* If we wanted to support the check for stale locks on remote machines,
-         here's where we'd do it.  */
-      return ANOTHER_OWNS_IT;
+	{
+	  on_current_host = linkhostlen == SBYTES (system_name);
+	  if (on_current_host)
+	    {
+	      /* Protect against the extremely unlikely case of the host
+		 name containing '@'.  */
+	      char *sysname = SSDATA (system_name);
+	      for (ptrdiff_t i = 0; i < linkhostlen; i++)
+		if (linkhost[i] != (sysname[i] == '@' ? '-' : sysname[i]))
+		  {
+		    on_current_host = false;
+		    break;
+		  }
+	    }
+	}
+      if (!on_current_host)
+	{
+	  /* Not on current host.  If we wanted to support the check for
+	     stale locks on remote machines, here's where we'd do it.  */
+	  return ANOTHER_OWNS_IT;
+	}
+
+      if (pid == getpid ())
+	return I_OWN_IT;
+
+      if (VALID_PROCESS_ID (pid)
+	  && ! (kill (pid, 0) < 0 && errno != EPERM)
+	  && (boot_time == 0
+	      || within_one_second (boot_time, get_boot_sec ())))
+	return ANOTHER_OWNS_IT;
     }
+
+  /* The owner process is dead or has a strange pid.
+     Try to zap the lockfile.  */
+  return emacs_unlink (SSDATA (lfname)) < 0 ? errno : 0;
 }
 
 \f
-- 
2.43.0


[-- Attachment #5: 0004-Remove-empty-invalid-lock-files.patch --]
[-- Type: text/x-patch, Size: 1612 bytes --]

From 8b36bfc553b97cf435bdfe1b84abe21c3a605b9f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 15 Aug 2024 13:30:23 -0700
Subject: [PATCH 4/4] Remove empty (& invalid) lock files

* src/filelock.c (current_lock_owner):
Remove empty lock files, as they are necessarily invalid
and can be caused by buggy file systems.
Problem reported by Michal Nazarewicz (bug#72641).
---
 src/filelock.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/filelock.c b/src/filelock.c
index c68aacc46fb..1ae57dc7344 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -397,8 +397,8 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
   if (lfinfolen < 0)
     return errno == ENOENT || errno == ENOTDIR ? 0 : errno;
 
-  /* Examine lock file contents.  */
-  if (true)
+  /* If the lock file seems valid, return a value based on its contents.  */
+  if (lfinfolen)
     {
       if (MAX_LFINFO < lfinfolen)
 	return ENAMETOOLONG;
@@ -496,8 +496,11 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
 	return ANOTHER_OWNS_IT;
     }
 
-  /* The owner process is dead or has a strange pid.
-     Try to zap the lockfile.  */
+  /* The owner process is dead or has a strange pid, or the lock file is empty.
+     Try to zap the lockfile.  If the lock file is empty, this assumes
+     the file system is buggy, e.g., <https://bugs.gnu.org/72641>.
+     Emacs never creates empty lock files even temporarily, so removing
+     an empty lock file should be harmless.  */
   return emacs_unlink (SSDATA (lfname)) < 0 ? errno : 0;
 }
 
-- 
2.43.0

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Michal Nazarewicz]

On Thu, Aug 15 2024, Paul Eggert wrote:
> That being said, I think Emacs can ignore and remove bad lock files 
> without introducing more races. I installed the attached into the master 
> branch and it works for me on your test case (which I introduced 
> artificially on GNU/Linux). Please give it a try.

With Emacs from current master, if I open a file, edit it and then kill
the buffer without saving the changes, the lock file is deleted.
However, if I save the file (be it by save-buffer or by killing the
buffer and picking save option), the lock file remains.

I didn’t fully track what is actually happening.  It looks like saving
the buffer results in the following:
- lock_file is called
  - it calls current_lock_owner
    - which deletes the lock file
  - and now lock_file creates new lock file
- unlock_file is called
  - it calls current_lock_owner
    - which return ENOENT for some reason
  - the lock file is left alone
 
In desperation I’ve tried attached patch (it adds `if (!lfinfolen)
return I_OWN_IT`; big diff is because than `if (lfinfolen)` check can be
removed and code dedented) and it worked.

Maybe this is a better approach? Because currently lock_file will delete
the lock file and then create an empty file.  With the below file,
lock_file will just notice file is there and do nothing.



From be05054ae47e74192bb3551e83d4afb2ff41f888 Mon Sep 17 00:00:00 2001
From: Michal Nazarewicz <mina86@mina86.com>
Date: Fri, 16 Aug 2024 02:49:55 +0200
Subject: [PATCH] Treat empty lock files as owned by us (bug#72641)

* src/filelock.c (current_lock_owner): Rather then deleting empty lock
files, treat them as if they were owned by us.  Previous commit which
deleted the lock file instead resulted in stale lock file remaining when
saving a file.
---
 src/filelock.c | 185 ++++++++++++++++++++++++-------------------------
 1 file changed, 92 insertions(+), 93 deletions(-)

diff --git a/src/filelock.c b/src/filelock.c
index 1ae57dc7344..f9aac0dc5c5 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -397,110 +397,109 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
   if (lfinfolen < 0)
     return errno == ENOENT || errno == ENOTDIR ? 0 : errno;
 
+  /* The lock file is empty which may be due to buggy file system, e.g.,
+     <https://bugs.gnu.org/72641>.  Treat it as us holding the lock.  */
+  if (!lfinfolen)
+	return I_OWN_IT;
+
   /* If the lock file seems valid, return a value based on its contents.  */
-  if (lfinfolen)
+  if (MAX_LFINFO < lfinfolen)
+    return ENAMETOOLONG;
+  owner->user[lfinfolen] = 0;
+
+  /* Parse USER@HOST.PID:BOOT_TIME.  If can't parse, return EINVAL.  */
+  /* The USER is everything before the last @.  */
+  char *at = memrchr (owner->user, '@', lfinfolen);
+  if (!at)
+    return EINVAL;
+  owner->at = at;
+  char *dot = strrchr (at, '.');
+  if (!dot)
+    return EINVAL;
+  owner->dot = dot;
+
+  /* The PID is everything from the last '.' to the ':' or equivalent.  */
+  if (! integer_prefixed (dot + 1))
+    return EINVAL;
+  errno = 0;
+  intmax_t pid = strtoimax (dot + 1, &owner->colon, 10);
+  if (errno == ERANGE)
+    pid = -1;
+
+  /* After the ':' or equivalent, if there is one, comes the boot time.  */
+  intmax_t boot_time;
+  char *boot = owner->colon + 1, *lfinfo_end;
+  switch (owner->colon[0])
     {
-      if (MAX_LFINFO < lfinfolen)
-	return ENAMETOOLONG;
-      owner->user[lfinfolen] = 0;
-
-      /* Parse USER@HOST.PID:BOOT_TIME.  If can't parse, return EINVAL.  */
-      /* The USER is everything before the last @.  */
-      char *at = memrchr (owner->user, '@', lfinfolen);
-      if (!at)
-	return EINVAL;
-      owner->at = at;
-      char *dot = strrchr (at, '.');
-      if (!dot)
-	return EINVAL;
-      owner->dot = dot;
+    case 0:
+      boot_time = 0;
+      lfinfo_end = owner->colon;
+      break;
 
-      /* The PID is everything from the last '.' to the ':' or equivalent.  */
-      if (! integer_prefixed (dot + 1))
+    case '\357':
+      /* Treat "\357\200\242" (U+F022 in UTF-8) like ":" (Bug#24656).
+	 This works around a bug in the Linux CIFS kernel client, which can
+	 mistakenly transliterate ':' to U+F022 in symlink contents.
+	 See <https://bugzilla.redhat.com/show_bug.cgi?id=1384153>.  */
+      if (! (boot[0] == '\200' && boot[1] == '\242'))
 	return EINVAL;
-      errno = 0;
-      intmax_t pid = strtoimax (dot + 1, &owner->colon, 10);
-      if (errno == ERANGE)
-	pid = -1;
-
-      /* After the ':' or equivalent, if there is one, comes the boot time.  */
-      intmax_t boot_time;
-      char *boot = owner->colon + 1, *lfinfo_end;
-      switch (owner->colon[0])
-	{
-	case 0:
-	  boot_time = 0;
-	  lfinfo_end = owner->colon;
-	  break;
-
-	case '\357':
-	  /* Treat "\357\200\242" (U+F022 in UTF-8) like ":" (Bug#24656).
-	     This works around a bug in the Linux CIFS kernel client, which can
-	     mistakenly transliterate ':' to U+F022 in symlink contents.
-	     See <https://bugzilla.redhat.com/show_bug.cgi?id=1384153>.  */
-	  if (! (boot[0] == '\200' && boot[1] == '\242'))
-	    return EINVAL;
-	  boot += 2;
-	  FALLTHROUGH;
-	case ':':
-	  if (! integer_prefixed (boot))
-	    return EINVAL;
-	  boot_time = strtoimax (boot, &lfinfo_end, 10);
-	  break;
-
-	default:
-	  return EINVAL;
-	}
-      if (lfinfo_end != owner->user + lfinfolen)
+      boot += 2;
+      FALLTHROUGH;
+    case ':':
+      if (! integer_prefixed (boot))
 	return EINVAL;
+      boot_time = strtoimax (boot, &lfinfo_end, 10);
+      break;
 
-      char *linkhost = at + 1;
-      ptrdiff_t linkhostlen = dot - linkhost;
-      Lisp_Object system_name = Fsystem_name ();
-      /* If `system-name' returns nil, that means we're in a
-	 --no-build-details Emacs, and the name part of the link (e.g.,
-	 .#test.txt -> larsi@.118961:1646577954) is an empty string.  */
-      bool on_current_host;
-      if (NILP (system_name))
-	on_current_host = linkhostlen == 0;
-      else
-	{
-	  on_current_host = linkhostlen == SBYTES (system_name);
-	  if (on_current_host)
-	    {
-	      /* Protect against the extremely unlikely case of the host
-		 name containing '@'.  */
-	      char *sysname = SSDATA (system_name);
-	      for (ptrdiff_t i = 0; i < linkhostlen; i++)
-		if (linkhost[i] != (sysname[i] == '@' ? '-' : sysname[i]))
-		  {
-		    on_current_host = false;
-		    break;
-		  }
-	    }
-	}
-      if (!on_current_host)
+    default:
+      return EINVAL;
+    }
+  if (lfinfo_end != owner->user + lfinfolen)
+    return EINVAL;
+
+  char *linkhost = at + 1;
+  ptrdiff_t linkhostlen = dot - linkhost;
+  Lisp_Object system_name = Fsystem_name ();
+  /* If `system-name' returns nil, that means we're in a
+     --no-build-details Emacs, and the name part of the link (e.g.,
+     .#test.txt -> larsi@.118961:1646577954) is an empty string.  */
+  bool on_current_host;
+  if (NILP (system_name))
+    on_current_host = linkhostlen == 0;
+  else
+    {
+      on_current_host = linkhostlen == SBYTES (system_name);
+      if (on_current_host)
 	{
-	  /* Not on current host.  If we wanted to support the check for
-	     stale locks on remote machines, here's where we'd do it.  */
-	  return ANOTHER_OWNS_IT;
+	  /* Protect against the extremely unlikely case of the host
+	     name containing '@'.  */
+	  char *sysname = SSDATA (system_name);
+	  for (ptrdiff_t i = 0; i < linkhostlen; i++)
+	    if (linkhost[i] != (sysname[i] == '@' ? '-' : sysname[i]))
+	      {
+		on_current_host = false;
+		break;
+	      }
 	}
+    }
+  if (!on_current_host)
+    {
+      /* Not on current host.  If we wanted to support the check for
+	 stale locks on remote machines, here's where we'd do it.  */
+      return ANOTHER_OWNS_IT;
+    }
 
-      if (pid == getpid ())
-	return I_OWN_IT;
+  if (pid == getpid ())
+    return I_OWN_IT;
 
-      if (VALID_PROCESS_ID (pid)
-	  && ! (kill (pid, 0) < 0 && errno != EPERM)
-	  && (boot_time == 0
-	      || within_one_second (boot_time, get_boot_sec ())))
-	return ANOTHER_OWNS_IT;
-    }
+  if (VALID_PROCESS_ID (pid)
+      && ! (kill (pid, 0) < 0 && errno != EPERM)
+      && (boot_time == 0
+	  || within_one_second (boot_time, get_boot_sec ())))
+    return ANOTHER_OWNS_IT;
 
-  /* The owner process is dead or has a strange pid, or the lock file is empty.
-     Try to zap the lockfile.  If the lock file is empty, this assumes
-     the file system is buggy, e.g., <https://bugs.gnu.org/72641>.
-     Emacs never creates empty lock files even temporarily, so removing
-     an empty lock file should be harmless.  */
+  /* The owner process is dead or has a strange pid.
+     Try to zap the lockfile.  */
   return emacs_unlink (SSDATA (lfname)) < 0 ? errno : 0;
 }
 
-- 
2.43.0

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On 2024-08-15 17:59, Michal Nazarewicz wrote:

> However, if I save the file (be it by save-buffer or by killing the
> buffer and picking save option), the lock file remains....
> - unlock_file is called
>    - it calls current_lock_owner
>      - which return ENOENT for some reason
>    - the lock file is left alone

Obviously current_lock_owner should not return ENOENT if there is an 
existing lock file - that would defeat the purpose of having a lock 
file. We need to get to the bottom of why current_lock_owner returns ENOENT.

 From inspection, current_lock_owner returns ENOENT only if Emacs 
notices that the "lock" file is actually an empty regular file (or looks 
stale), and calls 'unlink' on it, and 'unlink' fails with errno == 
ENOENT. Is that what's actually happening? You can use a debugger or 
'strace' to confirm.

Come to think of it, if 'unlink' fails with errno == ENOENT, that means 
there's no lock file so current_lock_owner should return 0. This is true 
because of NFS and similar network file systems where unlink can fail 
even though it actually removed the file. I installed the attached patch 
to fix this; a similar problem exists elsewhere, so this patch fixes all 
the instances of it in Emacs master.

With this patch, current_lock_owner should never return ENOENT and we 
can move on to the next problem you observe, if there is one.


> In desperation I’ve tried attached patch (it adds `if (!lfinfolen)
> return I_OWN_IT`; big diff is because than `if (lfinfolen)` check can be
> removed and code dedented) and it worked.

Yes, that doesn't sound right; on non-buggy file systems the invalid 
lock file would cause races to occur, if I'm reading the code correctly.

Let's see what happens with current master before proceeding in any 
direction like that.

[-- Attachment #2: 0001-Port-better-to-NFS-unlink.patch --]
[-- Type: text/x-patch, Size: 2738 bytes --]

From 9aad7664813d77f4dab2649d56adbf12239b7505 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 15 Aug 2024 20:10:53 -0700
Subject: [PATCH] Port better to NFS unlink
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

I found this problem while looking into Bug#72641.
* lib-src/etags.c (do_move_file):
* lib-src/update-game-score.c (unlock_file):
* src/androidvfs.c (android_hack_asset_fd_fallback):
* src/filelock.c (current_lock_owner):
Treat unlink as successful if it fails because the file wasn’t there.
This can happen with some NFS implementations, due to its
retrying over the network to get at-least-once semantics.
Although most of Emacs’s calls to unlink were already doing this,
a few instances were not.
---
 lib-src/etags.c             | 2 +-
 lib-src/update-game-score.c | 2 +-
 src/androidvfs.c            | 2 +-
 src/filelock.c              | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib-src/etags.c b/lib-src/etags.c
index 03bc55de03d..edadbc25901 100644
--- a/lib-src/etags.c
+++ b/lib-src/etags.c
@@ -7812,7 +7812,7 @@ do_move_file (const char *src_file, const char *dst_file)
   if (fclose (dst_f) == EOF)
     pfatal (dst_file);
 
-  if (unlink (src_file) == -1)
+  if (unlink (src_file) < 0 && errno != ENOENT)
     pfatal ("unlink error");
 
   return;
diff --git a/lib-src/update-game-score.c b/lib-src/update-game-score.c
index 4139073bcd7..e3b24ad7717 100644
--- a/lib-src/update-game-score.c
+++ b/lib-src/update-game-score.c
@@ -497,7 +497,7 @@ unlock_file (const char *filename, void *state)
   char *lockpath = (char *) state;
   int saved_errno = errno;
   int ret = unlink (lockpath);
-  if (0 <= ret)
+  if (! (ret < 0 && errno != ENOENT))
     errno = saved_errno;
   free (lockpath);
   return ret;
diff --git a/src/androidvfs.c b/src/androidvfs.c
index 14da8eed37e..ff81ef288f5 100644
--- a/src/androidvfs.c
+++ b/src/androidvfs.c
@@ -1323,7 +1323,7 @@ android_hack_asset_fd_fallback (AAsset *asset)
   if (fd < 0)
     return -1;
 
-  if (unlink (filename))
+  if (unlink (filename) && errno != ENOENT)
     goto fail;
 
   if (ftruncate (fd, size))
diff --git a/src/filelock.c b/src/filelock.c
index 1ae57dc7344..bc09fce69f8 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -501,7 +501,7 @@ current_lock_owner (lock_info_type *owner, Lisp_Object lfname)
      the file system is buggy, e.g., <https://bugs.gnu.org/72641>.
      Emacs never creates empty lock files even temporarily, so removing
      an empty lock file should be harmless.  */
-  return emacs_unlink (SSDATA (lfname)) < 0 ? errno : 0;
+  return emacs_unlink (SSDATA (lfname)) < 0 && errno != ENOENT ? errno : 0;
 }
 
 \f
-- 
2.43.0

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Michal Nazarewicz]

This appears to be network synchronisation issue.  I’ve run this
program:

---------- >8 --------------------------------------------------
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

void create(char *path) {
	int ret = symlink("dummy", path);
	if (ret < 0) {
		printf("%s: %d %s\n", path, errno, strerror(errno));
	} else {
		printf("%s: Ok\n", path);
	}
}

int check(char *path) {
	char buf[1024];
	ssize_t ret = readlink(path, buf, 1024);
	if (ret >= 0) {
		printf("%s: %.*s\n", path, ret, buf);
		return 0;
	}
	int err = errno;
	printf("%s: %d %s\n", path, err, strerror(err));
	return err;
}

int main(int argc, char **argv) {
	char *path = argc < 2 ? "bar" : argv[1];
	create(path);
	int loop = 0;
	while (check(path) != EINVAL && ++loop < 50) {
		usleep(100000);
	}
	return 0;
}
-------------------------------------------------- 8< ----------

and got the following:

---------- >8 --------------------------------------------------
/o/foo: 5 Input/output error
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 2 No such file or directory
/o/foo: 22 Invalid argument
-------------------------------------------------- 8< ----------

It looks like symlink(2) fails with EIO while the server creates
a regular file, however it takes the client to notice another second.


If you’re still interested, here’s strace when I find-file and then
kill-current-buffer without saving:

---------- >8 --------------------------------------------------
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                      = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o", 0x7ffec38f7370, 1024)                      = -1 EINVAL (Invalid argument)
readlinkat(AT_FDCWD, "/o/foo", 0x7ffec38f74d0, 1024)                  = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH)  = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o", 0x7ffec38f72c0, 1024)                      = -1 EINVAL (Invalid argument)
readlinkat(AT_FDCWD, "/o/foo", 0x7ffec38f7420, 1024)                  = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH)  = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC)                    = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o/.#foo", 0x7ffec38f13e8, 8193)                = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                      = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", W_OK, AT_EACCESS)                      = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                      = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o/foo", 0x7ffec38f7470, 1024)                  = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffec38f7750, 0)                     = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffec38f77f0, 0)                     = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo,v", F_OK, AT_EACCESS)                    = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffec38f5860, 0)                     = -1 ENOENT (No such file or directory)
symlink   ("mpn@erwin.223853:1723847375", "/o/.#foo")                 = -1 EIO (Input/output error)
readlinkat(AT_FDCWD, "/o/.#foo", 0x7ffec38f5ad8, 8193)                = -1 EINVAL (Invalid argument)
openat    (AT_FDCWD, "/o/.#foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC)       = 12
read      (12, "", 8193)                                              = 0
close     (12)                                                        = 0
unlink    ("/o/.#foo")                                                = 0
-------------------------------------------------- 8< ----------

And this is strace when I find-file and then save-buffer:

---------- >8 --------------------------------------------------
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                           = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o", 0x7ffe65452010, 1024)                           = -1 EINVAL (Invalid argument)
readlinkat(AT_FDCWD, "/o/foo", 0x7ffe65452170, 1024)                       = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH)       = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o", 0x7ffe65451f60, 1024)                           = -1 EINVAL (Invalid argument)
readlinkat(AT_FDCWD, "/o/foo", 0x7ffe654520c0, 1024)                       = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH)       = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC)                         = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o/.#foo", 0x7ffe6544c088, 8193)                     = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                           = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", W_OK, AT_EACCESS)                           = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                           = -1 ENOENT (No such file or directory)
readlinkat(AT_FDCWD, "/o/foo", 0x7ffe65452110, 1024)                       = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffe654523f0, 0)                          = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffe65452490, 0)                          = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo,v", F_OK, AT_EACCESS)                         = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffe65450500, 0)                          = -1 ENOENT (No such file or directory)
symlink   ("mpn@erwin.223938:1723847375", "/o/.#foo")                      = -1 EIO (Input/output error)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffe65452690, 0)                          = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                           = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo,v", F_OK, AT_EACCESS)                         = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY)      = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", F_OK, AT_EACCESS)                           = -1 ENOENT (No such file or directory)
faccessat2(AT_FDCWD, "/o/foo", W_OK, AT_EACCESS)                           = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH)       = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/o/foo", 0x7ffe6544ff80, 0)                          = -1 ENOENT (No such file or directory)
symlink   ("mpn@erwin.223938:1723847375", "/o/.#foo")                      = -1 EEXIST (File exists)
readlinkat(AT_FDCWD, "/o/.#foo", 0x7ffe65450078, 8193)                     = -1 EINVAL (Invalid argument)
openat    (AT_FDCWD, "/o/.#foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC)            = 12
read      (12, "", 8193)                                                   = 0
close     (12)                                                             = 0
unlink    ("/o/.#foo")                                                     = 0
symlink   ("mpn@erwin.223938:1723847375", "/o/.#foo")                      = -1 EIO (Input/output error)
openat    (AT_FDCWD, "/o/foo", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666)   = 12
write     (12, "ao sneuhta soneht sanoteu snothe"..., 33)                  = 33
close     (12)                                                             = 0
newfstatat(AT_FDCWD, "/o/foo", {st_mode=S_IFREG|0600, st_size=33, ...}, 0) = 0
readlinkat(AT_FDCWD, "/o/.#foo", 0x7ffe65450028, 8193)                     = -1 ENOENT (No such file or directory)
openat    (AT_FDCWD, "/o/foo", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH)       = 12
close     (12)                                                             = 0
-------------------------------------------------- 8< ----------

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Paul Eggert]

On 2024-08-17 13:03, Michal Nazarewicz wrote:
> It looks like symlink(2) fails with EIO while the server creates
> a regular file, however it takes the client to notice another second.

Yes, it's definitely a file system bug, and I don't see any good way for 
Emacs to work around it.

You might try doing your CIFS mount with the mfsymlinks option. See:

https://docs.kernel.org/admin-guide/cifs/usage.html

https://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks

If you're already using mfsymlinks it might be a good time to file a bug 
report with your file system supplier.

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Mike Kupfer]

Paul Eggert wrote:

> You might try doing your CIFS mount with the mfsymlinks option. See:
> 
> https://docs.kernel.org/admin-guide/cifs/usage.html

I see from that document that the CIFS client has a tunable cache
timeout.  I'd also try setting actimeo=0 and see if that helps.

mike

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Mike Kupfer]

Mike Kupfer wrote:

> I'd also try setting actimeo=0 and see if that helps.

Sorry, I was unclear.  I meant try actimeo=0 if mfsymlinks doesn't do
the job.

mike

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Michal Nazarewicz]

On Sat, Aug 17 2024, Paul Eggert wrote:
> Yes, it's definitely a file system bug, and I don't see any good way
> for Emacs to work around it.

Yeah, I think this bug can be close.  Though if you think the patch I’ve
sent makes sense, I can push it to master as well.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

[Paul Eggert]

On 2024-08-18 14:15, Michal Nazarewicz wrote:
> On Sat, Aug 17 2024, Paul Eggert wrote:
>> Yes, it's definitely a file system bug, and I don't see any good way
>> for Emacs to work around it.
> 
> Yeah, I think this bug can be close.  Though if you think the patch I’ve
> sent makes sense, I can push it to master as well.
> 

OK, closing the bug report, as the patch you sent in 
<https://bugs.gnu.org/72641#16> is problematic for the reasons discussed 
in <https://bugs.gnu.org/72641#19>.