Red Hat Bugzilla – Bug 154350
Loading file from archive fails if filename contains spaces
Last modified: 2007-11-30 17:11:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322 Epiphany/1.5.8
Description of problem:
Create a file called test.doc, and create a .zip archive using file-roller.
Open the archive, and double-click the file. OpenOffice launches.
Now rename test.doc in the archive to test with spaces.doc.
Open the archive, and double-click the file. OpenOffice cannot find it - the correct filename (although with escaped spaces) is shown in the error dialog.
Now add a pdf file with spaces. evince complains "cannot determine mime type".
I *think* this error message is wrong. It can't find the file either.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The problem (at least in version file-roller-2.10.0-1, which is the one I'm
using) is that in window_open_files__extract_done_c the filename has already
been escaped (using shell-style escaping). But then that function calls
gnome_vfs_get_uri_from_local_path, which escapes the _escaped_ filename (using
URL-style escaping), which doesn't make sense. The filename should only be
Both of the functions I mentioned are in src/window.c.
This affects all files with escapable characters anywhere in their path, not
just files with spaces.
Great! I thought it sounded like an escaping bug. Hopefully this will make FC4.
Any chance of getting this fix in?
Created attachment 120159 [details]
Example of failure
These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks
Yikes - why the reopen? It's fixed.