application/x-ole-storage does have two magic match entries on my installation.
I guess both refer to the same actual binary data, just one being given as string and the other as a number. shared-mime-info package 1.0 as far as I can tell. Cheers, Kevin On Monday, 2013-01-21, Jerome Leclanche wrote: > .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 -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
