>> 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 wrote: > > From: Duncan Greatwood > > 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