[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Strange emacs behavior after upgrade to bullseye



On Tue 20 Apr 2021 at 15:59:00 (+0200), Rainer Dorsch wrote:
> Am Dienstag, 20. April 2021, 13:50:14 CEST schrieb tomas@tuxteam.de:
> > On Tue, Apr 20, 2021 at 07:28:19AM -0400, Greg Wooledge wrote:
> > > On Tue, Apr 20, 2021 at 12:39:13PM +0200, tomas@tuxteam.de wrote:
> > > > On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> > > > > For me the crucial message is
> > > > > 
> > > > > basic-save-buffer-2: Unlocking file: Operation not permitted,
> > > > > /mnt/dor1rt/Local/ Managed/sb.blog
> > > > 
> > > > Anyway, this is a good hint. See
> > > > 
> > > >   "18.3.4 Protection against Simultaneous Editing"
> > > > 
> > > > in the Emacs user manual (or, if you prefer reading in a browser,
> > > > here [1].
> > > > 
> > > > But your permissions set up is... strange. The above behaviour
> > > > doesn't look plausible to me. Unless rd is actually root.
> > > 
> > > Or /mnt/dor1rt/Local/ is on a non-Unix file system.  Perhaps it's a
> > > removable USB device with an NTFS or FAT type file system.  Or perhaps
> > > it's some sort of network file system whose underlying implementation
> > > is not Unix-based.
> > 
> > Yes, non-Unix file system os definitely a reasonable option: the
> > /mnt/ part (and the 777 modes everywhere) could be seen as a
> > hint :-)
> 
> Yes, correct, its mounted through virtualbox (vboxsf) and the host is a window 
> system which uses NTFS (I think). From a permission perspective 777 should be 
> sufficient though. The question is why does emacs think that is not enough, and 
> opens it as read-only? And even if I toggle the read-only mode, it complains 
> while writing...

I would assume that, because the file is on a foreign system, emacs
wants to use file-locking to protect against two programs making
changes at the same time. For whatever reason, its attempts to lock
the file fail in such a way to (perhaps) think that the file is
already locked, or just open the file readonly out of an abundance
of caution (to use that trending phrase).

When you toggle the file to read/write, you're effectively overriding
either the lock or the caution. As pointed out, the complaint upon
writing is probably emacs trying to lock the file while it writes
the buffer, or to do the unlocking.

If you want to chase this down further, you could try strace, but
do send the output to a file because emacs polls continually,
which spews strace output even while you sit on your hands.

Cheers,
David.


Reply to: