1. Forum
  2. Usenet
  3. COMP.MAIL.MUTT

  • Mutt unlinking temp files too soon?

    From Dario Niedermann@21:1/5 to All on Sat May 4 11:37:18 2019
    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.

    --
    Dario Niedermann. Also on the Internet at:

    gopher://darioniedermann.it/ <> https://www.darioniedermann.it/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eike Rathke@21:1/5 to All on Sun May 5 18:09:07 2019
    * Dario Niedermann, 2019-05-04 09:37 UTC:
    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.

    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

    --
    OpenPGP/GnuPG encrypted mail preferred in all private communication.
    GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Use LibreOffice! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dario Niedermann@21:1/5 to Eike Rathke on Mon May 6 01:00:10 2019
    Eike Rathke <[email protected]> wrote:

    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?

    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.

    --
    Dario Niedermann. Also on the Internet at:

    gopher://darioniedermann.it/ <> https://www.darioniedermann.it/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Dario Niedermann on Mon May 6 01:17:04 2019
    Dario Niedermann <[email protected]> wrote:
    Anyway, I don't think Mutt should remove its temp files at all:

    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roger Bell_West@21:1/5 to Dario Niedermann on Mon May 6 08:06:47 2019
    On 2019-05-06, Dario Niedermann wrote:
    Roger Bell_West <[email protected]> wrote:
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dario Niedermann@21:1/5 to [email protected] on Mon May 6 09:37:18 2019
    Roger Bell_West <[email protected]> wrote:

    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.

    --
    Dario Niedermann. Also on the Internet at:

    gopher://darioniedermann.it/ <> https://www.darioniedermann.it/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dario Niedermann@21:1/5 to Rich on Mon May 6 09:46:12 2019
    Rich <[email protected]d> wrote:

    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.

    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).

    --
    Dario Niedermann. Also on the Internet at:

    gopher://darioniedermann.it/ <> https://www.darioniedermann.it/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roger Bell_West@21:1/5 to Dario Niedermann on Mon May 6 07:25:41 2019
    On 2019-05-05, Dario Niedermann wrote:
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Dario Niedermann on Mon May 6 10:58:44 2019
    Dario Niedermann <[email protected]> wrote:
    Rich <[email protected]d> wrote:

    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".

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eike Rathke@21:1/5 to All on Mon May 6 23:01:04 2019
    * Dario Niedermann, 2019-05-05 23:00 UTC:
    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

    --
    OpenPGP/GnuPG encrypted mail preferred in all private communication.
    GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Use LibreOffice! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eike Rathke@21:1/5 to All on Tue May 7 10:56:56 2019
    * Dario Niedermann, 2019-05-07 10:32 UTC:
    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

    --
    OpenPGP/GnuPG encrypted mail preferred in all private communication.
    GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Use LibreOffice! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dario Niedermann@21:1/5 to Eike Rathke on Tue May 7 12:32:53 2019
    Eike Rathke <[email protected]> wrote:

    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.

    --
    Dario Niedermann. Also on the Internet at:

    gopher://darioniedermann.it/ <> https://www.darioniedermann.it/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)