Am Dienstag, 20. April 2021, 17:08:57 CEST schrieb Stefan Monnier: > > Because the error says it cannot use LOCKS. > > Because you can't do Unix file locking on a non-Unix file system. > > The error does NOT say "Permission denied". > > FWIW, the error comes from Emacs's own locking code which doesn't seem > to use unix file locking, so the problem comes from elsewhere. > > Emacs implements its locking protocol using symlinks with names > that look like `.#<FILENAME>` and whose content looks like > `u...@host.pid:BOOT_TIME`. > > > Stefan "still not sure exactly where it goes wrong"
Hi Stefan, many thanks for that excellent diagnosis, that really helped to trace it down: - indeed vboxsf does not support symlinks (at least if ntfs is shared). But instead of the symlinks there were real files. I assume a prior version of emacs created them and used this as backup if the symlinks did not work on a filesystem - These files had permission 555 instead of 777. Changing this back (?) to 777 resolved the problem. How that happened I cannot tell. I do not even understand what these permissions mean on vboxsf, apparently they do at least something. Maybe one explanation model: -> I noticed that the timestamp of the .# lock files were super old (2019) on the vboxsf file system even for files which I touched many times with emacs since then -> I noticed that if I edit these files with emacs the .# lock files are not created anymore on the vboxsf filesystem by bullseye's emacs, but they get removed if I close bullseye's emacs So I speculate -> stretch emacs used .# files instead of .# symlinks, if the file system did not support symlinks. The content of the file contains the information which is otherwise encoded in the symlink target -> buster emacs did not care at all about .# on filesystems which do not support symlinks. Somehow the permissions changed while the system was on buster, possibly by virtualbox or by me myself in an accidential or intended chmod -R a-w or something similar. I noticed the error but reverted it only for the visible files. But since buster emacs did not care nobody noticed. -> bullseye emacs not does not create the .# files on file systems, if they don't have symlink support. But it finds them and puts the file in read-only mode, if it is there. In addition, it tries to cleanup and delete these files, which failed due to the wrong permission. Even on a file system which supports symlinks, the problem can be easily reproduced by rd@h370:~$ touch test.txt rd@h370:~$ touch .#test.txt rd@h370:~$ chmod a-w .#test.txt rd@h370:~$ emacs test.txt What is somewhat ugly is that after toggling read-only mode and editing the file, I cannot leave emacs anymore, it hangs. I am undecided if that is a bug and I should report it or a real corner case which is not worth to invest more time. Thanks again, that was a great help. Rainer -- Rainer Dorsch http://bokomoko.de/