Cannot open .svgz over NFS share.

[C.Kontros]

This is using Ubuntu-Hardy using Inkscape-SVN built on Sept. 16, 2008 as well as the current Hardy repo version.

While trying to open an Inkscape or plain .SVGZs on a NFS share I get this error: http://paste.ubuntu.com/47447 Putting the file in a path without spaces gives the same error.

If I switch mounting the share to use SMB it opens fine.

Using .46 on windows with SMB also works well. File opens fine.

Open the same files locally works without issue.

It's unclear whether this is a NFS, Inkscape or combination of the 2 issue.

[emparq (emparq)]

Same error happens for me as well, except it crashes with compressed Inkscape files (*.svgz) created/saved locally.

...<pasted from email to inkscape-devel, 2008-11-10>...

I noticed that Inkscape bails w/ an error message 'Failed to load the
requested file <filename>.svgz' when trying to open a compressed
Inkscape file through the GUI. However, it can still load the same
file just fine if I pass it to inkscape through the command-line:

$ # this works ok
$ inkscape myfile.svgz

...when it errors out, I get the following error message on the command line:

Entity: line 1: parser error : Start tag expected, '<' not found
�
^

To reproduce:
1 - create a new file
2 - add a shape (I just did a simple red square)
3 - save as 'Compressed Inkscape SVG (*.svgz)'
4 - close and re-open inkscape GUI
5 - in the GUI, File -> Open <your saved file> // this will result in the error
6 - open same file through command-line // this will open ok

I don't know how long this behavior has been around, I only started
using compressed SVG's recently, but I see the behavior as far back as
rev 20150.. I also keep rev 19967 handy (there seems to have been a
performance regression since this build, when zooming in/out.. the
canvas seems to refresh slower... but that's another matter
altogether), and it suffers the same problem BOTH through the GUI and
command-line.

...<snip>...

[capnhud (render1232)]

This is occurring on WIndows versions also. I can go to the directory and choose the file in which I then right-click Open with (Inkscape-dev) and the file works fine. But using the Inkscape-dev GUI returns a inkscape fail to load error message and then promptly crashes.

[Alvin Penner (apenner)]

>> This is occurring on WIndows versions also

- is this a local file or NFS share ?
- running Win32 Inkscape20168 from Nov 10, I have not encountered any problems

[su_v (suv-lp)]

Do you still get this error with the current release version (Inkscape 0.47)?

[emparq (emparq)]

No, I can't reproduce the behavior using the method I described
before. I guess this got fixed at some point (I'm on Fedora-12
packaged Inkscape 0.47 r22583, built Feb 9 2010).

On Thu, Feb 18, 2010 at 6:14 PM, ~suv <email address hidden> wrote:
> Do you still get this error with the current release version (Inkscape
> 0.47)?
>
> ** Changed in: inkscape
>       Status: New => Incomplete
>
> --
> Cannot open .svgz over NFS share.
> https://bugs.launchpad.net/bugs/270990
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[C.Kontros (coryisatm)]

I think this can be closed now. I haven't seen the issue in some time. I actually thought this was closed. :)

[jazzynico (jazzynico)]

Thanks for your feedback!
Report closed "Fix Released".

[su_v (suv-lp)]

Reopening because the problem opening *.svgz on NFS shares still exists - see new duplicate report Bug #595549 “Cannot open saved SVGZ files”, reported with

Package: inkscape
Version: 0.47.0-2ubuntu2
Ubuntu Lucid Lynx 10.04

[bluebomber (bluebomber)]

See also duplicate bug Bug #770303 I just filed. The bug still exists for me here. :(

[Olivier Clavel (zeitounator)]

WoW !!! Looks like I'm doing some archeology here :)

The bug is still present:
inkscape version: 0.91
OS: ubuntu 15.10 x64

Please note: the bug on nfs happens only on reading. If you save the file to nfs, move it to a local drive and openit again, it opens just fine.

[Olivier Clavel (zeitounator)]

I have spoted the problem against the latest version of the code from bzr.

File: src/extension/svg.cpp
Method: Svg::open

If compiled with gnome vfs, we go through line 196 which chekcs if gnome_vfs is uninitialised or if the uri of the file is local. In that case, the built-in loader is used

For files situated on an nfs share, gnome_vfs_uri_is_local(gnome_vfs_uri_new(uri)) returns false so we go through the rest of the code (lines 200-208). What happens here basically is that we ask gnome_vfs to open the file and load it's content to memory to later create a doc from it. But in that case, the file is read literally to memory with the private method _load_uri which does not seem to be able to make a difference between compressed or uncompressed data. In the case of .svg it works correctly. In the case of svgz, the xml parser will fire an error at opening time since the compressed data does not reflect a valid xml.

I have no idea why there was originally a difference in the code between local and remote file ressources and why. Meanwhile, keeping code that does the job and trying the simplest fix, I was able to open svgz file on nfs with the following attached patch.

[jazzynico (jazzynico)]

@Olivier - Thanks for taking the time to investigate!
Your patch removes the gnomeVFS specific code. It's not a bad idea, because according to [1], gnomeVFS is deprecated. But we need to test for side effects when opening files with ftp or http protocols.

Of course, the most elegant fix would be to replace gnomeVFS with gvfs (and update our dependencies list).

[1] https://help.gnome.org/misc/release-notes/2.22/#sect:gvfs-gio

[Olivier Clavel (zeitounator)]

@jazzynico - You're welcome. Actually it was my first time looking at a c++ dev and messing arround with gdb on the command line and that was fun :)

I wasn't aware that inkscape could open urls directly from the command line... and I now understand why there was a local/distant distinction in the code. My patch indeed breaks that feature (just tested).

As you pointed out, he best move would be to go for gvfs but I guess this is a rather big change in the code base involving quite a few test.

I think there is an elegant way to quickfix this by concatenating the good method to the gnome_vfs_uri string (i.e. file:/path/to/file.svgz#gzip). I was trying to test that but I need to increase my skills level in cpp ;) I'll come back if I succeed !

[Olivier Clavel (zeitounator)]

Ok, first stop towards success:

Without making any changes, it is possible to open a distant svgz file under linux with the following command line:

inkscape file:///path/to/file.svgz#gzip:

Drawback: you get an error dialog upon opening with message "Format autodetect failed. The file is being opened as SVG"

Note that the current bug affects not only svgz files on nfs but any distant file (e.g. ftp, http). And this workarround works for them to:

inkscape http://my.server.com/file.svgz#gzip:

If I can get rid off the error dialog, the fix should be fairly trivial.

[Olivier Clavel (zeitounator)]

Good evening,

Here are two patches. The first is a partial fix letting aside some gnome_vfs_uri notations on the command line which are still buggy.

The second fixes everything but introduces a dependency to gnome_vfs in system.cpp.

Here are the tests I've been running.
Buggy = auto-detect file format fails and filename contains the vfs method suffix (#gzip:)

Open file GUI current patch1 patch2
/local/path/file.svg ok ok ok
/local/path/file.svgz ok ok ok
/nfs/path/file.svg ok ok ok
/nfs/path/file.svgz KO ok ok

Open vfs uri on CLI
/local/path/file.svg ok ok ok
/local/path/file.svgz ok ok ok
file:///local/path/file.svg KO ok ok
file:///local/path/file.svgz KO ok ok
file:///local/path/file.svgz KO Buggy ok
/nfs/path/file.svg ok ok ok
/nfs/path/file.svgz KO ok ok
file:///nfs/path/file.svg ok ok ok
file:///nfs/path/file.svgz KO ok ok
file:///nfs/path/file.svgz#g Buggy Buggy ok
http://server.com/file.svg ok ok ok
http://server.com/file.svgz KO ok ok
http://server.com/file.svgz# Buggy Buggy ok

[Olivier Clavel (zeitounator)]

Here's the second patch (see above comment)

[Olivier Clavel (zeitounator)]

Here's the second patch (see above comment)

[Olivier Clavel (zeitounator)]

A slightly more readable format of my test table above with special chars not stripped out of uris....

[Olivier Clavel (zeitounator)]

There was still a problem with relative paths on the command line and some utf-8 gotchas with files over http/ftp.....

I added some test cases that you will find in the attached png. Corresponding patch in the next message.

[Olivier Clavel (zeitounator)]

Here is the patch for the above test cases agains latest version on bzr