GNU bug report logs - #78638
30.1; When editing a remote file owned by another user, Tramp signals an error because it cannot change the file mode

Previous Next

Package: emacs;

Reported by: Michael McClennen <mmcclenn <at> geology.wisc.edu>

Date: Thu, 29 May 2025 21:10:02 UTC

Severity: normal

Found in version 30.1

Full log


Message #83 received at 78638 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: mmcclenn <at> geology.wisc.edu, eggert <at> cs.ucla.edu, 78638 <at> debbugs.gnu.org
Subject: Re: bug#78638: 30.1; When editing a remote file owned by another
 user, Tramp signals an error because it cannot change the file mode
Date: Mon, 16 Jun 2025 13:56:44 +0300
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu,  mmcclenn <at> geology.wisc.edu,  78638 <at> debbugs.gnu.org
> Date: Mon, 16 Jun 2025 12:31:59 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Hi Eli,
> 
> > So the problem is not with saving the edited buffer, the problem is
> > that backup-file doesn't work for some reason in this case.  Does
> > setting backup-by-copying non-nil solve the problem?
> 
> No.
> 
> > If not, then (as I don't have access to a system where I can do "sudo
> > useradd"), would it be possible for you to step through the code in
> > backup-buffer, and tell which part there fails and why, both with
> > backup-by-copying set to nil and non-nil?
> 
> In both cases (backup-by-copying being nil or t), backup-buffer returns
> almost immediately, because
> 
> --8<---------------cut here---------------start------------->8---
> backup-inhibited is a variable defined in ‘files.el’.
> 
> Its value is t
> Local in buffer xxx; global value is nil
> --8<---------------cut here---------------end--------------->8---
> 
> I have tested both cases like this:
> 
> --8<---------------cut here---------------start------------->8---
> # emacs -Q --eval '(setq backup-by-copying nil)' /tmp/xxx
> # emacs -Q --eval '(setq backup-by-copying t)' /tmp/xxx
> --8<---------------cut here---------------end--------------->8---

So this is because the file is in "/tmp/", is that so?

If that's the reason, this is a different problem, because AFAICT the
original recipe didn't involve a file in "/tmp/".




This bug report was last modified 32 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.