[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: Strange emacs behavior after upgrade to bullseye
From:       Rainer Dorsch <ml () bokomoko ! de>
Date:       2021-04-22 15:33:03
Message-ID: 4514070.CjeeycDt4o () h370
[Download RAW message or body]

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-<PID>-<HOSTNAME>~ 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/


[prev in list] [next in list] [prev in thread] [next in thread]