Bug 216537
| Summary: | Can't open .pdf file from evolution. | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Tom Kincaid <tkincaid> | ||||||||||||
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> | ||||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> | ||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | 5.0 | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | RC | Doc Type: | Bug Fix | ||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2007-02-08 00:39:58 UTC | Type: | --- | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Tom Kincaid
2006-11-20 23:18:31 UTC
Created attachment 141708 [details]
This it the .PDF file that was sent to me.
Created attachment 141817 [details]
Acrobat Error.
Created attachment 141818 [details]
Error from document viewer.
Mishandling the space in the filename ? Ah, no. In fact, it is the # in the filename that breaks things. When I tested this with an attachment named "test # 111.pdf", evince was called with the argument file:///home/mclasen/.evolution/cache/tmp/evolution-tmp-3K8rQ7/test_%23_111.pdf but looking in that directory, I find a file named test_ I believe the problem is that for viewing attachments, evo calls em_utils_temp_save_part(), which constructs a temp path and passes it on to mail_save_part(), which defers the acutal saving to a thread that calls save_part_save(), which treats the path as an uri and passes it into camel_stream_vfs_new_with_uri(). The attached (untested) patch should fix the issue. Created attachment 142657 [details]
patch
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. Forwarded this upstream: http://bugzilla.gnome.org/show_bug.cgi?id=383047 Created attachment 142968 [details]
Revised patch
Verified mclasen's patch and did a bit of extra code cleanup.
Here's what I submitted upstream.
Fixed in evolution-2.8.0-22.el5. This patch breaks the ability to save attachements. Cannot save attachements with 2.8.0-22. backed down to 2.8.0-21 and it works Confirmed that both patches (mclasen's and mine) cause bug #219228. There's no time to investigate this further before RHEL-5 GA, so the best we can do revert the patch that caused the regression and defer this to RHEL-5.1. Hence, Devel_NACK. Patch disabled in evolution-2.8.0-30.el5. A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |