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

[Kevin Krammer]

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
-------------- 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/6dd8467a/attachment.pgp>