From debian-user Thu Apr 22 15:33:03 2021 From: Rainer Dorsch Date: Thu, 22 Apr 2021 15:33:03 +0000 To: debian-user Subject: Re: Strange emacs behavior after upgrade to bullseye Message-Id: <4514070.CjeeycDt4o () h370> X-MARC-Message: https://marc.info/?l=debian-user&m=161910560901932 Hi David, I did some more testing, you can see the effect on bullseye without vboxsf even on a ext4 filesystem. Am Mittwoch, 21. April 2021, 20:49:14 CEST schrieb David Wright: [...deleted a lot of history] > > -> 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. > I can't reproduce that. I get locks (that are files) and autosave > files, both these being listed in the usual manner in each user's own > respective ~/.emacs.d/.saves--~ files. > However, AIUI locks only get created by the user who owns the directory > (I assume), and not by others. In your case, the owner was root, and > you were not running emacs as root. > > Also bear in mind that locks aren't created until a need arises. > Opening a file in emacs is not enough: you have to modify the buffer. > > Upon attempting to save a file being edited by several users, I get > the expected response with the user@host and PID of any valid lock. > I also observe the use of ~/.emacs.d/%backup%~ when an instance won't > overwrite the normal backup file, filename~, which it realises it > didn't write itself, perhaps. I did go to a buster system with btrfs: rd@master:~$ touch test.txt rd@master:~$ touch .#test.txt rd@master:~$ chmod a-w .#test.txt rd@master:~$ emacs test.txt works without emacs complaining about anything. .# files are created as symlinks. I had no filesystem which does not support symlinks on that system. > > -> 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. > > When I start (buster) emacs with a fake, empty lock(file), even one > that I own like the above, it's not refreshed, but merely ignored. > Nor is the fake lock removed when emacs exits. I would assume that > a lock only works if the information it holds is valid, as far as > can be determined. I haven't bothered to check what happens with > manifestly stale locks (ie holding verifiable information). > > I don't know how vboxsf is implemented, but I think it would be > necessary to disentangle the effects of the underlying components, > filesystem, OS, access method, before attributing strange behaviour > to emacs. On the bullseye system with ext4 (but I do not expect that ext4 vs btrfs makes a difference): rd@h370:~$ touch test.txt rd@h370:~$ touch .#test.txt rd@h370:~$ chmod a-w .#test.txt rd@h370:~$ emacs test.txt opens test.txt as read only and if I modify it and try to leave emacs it even hangs. Rainer -- Rainer Dorsch http://bokomoko.de/