Alpine will not show attachments

[Dirk Hoffmann]

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