Re: Strange emacs behavior after upgrade to bullseye
On Tue 20 Apr 2021 at 20:43:46 (+0200), Rainer Dorsch wrote:
> 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`.
>
> 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
My comments are only on buster. I don't use vboxsf.
On a vfat USB stick, emacs can create locks and autosave files as
usual, where the lock, .#filename, is a file containing the target
of what would normally be a symlink.
(BTW I'd avoid using the term "backup", and say instead, perhaps,
"alternative method".)
> - These files had permission 555 instead of 777. Changing this back (?) to 777
> resolved the problem.
Write-protecting the contents of lockfiles seems reasonable in that
their username, hostname, PID, and process start time are invariant.
However, I've been testing on a single system with a vfat filesystem,
mounted so as to give 777 permissions (to test sharing), and haven't
observed them being set that way, or changing.
I have no idea what the role of vboxsf/Windows/NTFS would be, or
would have been at the time (2019, you say) these files were created.
> 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
I don't think this is contentious.
> -> 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.
> -> 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.
Cheers,
David.
Reply to: