Bug 481593 - evince cannot open a symlink to a PDF on an NFS share
evince cannot open a symlink to a PDF on an NFS share
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gnome-vfs2 (Show other bugs)
All Linux
high Severity medium
: rc
: ---
Assigned To: Tomáš Bžatek
Depends On:
Blocks: 499522
  Show dependency treegraph
Reported: 2009-01-26 11:35 EST by Olivier Fourdan
Modified: 2015-03-03 17:33 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-01-13 07:08:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (2.41 KB, patch)
2009-01-26 11:35 EST, Olivier Fourdan
no flags Details | Diff
Proposed patch for gnome-vfs instead (764 bytes, patch)
2009-09-14 08:44 EDT, Olivier Fourdan
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 331254 None None None Never

  None (edit)
Description Olivier Fourdan 2009-01-26 11:35:46 EST
Created attachment 329999 [details]
Proposed patch

Description of problem:

Opening a symlink on a NFS share with evince cause an error:

     Unable to open document
     Unhandled MIME type: “application/octet-stream”

Version-Release number of selected component (if applicable):


How reproducible:

100% reproducible

Steps to Reproduce:
1. Mount a NFS share on /mnt/test
2. put a PDF file as /mnt/test/some.pdf
2. Create a link from /mnt/test/some.pdf to /mnt/test/test.pdf
3. Use evince to open "/mnt/test/test.pdf"
Actual results:

evince is "Unable to open document"

Expected results:

evince opens the document

Additional info:

This is the upstream bug #331254 that became obsolete when evince switched to gio.

The problem is that evince checks if the file is local with gnome_vfs_uri_is_local() which returns FALSE for NFS mounts. As a result, evince will call gnome_vfs_xfer_uri() on the symlink on the NFS share,  which uses copy_symlink() because the type is GNOME_VFS_FILE_TYPE_SYMBOLIC_LINK.
Therefore gnome_vfs_xfer_uri() copies a link a link and we end up with a dangling symlink in /tmp/evince-{$PID}/document-0-file.pdf
By default, the MIME type associated with a symlink for which the target is missing is “application/octet-stream”, thus the error.
The fix adds a check to see if the source is a link, in which case it does not try to vfs_xfer_uri() the file.

Proposed patch attached.
Comment 1 RHEL Product and Program Management 2009-03-26 13:25:56 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 5 Marek Kašík 2009-06-19 03:52:41 EDT

this is a bug in gnome-vfs2. Its upstream version can be found here :
http://bugzilla.gnome.org/show_bug.cgi?id=349086 (together with a reproducer)
and here:
I'm reassigning this.


Comment 8 Olivier Fourdan 2009-09-14 08:44:29 EDT
Created attachment 360932 [details]
Proposed patch for gnome-vfs instead

This patch is for gnome-vfs.

It copies the file instead of the symlink if the option GNOME_VFS_XFER_FOLLOW_LINKS is set.
Comment 10 Chris Ward 2009-10-14 10:28:12 EDT
This is not an approved component for 5.5

FastTrack candidate?
Comment 15 errata-xmlrpc 2010-01-13 07:08:49 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.