GNOME Bugzilla – Bug 322314
Files without an extension always get MIME-sniffed (/usr/bin/*)
Last modified: 2018-02-10 19:06:35 UTC
when i play a movie email attachment, thunderbird allows me to choose another movie player. so i get the file chooser. i click ctrl-l, and get the edit box where i type /usr/bin/xine and get nice completions (although, usually it completes before allowing me to continue, so when i get to /usr/bin/xin it completes to /usr/bin/xine, but then i hit 'e', and get /usr/bin/xinee. maybe it should allow more time before completing) i then hit enter. the edit box dialog closes, and it then takes the main file chooser dialog apx. 15 seconds to come back. obviously, it reads all the entries in this directory. 1. no need to read *all* entries, just those that will be visible in the gui, and a bit before and after (to allow for scrolling) when the user scrolls, read more. 2. no need to refresh the file entries list if i already typed a file in the edit box. obviously, if there are also files with suffixes, there is a need to show the list, but then you'd know that (because the edit box has completions) Other information:
I would really like if the file-dialog simply closes when I give an entire filename in the location-popup. It would be faster for one thing, and it will also make sense, in my opinion. -- Adil
The firefox/thunderbird bug here is that it should not use a file chooser to pick an application in the first place. But it is a well-known problem that opening /usr/bin is slow, and we have some medium-term plans to fix this.
(In reply to comment #2) > it is a well-known problem that > opening /usr/bin is slow, and we have some medium-term plans to fix this. The original bug report made a very good suggestion, which is to close the file chooser immediately when a valid filename is selected in the Open Location dialog, instead of trying to show the directory listing for the enclosing directory.
The problem is that files in /usr/bin have no extension, and so they all get sniffed to figure out the MIME type. xdg-mime should detect that these files are executables and return the appropriate MIME type without actually sniffing the files. See also bug #310642 (Retitling for clarity)
*** Bug 329561 has been marked as a duplicate of this bug. ***
*** Bug 488517 has been marked as a duplicate of this bug. ***
What if we just hardcoded in xdgmime "file directly in /usr/bin == executable"? This bug really only comes up in exactly one context ... the broken user interface in firefox.
Owen, can you suggest a GTK widget to use instead of GtkFileChooser for choosing a file from /usr/bin? I mean instead of bashing applications for using GTK? Firefox, as you surely know, only has this problem on Linux and has only had the problem since it started using GtkFileChooser. If GtkFileChooser is unable, by design and purpose, to choose files from /usr/bin, it should clearly say so in the documentation. I guess it sniffs the MIME type to compare with the type selected in the file types drop-down? How about if 'all' is selected there it doen't do any type detection at all? That seems to be the easiest fix, though I wouldn't know of course.
Putting a filechooser on /usr/bin to choose an application is just a ridiculous user interface choice. Does the user really want to scroll through 3000+ files and pick 'od'? 'ar'? 'unwrapdiff'? Just an entry to type in a name of an application would be a far better user interface then the file chooser. A really good interface would look more like the <Alt>F2 dialog in GNOME ... an entry plus a list of applications found by reading the desktop files under /usr/share/applications. (Of course, there may be performance implications there as well for reading all the files... the <Alt>F2 dialog runs in the panel, which has already ready all those files.) I don't see how a windows vs. linux vs. OS X comparison is useful here. Neither windows nor OS X has an equivalent of /usr/bin containing all GUI applications on the system. The mime is used to select icons as well as for filtering.
(In reply to comment #7) > What if we just hardcoded in xdgmime "file directly in /usr/bin == executable"? I don't remember the xdgmime API right now, but somewhere you can feed it the struct stat of what you want to test. If the struct stat is for a regular file and it is executable, I'd simply return a MIME type for executables. There may be another function to which you feed the first few bytes of a file. I don't remember if the file chooser calls that explicitly or if it's all done inside xdg / gnome-vfs.
*** Bug 520663 has been marked as a duplicate of this bug. ***
*** Bug 529811 has been marked as a duplicate of this bug. ***
This isn't strictly a problem with /usr/bin. The same thing (to a lesser extent) happens in my home directory, where I currently have about 1000 files, most of which have no extension. From a quick measurement, on my laptop, it takes about 5.6 seconds to "ls -l" /usr/bin on a cold system, with 4600 files (it's probably not entirely cold, even). Repeating it takes about 0.17 seconds. This is reiserfs on a 5400 RPM disk. So you really want to avoid doing a stat if possible, much less actually opening the file. Running "file *", of course, is much worse -- 45 seconds cold, 2.2 seconds hot. Personally, I don't give a hoot for MIME type checking, icons, or whatnot. If I want an application to use a specific file, I want it to use that file if it at all possibly can. I don't care for icons, either. But that's neither here nor there. (As an aside, always assuming an executable file is simply an executable blob isn't always the right thing. Scripts are normally executable, but if you're opening them in a text editor or a browser you want to treat them as text. But that's also somewhat neither here nor there.) The real problem with this -- and it's terribly annoying in GIMP (not in Firefox, since I've long since switched back to the much better traditional Mozilla file dialog) -- is that the scan takes precedence over user input. User input should *always* take precedence in this kind of thing. If the user's typing fast, she might not even care about completion. Not to mention that if the directory is mounted over the network the current algorithm might be extremely unfriendly. The algorithm I'd suggest is: 1) Start with a simple readdir scan. Periodically check for user input, and always process said user input where possible. Assign MIME types on the fly when they can be computed from the file name (no other information). If the user changes directory, of course, abort the scan. Obviously, you don't even know which files are real files, which files are symlinks, which files are directories, etc., but you may never need to if the user types fast enough. 2) Stat all of the files. Again, periodically check for user input. If there's partial input, start by stat'ing the files that match the partial input. Again, assign any MIME types possible from the stat scan. 3) Only then go back and individually sniff the files -- again, starting with any partial completion that the user has input. The nice thing about this is that there's no need to special case any particular directories or whatnot. KPhotoAlbum had a similar problem with startup or scan for new images; by being clever about not stat'ing things that didn't need to be I sped it up from about 60 seconds (on my laptop, with about 20,000 images) to about 2 seconds. I don't appreciate it if I want to enter "/usr/bin/soffice" (to assign a file extension to OOo in Firefox) and it takes me 20 seconds to enter something that takes me about 2 seconds to type.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.
Matthias, in future comments of this kind, can you please provide a link to some text explaining the change along with the URL of the new bug tracker?