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

[Kevin Krammer]

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

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20130121/4848683e/attachment.pgp>