<div dir="ltr">.msi files (application/x-msi, subclass of application/x-ole-storage) do not have any content match. I get the feeling the issue might be deeper, eg. an overzealous thumbnailer.</div><div class="gmail_extra"> <div>J. Leclanche</div> <div class="gmail_quote">On Mon, Jan 21, 2013 at 6:32 PM, Kevin Krammer <<a href="mailto:krammer@kde.org" target="_blank">krammer@kde.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Saturday, 2013-01-19, westlake wrote: > Actually this does not occur at all with lynx or mc console interfaces don't have the same requirements, e.g. they usually don't have to retrieve the same amount of meta data. GUI file managers nowadays are required to show different icons depending on the file's MIME type, I doubt mc needs to know the MIME type at all. > So far as any file navigator knows.. these are just local files.. > (I'm not using webdav/ssl via dbus/gvfs -- but have the mountpoint under > /etc/fstab as webdavfs) Which is of course part of the problem, since local files are assumed to be random, high througput and low latency access. Remote file access systems which have been developed with the requirements of GUI programs in mind provide a way for applications to check if a file can be considered local for optimization, but keep it aware of potential I/O bounds if it can not. > I also tried to narrowed it down, and did long ago what you may suspect > is the problem. But it only occurs with anything that uses mimelists.. > -- So I disable any thumbnail checking. > > I guess I would be able to address this on another mailing list.. since > it doesn't seem anybody really understands this problem I'm having.. > > I would of thought too that it's the file managers. But this happens > with 5 GUI file managers.. and not at all for any of the cli file > navigators. Which would be a good indication that the GUI file managers do something they CLI file manager don't. Since you describe the problem occuring with files that have binary patterns defined for MIME type detection. Do the respective file extensions have multiple file type associations? Or the other way around: is the file extension unqiue? If it is not unique, e.g. the same extension being associated with two different file types, then file managers would need to look deeper, e.g. content inspection. And since the file is considered local, that is OK and considered very fast (loading of a handful of bytes). > (Another thing, is if I use a Web browser with file:// as part of the > URL, the directory lists is always quick) My guess on this data point is that as soon as file managers are aware they are not dealing with a local file they don't consider content inspection a viable option during listing. > and I disable any thumbnail checking --<< It ONLY occurs with .msi/.msu > files.. and a <match> rule is seldomly ever used... so it definitely has > something to do with the freedeskto project.. << BUT.. it does not > occur on a "local" storage.. <div class="im">> > So if I had these problematic filetypes (.msi/.msu) in ~ , I get no > long-long long delay.. </div>Probably orders of magnitude faster medium, no? <div class="im"> > ^ I tested it.. thumbnails off. A long list of files.. I then add just > "one" problematic .msi file and it nearly stalls the listing completely > (2+ minute delay) -- just because of ONE file. </div>Does this also happen if you have fetched the file already? E.g. by cat'ing it to /dev/null? I.e. so that any further access is likely to be answered from kernel I/O buffers? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring _______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div> </div>