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

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael McClennen <mmcclenn <at> geology.wisc.edu>
Cc: 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: Sat, 31 May 2025 09:54:42 +0300

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
> Date: Fri, 30 May 2025 19:08:09 +0000
> 
> Unfortunately, Emacs is not behaving as expected. My emacs currently has backup-by-copying = nil,
> backup-by-copying-when-linked = nil, and backup-by-copying-when-mismatch = t. That ought to result in
> copying being used in this situation, which should not cause the problem I am experiencing. 

Not necessarily.  What you describe are the default values.  They
result in copying being used only if the file-owner's user ID and
group ID do not exceed the value of
backup-by-copying-when-privileged-mismatch, which is 200 by default.
So this only uses copying by default for files owned by root and other
super-user accounts, which I'm guessing is not your case.

> I just tested this by creating a file on my local machine, changing its ownership to a different user, and then
> editing it. The file saves just fine, with no errors. The owner remains as I originally set it. Emacs also
> correctly tells me that the file has not changed since I last saved it. I tried this with various file modes, and it
> did not throw any “error setting the file mode”.
> 
> The problem is only occurring with Tramp. When I edit a remote file owned by somebody else and then save
> it, the ownership doesn’t change. As far as I am aware, that means it is using copying. But I still get the
> errors that I described in my bug report. I don’t think it is too much to ask that editing a remote file with
> Tramp should exhibit as closely as possible the same behavior as editing a local file, and in particular that it
> shouldn’t (a) throw unnecessary errors, and (b) get confused about whether or not the file has changed
> since it was last saved.

Did you try setting backup-by-copying = t ?  If not, could you please
try it and see if the problem with editing via Tramp goes away then?
This experiment should tell us whether the problem is with Tramp and
only with Tramp.  Because the alternative is that your remote files
and directories have some as yet unknown file ownership and access
issues which the Emacs core functionality doesn't handle correctly.
(The experiment with local files you did might not reproduce
accurately the exact conditions with the original remote files.)  IOW,
we need to know whether to look for the reasons in Tramp or in Emacs
core.

Thanks.

Previous Next

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