GNU bug report logs -
#79252
Option 'file-precious-flag' creates unrelatable/untrackable temporary filenames
Previous Next
Full log
Message #11 received at 79252 <at> debbugs.gnu.org (full text, mbox):
> 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?
This bug report was last modified 20 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.