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.