Subject: Re: bug#79252: Option 'file-precious-flag' creates unrelatable/untrackable temporary filenames

From: "R. Diez" <[email-masked]>
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@my-hostname using sudo...done
   ...somewhere/prometheus.yml locked by rdiez@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