GNOME Bugzilla – Bug 154549
Use autorun.inf icon for cdroms
Last modified: 2008-02-18 11:22:27 UTC
From https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121763 When a cd is automounted on gnome's desktop, it would be nice if it could read the autorun.inf file and change the cd's icon to the one indicated by it, the same way it happens on windows. I know gnome can run the linux's autorun file, but it ignores the autorun.inf. Version-Release number of selected component (if applicable): nautilus-2.4.0-7 How reproducible: Always Steps to Reproduce: 1. Insert a cd containing a icon and with a autorun.inf saying: "icon=blabla" 2. Wait for cd to be auto-mounted 3. The icon is a plain cd. Actual Results: Nothing. It mounts normally, but the icon is not changed. Expected Results: The icon be the .ico file pointed in autorun.inf.
Thanks for your bug report! This is still an issue with recent Nautilus builds.
Created attachment 102296 [details] [review] Show Windows-style autorun icons in mounted CD-ROMs Quick patch. This is my first encounter with GIO, so I fully expect it to be buggy in some way.
+ if (g_ascii_strcasecmp (this_name, name) == 0) I have one small comment. If both strings are valid utf8, you should perhaps do an utf8 compare instead?
Created attachment 103220 [details] [review] Show Windows-style autorun icons in mounted CD-ROMs (v2) Are CD-ROM filenames allowed to contain non-ASCII characters? I thought that was one of their limitations. Either way, you are correct, it would be better to use UTF-8 comparisons.
This does synchronous I/O which is not permitted in Nautilus. Furthermore, it does so in a core code-path which is called a lot. I recommend reading docs/nautilus-internals.pdf for some (slighly out-of-date now) descriptions on how the nautilus i/o model works. Also, in the current code we're already reading autorun.inf in the new autorun handling code (libnautilus-private/nautilus-autorun.c). This seems a better place to do something like this.
I did not see any reading of autorun.inf in the autorun code (as an aside, that code does not properly search for autorun.*, see bug #511450). Also, I don't think autorun would be the correct place for this - the icon should be found the first time it is rendered, not just when the disc is inserted. I can't find where in particular the search itself should be placed. Ideally it would be in g_mount_get_icon(), but GIO has no functions for case-insensitive path traversal and I am hesitant to screw with what is obviously a heavily-planned API. If I place it in nautilus_file_get_icon(), 1) it's a block of sync I/O and 2) can't be used in the pathbar.
Created attachment 103712 [details] [review] Show Windows-style autorun icons in mounted CD-ROMs (v3) New version with asynchronous I/O. When nautilus_file_get_icon is called, if the file is a mountpoint, a search is started for the file's icon. If one is found, the file's icon is updated and changed signal is emitted.
Created attachment 104687 [details] [review] Listen for "changed" events from a desktop link's GMount As suggested on nautilus-list, new version of the patch that uses GVFS to find mount icons. This is the Nautilus portion of the patch. It listens for a "changed" signal from a GMount, and updates the desktop link's icon as appropriate.
Created attachment 104688 [details] [review] Retrieve CD-ROM autorun icons in GHalMount Second part of the GVFS-method patch. Extremely raw - basically just dumps the Nautilus-only patch into the ghalmount.c file and tweaks a few symbol names as needed. Does work, though. As an aside, it would be very nice if the insensitive file search functions in this patch and in nautilus-file-utilities.c merged into main GIO. They seem like something that would be very useful to others. If I filed a bug/wrote a patch for it, any chance they could be accepted?
I commited the nautilus part (with some changes, g_object_unref is not safe with NULL pointers).
I commited the gvfs patch with a variety of fixes and cleanups, including reformating to glib/gio/gvfs coding style. However, there are still some issues that ideally should be fixed in the find-insensitive code: * for each component, first check with g_file_query_info to see if the give name exists, which is faster for the case of an insensitive filesystem or if the given name is correct. * It should handle both the given name and the on disk name not being utf8 and fall back on ascii case folding. See the nautilus version of the code which has been fixed to do this. * Unrefing the enumerator without doing an async close on it will result in a sync close call I agree that the case-insensitive helper might be useful in gio itself, but we're kind of semi frozen there, so we don't want to add it in this release.
Created attachment 104768 [details] [review] Check if the file exists, fallback to ASCII, async close the enumerator > However, there are still some issues that ideally should be fixed in the > find-insensitive code Patch to fix these issues.
The close callback leaks in the case the close fails. And anyway, you don't need to actually handle the close callback, just scheduling the async close and then unrefing the handle is fine, the outstanding close async operation will ref the handle until its done.
fixed that and commited.