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