Bug 470302 - OpenOffice.org writer can't open doc files from remote directories opened by nautilus because g_file_input_stream_query_info doesn't do anything then
OpenOffice.org writer can't open doc files from remote directories opened by ...
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-11-06 11:03 EST by Oded Arbel
Modified: 2009-01-29 18:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-26 10:13:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screencast showing the problem (2.60 MB, application/octet-stream)
2008-11-06 11:52 EST, Oded Arbel
no flags Details
Just to show that it works fine here (972.93 KB, application/ogg)
2008-11-07 04:16 EST, Caolan McNamara
no flags Details
standalone demo (2.14 KB, text/plain)
2008-11-10 07:00 EST, Caolan McNamara
no flags Details

  None (edit)
Description Oded Arbel 2008-11-06 11:03:09 EST
Description of problem:
When browing an SMB share (from an MS-Windows file server) double clicking a .doc file opens OpenOffice.org Writer and then pops up a dialog with the text "This is not a WinWord97 File". Copying the same file to a local disk and opening it works just fine.

The same problem occurs with remote SSH browsing, so its not an SMB specific problem like Bug #454242.

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

How reproducible:

Steps to Reproduce:
1. Browse to a remote file share using nautilus
2. Locate a .doc file on the remote directory
3. Double click the doc file or right click and choose Open with "OpenOffice.org Writer"
Actual results:
OpenOffice.org writer starts but doesn't open the file, instead an error dialog appears.

Expected results:
The files should be opened by writer.

Additional info:
Comment 1 Oded Arbel 2008-11-06 11:04:19 EST
I also forgot to mention that opening ODT files from remote shares works just fine - no problems there.
Comment 2 Caolan McNamara 2008-11-06 11:29:59 EST
"The same problem occurs with remote SSH browsing, so its not an SMB specific

With two F-10 boxes.
On box A (i386), places->connect to server->ssh->fill in details for b->ok->remember forever->browse to somewhere where there are .doc and .odt files and I can open them fine without any errors.

Seems very odd that the *format* of the document would matter for this sort of stuff. And you have zero problems at all if you use nautilus to copy the .doc file to a local location.
Comment 3 Oded Arbel 2008-11-06 11:52:36 EST
Created attachment 322758 [details]
Screencast showing the problem

I've opened nautilus directly to the remote share using "ssh://server/home/oded" and tried to open documents from the new window. ODT works fine, .doc fails.

See attached screencast. I've added PDF opening with evince for extra points ;-)
Comment 4 Caolan McNamara 2008-11-07 04:16:34 EST
Created attachment 322835 [details]
Just to show that it works fine here

Is the remote file truly a .doc file. Not some other format renamed to .doc which maybe OOo could only detect the format of if it was truly a local file. What is the output of "file" on the .doc. (A pretty tenuous theory I guess)
Comment 5 Oded Arbel 2008-11-09 03:53:10 EST
The files I'm having problem with include all .doc files on the remote server. Copying the files to the local file system and then opening them works fine.

'file' claims these are "Microsoft Office Document" files (no mention of version).
Comment 6 Oded Arbel 2008-11-09 14:41:42 EST
BTW - using File->Open from within OpenOffice.org writer makes no difference: .doc files that I created using OpenOffice and copied to the remote server generate a "no a winword97 file" error while .odt files load just fine.
Comment 7 Caolan McNamara 2008-11-09 18:14:16 EST
Hmm, I can reproduce this if I save a .doc to the remote share and try and reopen it. I'll have a poke at this in the morning
Comment 8 Caolan McNamara 2008-11-10 06:42:38 EST
I'm not getting a size attribute back from gio, which doesn't matter for stream oriented .odt formats, but does matter for seekable .doc formats
Comment 9 Caolan McNamara 2008-11-10 07:00:46 EST
Created attachment 323060 [details]
standalone demo

So, g_file_input_stream_query_info doens't do anything :-(
Comment 10 Caolan McNamara 2008-11-10 07:37:04 EST
Hence a need to workaround in OOo, fix checked in. Will be in >= 3.0.0-9.11
Comment 11 Bug Zapper 2008-11-25 23:53:43 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 12 Caolan McNamara 2008-11-26 10:13:04 EST
In rawhide, will be in first F-10 update for OOo if there is one
Comment 13 Oded Arbel 2008-11-26 10:54:37 EST
Two questions, if I may: 
a. Does that mean that this bug may not be fixed in Fedora 10 lifetime? (I'm referring specifically to the "if there is one" comment.
b. This bug was closed as "fixed in rawhide" - when will there be rawhide packages with the fix, in order for me to test it? This fix is very important for my employer's plan to move to Fedora/RHEL on workstations.
Comment 14 Caolan McNamara 2008-11-26 11:23:04 EST
a) There will definitely be a 3.0.1 update for F-10, which is scheduled upstream for Jan 15th (http://wiki.services.openoffice.org/wiki/OOoRelease301). There may not be any 3.0.0 F-10 updates before that date for F-10

b) Yes, probably tomorrow.
Comment 15 Oded Arbel 2008-11-27 13:10:59 EST
Thank you for the answers and for fixing the bug.
Comment 16 Fedora Update System 2009-01-13 03:47:00 EST
openoffice.org-3.0.1-15.1.fc10 has been submitted as an update for Fedora 10.
Comment 17 Fedora Update System 2009-01-29 18:09:51 EST
openoffice.org-3.0.1-15.2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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