GNU bug report logs -
#79252
Option 'file-precious-flag' creates unrelatable/untrackable temporary filenames
Previous Next
Full log
Message #20 received at 79252 <at> debbugs.gnu.org (full text, mbox):
> 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.
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.