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

View this message in rfc822 format

From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "78638 <at> debbugs.gnu.org" <78638 <at> debbugs.gnu.org>
Subject: 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 20:12:07 +0000

I set the value of ‘backup-by-copying-when-privileged-mismatched’ to 10000, and the error still occurs. I then set ‘backup-by-copying’ to t, and the error still occurs. I checked the *Messages* buffer, and it reports that Emacs is using copying for this file. This is definitely an error in Tramp, not the result of proper Emacs behavior.

  — Michael McClennen

> On May 31, 2025, at 1:54 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> [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.