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

[Jerome Leclanche]

.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>