Mutt unlinking temp files too soon?

[Dario Niedermann]

From the symptoms it would seem that way. When I press 'm' on the
text/html part of an email, the '/usr/bin/sensible-browser' shell script
is started (as per mailcap) but then the X11 browser doesn't find temp
file 'mutt.html' in my ~/tmp/.

If I insert a "sleep 10" in '/usr/bin/sensible-browser' between
the browser call and the script's exit, the browser finds the
'~/tmp/mutt.html' file.

So it seems that there's a race going on between the browser and Mutt's
unlink().

I'm using Mutt 1.10.1, but I haven't seen this problem mentioned in the
release notes of more recent versions.

[Eike Rathke]

Post by Dario Niedermann
From the symptoms it would seem that way. When I press 'm' on the
text/html part of an email, the '/usr/bin/sensible-browser' shell script
is started (as per mailcap) but then the X11 browser doesn't find temp
file 'mutt.html' in my ~/tmp/.
If I insert a "sleep 10" in '/usr/bin/sensible-browser' between
the browser call and the script's exit, the browser finds the
'~/tmp/mutt.html' file.
So it seems that there's a race going on between the browser and Mutt's
unlink().

It feels like a race but actually is not a race, Mutt removes the temp
file when the command invoked returns, Mutt does not know whether the
command placed any other command in the background which didn't digest
the file yet when the command returns.

So the correct invocation in this case is to place a sleep or any other
means that makes the invoked script wait the needed amount of time
before it returns.

Instead of modifying /usr/bin/sensible-browser I'd rather use a script
that itself calls /usr/bin/sensible-browser and then waits some seconds.

Post by Dario Niedermann
I'm using Mutt 1.10.1, but I haven't seen this problem mentioned in the
release notes of more recent versions.

This is not new behaviour, afaik it has always been like that.

Eike

[Dario Niedermann]

Post by Eike Rathke
So the correct invocation in this case is to place a sleep or any other
means that makes the invoked script wait the needed amount of time
before it returns.

Rather inelegant, though, isn't it?

Post by Eike Rathke
This is not new behaviour, afaik it has always been like that.

I never noticed it before, maybe my computer got slower with the latest
batch of updates.

Anyway, I don't think Mutt should remove its temp files at all: usually
there are local policies on when to clean up temporary directories.
Mutt should just give temp files a unique name and let them there for
the user to do as he pleases.

[Rich]

Nope, if a program creates a temp file, it should cleanup after itself
when done with that temp file.

usually there are local policies on when to clean up temporary
directories.

This is *far* from universal.

Mutt should just give temp files a unique name and let them there for
the user to do as he pleases.

No, it should clean them up when it is done with them (like it does
now).

[Dario Niedermann]

Post by Rich
Nope, if a program creates a temp file, it should cleanup after itself
when done with that temp file.

Says who? Lynx and w3m don't do that, just to mention a couple of
examples. Lynx cleans up at program quit, which seems sensible.

Post by Rich
This is *far* from universal.

All Linux and BSD distros I've seen manage /tmp in some way by default,
usually cleaning it up at reboot (more recently, some Linux distros use
/tmp as a mountpoint for a temporary, possibly RAM-based filesystem).

[Rich]

Post by Dario Niedermann

Post by Rich
Nope, if a program creates a temp file, it should cleanup after itself
when done with that temp file.

Says who? Lynx and w3m don't do that, just to mention a couple of
examples. Lynx cleans up at program quit, which seems sensible.

That is *still* "cleanup after itself".

Post by Dario Niedermann

Post by Rich
This is *far* from universal.

All Linux and BSD distros I've seen manage /tmp in some way by
default, usually cleaning it up at reboot (more recently, some Linux
distros use /tmp as a mountpoint for a temporary, possibly RAM-based
filesystem).

No, not all. Slackware for one does not auto-empty /tmp on boot.

[Eike Rathke]

Post by Dario Niedermann
All Linux and BSD distros I've seen manage /tmp in some way by default,
usually cleaning it up at reboot (more recently, some Linux distros use
/tmp as a mountpoint for a temporary, possibly RAM-based filesystem).

You unnecessarily reboot machines to cleanup /tmp?

Eike

[Roger Bell_West]

Post by Dario Niedermann
Rather inelegant, though, isn't it?

Inelegant is using a viewer that returns before it's done its job.

When I run sensible-browser on a Debian system, it doesn't. So perhaps
that would be the thing to fix?

[Dario Niedermann]

Post by Roger Bell_West
Inelegant is using a viewer that returns before it's done its job.

So basically any modern browser. All modern browsers return immediately
after receiving a 'new tab' message. It's been like that for a long
time, actually.

[Roger Bell_West]

Post by Dario Niedermann

Post by Roger Bell_West
Inelegant is using a viewer that returns before it's done its job.

So basically any modern browser. All modern browsers return immediately
after receiving a 'new tab' message. It's been like that for a long
time, actually.

Bad choice for viewing a temp file, then. Why not just use elinks, since
we have the good taste to be running mutt in the first place?

[Eike Rathke]

Post by Roger Bell_West

Post by Dario Niedermann

Post by Roger Bell_West
Inelegant is using a viewer that returns before it's done its job.

So basically any modern browser. All modern browsers return immediately
after receiving a 'new tab' message. It's been like that for a long
time, actually.

Bad choice for viewing a temp file, then.

Good choice for viewing a temp file if the user wants bells and whistles
in a graphical browser.

Post by Roger Bell_West
Why not just use elinks, since
we have the good taste to be running mutt in the first place?

For that it doesn't even need an explicit temp file, just auto_view
text/html and copiousoutput.

Eike

[Eike Rathke]

Post by Dario Niedermann
Anyway, I don't think Mutt should remove its temp files at all: usually
there are local policies on when to clean up temporary directories.
Mutt should just give temp files a unique name and let them there for
the user to do as he pleases.

Your view is narrowed on only a few systems, Mutt runs on more systems
and not even every Linux system has auto-clean on /tmp enabled.

Eike

[Dario Niedermann]

Post by Eike Rathke
Your view is narrowed on only a few systems, Mutt runs on more systems
and not even every Linux system has auto-clean on /tmp enabled.

Whatever. That's no reason to remove the file right after a viewer
returns. Cleaning up temporary files on quit, like Lynx does, is the
way to go.

[Eike Rathke]

Post by Dario Niedermann
Whatever. That's no reason to remove the file right after a viewer
returns. Cleaning up temporary files on quit, like Lynx does, is the
way to go.

To me there is a good reason to remove it as soon as possible, it
reduces the chance that anyone else (with admin or staff/wheel rights)
gets to see it. It also prevents cluttering the tmp directory, cleaning
only on quit is suboptimal if the Mutt instance is running for days or
weeks.

Eike