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

[Duncan Greatwood <dgreatwood@gmail.com>]

[-- 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 --]