gvfs-open exit code is 0 when file is not found and no default application is registred

[MestreLion]

gvfs-open exits with error code 0 (success) even when there is error.

The following conditions should exit with error code > 0:
- File is not found
- File is found, but default application for opening it is not registred

Examples:
$ gvfs-open nofile.txt || echo "NOT FOUND!"
gvfs-open: file:///home/rodrigo/nofile.txt: error opening location: Error stating file '/home/rodrigo/nofile.txt': No such file or directory

$ touch test.mdb ; gvfs-open nofile.txt || echo "NO ASSOCIATION!" ; rm test.mdb
gvfs-open: file:///home/rodrigo/nofile.txt: error opening location: Error stating file '/home/rodrigo/nofile.txt': No such file or directory

In both situations exit code was 0, meaning success, even when gvfs-open was clearly NOT successful. This makes gvfs-open hard to use in scripts.

And the problem is even worse considering gvfs-open is used by xdg-open

A quick look at source code shows that it has a hardcoded "return 0" in main() function. The open() function is "static void". Both could easily be changed so open would be "static int open(...)", set a proper return code, and main would test for it.

Using Maverick 10.10 64bits, gvfs 1.6.4-0ubuntu1.1

[MestreLion (mestrelion)]

Question: if this patch gets approved and merged upstream, what should i do to make it cherry-picked all the way to Maverick ?

[Sebastien Bacher (seb128)]

Thank you for your work there

[Sebastien Bacher (seb128)]

To reply to your question it's not likely that will be a candidate for stable updates, see the criterious on https://wiki.ubuntu.com/StableReleaseUpdates

[MestreLion (mestrelion)]

Updated patch, with cosmetic changes (spacing, line breaks, commit message)

[Sebastien Bacher (seb128)]

the fix has been commited to the upstream git and will be in the next update

[MestreLion (mestrelion)]

Any chance this can be cherry-picked to maverick backports or updates?

[Martin Pitt (pitti)]

This was fixed in 1.9.4.