Hm, this looks like an xdg-open problem that it doesn't wait before the file is actually opened, not sure if it's possible to fix it without reverting to the blocking behavior. Maybe this could be enabled with a command line option or an environment variable?

A workaround is to add the needsterminal flag to the mailcap entry, so mutt waits for a key press before removing the file in tmp.

Yeah, not all helper applications wait before returning (kde-open in particular is one example).  Not much xdg-utils can do about that.

Well, xdg-utils can fix xdg-open, at least.

But either xdg-open or mutt needs to be fixed. The interesting question is which.

And while one could argue that any mutt users are confortable editing the mailcap entries, one should not have to. And, does adding "needsterminal" flag to mailcap entries break anything else? More importantly, does adding this flag then break rpms from being able to update the mailcap on their own?

kde-open has a --tempfile option, that could be useful here.  Need to be careful about it's use though,

$ kde-open --help-kde-tempfile
...
KDE-tempfile options:
  --tempfile    The files/URLs opened by the application will be deleted after use

Perhaps we could use some sort of heuristic like "if file is in $TMPDIR or /tmp, use --tempfile"...

Filed bug upstream,
https://bugs.freedesktop.org/show_bug.cgi?id=32016

to help track this.

Speaking of heuristics, perhaps we could assume that all calls from mailcap are on temp files?

Well, why not? :)

Is kde-open the only one which does this?

I don't know, there are numerous backends that xdg-open can/does use.

that said, kde-open is the only one with this behavior that I'm currently aware of.

Affects alpine, too.

For what it's worth, I think it is clearly xdg-open's responsibility to return either an error code or success after processing the input data.  That doesn't mean it has to wait until the chosen viewer is closed, but it can't quite before the back-end has *successfully* launched.  As it is, xdg-open returns success, even though the back-end fails immediately.

*** Bug 770782 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> Hm, this looks like an xdg-open problem 

While tracking bug 770782 I tried with other "intermediary" shell scripts instead of xdg-open.  Consistently if I will append "; copiousoutput" to such mailcap entry then this works just fine; otherwise see above.  If a "handler" is called directly, say:

application/pdf; evince %s
image/*; display %s

then no problems and "; copiousoutput" is not required.

I seem to no longer be able to reproduce this testing with kde-open, though gvfs-open still exhibits it.

fyi, Paul, xdg-open *does* wait for the backend to return and passes back the error code given by the helper.

My small test case script:

echo 'text!' > foo.txt
kde-open foo.txt
rm -v foo.txt

seems to work for me.  replace kde-open with gvfs-open and it fails (I think I have an upstream bug open, I'll try to dig it up).

anyone seeing this on KDE ?

Here we go, bug #571932 , upstream 
http://bugzilla.gnome.org/show_bug.cgi?id=652262

I'm not sure what appending '; copiousoutput' does in the context of mailcap, but if it works, our mailcap maintainers could consider tweaking it as such as a workaround to xdg-open backend bugs (like the aforemened gvfs-open).

(In reply to comment #15)
> I'm not sure what appending '; copiousoutput' does in the context of mailcap,

That what mutt docs have to say (plus a bit more) on the subject:

   copiousoutput
          This flag tells Mutt that the command passes possibly large
          amounts of text on standard output. This causes Mutt to invoke a
          pager (either the internal pager or the external pager defined
          by the pager variable) on the output of the view command.
          Without this flag, Mutt assumes that the command is interactive.

> but if it works, our mailcap maintainers could consider tweaking it as such as
> a workaround to xdg-open backend bugs (like the aforemened gvfs-open).

It did work for me in all cases I tried even if there was no output.  It looks to  me that this "fix" is a side-effect of forcing mutt to wait.  The keyword seems to be "possbily". If this will have any effect on alpine, which somebody mentioned is affected too, I really have no idea.

For what it is worth - how my solution does not always work.... so not the real fix.

I changed my .mailcap to put a 3 second delay after starting evince. This allows me to see/read the PDF ... 3 seconds is long enough for evince to get going. But if I try to print it I get empty pages - to print I need to save the attachment to a file and then view with evince. I assume that the print function involves reopening the file somewhere.

Probably similar issues with other attachment types.

I am using a very ugly hack but a valid workaround by pointing mutt MIME to a script called mutt-open like below.
(you can change kde-open to xdg-open)

===
#!/bin/bash
NEWFILE=/tmp/mutt_bak_`basename $1`
rm ${NEWFILE} -f
cp $1 ${NEWFILE} 1>/dev/null 2>&1
kde-open ${NEWFILE}
===

It just copy the file and open the new one.

I tried hard link, but still even hard link created, the both hard link and file vanish.

This also affects XFCE.  exo-open also returns, like gvfs-open, before
the child application is done.  On the other hand, the open_generic
option inside xdg-open does work.

Since the bugs in gvfs-open, exo-open, etc have been open for over 3
years, I would request an xdg-open work around flag.  xdg-open could
accept an option like --use-generic.  This could skip the desktop
environment check and call open_generic.  This will help many of the
affected terminal applications work around the issue.

FWIW, Emacs is also affected when calling xdg-open asynchronously.
See:

  <http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html>

If you will accept a patch, I can work on this.  Please let me know if
that is agreeable.

Feature request denied, however I have an alternative suggested that can work just as well,

DE=generic xdg-open ...

should work like you want.

Well, not *denied* denied, but I really don't want to add options to workaround someone else's bugs or lack of features when a workaround already exists.  Let me know if my suggestion is not workable or acceptable for whatever reason.

I was not aware of this possibility.  This work around is much better
than new options.  Some background: I came across this issue when
users started complaining after Org mode (an Emacs major mode) started
using xdg-open.  I will discuss this work around with the devs there.

Thank you very much :).

Since I'm not very smart, could you please explain how/where to apply the
workaround DE=generic xdg-open ...

Jim, in this case, presumably to /etc/mailcap

Or... according to 'man mailcap', you can add user-specific customizations to ~/.mailcap

(In reply to Rex Dieter from comment #24)
> Jim, in this case, presumably to /etc/mailcap

If we are talking about mutt then, accordingly to mutt manual, mailcap is searched along mailcap_path and you can get its value by running
'mutt -nF /dev/null -Q mailcap_path'.  On Fedora this gives a default mailcap_path="~/.mailcap:/usr/share/mutt/mailcap:/etc/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap".  So mutt specific but system-wide mailcap entries with workarounds may go into /usr/share/mutt/mailcap.

That, of course, is not doing anything for other breakage, like that one from a comment 19, and every such case has to be worked around separately.  As gnome-open remains now broken for many years then likely it will stay that way.

OK, that seems to work for me too - I'm using alpine as the mail program,
and making that change to /etc/mailcap allows it to work as it should.
Thanks.

In 2015, this still affects me (and I am still using mutt ;))

Running Gnome3 on Fedora23, "XDG_CURRENT_DESKTOP" is set to "GNOME" and thus the code in xdg-open's detectDE() does not trigger when I set "DE". Instead setting X_C_D to X-Generic works fine for me:

  XDG_CURRENT_DESKTOP=X-Generic xdg-open …

one could also unset the var and then the DE one would win

  XDG_CURRENT_DESKTOP= DE=generic xdg-open …

Greets
Evgeni