No subject


Mon Jul 30 04:12:14 PDT 2007


not care about the magic rules, partly because users are used to have =
the file extension detemine the type anyway. Also there are some cases =
where developers only use the magic rules since the file names are =
untrusted.
=20
Regards,
=20
-- Jaap <pardus at cpan.org>

________________________________

From: xdg-bounces at lists.freedesktop.org on behalf of Sanel Zukan
Sent: Fri 7/27/2007 8:11 PM
To: xdg at freedesktop.org
Subject: Re: Shared-mime checking order



Thank you for replies.

> Yeah, I also found that too, when checking my chemical MIME types =
list.
> Seems, priorities of "50" are enough for magic patterns. Should the =
spec
> be adjusted? What do you (people in general) think about this? I mean,
> the spec was written to have a standardized way to handle things. That
> doesn't mean, that things cannot be improved :) So is it time to =
update
> the spec? I would really like to see GNOME and KDE [1] (and other like
> rox-filer, ...) detecting the file types with the same success (of
> course, there are some false positives with the way of GNOME's
> implementation too - so there is place for improvement :)).

Yes; I'm also very interested to see unified detection, even if that
detection for corner cases shows to be wrong.

On other hand (maybe going little bit offtopic, but probably is perfect
time to ask), you (Alexander) noted that GNOME is going to use more
extension approach than mime magic checks. Why this way?

Clearly, user can fix bad detected file by changing extension indeed,
but how often mime magic can be shown to be wrong? I.e. most of the (let =
say
binary) files are distinguished by unique header and returning bad mime
type (after magic check) is probably result that someone messed with =
that
file.

> BCCing David Faure

Thanks; it would be really nice to see other implementations too :-)

Best,
--
Sanel
_______________________________________________
xdg mailing list
xdg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg




More information about the xdg mailing list