GNU bug report logs - #79252
Option 'file-precious-flag' creates unrelatable/untrackable temporary filenames

Previous Next

To reply to this bug, email your comments to 79252 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: "R. Diez" <rdiez-2006 <at> rd10.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Option 'file-precious-flag' creates unrelatable/untrackable temporary
 filenames
Date: Fri, 15 Aug 2025 21:14:17 +0200

Hi all:

Some time ago, I enabled option 'file-precious-flag' after getting file corruption when editing remote files over unstable links.

The trouble is, 'file-precious-flag' generates cryptic temporary filenames like "tmp1eghjG". If there is a network problem while saving, such files are left scattered behind, and when you (or some other sysadmin) realise about those orphaned files next month (or even later), such filenames make it hard to know exactly was caused the problem and what file it was related to.

In the past months, I have increasingly suffered this orphaned file problem due to a Tramp issue described here:

Please change the naming template for temporary files
https://lists.gnu.org/archive/html/tramp-devel/2025-08/msg00007.html

After some struggling (I am no Emacs guru), I finally tracked down the related code in my Emacs 29. Function basic-save-buffer-2 in files.el builds the temporary filename like this:

(setq tempname
  (make-temp-file
   (expand-file-name "tmp" dir)))

That is where those tmpXXXX filenames are coming from.

In contrast, function make-auto-save-file-name in the same file (files.el) uses the buffer's filename to construct the temporary filename:

(make-temp-file
 (let ((fname
    (expand-file-name
     (format "#%s#" buffer-name)

Could you modify the first make-temp-file call, so that it is clear what file the temporary file relates to? It would also be best if the word "Emacs" were part or the temporary filename, like Tramp does, so that you know what piece of software caused the littering.

Thanks in advance,
  rdiez

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "R. Diez" <rdiez-2006 <at> rd10.de>
Cc: 79252 <at> debbugs.gnu.org
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sat, 16 Aug 2025 12:33:03 +0300

> Date: Fri, 15 Aug 2025 21:14:17 +0200
> From:  "R. Diez" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Hi all:
> 
> Some time ago, I enabled option 'file-precious-flag' after getting file corruption when editing remote files over unstable links.
> 
> The trouble is, 'file-precious-flag' generates cryptic temporary filenames like "tmp1eghjG". If there is a network problem while saving, such files are left scattered behind, and when you (or some other sysadmin) realise about those orphaned files next month (or even later), such filenames make it hard to know exactly was caused the problem and what file it was related to.
> 
> In the past months, I have increasingly suffered this orphaned file problem due to a Tramp issue described here:
> 
> Please change the naming template for temporary files
> https://lists.gnu.org/archive/html/tramp-devel/2025-08/msg00007.html
> 
> After some struggling (I am no Emacs guru), I finally tracked down the related code in my Emacs 29. Function basic-save-buffer-2 in files.el builds the temporary filename like this:
> 
> (setq tempname
>    (make-temp-file
>     (expand-file-name "tmp" dir)))
> 
> That is where those tmpXXXX filenames are coming from.
> 
> In contrast, function make-auto-save-file-name in the same file (files.el) uses the buffer's filename to construct the temporary filename:
> 
> (make-temp-file
>   (let ((fname
>      (expand-file-name
>       (format "#%s#" buffer-name)
> 
> Could you modify the first make-temp-file call, so that it is clear what file the temporary file relates to? It would also be best if the word "Emacs" were part or the temporary filename, like Tramp does, so that you know what piece of software caused the littering.

Sorry, I don't understand the issue.  Perhaps some details are
missing.

The file-precious-flag variable is so that the original file is not
wiped out when there are some I/O errors during saving.  If everything
goes okay, the temporary file created when file-precious-flag is
non-nil is renamed into the original file, and the temporary file will
no longer exist.  If something does go wrong, you should see an error
message when you save the buffer, and the message should tell you
right there and then what problem happened and which file was involved
in the problem.  At that moment, the original file still exists with
its original contents, and the new contents may or may not have been
written to the temporary file.  So you should be able to see the
reason for the I/O problem and the two versions of the file, and take
the proper action.

Thus, there should not be any reason for examining these files after a
long time, because any errors are immediately reported to the user.
Why doesn't this happen for you? did you somehow suppress those error
messages?  Or perhaps there's a different bug, not directly related to
the way we generate the temporary file's name in this case?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "R. Diez" <rdiez-2006 <at> rd10.de>
Cc: 79252 <at> debbugs.gnu.org
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sat, 16 Aug 2025 22:32:53 +0300

> Date: Sat, 16 Aug 2025 20:53:04 +0200
> From: "R. Diez" <rdiez-2006 <at> rd10.de>
> Cc: 79252 <at> debbugs.gnu.org
> 
> 
> > Sorry, I don't understand the issue.  Perhaps some details are missing.
> 
> OK, I'll try to explain it with more details.
> 
> A number of years ago, I enabled option 'file-precious-flag' after getting file corruption when editing remote files with Tramp over unstable network connections. When you enable 'file-precious-flag', you never actually see the temporary filenames being generated, because they are short lived. If everything works well, those files quickly disappear anyway.
> 
> After enabling 'file-precious-flag', I just noticed that my file corruption problems went away. I quickly forgot the implementation trick with the temporary file. Whenever the editing session failed, I got a network error, which was expected in my environment. So I just tried later, when the link was up again.
> 
> I didn't think at the time that Emacs might be leaving temporary files behind when the network link failed. The reason is, I normally do not look at the directories, because I keep the complicated Tramp paths in a text file, so I just copy-and-paste them to re-open the remote files directly. An example of such a Tramp filename is:
> 
> /ssh:username <at> my-hostname|sudo:root <at> my-hostname:/etc/prometheus/prometheus.yml
> 
> Every now and then, I did spot a files named like "tmp1eghjG" here and there, but at a much later time, and I didn't think much of it. The config files I edit are small, and in the rare occasion I did look at the file, it was 0 bytes long anyway.
> 
> These aren't my systems and I do not edit their config files often, so even if I had investigated further and the temporary files hadn't been empty, I would have probably blamed them on some pesky sysadmin using a lesser editor like Vim, or even worse, some editor written in JavaScript. }8-)
> 
> Fast forward a few years. I have recently started to hit the Tramp issue I described, and this time I did look around, so that's how I figured out that those temporary files were actually my doing. It never occurred to me that the core Emacs wouldn't go out of its way to make my life super easy, how would I??? So naturally, the first thing I tried was to blame Tramp, but its developers were smart enough to generate temporary filenames with a recognisable prefix.
> 
> Now that I know, and after the time I invested, I will forever remember. I just thought I shouldn't let the next Emacs user, or some unrelated sysadmin, unnecessarily scratch their heads when the next network hitch or software bug unduly leaves such a temporary file behind, or when such a file comes up in an strace log. If the temporary file had been named "prometheus.yml.Emacs-tmp1eghjG", I would have known straight away where it came from.

Thanks for the details.  But I still don't understand one aspect of
this: when these temporary files are left around, there should have
been some error either writing them or renaming them to the original
name.  Those error messages should have alerted you to the fact that
something went wrong, right there and then.  So I don't understand why
you haven't paid attention to those problems right when they happened,
instead of noticing those temporary files much later.

Are you saying that these errors happen silently in your case?  If so,
I would like to see a recipe for reproducing these problems, because
errors during saving of a buffer should never be silent.

And if you don't care about the errors that caused these files to be
left around, then I don't really understand why you want to know from
which files they came.  The temporary files directory is usually
emptied from time to time, because the files left there are of no
importance.  So why deleting them all is not what you do? why is it
important to know which files gave birth to them?

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

From: "R. Diez" <rdiez-2006 <at> rd10.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79252 <at> debbugs.gnu.org
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sat, 16 Aug 2025 20:53:04 +0200

> Sorry, I don't understand the issue.  Perhaps some details are missing.

OK, I'll try to explain it with more details.

A number of years ago, I enabled option 'file-precious-flag' after getting file corruption when editing remote files with Tramp over unstable network connections. When you enable 'file-precious-flag', you never actually see the temporary filenames being generated, because they are short lived. If everything works well, those files quickly disappear anyway.

After enabling 'file-precious-flag', I just noticed that my file corruption problems went away. I quickly forgot the implementation trick with the temporary file. Whenever the editing session failed, I got a network error, which was expected in my environment. So I just tried later, when the link was up again.

I didn't think at the time that Emacs might be leaving temporary files behind when the network link failed. The reason is, I normally do not look at the directories, because I keep the complicated Tramp paths in a text file, so I just copy-and-paste them to re-open the remote files directly. An example of such a Tramp filename is:

/ssh:username <at> my-hostname|sudo:root <at> my-hostname:/etc/prometheus/prometheus.yml

Every now and then, I did spot a files named like "tmp1eghjG" here and there, but at a much later time, and I didn't think much of it. The config files I edit are small, and in the rare occasion I did look at the file, it was 0 bytes long anyway.

These aren't my systems and I do not edit their config files often, so even if I had investigated further and the temporary files hadn't been empty, I would have probably blamed them on some pesky sysadmin using a lesser editor like Vim, or even worse, some editor written in JavaScript. }8-)

Fast forward a few years. I have recently started to hit the Tramp issue I described, and this time I did look around, so that's how I figured out that those temporary files were actually my doing. It never occurred to me that the core Emacs wouldn't go out of its way to make my life super easy, how would I??? So naturally, the first thing I tried was to blame Tramp, but its developers were smart enough to generate temporary filenames with a recognisable prefix.

Now that I know, and after the time I invested, I will forever remember. I just thought I shouldn't let the next Emacs user, or some unrelated sysadmin, unnecessarily scratch their heads when the next network hitch or software bug unduly leaves such a temporary file behind, or when such a file comes up in an strace log. If the temporary file had been named "prometheus.yml.Emacs-tmp1eghjG", I would have known straight away where it came from.

Best regards,
  rdiez

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

From: "R. Diez" <rdiez-2006 <at> rd10.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79252 <at> debbugs.gnu.org
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sat, 16 Aug 2025 22:08:40 +0200

> Thanks for the details.  But I still don't understand one aspect of
> this: when these temporary files are left around, there should have
> been some error either writing them or renaming them to the original
> name.  Those error messages should have alerted you to the fact that
> something went wrong, right there and then.  So I don't understand why
> you haven't paid attention to those problems right when they happened,
> instead of noticing those temporary files much later.

I can't remember well at the moment, but I think that, when the network I had was unstable, I was getting a network error, and I was expecting such trouble.

That network error did not mention that a temporary file like tmp1eghjG could not be renamed on the remote host. Or it may have been in the *Messages* log, but I did not look so far, and I cannot remember such an explicit error message on the minibuffer. If it had been that explicit, I would probably have made a note to delete that temporary file later on, when the connection was up again.

In the case of the Tramp issue I mentioned above, Tramp was timing out the SSH connection, and upon reconnection I was getting the prompt:

Tramp: Opening connection nil for root <at> my-hostname using sudo...done
  ...somewhere/prometheus.yml locked by rdiez <at> rdiez4 ... (pid
2019108144160269955): (s, q, p, ?)?

Whether I chose "steal" or "proceed" did not really matter, I could save changes and carry on working on the file.

At no point in time was I shown any message regarding a temporary file like tmp1eghjG having been left behind on the remote host.

Your suspicion is probably right: there must be some Lisp code path somewhere which is not reporting or handling such an error properly. The trouble is, my Emacs skills are not great, and I have already invested quite a lot of time in this matter, so I am not inclined to research even more at this time. I hope you understand.

You can probably simulate such an error by setting a low Tramp connection timeout and injecting an error in the code which renames the temporary file.


> And if you don't care about the errors that caused these files to be left around,

It is not that I do not care about such errors. In the first scenario, I was expecting a network error, because the connection was unstable, and I got one. I then retried later, and it worked. You wouldn't normally think that, when the first error occurred, a temporary file may have been left behind.

In the second scenario, I did not get an error, but an annoying prompt, which I answered every time, and then I could carry on editing. Again, there is nothing there which would make me think that a temporary file had been left behind on the remote host.


> then I don't really understand why you want to know from
> which files they came.  The temporary files directory is usually
> emptied from time to time, because the files left there are of no
> importance.  So why deleting them all is not what you do? why is it
> important to know which files gave birth to them?

Because those temporary files were not created under /tmp, but next to the edited file. This is what the directory looked like (it is just an example, this could happen with any config file you edit with Tramp's sudo method):

$ ls /etc/prometheus  [on the remote host]

alertmanager_templates
alertmanager.yml
blackbox.yml
consoles
console_libraries
prometheus.yml
tmp1egfjG
tmpXtggjx
tmp6rgzjT
tmpK5gkjY

There is nothing linking those temporary files to say alertmanager.yml or blackbox.yml.

Those temporary files tend to be 0 bytes long and they remain forever under /etc/prometheus (or wherever you happened to edit files).

But even if you are only littering your /tmp directory, or if you are only inspecting an strace output whilst troubleshooting something else, it would be nice to recognise what is generating a particular temporary file, or what its purpose is. Well-written software like systemd (hold on, did I just say that???) generates proper names even under /tmp/. For example:

$ ls -la /tmp/

drwx------ 3 root root 4.096 2025-08-01 20:39 systemd-private-7052d6f3239046d9949f866654072e46-bluetooth.service-cInwER/
drwx------ 3 root root 4.096 2025-08-01 20:39 systemd-private-7052d6f3239046d9949f866654072e46-colord.service-lHaH71/
drwx------ 3 root root 4.096 2025-08-01 20:39 systemd-private-7052d6f3239046d9949f866654072e46-ModemManager.service-Zr0yTf/

Best regards,
  rdiez

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "R. Diez" <rdiez-2006 <at> rd10.de>, Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79252 <at> debbugs.gnu.org
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sun, 17 Aug 2025 10:28:54 +0300

> Date: Sat, 16 Aug 2025 22:08:40 +0200
> Cc: 79252 <at> debbugs.gnu.org
> From: "R. Diez" <rdiez-2006 <at> rd10.de>
> 
> 
> > Thanks for the details.  But I still don't understand one aspect of
> > this: when these temporary files are left around, there should have
> > been some error either writing them or renaming them to the original
> > name.  Those error messages should have alerted you to the fact that
> > something went wrong, right there and then.  So I don't understand why
> > you haven't paid attention to those problems right when they happened,
> > instead of noticing those temporary files much later.
> 
> I can't remember well at the moment, but I think that, when the network I had was unstable, I was getting a network error, and I was expecting such trouble.
> 
> That network error did not mention that a temporary file like tmp1eghjG could not be renamed on the remote host. Or it may have been in the *Messages* log, but I did not look so far, and I cannot remember such an explicit error message on the minibuffer. If it had been that explicit, I would probably have made a note to delete that temporary file later on, when the connection was up again.
> 
> In the case of the Tramp issue I mentioned above, Tramp was timing out the SSH connection, and upon reconnection I was getting the prompt:
> 
> Tramp: Opening connection nil for root <at> my-hostname using sudo...done
>    ...somewhere/prometheus.yml locked by rdiez <at> rdiez4 ... (pid
> 2019108144160269955): (s, q, p, ?)?
> 
> Whether I chose "steal" or "proceed" did not really matter, I could save changes and carry on working on the file.
> 
> At no point in time was I shown any message regarding a temporary file like tmp1eghjG having been left behind on the remote host.
> 
> Your suspicion is probably right: there must be some Lisp code path somewhere which is not reporting or handling such an error properly. The trouble is, my Emacs skills are not great, and I have already invested quite a lot of time in this matter, so I am not inclined to research even more at this time. I hope you understand.
> 
> You can probably simulate such an error by setting a low Tramp connection timeout and injecting an error in the code which renames the temporary file.
> 
> 
> > And if you don't care about the errors that caused these files to be left around,
> 
> It is not that I do not care about such errors. In the first scenario, I was expecting a network error, because the connection was unstable, and I got one. I then retried later, and it worked. You wouldn't normally think that, when the first error occurred, a temporary file may have been left behind.
> 
> In the second scenario, I did not get an error, but an annoying prompt, which I answered every time, and then I could carry on editing. Again, there is nothing there which would make me think that a temporary file had been left behind on the remote host.
> 
> 
> > then I don't really understand why you want to know from
> > which files they came.  The temporary files directory is usually
> > emptied from time to time, because the files left there are of no
> > importance.  So why deleting them all is not what you do? why is it
> > important to know which files gave birth to them?
> 
> Because those temporary files were not created under /tmp, but next to the edited file. This is what the directory looked like (it is just an example, this could happen with any config file you edit with Tramp's sudo method):

OK, thanks.  I think the patch below should do what you are asking
for.

Michael, could you please review the patch and tell if you see any
issues with it?

diff --git a/lisp/files.el b/lisp/files.el
index 84e9254..3e85244 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -6245,7 +6245,13 @@ basic-save-buffer-2
 		  ;; for saving the buffer.
 		  (setq tempname
 			(make-temp-file
-			 (expand-file-name "tmp" dir)))
+                         ;; The MSDOS 8+3 restricted namespace cannot be
+                         ;; relied upon to produce a different file name
+                         ;; if we append ".tmp".
+	                 (if (and (eq system-type 'ms-dos)
+		                  (not (msdos-long-file-names)))
+                             (expand-file-name "tmp" dir)
+                           (concat buffer-file-name ".tmp"))))
 		  ;; Pass in nil&nil rather than point-min&max
 		  ;; cause we're saving the whole buffer.
 		  ;; write-region-annotate-functions may use it.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79252 <at> debbugs.gnu.org, "R. Diez" <rdiez-2006 <at> rd10.de>
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sun, 17 Aug 2025 09:56:02 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

> Michael, could you please review the patch and tell if you see any
> issues with it?
>
> diff --git a/lisp/files.el b/lisp/files.el
> index 84e9254..3e85244 100644
> --- a/lisp/files.el
> +++ b/lisp/files.el
> @@ -6245,7 +6245,13 @@ basic-save-buffer-2
>  		  ;; for saving the buffer.
>  		  (setq tempname
>  			(make-temp-file
> -			 (expand-file-name "tmp" dir)))
> +                         ;; The MSDOS 8+3 restricted namespace cannot be
> +                         ;; relied upon to produce a different file name
> +                         ;; if we append ".tmp".
> +	                 (if (and (eq system-type 'ms-dos)
> +		                  (not (msdos-long-file-names)))
> +                             (expand-file-name "tmp" dir)
> +                           (concat buffer-file-name ".tmp"))))
>  		  ;; Pass in nil&nil rather than point-min&max
>  		  ;; cause we're saving the whole buffer.
>  		  ;; write-region-annotate-functions may use it.

On a first glance, it looks OK. I don't know whether we need special care
for symlinks, i.e., use buffer-file-truename instead of buffer-file-name.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79252 <at> debbugs.gnu.org, rdiez-2006 <at> rd10.de
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sun, 17 Aug 2025 11:07:06 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: "R. Diez" <rdiez-2006 <at> rd10.de>,  79252 <at> debbugs.gnu.org
> Date: Sun, 17 Aug 2025 09:56:02 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Hi Eli,
> 
> > Michael, could you please review the patch and tell if you see any
> > issues with it?
> >
> > diff --git a/lisp/files.el b/lisp/files.el
> > index 84e9254..3e85244 100644
> > --- a/lisp/files.el
> > +++ b/lisp/files.el
> > @@ -6245,7 +6245,13 @@ basic-save-buffer-2
> >  		  ;; for saving the buffer.
> >  		  (setq tempname
> >  			(make-temp-file
> > -			 (expand-file-name "tmp" dir)))
> > +                         ;; The MSDOS 8+3 restricted namespace cannot be
> > +                         ;; relied upon to produce a different file name
> > +                         ;; if we append ".tmp".
> > +	                 (if (and (eq system-type 'ms-dos)
> > +		                  (not (msdos-long-file-names)))
> > +                             (expand-file-name "tmp" dir)
> > +                           (concat buffer-file-name ".tmp"))))
> >  		  ;; Pass in nil&nil rather than point-min&max
> >  		  ;; cause we're saving the whole buffer.
> >  		  ;; write-region-annotate-functions may use it.
> 
> On a first glance, it looks OK. I don't know whether we need special care
> for symlinks, i.e., use buffer-file-truename instead of buffer-file-name.

Thanks for the review.

What could be the issues with symlinks?  The directory of
buffer-file-name is writable, so using the name of the symlink should
be okay, since we create a normal file.  Or what am I missing?

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79252 <at> debbugs.gnu.org, rdiez-2006 <at> rd10.de
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sun, 17 Aug 2025 10:48:17 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> On a first glance, it looks OK. I don't know whether we need special care
>> for symlinks, i.e., use buffer-file-truename instead of buffer-file-name.
>
> What could be the issues with symlinks?  The directory of
> buffer-file-name is writable, so using the name of the symlink should
> be okay, since we create a normal file.  Or what am I missing?

I don't see an issue. It is just the idea, that the temp file is more
related to the canonical file instead of the link source.

Best regards, Michael.

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

From: "R. Diez" <rdiez-2006 <at> rd10.de>
To: Eli Zaretskii <eliz <at> gnu.org>, Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79252 <at> debbugs.gnu.org
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sun, 17 Aug 2025 20:58:38 +0200

> I think the patch below should do what you are asking for.

I don't really know much Emacs or Lisp, but the patch looks fine to me too.

At first, I thought that Tramp was the one creating the temporary file, so I suggested this change to Tramp:

> For a file like:
>
> myfile.txt
>
> I suggest a temporary filename like:
>
> myfile.txt.EmacsTrampTmp1eghjG

Michael Albinus' reply was:

> That wouldn't be possible. An extension, like ".txt", must be kept.

See the full text here: https://lists.gnu.org/archive/html/tramp-devel/2025-08/msg00008.html

Your patch does change the file extension, but I do not know whether that is actually a problem. The original temporary filename had no extension anyway.


> I don't see an issue. It is just the idea, that the temp file is more
> related to the canonical file instead of the link source.

While checking 'file-precious-flag' because of this issue, I saw related option 'file-preserve-symlinks-on-save'.

The documentation does not recommend enabling it, or leaving it disabled, but since enabling it seems to mirror the symlink behaviour when 'file-precious-flag' is disabled, I decided to enable 'file-preserve-symlinks-on-save' on my system. So far without trouble.

I am mentioning it mainly because I would imagine the Lisp code that queries 'file-preserve-symlinks-on-save' could offer some insight into the necessary symlink handling. However, if anything comes out of that, I would do it in a separate patch.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: "R. Diez" <rdiez-2006 <at> rd10.de>
Cc: 79252 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Mon, 18 Aug 2025 08:44:45 +0200

"R. Diez" <rdiez-2006 <at> rd10.de> writes:

Hi,

> At first, I thought that Tramp was the one creating the temporary file, so I suggested this change to Tramp:
>
>> For a file like:
>>
>> myfile.txt
>>
>> I suggest a temporary filename like:
>>
>> myfile.txt.EmacsTrampTmp1eghjG
>
> Michael Albinus' reply was:
>
>> That wouldn't be possible. An extension, like ".txt", must be kept.
>
> See the full text here: https://lists.gnu.org/archive/html/tramp-devel/2025-08/msg00008.html
>
> Your patch does change the file extension, but I do not know whether that is actually a problem. The original temporary filename had no extension anyway.

Keeping the extension of a file in a respective temp file is needed, if
you want to apply actions on that temp file. For example, set a proper
major mode for the temp file according to auto-mode-alist.

In the given case, use a temporary file for handling file-precious-flag,
it isn't needed, indeed.

Best regards, Michael.

Message #40 received at 79252-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "R. Diez" <rdiez-2006 <at> rd10.de>
Cc: 79252-done <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#79252: Option 'file-precious-flag' creates
 unrelatable/untrackable temporary filenames
Date: Sat, 23 Aug 2025 15:11:22 +0300

> X-Spam-Status: No, score=-2.898 required=6.31 tests=[ALL_TRUSTED=-1,
> 	BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001,
> 	URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001]
> 	autolearn=ham autolearn_force=no
> Date: Sun, 17 Aug 2025 20:58:38 +0200
> Cc: 79252 <at> debbugs.gnu.org
> From: "R. Diez" <rdiez-2006 <at> rd10.de>
> 
> 
> > I think the patch below should do what you are asking for.
> 
> I don't really know much Emacs or Lisp, but the patch looks fine to me too.

Thanks, so now installed on the master branch, and closing the bug.

Previous Next

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