View attachment fails in Alpine when attachment is an image: image Viewer cannot find file

[Christopher Barrington-Leigh]

My email message has an attachment. It's an image.
I choose to view it externally (with v-v)

Up pops gnome's image viewer with the following error:

No images found in 'file:///tmp/img-image001-56128.png'.

Indeed, there is no such file.

What should happen is that a temporary file is created and successfully displayed.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: alpine 2.02-3build1
ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
Uname: Linux 3.0.0-14-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Fri Dec 16 14:34:35 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110921.2)
ProcEnviron:
 LANGUAGE=en_CA:en
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: alpine
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gerry (gsker)]

I have this issue. I think I might be able to shed some light:

Run alpine with -d9 and look in the .pine-debug1 file.

11:51:44.256960
exec_mailcap_cmd: command=(soffice -no-oosplash --writer '/tmp/img-MSWORD-09433.doc' ; rm -f /tmp/img-MSWORD-09433.doc) &

That's what it's trying to do to view the attachment. However, if I run soffice at the command line, it returns to the prompt right away. So when this is run from alpine, what happens next is the tmp file gets deleted before it can be opened and openoffice reports that it can't find the file.

Not sure how to fix this, but maybe alpine needs to have an option to not delete the temporary file?
Or can it be done in the mailcap? Probably not.

This needs to be reported upstream.

[Gerry (gsker)]

I was inspired to dig some. I changed my /etc/mailcap file to get rid of "-no-oosplash"

  sed -i.bak -e 's/-no-oosplash/--nologo/g;' /etc/mailcap

And it is no longer a problem for me. Attachments now work correctly.

If the original submitter would run alpine with a -d9 and send on the output of

  grep exec_mailcap_cmd ~/.pine-debug1

we could probably decide what the bug really is.

In my case, it's -no-oosplash in my mailcap file which probably came from going through an upgrade from maverick to oneiric OR from OpenOffice to LibreOffice.

[Christopher Barrington-Leigh (cpbl)]

Thank you!
Oh-oh; I don't get anything from your grep command. In fact (after -v9 launch):

 grep mailcap ~/.pine-debug1
set_current_val(var=mailcap-search-path, expand=1, cmdline=1)
  no-enable-mailcap-param-substitution

[Gerry (gsker)]

Interesting. I still think it's likely the file is getting created and then deleted, but now I have no evidence of that.

2 things:

1. Could you attach the entire debug file to this bug?
2. You could make sure the temp file is getting created? Here are the steps I used:

sudo aptitude install inotify-tools

In one terminal window do this:
while inotifywait -e create /tmp
do
done

Then in another terminal window run
pine -d9

and open an attachement (with v-v)

The first terminal window should spit out the file creation event
Mine looks like this:

gsker@veeta:/tmp> while inotifywait -e create /tmp/
do
done
Setting up watches.
Watches established.
/tmp/ CREATE .806.b959f
Setting up watches.
Watches established.
/tmp/ CREATE img-MSWORD-78337.doc
Setting up watches.
Watches established.
/tmp/ CREATE OSL_PIPE_500_SingleOfficeIPC_5939f244e699d216fa941a4dd38f371
Setting up watches.
Watches established.
/tmp/ CREATE .~lock.img-MSWORD-78337.doc#
Setting up watches.
Watches established.

press Ctrl-C to or close the terminal when you are done.

[Gerry (gsker)]

Just to update this.

/etc/mailcap is created by update-mime which gets its data from /usr/lib/mime/packages

the libreoffice files in there come from the libreoffice packages

dpkg-query -S /usr/lib/mime/packages/libreoffice-writer

libreoffice-writer: /usr/lib/mime/packages/libreoffice-writer

So mailcap gets overwritten that way. No point in manually edting that. And, although it works, modified files in that directory probabaly get overwritten when libreoffice gets updated so it won't work for long

A workaround would be to put a file in that directory and then add it to /etc/mailcap.order.

For alpine, the problem came back for me, so I've put a couple of scripts in ~/bin/ that run soffice and libreoffice with a sleep 10 command after. alpine then waits the 10 seconds to delete the file which by then is engaged by libreoffice and won't really go away until libreoffice lets it go.

I would like to see alpine add a sleep before deleting the temp file. If I find where that is in the source, I'll post ithere.

[Christopher Barrington-Leigh (cpbl)]

Gerry,

To your second last reply, which I overlooked at the time:

No, there is lots of private info in the complete debug file.
Unless you assure me that there won't be passwords, I won't even send it to you privately.
But if it can't contain any auth info, I can email it to you?

[Oliver R. (oliverr)]

Suggestion: What about an option that allows to turn off deletion of such temporary files at all, maybe only for specified mimetypes?

[Christopher Barrington-Leigh (cpbl)]

I just changed my image viewer from eog (I think) to /usr/bin/chromium-browser --new-window
and now images appear just fine, even though when I check the existence of the image (or, for instance, reload it) it has disappeared. So is the current bug just a matter of how long the viewer application takes to load the image? Or to return a 0 status to its caller??

[Gerry (gsker)]

*I THOUGHT* it was matter of if the viewer stays in the foreground or
switches to the background. BUT, chromium-browser --new-window will got to the
background if there's already a chromium-browser window open.

As you say, though, if chromium-browser opens the file BEFORE going into the
background, then it will work.

On Mon, 28 May 2012, Christopher Barrington-Leigh wrote:

> I just changed my image viewer from eog (I think) to /usr/bin/chromium-browser --new-window
> and now images appear just fine, even though when I check the existence of the image (or, for instance, reload it) it has disappeared. So is the current bug just a matter of how long the viewer application takes to load the image? Or to return a 0 status to its caller??
>
>

--
Gerry Skerbitz
<email address hidden>