After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 389273 - gnome_vfs_url_show_with_env does not work if .desktop entry has empty Path=.
gnome_vfs_url_show_with_env does not work if .desktop entry has empty Path=.
Status: RESOLVED FIXED
Product: gnome-vfs
Classification: Deprecated
Component: URI handling
unspecified
Other All
: Normal major
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
Depends on:
Blocks:
 
 
Reported: 2006-12-24 19:27 UTC by Peter
Modified: 2007-01-08 14:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
The patch to fix the problem (634 bytes, patch)
2006-12-24 19:28 UTC, Peter
needs-work Details | Review
Updated patch. (742 bytes, patch)
2006-12-25 14:17 UTC, Peter
none Details | Review

Description Peter 2006-12-24 19:27:53 UTC
Please describe the problem:
Hello.

Although I know that gnome-vfs should die some day, I've spent week on investigation of this issue and really appreciate any comments on the patch I'll attach. The problem occurs that ~/gnome-open stopped working on *.html files with the error:

Error showing url: There was an error launching the default action command associated with this location.

Now I know that to reproduce this behavior you should have .desktop file (mozillafirefox-2.0.desktop in my case) with 'Path=' element inside. So just add 'Path=' into desktop file and you'll get this behavior.

Inside gnome_vfs_mime_application_launch_with_env() (gnome-vfs-mime-handlers.c:1016) the g_spawn_async receives as it's first parameter app->priv->path which is just '' in case you have 'Path=' in .desktop file and as the result g_spawn_async returns with error->message:

Error: Failed to change to directory '' (No such file or directory)

If you do not have 'Path=' this parameter is (null) and if you have 'Path=/any/dir' this parameter is /any/dir.

If I understood correctly the root of the problem is gnome_vfs_mime_application_new_from_desktop_id() function. It just fill in app->priv->path:
app->priv->path = g_key_file_get_string (key_file, DESKTOP_ENTRY_GROUP,
                                                 "Path", NULL);
and does not check for value. So my solution is to check and if app->priv->path is "" then set it explicitly into NULL. Something like:

if (!g_ascii_strcasecmp(app->priv->path,""))
  app->priv->path=NULL;

Thank you for your time,
Peter.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Peter 2006-12-24 19:28:33 UTC
Created attachment 78862 [details] [review]
The patch to fix the problem
Comment 2 Christian Neumair 2006-12-25 12:39:32 UTC
I'm not sure how these pathological edge cases should be dealt with, but your idea is probably correct.

You should just ensure to free the old app->priv->path value before setting it to NULL, because else you'd leak memory (usually 2+4 bytes, 2 for the null-terminated string and 4 for the malloc header).

Setting patch status to "needs-work", confirming.

Maybe you could submit your patch to the gnome-vfs mailing list once it's ready?
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Comment 3 Peter 2006-12-25 14:17:25 UTC
Created attachment 78875 [details] [review]
Updated patch.

Thank you for review, Christian. The mail into gnome-vfs sent.
Comment 4 Alexander Larsson 2007-01-08 14:38:13 UTC
Commited.