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

Previous Next

To reply to this bug, email your comments to 70973 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Duncan Greatwood <dgreatwood <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; "Unlocking file: Invalid argument" Warning saving via a
 softlink with stale file lock
Date: Wed, 15 May 2024 17:53:05 -0700

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

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 <at> xage.com <mailto:security-alerts <at> xage.com>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Duncan Greatwood <dgreatwood <at> gmail.com>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1;
 "Unlocking file: Invalid argument" Warning saving via a softlink with
 stale file lock
Date: Thu, 16 May 2024 11:43:45 +0300

> From: Duncan Greatwood <dgreatwood <at> 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".

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

From: Duncan Greatwood <dgreatwood <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 07:17:59 -0700

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

> 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 <at> gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood <at> 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 <at> xage.com <mailto:security-alerts <at> xage.com>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Duncan Greatwood <dgreatwood <at> gmail.com>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 18:46:51 +0300

> From: Duncan Greatwood <dgreatwood <at> gmail.com>
> Date: Thu, 16 May 2024 07:17:59 -0700
> Cc: 70973 <at> 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.

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

From: Duncan Greatwood <dgreatwood <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 08:55:17 -0700

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

> 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 <at> gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood <at> gmail.com>
> > Date: Thu, 16 May 2024 07:17:59 -0700
> > Cc: 70973 <at> 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 <at> xage.com <mailto:security-alerts <at> xage.com>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Duncan Greatwood <dgreatwood <at> gmail.com>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 19:09:52 +0300

> From: Duncan Greatwood <dgreatwood <at> gmail.com>
> Date: Thu, 16 May 2024 08:55:17 -0700
> Cc: 70973 <at> 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?

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

From: Duncan Greatwood <dgreatwood <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 09:20:46 -0700

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

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 <at> gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood <at> gmail.com>
> > Date: Thu, 16 May 2024 08:55:17 -0700
> > Cc: 70973 <at> 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 <at> xage.com <mailto:security-alerts <at> xage.com>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Duncan Greatwood <dgreatwood <at> gmail.com>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 21:18:46 +0300

> From: Duncan Greatwood <dgreatwood <at> gmail.com>
> Date: Thu, 16 May 2024 09:20:46 -0700
> Cc: 70973 <at> 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.

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

From: Duncan Greatwood <dgreatwood <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 12:27:05 -0700

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

>> 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 <at> 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 <at> 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 <at> 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 <at> gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood <at> gmail.com>
> > Date: Thu, 16 May 2024 09:20:46 -0700
> > Cc: 70973 <at> 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 <at> xage.com <mailto:security-alerts <at> xage.com>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Duncan Greatwood <dgreatwood <at> gmail.com>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 22:51:30 +0300

> From: Duncan Greatwood <dgreatwood <at> gmail.com>
> Date: Thu, 16 May 2024 12:27:05 -0700
> Cc: 70973 <at> 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 <at> 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 <at> 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 <at> 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.

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

From: Duncan Greatwood <dgreatwood <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70973 <at> debbugs.gnu.org
Subject: Re: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning
 saving via a softlink with stale file lock
Date: Thu, 16 May 2024 14:36:37 -0700

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

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 <at> gnu.org> wrote:

> > From: Duncan Greatwood <dgreatwood <at> gmail.com>
> > Date: Thu, 16 May 2024 12:27:05 -0700
> > Cc: 70973 <at> 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 <at> 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 <at> 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 <at> 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 <at> xage.com <mailto:security-alerts <at> xage.com>

[Message part 2 (text/html, inline)]

Previous Next

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