about <match> value -- file /usr/share/mime/packages/freedesktop.org.xml

Jerome Leclanche adys.wh at gmail.com
Mon Jan 21 11:02:07 PST 2013

.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 <krammer at kde.org> 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
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20130121/faf37cab/attachment-0001.html>

More information about the xdg mailing list