| Summary: | Two types that only differ in case cause the data from one to be overwritten | ||
|---|---|---|---|
| Product: | shared-mime-info | Reporter: | Jann Horn <jann+freedesktop_bugzilla> |
| Component: | general | Assignee: | Shared Mime Info group <shared_mime_info> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | iplaw67 |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=88004 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 82711 | ||
|
Description
Jann Horn
2014-08-18 18:38:47 UTC
If types that only differ in case should be treated the same, what would be the best way to fix it? Create functions g_str_equal_nocase and g_str_hash_nocase or so that call g_str_equal and g_str_hash with the argument lowercased, then pass pointers to those functions to g_hash_table_new? I would write a patch, but I'm not sure what the expected behavior is here. Can some developer please comment on that? Adding self to CC if not already on That's not a bug. Mime-types are case unsensitive. See: https://bugs.freedesktop.org/show_bug.cgi?id=62473 for details. > On my system (Debian jessie), the two MIME types > 'application/vnd.ms-powerpoint.presentation.macroenabled.12' and > 'application/vnd.ms-powerpoint.presentation.macroEnabled.12' that > only differ in case exist They're not two different mime-types, it's a duplicated mime-type. So what exactly is your position on duplicate mimetypes?
"They must not exist and if they do, that invokes undefined behavior"?
"They must not exist and if they do, one copy wins and the others are discarded silently?"
In my opinion, if a tool can't cope with its input, it should throw an error message, or at least a warning, instead of blindly soldiering on.
> That's not a bug. Mime-types are case unsensitive.
And what I complained about here specifically is that the hashtable "types" is case-sensitive (while filenames are lowercased). If MIME types are case-insensitive, shouldn't the hashtable be case-insensitive, too?
I opened this bug because it blocks the patch in bug #82711. The problem is that update-mime-database ends up writing a new file, then immediately writes over the same file again. Certainly that's not desirable behavior? (In reply to Jann Horn from comment #5) > So what exactly is your position on duplicate mimetypes? > "They must not exist and if they do, that invokes undefined behavior"? > "They must not exist and if they do, one copy wins and the others are > discarded silently?" > > In my opinion, if a tool can't cope with its input, it should throw an error > message, or at least a warning, instead of blindly soldiering on. My "position" is the status quo. It's not mentioned in the spec, and the behaviour is undefined. In our case, we don't merge, we override. So, yes, the others would be discarded silently. > > That's not a bug. Mime-types are case unsensitive. > > And what I complained about here specifically is that the hashtable "types" > is case-sensitive (while filenames are lowercased). If MIME types are > case-insensitive, shouldn't the hashtable be case-insensitive, too? Feel free to submit a test case that would fail before that change, and wouldn't afterwards. If you want a change of behaviour, then it must first be defined, and for that, discussions happen on the xdg mailing-list. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.