Re: Strange emacs behavior after upgrade to bullseye
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
> `USER@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/
Reply to: