it does the same on my box when doing that:
- create a new mail
- attach a .xls to it
- double click on the icon from the attachment bar it does the same
- right click on it, open with works fine

It tries to run "app file:PATH", which some apps don't like...

The issue is to widgets/misc/e-attachment-bar.c eab_icon_clicked_cb()

"			attachment = (EAttachment *)p->data;

			/* Check if the file is stored already */
			if (!attachment->store_uri) {
				CamelURL *curl;
				
				path = temp_save_part (attachment->body);				
				curl  = camel_url_new ("file:", NULL);
				camel_url_set_path ( curl, path);
				attachment->store_uri = camel_url_to_string (curl, 0);
				camel_url_free (curl);
			}

			/* launch the url now */
			gnome_url_show (attachment->store_uri, &error);"

Reproducible in evolution 2.6.1

A fix has been made by Srag for this. 

could people attach their fixes to bugzilla instead of keeping them to some random place or hidden?

Created attachment 65992 [details] [review]
Proposed patch

This should fix the issue.

Added the wrong stuff.

Created attachment 65993 [details] [review]
Attaching the right fix

did you try that patch? I tried a similar hack when I sent the bug and it makes no difference with the GNOME 2.14.1 code. I just tried your patch and it doesn't seem to fix the issue

seb, I have that working now. It fixes the problem for me. Even try 

'gnome-open file:/home/test/foo.xls' would give a similiar error.

'gnome-open file:///home/test/foo.xls' should work. I have done the same fix. It works for me for sure :)

weird, the path is still file:PATH with your change, it looks like that your change doesn't make a difference. Maybe the API behaviour changed with the CVS since GNOME 2.14?

seb, if possible do a print of what cmd it execs, it works for me. May be Ill ask someone else to try this too

In my case (Ubuntu Dapper Drake 6.06) OpenOffice pops up a message box with the following error:

/home/sven/file:/home/sven/.evolution/cache/tmp/evolution-tmp-PvXEmM/Meeting.xls doesn't exist

I guess that OpenOffice fails because my home directory "/home/sven/" shows up twice in this path.

hmm, any news on this? srag, seb? :-/

With this patch It just works for me. Any other volunteers to test this patch?

The patch doesn't apply to current code and doing a similar change makes no difference to GNOME 2.15.90, it still tries to open "file:/path". With what version are you trying? Are you sure that's not your openoffice simply accepting to open "file:/path"?

Seb, with out this I face the issue and with this I dont see it. 

I tested the patch and it works perfectly. I am not sure if the version of OpenOffice one has got something to do with this. I tested against the stable build of Evolution (2.6.3) and OpenOffice  2.0.2 and the patch works fine.

Approved for both stable branch and HEAD.

The code is like that:

"...
			/* Check if the file is stored already */
			if (!attachment->store_uri) {
				path = temp_save_part (attachment->body);				
				url = camel_url_new ("file:", NULL);
				camel_url_set_path (url, path);
				attachment->store_uri = camel_url_to_string (url, 0);
				camel_url_free (url);
				g_free (path);
			}

			/* launch the url now */
			gnome_url_show (attachment->store_uri, &error);
..."

some printfs to the code indicates that when double clicking on the attachment from the composer window the "if (!attachment->store_uri)" is false (attachment->store_uri already set), so your patch makes no change to the behaviour, it might be right but fix only the case where store_uri was not set

Created attachment 70615 [details] [review]
Updated patch

Seb, You rock. I have put an updated fix. This should solve all the problem. Thanks for your extended support :)

I was trying a scenario, where the attachment wasnt downloaded earlier. Not, with this, when ever the attachment is downloaded, it has the right store.

the new patch works fine!

Fixed to stable and HEAD.

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