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

[Eli Zaretskii <eliz@gnu.org>]

> 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.