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

Previous Next

Package: emacs;

Reported by: Duncan Greatwood <dgreatwood <at> gmail.com>

Date: Thu, 16 May 2024 05:13:01 UTC

Severity: normal

Merged with 72641

Found in versions 29.1, 31.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


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.




This bug report was last modified 302 days ago.

Previous Next


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