GNU bug report logs -
#79252
Option 'file-precious-flag' creates unrelatable/untrackable temporary filenames
Previous Next
Full log
View this message in rfc822 format
> 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?
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.