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

westlake westlake2012 at videotron.ca
Fri Jan 18 15:51:19 PST 2013


Actually this does not occur at all with lynx or mc

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)


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.
(Another thing, is if I use a Web browser with file:// as part of the 
URL, the directory lists is always quick)

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

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

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

I'm addressing these suspicions for anybody wanting to know more in 
detail what the problem may be..

I have a feeling it's beyond the libraries that GUI file navigators use 
-- there's definitely a problem somewhere..

The thing is it occurs with KDE (dolphin) and Gnome (nautilus) ..

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)

-Scott


On 13-01-17 04:28 PM, Thomas Kluyver wrote:
> On 17 January 2013 20:37, westlake <westlake2012 at videotron.ca 
> <mailto:westlake2012 at videotron.ca>> wrote:
>
>       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
>
>
> I'm guessing that the delay occurs because the file manager is 
> attempting to open each file to check its contents for mimetype matches?
>
> 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:
>
> - Detect that file operations are slow over ssl+webdav, and decide not 
> to examine the contents to find MIME types.
> - Display the list first, and progressively update icons etc. as they 
> gather MIME type information.
>
> I hope that helps,
> Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20130118/fb2a9313/attachment.html>


More information about the xdg mailing list