<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Actually this does not occur at all
with lynx or mc<br>
<br>
So far as any file navigator knows.. these are just local files..<br>
(I'm not using webdav/ssl via dbus/gvfs -- but have the mountpoint
under /etc/fstab as webdavfs)<br>
<br>
<br>
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.<br>
<br>
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..<br>
<br>
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.<br>
(Another thing, is if I use a Web browser with <a class="moz-txt-link-freetext" href="file://">file://</a> as part of
the URL, the directory lists is always quick)<br>
<br>
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..<br>
<br>
So if I had these problematic filetypes (.msi/.msu) in ~ , I get
no long-long long delay.. <br>
<br>
^ 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.<br>
<br>
So it can't be anything you're suspecting because it takes just
one .msi file to confirm it.. (Happens with 5 GUI file
navigators)..<br>
<br>
I'm addressing these suspicions for anybody wanting to know more
in detail what the problem may be.. <br>
<br>
I have a feeling it's beyond the libraries that GUI file
navigators use -- there's definitely a problem somewhere..<br>
<br>
The thing is it occurs with KDE (dolphin) and Gnome (nautilus) ..<br>
<br>
I'm betting disabling <Match, > can have a positive effect
since I do not really need to have magic numbers scanned on
Windows filetypes, but I do not know how to do this.. so meanwhile
I can try this to see if it has any effect at all.. Anyone knows
how I can try this? (just for the heck of it)<br>
<br>
-Scott<br>
<br>
<br>
On 13-01-17 04:28 PM, Thomas Kluyver wrote:<br>
</div>
<blockquote
cite="mid:CAOvn4qiQLu8uBRuxqYOhaNsbUy2kzQtadgURdGGD22k5P0vo3w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 17 January 2013 20:37, westlake <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:westlake2012@videotron.ca" target="_blank">westlake2012@videotron.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
It is because of <match> values that there's a 2+
minute delay when listing filetypes(Nautilus/Dolphin, but
not cli tools like mc and lynx) on an ssl+webdav
mountpoint</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">
I'm guessing that the delay occurs because the file manager is
attempting to open each file to check its contents for
mimetype matches?<br>
<br>
</div>
<div class="gmail_extra">I'm inclined to say that that's an
issue for the file managers, not the MIME database. The
database provides information about MIME types, but it's up to
the application how to use that. Specifically, they could:<br>
<br>
</div>
<div class="gmail_extra">- Detect that file operations are slow
over ssl+webdav, and decide not to examine the contents to
find MIME types.<br>
</div>
<div class="gmail_extra">- Display the list first, and
progressively update icons etc. as they gather MIME type
information.<br>
<br>
</div>
<div class="gmail_extra">I hope that helps,<br>
</div>
<div class="gmail_extra">Thomas<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>