Dear fellow users,
I found an old message by Tom Diehl in 2009 while stumbling on exactly
the same problem:
I am running alpine-2.00-1.fc10.x86_64 on an F10 box. If I get a
message
with an html or file attachment and I try to open it, I get an error
that "Firefox can't find the file at /tmp/img--46112.htm" The correct
program opens up but I always get the can't find file errors. If the
message contains a URL then it comes up and displays properly.
Does anyone know how to troubleshoot this problem?
The problem is still present with a F14 default installation (no private
.pinerc settings) using Gnome:
HTML delegation works correctly with Firefox (defined as default browser
in Fedora preferences). But attachments are not found. Read the original
thread for more details.
Here is my analysis.
* alpine uses mime/mailcap to find the correct delegate application and
launches it.
* /etc/mailcap defines "/usr/bin/xdg-open" as delegate application for
effectively every filetype.
* on an attachment opening attempt by the user, xdg-open is called by
alpine, after having saved the attachment in a temporary file alike
/tmp/img-something.filetype. xdg-open delegates again and calls exit().
This early exit seems trigger removal of the tempfile by alpine.
* In fact xdg-open delegates to gvfs-open or gnome-open, if it detects a
Gnome DE. These applications also exit after calling the final delegate.
The basic problem (no wait(2) call on final delegate possible) remains the
same.
My solution:
I added one line in /usr/bin/xdg-open::exit_success() to delay the exit:
exit_success()
{
if [ $# -gt 0 ]; then
echo "$@"
echo
fi
#=DH, April 2011
sleep 3
exit 0
}
This delays the exit call sufficiently, until the final delegate has
opened the file. It is then still erased by alpine. But in all tests I
made the delegate application had loaded the file in memory and could
handle (or save-as) it correctly. It is also possible (I am just
guessing.) that ext2/3/4 FS, alike NFS, keep an intact copy of an
unlink(2)ed file, as long as an open file descriptor exists on the file.
Anyway, this is a quick-and-dirty workaround. (Hope it helps though.) And
the default installation should provide a similar effect by a clean
implementation of a delegate that can be wait(2)ed correctly rather than
being detached from the calling process.
Cheers
Dirk