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
To reply to this bug, email your comments to 78638 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Thu, 29 May 2025 21:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael McClennen <mmcclenn <at> geology.wisc.edu>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 29 May 2025 21:10:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Current behavior of Emacs
-------------------------
1. Use Tramp to edit any remote file owned by a different user, where the
file mode allows you to write to it.
2. Make a change to the file, and then save it.
3. The changes are saved, but the following error is thrown:
"Error while changing file’s mode /scp:[hostname]:[filename]"
4. Make another change to the file, and save it again.
5. Emacs asks "[filename] has changed since it was last visited or
saved. Save anyway?". This message is incorrect, since the file
contents have not changed and were in fact saved correctly. Presumably, this
question is triggered because the file mode is different than expected,
but this particular case should not trigger this question.
Expected behavior
-----------------
1. Use Tramp to edit any remote file owned by a different user, where
the file mode allows you to write to it.
2. Make a change to the file, and then save it.
3. The changes should be saved, and no error should be thrown. Perhaps
the Tramp code could check whether the owner is different, and ignore
the file mode if that is the case.
4. Make another change to the file, and save it again.
5. The save should occur without any questions, provided that the contents of
the file have not changed on the remote server since the file was last
visited or saved.
Why this is important
---------------------
When editing collaboratively with a remote partner, it is important that
Emacs should tell me truthfully whether or not my partner has changed
the file before I save it. If Tramp always flags a file owned by my
partner as having been changed since I saved it, I have no way to know
whether that is actually true or not.
In GNU Emacs 30.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
Version 10.14.6 (Build 18G9323)) of 2025-02-24 built on
builder10-14.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description: macOS 12.7.1
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=10000
-DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'
Configured features:
ACL GLIB GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: ELisp/l
Minor modes in effect:
delete-selection-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
column-number-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/Users/michaelm/.emacs.d/elpa/eglot-1.18/eglot hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/eglot
Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epa derived
epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
jka-compr cl-print debug backtrace find-func perl-mode grep compile
novice cl-extra noutline outline ispell tabify face-remap cus-edit pp
cus-start help-fns radix-tree yank-media mhtml-mode css-mode smie eww
url-queue thingatpt shr pixel-fill kinsoku url-file svg xml puny mm-url
gnus nnheader gnus-util text-property-search mail-utils range wid-edit
mm-util mail-prsvr color sgml-mode dom misearch multi-isearch vc-hg
vc-git diff-mode track-changes easy-mmode vc-bzr vc-dispatcher js
c-ts-common treesit imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs tramp-cmds tramp-cache
time-stamp tramp-sh tramp trampver tramp-integration files-x
tramp-message help-mode tramp-compat xdg shell pcomplete comint ansi-osc
ring parse-time iso8601 time-date format-spec ansi-color tramp-loaddefs
dired-aux dired dired-loaddefs cperl-mode rx facemenu elec-pair delsel
cus-load info eglot-autoloads eldoc-diffstat-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)
Memory information:
((conses 16 365713 99102) (symbols 48 19681 0) (strings 32 74564 3835)
(string-bytes 1 2064538) (vectors 16 39135)
(vector-slots 8 1144840 191291) (floats 8 256 544)
(intervals 56 61413 464) (buffers 992 36))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Fri, 30 May 2025 07:35:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 29 May 2025 21:09:31 +0000
> From: Michael McClennen via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
>
> Current behavior of Emacs
> -------------------------
>
> 1. Use Tramp to edit any remote file owned by a different user, where the
> file mode allows you to write to it.
>
> 2. Make a change to the file, and then save it.
>
> 3. The changes are saved, but the following error is thrown:
> "Error while changing file’s mode /scp:[hostname]:[filename]"
>
> 4. Make another change to the file, and save it again.
>
> 5. Emacs asks "[filename] has changed since it was last visited or
> saved. Save anyway?". This message is incorrect, since the file
> contents have not changed and were in fact saved correctly. Presumably, this
> question is triggered because the file mode is different than expected,
> but this particular case should not trigger this question.
>
> Expected behavior
> -----------------
>
> 1. Use Tramp to edit any remote file owned by a different user, where
> the file mode allows you to write to it.
>
> 2. Make a change to the file, and then save it.
>
> 3. The changes should be saved, and no error should be thrown. Perhaps
> the Tramp code could check whether the owner is different, and ignore
> the file mode if that is the case.
>
> 4. Make another change to the file, and save it again.
>
> 5. The save should occur without any questions, provided that the contents of
> the file have not changed on the remote server since the file was last
> visited or saved.
>
> Why this is important
> ---------------------
>
> When editing collaboratively with a remote partner, it is important that
> Emacs should tell me truthfully whether or not my partner has changed
> the file before I save it. If Tramp always flags a file owned by my
> partner as having been changed since I saved it, I have no way to know
> whether that is actually true or not.
Please read the node "Backup Copying" in the Emacs user manual. I
think Emacs behaves as expected in this case, because the default
method of saving a file also makes you the owner of the file, and that
is not always allowed when you edit files owned by a different user
(presumably in a directory owned by that user). What you need in
these cases is to set either backup-by-copying to t or
backup-by-copying-when-mismatch to nil (and perhaps increase
backup-by-copying-when-privileged-mismatch to a very large number), so
that backup files are created by copying and not by renaming.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sat, 31 May 2025 06:55:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 78638 <at> debbugs.gnu.org (full text, mbox):
[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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sat, 31 May 2025 20:13:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78638 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 01 Jun 2025 05:21:07 GMT)
Full text and
rfc822 format available.
Message #17 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
> CC: "78638 <at> debbugs.gnu.org" <78638 <at> debbugs.gnu.org>
> 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.
Thanks, I agree with your conclusion.
Michael, could you please look into this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 01 Jun 2025 16:43:04 GMT)
Full text and
rfc822 format available.
Message #20 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi,
>> 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.
>
> Thanks, I agree with your conclusion.
>
> Michael, could you please look into this?
Will do.
Michael: as a first step, I'd like to gather more information. Michael,
could you pls start a new Emacs session like this:
--8<---------------cut here---------------start------------->8---
# emacs -Q -l tramp --eval '(setq tramp-verbose 6 backup-by-copying t)'
--8<---------------cut here---------------end--------------->8---
Provoke the error on a remote host. Describe in detail, which steps you
have performed in order to see the error.
There will be a Tramp debug buffer. Pls send it as attachment here.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Wed, 11 Jun 2025 23:25:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78638 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Michael,
I have done as you asked. Here are the steps I took, in detail:
1. Run emacs with the arguments listed below.
2. Hit c-x c-f.
3. Opened the file “/scp:taphonomy:/var/paleobiodb/frontend/pbdb-app/collections/collections.html”. The file is owned by somebody else, but its mode bits allow me to edit it.
4. Made a single change to the file.
5. Hit c-x c-s.
6. Heard a beep
7. The minibuffer displays the error message "File error: Error while changing file’s mode /scp:taphonomy:/var/paleobiodb/frontend/pbdb-app/collections/collections.html”
8. Hit c-x c-s again.
9. The minibuffer displays the message "collections.html has changed since visited or saved. Save anyway? (yes or no) “. This is erroneous, since the file has not in fact changed on disk since I saved it a moment ago.
10. Hit c-x c-f
11. Opened the same file again. Verified that the single change I made was saved to disk, and no other changes were made to the file.
I have attached the contents of the buffer *debug tramp/scp taphonomy*
I hope this helps. Thank you for responding to this issue!
— Michael McClennen
> On Jun 1, 2025, at 11:42 AM, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi,
>
>>> 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.
>>
>> Thanks, I agree with your conclusion.
>>
>> Michael, could you please look into this?
>
> Will do.
>
> Michael: as a first step, I'd like to gather more information. Michael,
> could you pls start a new Emacs session like this:
>
> --8<---------------cut here---------------start------------->8---
> # emacs -Q -l tramp --eval '(setq tramp-verbose 6 backup-by-copying t)'
> --8<---------------cut here---------------end--------------->8---
>
> Provoke the error on a remote host. Describe in detail, which steps you
> have performed in order to see the error.
>
> There will be a Tramp debug buffer. Pls send it as attachment here.
>
> Best regards, Michael.
[Message part 2 (text/html, inline)]
[emacs-tramp-debug.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Thu, 12 Jun 2025 10:26:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Michael McClennen <mmcclenn <at> geology.wisc.edu> writes:
> Hello Michael,
Hi Michael,
> I have done as you asked. Here are the steps I took, in detail:
>
> 1. Run emacs with the arguments listed below.
> 2. Hit c-x c-f.
> 3. Opened the file
> “/scp:taphonomy:/var/paleobiodb/frontend/pbdb-app/collections/collections.html”.
> The file is owned by somebody else, but its mode bits allow me to edit
> it.
Hmm. The file has the attributes:
--8<---------------cut here---------------start------------->8---
18:07:21.527949 tramp-send-command (6) # tramp_stat_file_attributes /var/paleobiodb/frontend/pbdb-app/collections/collections.html 2>/dev/null; echo tramp_exit_status $?
18:07:21.589164 tramp-wait-for-regexp (6) #
(("‘/var/paleobiodb/frontend/pbdb-app/collections/collections.html’") 1 ("bnoushin7" . 29012) ("pbdb" . 1000) 1749680914 1749680900 1749680900 84008 "-rw-rw-r--" t 1847394 -1)
--8<---------------cut here---------------end--------------->8---
Your remote identity is:
--8<---------------cut here---------------start------------->8---
18:07:21.758801 tramp-send-command (6) # /bin/id
18:07:21.824346 tramp-wait-for-regexp (6) #
uid=1000(mmcclenn) gid=1000(pbdb) groups=1000(pbdb),119(docker),22999(sudo_passwd)
--8<---------------cut here---------------end--------------->8---
So indeed, the group id "pbdb" should be sufficient for editing. After
saving your edits, the used local temporary file is copied to remote:
--8<---------------cut here---------------start------------->8---
18:07:40.213573 tramp-do-copy-or-rename-file-out-of-band (6) # scp -T -q -r -o ControlMaster=auto -o ControlPath=tramp.%C -o ControlPersist=no /var/folders/rd/94y9m04x2v1cttshz_mprjdr0000gp/T/tramp.NtIfrx.html taphonomy:/var/paleobiodb/frontend/pbdb-app/collections/collections.html
--8<---------------cut here---------------end--------------->8---
This succeeds. However, the next step, changing the file mode of the
copied file fails. And this is reported as error:
--8<---------------cut here---------------start------------->8---
18:07:40.559966 tramp-send-command (6) # chmod 664 /var/paleobiodb/frontend/pbdb-app/collections/collections.html 2>/dev/null; echo tramp_exit_status $?
18:07:40.626488 tramp-wait-for-regexp (6) #
tramp_exit_status 1
18:07:40.627115 tramp-barf-unless-okay (1) # File error: Error while changing file’s mode /scp:taphonomy:/var/paleobiodb/frontend/pbdb-app/collections/collections.html
--8<---------------cut here---------------end--------------->8---
But the file has a changed modification time (1749683260) and size
(84009), which is proper:
--8<---------------cut here---------------start------------->8---
18:08:45.246430 tramp-send-command (6) # tramp_stat_file_attributes /var/paleobiodb/frontend/pbdb-app/collections/collections.html 2>/dev/null; echo tramp_exit_status $?
18:08:45.307161 tramp-wait-for-regexp (6) #
(("‘/var/paleobiodb/frontend/pbdb-app/collections/collections.html’") 1 ("bnoushin7" . 29012) ("pbdb" . 1000) 1749680914 1749683260 1749683260 84009 "-rw-rw-r--" t 1847394 -1)
--8<---------------cut here---------------end--------------->8---
So the chmod command fails.
Since Emacs 30.1, there is the user option
tramp-inhibit-errors-if-setting-file-attributes-fail. See (info "(tramp)
Frequently Asked Questions")
--8<---------------cut here---------------start------------->8---
• How to ignore errors when changing file attributes?
Sometimes, for example while saving remote files, errors appear
when changing file attributes like permissions, time stamps, or
ownership. If these errors can be ignored, set user option
‘tramp-inhibit-errors-if-setting-file-attributes-fail’ to a
non-‘nil’ value. This transforms the error into a warning.
--8<---------------cut here---------------end--------------->8---
> I hope this helps. Thank you for responding to this issue!
>
> — Michael McClennen
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Thu, 12 Jun 2025 11:15:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, "78638 <at> debbugs.gnu.org"
> <78638 <at> debbugs.gnu.org>
> Date: Thu, 12 Jun 2025 12:24:48 +0200
>
> So indeed, the group id "pbdb" should be sufficient for editing. After
> saving your edits, the used local temporary file is copied to remote:
>
> --8<---------------cut here---------------start------------->8---
> 18:07:40.213573 tramp-do-copy-or-rename-file-out-of-band (6) # scp -T -q -r -o ControlMaster=auto -o ControlPath=tramp.%C -o ControlPersist=no /var/folders/rd/94y9m04x2v1cttshz_mprjdr0000gp/T/tramp.NtIfrx.html taphonomy:/var/paleobiodb/frontend/pbdb-app/collections/collections.html
> --8<---------------cut here---------------end--------------->8---
>
> This succeeds. However, the next step, changing the file mode of the
> copied file fails. And this is reported as error:
>
> --8<---------------cut here---------------start------------->8---
> 18:07:40.559966 tramp-send-command (6) # chmod 664 /var/paleobiodb/frontend/pbdb-app/collections/collections.html 2>/dev/null; echo tramp_exit_status $?
> 18:07:40.626488 tramp-wait-for-regexp (6) #
> tramp_exit_status 1
> 18:07:40.627115 tramp-barf-unless-okay (1) # File error: Error while changing file’s mode /scp:taphonomy:/var/paleobiodb/frontend/pbdb-app/collections/collections.html
> --8<---------------cut here---------------end--------------->8---
>
> But the file has a changed modification time (1749683260) and size
> (84009), which is proper:
>
> --8<---------------cut here---------------start------------->8---
> 18:08:45.246430 tramp-send-command (6) # tramp_stat_file_attributes /var/paleobiodb/frontend/pbdb-app/collections/collections.html 2>/dev/null; echo tramp_exit_status $?
> 18:08:45.307161 tramp-wait-for-regexp (6) #
> (("‘/var/paleobiodb/frontend/pbdb-app/collections/collections.html’") 1 ("bnoushin7" . 29012) ("pbdb" . 1000) 1749680914 1749683260 1749683260 84009 "-rw-rw-r--" t 1847394 -1)
> --8<---------------cut here---------------end--------------->8---
>
> So the chmod command fails.
>
> Since Emacs 30.1, there is the user option
> tramp-inhibit-errors-if-setting-file-attributes-fail. See (info "(tramp)
> Frequently Asked Questions")
>
> --8<---------------cut here---------------start------------->8---
> • How to ignore errors when changing file attributes?
>
> Sometimes, for example while saving remote files, errors appear
> when changing file attributes like permissions, time stamps, or
> ownership. If these errors can be ignored, set user option
> ‘tramp-inhibit-errors-if-setting-file-attributes-fail’ to a
> non-‘nil’ value. This transforms the error into a warning.
> --8<---------------cut here---------------end--------------->8---
Yes, but why does chmod fail? Can we see the error message from chmod
in that case, instead of redirecting its stderr to /dev/null?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Thu, 12 Jun 2025 12:43:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> --8<---------------cut here---------------start------------->8---
>> • How to ignore errors when changing file attributes?
>>
>> Sometimes, for example while saving remote files, errors appear
>> when changing file attributes like permissions, time stamps, or
>> ownership. If these errors can be ignored, set user option
>> ‘tramp-inhibit-errors-if-setting-file-attributes-fail’ to a
>> non-‘nil’ value. This transforms the error into a warning.
>> --8<---------------cut here---------------end--------------->8---
>
> Yes, but why does chmod fail? Can we see the error message from chmod
> in that case, instead of redirecting its stderr to /dev/null?
On a remote machine, I have mimicked the situation. There is a file
--8<---------------cut here---------------start------------->8---
# ls -al /tmp/xxx
-rw-rw-r-- 1 sigrid everyone 0 2025-06-12 14:15 /tmp/xxx
--8<---------------cut here---------------end--------------->8---
"sigrid" and "albinus" (me) are users on that machine:
--8<---------------cut here---------------start------------->8---
# id
uid=500(albinus) gid=100(everyone) groups=0(administrators),100(everyone)
# id sigrid
uid=506(sigrid) gid=100(everyone) groups=100(everyone)
--8<---------------cut here---------------end--------------->8---
But I ("albinus") cannot change the permissions of /tmp/xxx
--8<---------------cut here---------------start------------->8---
# chmod 775 /tmp/xxx
chmod: /tmp/xxx: Operation not permitted
--8<---------------cut here---------------end--------------->8---
Likely, this is due to missing permissions in the upper directory.
Michael, what do the following commands return on the remote machine:
--8<---------------cut here---------------start------------->8---
# getfacl -ac /var/paleobiodb/frontend/pbdb-app/collections
# ls -ld /var/paleobiodb/frontend/pbdb-app/collections
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Thu, 12 Jun 2025 16:23:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
> Date: Thu, 12 Jun 2025 14:42:44 +0200
>
> > Yes, but why does chmod fail? Can we see the error message from chmod
> > in that case, instead of redirecting its stderr to /dev/null?
>
> On a remote machine, I have mimicked the situation. There is a file
>
> --8<---------------cut here---------------start------------->8---
> # ls -al /tmp/xxx
> -rw-rw-r-- 1 sigrid everyone 0 2025-06-12 14:15 /tmp/xxx
> --8<---------------cut here---------------end--------------->8---
>
> "sigrid" and "albinus" (me) are users on that machine:
>
> --8<---------------cut here---------------start------------->8---
> # id
> uid=500(albinus) gid=100(everyone) groups=0(administrators),100(everyone)
> # id sigrid
> uid=506(sigrid) gid=100(everyone) groups=100(everyone)
> --8<---------------cut here---------------end--------------->8---
>
> But I ("albinus") cannot change the permissions of /tmp/xxx
>
> --8<---------------cut here---------------start------------->8---
> # chmod 775 /tmp/xxx
> chmod: /tmp/xxx: Operation not permitted
> --8<---------------cut here---------------end--------------->8---
>
> Likely, this is due to missing permissions in the upper directory.
If the permission of the parent directory are the problem, then the
same problem could happen with local files, right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Fri, 13 Jun 2025 14:12:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Likely, this is due to missing permissions in the upper directory.
>
> If the permission of the parent directory are the problem, then the
> same problem could happen with local files, right?
Likely, I am wrong. As Andreas Schwab wrote, to be able to chmod a file
you need to be owner (or privileged), other permissions are not
relevant.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Fri, 13 Jun 2025 15:19:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2025 16:11:06 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli,
>
> >> Likely, this is due to missing permissions in the upper directory.
> >
> > If the permission of the parent directory are the problem, then the
> > same problem could happen with local files, right?
>
> Likely, I am wrong. As Andreas Schwab wrote, to be able to chmod a file
> you need to be owner (or privileged), other permissions are not
> relevant.
Again, this can happen with local files as well. And AFAIU
backup-by-copying should have handled that situation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sat, 14 Jun 2025 14:03:08 GMT)
Full text and
rfc822 format available.
Message #44 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> >> Likely, this is due to missing permissions in the upper directory.
>> >
>> > If the permission of the parent directory are the problem, then the
>> > same problem could happen with local files, right?
>>
>> Likely, I am wrong. As Andreas Schwab wrote, to be able to chmod a file
>> you need to be owner (or privileged), other permissions are not
>> relevant.
>
> Again, this can happen with local files as well. And AFAIU
> backup-by-copying should have handled that situation.
I've reproduced the problem with local files, no Tramp involved. It
happens also, both with setting backup-by-copying to nil or t.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sat, 14 Jun 2025 15:17:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
> Date: Sat, 14 Jun 2025 16:01:56 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli,
>
> >> >> Likely, this is due to missing permissions in the upper directory.
> >> >
> >> > If the permission of the parent directory are the problem, then the
> >> > same problem could happen with local files, right?
> >>
> >> Likely, I am wrong. As Andreas Schwab wrote, to be able to chmod a file
> >> you need to be owner (or privileged), other permissions are not
> >> relevant.
> >
> > Again, this can happen with local files as well. And AFAIU
> > backup-by-copying should have handled that situation.
>
> I've reproduced the problem with local files, no Tramp involved. It
> happens also, both with setting backup-by-copying to nil or t.
So it is no longer a Tramp issue.
Can you show a full recipe to reproduce it?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sat, 14 Jun 2025 17:06:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 78638 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Michael,
As you suggested, setting tramp-inhibit-errors-if-setting-file-attributes-fail to t solved the problem. Thank you for this information!
However, I think the best long-term solution would be to fix Tramp so as not to make this step necessary. Perhaps a check could be added so that the chmod command is not run unless the remote file is owned by the user?
I set up the same situation on my local machine, and the error does not occur locally. I tried it with backup-by-copying set to both nil and t, and in neither case do I get the error.
My local machine is running MacOS, whereas the remote machine is running Ubuntu, so that may have something to do with the difference.
— Michael McClennen
On Jun 12, 2025, at 5:24 AM, Michael Albinus <michael.albinus <at> gmx.de<mailto:michael.albinus <at> gmx.de>> wrote:
Since Emacs 30.1, there is the user option
tramp-inhibit-errors-if-setting-file-attributes-fail. See (info "(tramp)
Frequently Asked Questions")
--8<---------------cut here---------------start------------->8---
• How to ignore errors when changing file attributes?
Sometimes, for example while saving remote files, errors appear
when changing file attributes like permissions, time stamps, or
ownership. If these errors can be ignored, set user option
‘tramp-inhibit-errors-if-setting-file-attributes-fail’ to a
non-‘nil’ value. This transforms the error into a warning.
--8<---------------cut here---------------end--------------->8---
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sat, 14 Jun 2025 17:13:03 GMT)
Full text and
rfc822 format available.
Message #53 received at 78638 <at> debbugs.gnu.org (full text, mbox):
The remote directory has mode 775, so I am able to create files there as well as edit them.
> On Jun 12, 2025, at 7:42 AM, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Likely, this is due to missing permissions in the upper directory.
>
> Michael, what do the following commands return on the remote machine:
>
> --8<---------------cut here---------------start------------->8---
> # getfacl -ac /var/paleobiodb/frontend/pbdb-app/collections
> # ls -ld /var/paleobiodb/frontend/pbdb-app/collections
> --8<---------------cut here---------------end--------------->8---
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 07:42:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> I've reproduced the problem with local files, no Tramp involved. It
>> happens also, both with setting backup-by-copying to nil or t.
>
> So it is no longer a Tramp issue.
>
> Can you show a full recipe to reproduce it?
I've added a new user testuser1 on my Fedora machine, which uses the
same group albinus as I do:
--8<---------------cut here---------------start------------->8---
# sudo useradd -g albinus testuser1
# id albinus
uid=1000(albinus) gid=1000(albinus) groups=1000(albinus),4(adm),10(wheel),984(libvirt),1001(docker),1002(podman),1008(plugdev)
# id testuser1
uid=1007(testuser1) gid=1000(albinus) groups=1000(albinus)
--8<---------------cut here---------------end--------------->8---
I've created a new file /tmp/xxx as user testuser1 with proper permissions
--8<---------------cut here---------------start------------->8---
# sudo -u testuser1 touch /tmp/xxx
# sudo chmod 660 /tmp/xxx
# ll /tmp/xxx
-rw-rw----. 1 testuser1 albinus 0 Jun 15 09:17 /tmp/xxx
--8<---------------cut here---------------end--------------->8---
I've opened the file in Emacs (as user albinus), edited it, and tried to
save:
--8<---------------cut here---------------start------------->8---
# emacs -Q /tmp/xxx
--8<---------------cut here---------------end--------------->8---
There is the error
--8<---------------cut here---------------start------------->8---
basic-save-buffer-2: Opening output file: Permission denied, /tmp/xxx
--8<---------------cut here---------------end--------------->8---
Michael mentioned, that there was no problem on his local macOS
machine. So I reran a similar test on a FreeBSD 14 VM, and indeed,
there's no error.
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 07:53:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Michael McClennen <mmcclenn <at> geology.wisc.edu> writes:
> Hi Michael,
Hi Michael.
> However, I think the best long-term solution would be to fix Tramp so
> as not to make this step necessary. Perhaps a check could be added so
> that the chmod command is not run unless the remote file is owned by
> the user?
We've discussed this already on the Tramp ML, see
<https://lists.gnu.org/archive/html/tramp-devel/2024-04/msg00005.html>. I
believe it would be too much testing in Tramp, with related performance
degradation. The test needs to be more complex, not only for the ownership
of the file. As you have shown, on macOS (and *BSD, see my other message
to Eli), it works also for files not owned by the same user.
So no, use the option.
> — Michael McClennen
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 08:17:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
> Date: Sun, 15 Jun 2025 09:41:09 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Can you show a full recipe to reproduce it?
>
> I've added a new user testuser1 on my Fedora machine, which uses the
> same group albinus as I do:
>
> --8<---------------cut here---------------start------------->8---
> # sudo useradd -g albinus testuser1
> # id albinus
> uid=1000(albinus) gid=1000(albinus) groups=1000(albinus),4(adm),10(wheel),984(libvirt),1001(docker),1002(podman),1008(plugdev)
> # id testuser1
> uid=1007(testuser1) gid=1000(albinus) groups=1000(albinus)
> --8<---------------cut here---------------end--------------->8---
>
> I've created a new file /tmp/xxx as user testuser1 with proper permissions
>
> --8<---------------cut here---------------start------------->8---
> # sudo -u testuser1 touch /tmp/xxx
> # sudo chmod 660 /tmp/xxx
> # ll /tmp/xxx
> -rw-rw----. 1 testuser1 albinus 0 Jun 15 09:17 /tmp/xxx
> --8<---------------cut here---------------end--------------->8---
>
> I've opened the file in Emacs (as user albinus), edited it, and tried to
> save:
>
> --8<---------------cut here---------------start------------->8---
> # emacs -Q /tmp/xxx
> --8<---------------cut here---------------end--------------->8---
>
> There is the error
>
> --8<---------------cut here---------------start------------->8---
> basic-save-buffer-2: Opening output file: Permission denied, /tmp/xxx
> --8<---------------cut here---------------end--------------->8---
Thanks. Can I ask you to show a Lisp backtrace from this error?
In any case, this is not about chmod, it's about opening the file, so
I'm not sure what Andreas said is the root cause here.
> Michael mentioned, that there was no problem on his local macOS
> machine. So I reran a similar test on a FreeBSD 14 VM, and indeed,
> there's no error.
We'd need to address this subtlety after we understand what happens on
Fedora.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 08:44:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
> Date: Sun, 15 Jun 2025 11:16:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > --8<---------------cut here---------------start------------->8---
> > basic-save-buffer-2: Opening output file: Permission denied, /tmp/xxx
> > --8<---------------cut here---------------end--------------->8---
>
> Thanks. Can I ask you to show a Lisp backtrace from this error?
Actually, what is interesting is the line of basic-save-buffer-2 which
signaled the error. Is it possible for you to figure that out?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 10:56:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
>> Date: Sun, 15 Jun 2025 11:16:35 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> > --8<---------------cut here---------------start------------->8---
>> > basic-save-buffer-2: Opening output file: Permission denied, /tmp/xxx
>> > --8<---------------cut here---------------end--------------->8---
>>
>> Thanks. Can I ask you to show a Lisp backtrace from this error?
>
> Actually, what is interesting is the line of basic-save-buffer-2 which
> signaled the error. Is it possible for you to figure that out?
Line 6309 in files.el:
--8<---------------cut here---------------start------------->8---
(write-region nil nil
buffer-file-name nil t buffer-file-truename)
--8<---------------cut here---------------end--------------->8---
And the error is raised in line 5536 of fileio.c:
--8<---------------cut here---------------start------------->8---
(gdb) n
5536 report_file_errno ("Opening output file", filename, open_errno);
(gdb) bt
#0 write_region (start=<optimized out>, end=<optimized out>, filename=0x9c9364, append=0x0, visit=<optimized out>, lockname=0x1302a84, mustbenew=<optimized out>, desc=-1) at fileio.c:5536
#1 0x000000000058438f in Fwrite_region (start=<optimized out>, end=<optimized out>, filename=<optimized out>, append=<optimized out>, visit=<optimized out>, lockname=<optimized out>, mustbenew=0x0) at fileio.c:5383
#2 0x00000000005d0b3b in funcall_subr (subr=<optimized out>, numargs=<optimized out>, args=<optimized out>) at eval.c:3231
#3 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd798) at eval.c:3151
#4 0x00007ffff0c08ed4 in F62617369632d736176652d6275666665722d32_basic_save_buffer_2_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
#5 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd830) at eval.c:3151
#6 0x00007ffff0c083e9 in F62617369632d736176652d6275666665722d31_basic_save_buffer_1_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
#7 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd8d8) at eval.c:3151
#8 0x00007ffff0c07afd in F62617369632d736176652d627566666572_basic_save_buffer_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
#9 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd970) at eval.c:3151
#10 0x00007ffff0c06faf in F736176652d627566666572_save_buffer_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
#11 0x00000000005d2817 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffda58) at eval.c:3151
#12 0x00000000005cb244 in Ffuncall_interactively (nargs=2, args=0x7fffffffda58) at callint.c:250
#13 0x00000000005d2817 in Ffuncall (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffda50) at eval.c:3151
#14 0x00000000005cbbde in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>, keys=<optimized out>) at callint.c:789
#15 0x00007ffff0aa31e5 in F636f6d6d616e642d65786563757465_command_execute_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/simple-fab5b0cf-9e866eaa.eln
#16 0x00000000005d2817 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffdd40) at eval.c:3151
#17 0x0000000000554924 in command_loop_1 () at keyboard.c:1545
#18 0x00000000005cde34 in internal_condition_case (bfun=bfun <at> entry=0x554550 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5474d0 <cmd_error>) at eval.c:1684
#19 0x000000000053f242 in command_loop_2 (handlers=0x90) at keyboard.c:1163
#20 0x00000000005cdd8e in internal_catch (tag=tag <at> entry=0x125d0, func=func <at> entry=0x53f220 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1364
#21 0x000000000053f1df in command_loop () at keyboard.c:1141
#22 0x0000000000547081 in recursive_edit_1 () at keyboard.c:749
#23 0x000000000054740e in Frecursive_edit () at keyboard.c:832
#24 0x0000000000411c06 in main (argc=3, argv=<optimized out>) at emacs.c:2582
Lisp Backtrace:
"write-region" (0xffffd7a0)
"basic-save-buffer-2" (0xffffd838)
"basic-save-buffer-1" (0xffffd8e0)
"basic-save-buffer" (0xffffd978)
"save-buffer" (0xffffda60)
"funcall-interactively" (0xffffda58)
"command-execute" (0xffffdd48)
(gdb)
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 13:03:04 GMT)
Full text and
rfc822 format available.
Message #71 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
> Date: Sun, 15 Jun 2025 12:55:38 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli,
>
> >> Cc: mmcclenn <at> geology.wisc.edu, 78638 <at> debbugs.gnu.org
> >> Date: Sun, 15 Jun 2025 11:16:35 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >>
> >> > --8<---------------cut here---------------start------------->8---
> >> > basic-save-buffer-2: Opening output file: Permission denied, /tmp/xxx
> >> > --8<---------------cut here---------------end--------------->8---
> >>
> >> Thanks. Can I ask you to show a Lisp backtrace from this error?
> >
> > Actually, what is interesting is the line of basic-save-buffer-2 which
> > signaled the error. Is it possible for you to figure that out?
>
> Line 6309 in files.el:
>
> --8<---------------cut here---------------start------------->8---
> (write-region nil nil
> buffer-file-name nil t buffer-file-truename)
> --8<---------------cut here---------------end--------------->8---
>
> And the error is raised in line 5536 of fileio.c:
>
> --8<---------------cut here---------------start------------->8---
> (gdb) n
> 5536 report_file_errno ("Opening output file", filename, open_errno);
Thanks. Is this with backup-by-copying = t or nil? Also, does the
file /tmp/xxx exist at this point with the original owner and modes
before you edited and saved it?
> (gdb) bt
> #0 write_region (start=<optimized out>, end=<optimized out>, filename=0x9c9364, append=0x0, visit=<optimized out>, lockname=0x1302a84, mustbenew=<optimized out>, desc=-1) at fileio.c:5536
> #1 0x000000000058438f in Fwrite_region (start=<optimized out>, end=<optimized out>, filename=<optimized out>, append=<optimized out>, visit=<optimized out>, lockname=<optimized out>, mustbenew=0x0) at fileio.c:5383
> #2 0x00000000005d0b3b in funcall_subr (subr=<optimized out>, numargs=<optimized out>, args=<optimized out>) at eval.c:3231
> #3 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd798) at eval.c:3151
> #4 0x00007ffff0c08ed4 in F62617369632d736176652d6275666665722d32_basic_save_buffer_2_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
> #5 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd830) at eval.c:3151
> #6 0x00007ffff0c083e9 in F62617369632d736176652d6275666665722d31_basic_save_buffer_1_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
> #7 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd8d8) at eval.c:3151
> #8 0x00007ffff0c07afd in F62617369632d736176652d627566666572_basic_save_buffer_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
> #9 0x00000000005d2817 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd970) at eval.c:3151
> #10 0x00007ffff0c06faf in F736176652d627566666572_save_buffer_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/files-1e8937b2-7dcbec5d.eln
> #11 0x00000000005d2817 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffda58) at eval.c:3151
> #12 0x00000000005cb244 in Ffuncall_interactively (nargs=2, args=0x7fffffffda58) at callint.c:250
> #13 0x00000000005d2817 in Ffuncall (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffda50) at eval.c:3151
> #14 0x00000000005cbbde in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>, keys=<optimized out>) at callint.c:789
> #15 0x00007ffff0aa31e5 in F636f6d6d616e642d65786563757465_command_execute_0 () at /home/albinus/src/emacs/src/../native-lisp/31.0.50-289b8565/preloaded/simple-fab5b0cf-9e866eaa.eln
> #16 0x00000000005d2817 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffdd40) at eval.c:3151
> #17 0x0000000000554924 in command_loop_1 () at keyboard.c:1545
> #18 0x00000000005cde34 in internal_condition_case (bfun=bfun <at> entry=0x554550 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5474d0 <cmd_error>) at eval.c:1684
> #19 0x000000000053f242 in command_loop_2 (handlers=0x90) at keyboard.c:1163
> #20 0x00000000005cdd8e in internal_catch (tag=tag <at> entry=0x125d0, func=func <at> entry=0x53f220 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1364
> #21 0x000000000053f1df in command_loop () at keyboard.c:1141
> #22 0x0000000000547081 in recursive_edit_1 () at keyboard.c:749
> #23 0x000000000054740e in Frecursive_edit () at keyboard.c:832
> #24 0x0000000000411c06 in main (argc=3, argv=<optimized out>) at emacs.c:2582
>
> Lisp Backtrace:
> "write-region" (0xffffd7a0)
> "basic-save-buffer-2" (0xffffd838)
> "basic-save-buffer-1" (0xffffd8e0)
> "basic-save-buffer" (0xffffd978)
> "save-buffer" (0xffffda60)
> "funcall-interactively" (0xffffda58)
> "command-execute" (0xffffdd48)
> (gdb)
> --8<---------------cut here---------------end--------------->8---
>
> Best regards, Michael.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 13:52:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Line 6309 in files.el:
>>
>> --8<---------------cut here---------------start------------->8---
>> (write-region nil nil
>> buffer-file-name nil t buffer-file-truename)
>> --8<---------------cut here---------------end--------------->8---
>>
>> And the error is raised in line 5536 of fileio.c:
>>
>> --8<---------------cut here---------------start------------->8---
>> (gdb) n
>> 5536 report_file_errno ("Opening output file", filename, open_errno);
>
> Thanks. Is this with backup-by-copying = t or nil? Also, does the
> file /tmp/xxx exist at this point with the original owner and modes
> before you edited and saved it?
I've started 'emacs -Q', so it is the default: nil
And yes, it is still the file owned by another user:
--8<---------------cut here---------------start------------->8---
# ll /tmp/xxx
-rw-rw----. 1 testuser1 albinus 0 Jun 15 09:17 /tmp/xxx
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Sun, 15 Jun 2025 14:10:05 GMT)
Full text and
rfc822 format available.
Message #77 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, mmcclenn <at> geology.wisc.edu,
> 78638 <at> debbugs.gnu.org
> Date: Sun, 15 Jun 2025 15:50:54 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli,
>
> >> Line 6309 in files.el:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> (write-region nil nil
> >> buffer-file-name nil t buffer-file-truename)
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> And the error is raised in line 5536 of fileio.c:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> (gdb) n
> >> 5536 report_file_errno ("Opening output file", filename, open_errno);
> >
> > Thanks. Is this with backup-by-copying = t or nil? Also, does the
> > file /tmp/xxx exist at this point with the original owner and modes
> > before you edited and saved it?
>
> I've started 'emacs -Q', so it is the default: nil
>
> And yes, it is still the file owned by another user:
>
> --8<---------------cut here---------------start------------->8---
> # ll /tmp/xxx
> -rw-rw----. 1 testuser1 albinus 0 Jun 15 09:17 /tmp/xxx
> --8<---------------cut here---------------end--------------->8---
Thanks.
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?
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Mon, 16 Jun 2025 10:33:03 GMT)
Full text and
rfc822 format available.
Message #80 received at 78638 <at> debbugs.gnu.org (full text, mbox):
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---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Mon, 16 Jun 2025 10:58:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 78638 <at> debbugs.gnu.org (full text, mbox):
> 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/".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Mon, 16 Jun 2025 12:09:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> So this is because the file is in "/tmp/", is that so?
Indeed. I've moved the file to ~/tmp/xxx, and now saving and
backup works w/o any problem, whatever value of backup-by-copying.
--8<---------------cut here---------------start------------->8---
# ll -d ~/tmp ~/tmp/xxx*
drwxrwxr-x. 11 albinus albinus 16384 Jun 16 13:58 /home/albinus/tmp
-rw-rw----. 1 testuser1 albinus 7 Jun 16 13:58 /home/albinus/tmp/xxx
-rw-rw----. 1 albinus albinus 4 Jun 16 13:57 /home/albinus/tmp/xxx~
--8<---------------cut here---------------end--------------->8---
> If that's the reason, this is a different problem, because AFAICT the
> original recipe didn't involve a file in "/tmp/".
Yep. The original error was a failing chmod command. This has been
discussed already with the OP, so I guess there's nothing left to do.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Tue, 24 Jun 2025 02:18:03 GMT)
Full text and
rfc822 format available.
Message #89 received at 78638 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
When Emacs saves a file directly, its preferred method is to write the
file under another name and then ewnames it into the desired name.
That is to avoid problems like this.
Should Tramp do it that way too?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Tue, 24 Jun 2025 06:56:04 GMT)
Full text and
rfc822 format available.
Message #92 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
Hi Richard,
> When Emacs saves a file directly, its preferred method is to write the
> file under another name and then ewnames it into the desired name.
> That is to avoid problems like this.
>
> Should Tramp do it that way too?
This is what Tramp does. It writes the file to a local temporary name,
and copies it then to the remote side. The error happened when calling
"chmod ..." afterwards.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Fri, 27 Jun 2025 02:52:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 78638 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > When Emacs saves a file directly, its preferred method is to write the
> > file under another name and then ewnames it into the desired name.
> > That is to avoid problems like this.
> This is what Tramp does. It writes the file to a local temporary name,
> and copies it then to the remote side.
Those two methods are different in a crucial way. Whan Emacs usually
does is _rename_ the temporary file, which it has written in the
destination directory, to the desired name. It sounds like Tramp
writes a temporary file in the local machine, then _copies_ the
temporary file to the desired name in the destination directory.
That difference, renaming vs copying, may be the reason why Tramp runs
into a problem trying to do chmod. For Emacs, it is actually the
initial output _name_ which is temporary; that output file will
remain, once renamed, under the final name.
Is it possible for Tramp to write the output into a remote file
in the intended remote directory, then rename it to the intended
file name?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Tue, 08 Jul 2025 16:37:04 GMT)
Full text and
rfc822 format available.
Message #98 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
Hi Richard,
> > > When Emacs saves a file directly, its preferred method is to write the
> > > file under another name and then ewnames it into the desired name.
> > > That is to avoid problems like this.
>
> > This is what Tramp does. It writes the file to a local temporary name,
> > and copies it then to the remote side.
>
> Those two methods are different in a crucial way. Whan Emacs usually
> does is _rename_ the temporary file, which it has written in the
> destination directory, to the desired name. It sounds like Tramp
> writes a temporary file in the local machine, then _copies_ the
> temporary file to the desired name in the destination directory.
>
> Is it possible for Tramp to write the output into a remote file
> in the intended remote directory, then rename it to the intended
> file name?
Tramp writes a local temporary file for a reason: In general, Emacs
cannot write a file to the remote host directly. It needs external help
(like scp and alike) to transfer a local file to the remote side.
Tramp could write a local temporary file, transfer it to a remote
temporary file, and rename the remote temporary file to the intended
file name. But this would require an additional step, which will be not
acceptable for performance reasons.
Note, that the root case of this bug was Tramp calling chmod, not the
copying action itself. Annoying, but not the end of the word.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Thu, 10 Jul 2025 02:23:10 GMT)
Full text and
rfc822 format available.
Message #101 received at 78638 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Tramp could write a local temporary file, transfer it to a remote
> temporary file, and rename the remote temporary file to the intended
> file name. But this would require an additional step, which will be not
> acceptable for performance reasons.
You may be right about that, but directly writing the requested remote
file name will tend to cause various problems, such as the one you're
trying to fix here.
> Note, that the root case of this bug was Tramp calling chmod, not the
> copying action itself. Annoying, but not the end of the word.
I understand, but other problems can occur -- for instance, if writing
the remote output file fails, that file can be left in a broken state,
or perhaps absent entirely.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78638; Package
emacs.
(Thu, 10 Jul 2025 06:11:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 78638 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
Hi Richard,
> > Tramp could write a local temporary file, transfer it to a remote
> > temporary file, and rename the remote temporary file to the intended
> > file name. But this would require an additional step, which will be not
> > acceptable for performance reasons.
>
> You may be right about that, but directly writing the requested remote
> file name will tend to cause various problems, such as the one you're
> trying to fix here.
>
> > Note, that the root case of this bug was Tramp calling chmod, not the
> > copying action itself. Annoying, but not the end of the word.
>
> I understand, but other problems can occur -- for instance, if writing
> the remote output file fails, that file can be left in a broken state,
> or perhaps absent entirely.
Could be.
However, Tramp is very careful about this. Over the last 20+ years, I do
not remember any report about data loss due to Tramp.
Best regards, Michael.
This bug report was last modified 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.