.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.
J. Leclanche On Mon, Jan 21, 2013 at 6:32 PM, Kevin Krammer <[email protected]> wrote: > 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.. > > > > So if I had these problematic filetypes (.msi/.msu) in ~ , I get no > > long-long long delay.. > > Probably orders of magnitude faster medium, no? > > > ^ 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. > > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > >
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
