GNOME Bugzilla – Bug 780384
gio/tests/contenttype fails on OS X: "public.directory" != "public.folder"
Last modified: 2018-05-24 19:27:28 UTC
Building glib-2.52.0 on OS X 10.11, I get a test failure: /contenttype/guess: ** GLib-GIO:ERROR:contenttype.c:42:test_guess: assertion failed (expected == res): ("public.directory" == "public.folder") Looks like gio/goscontenttype.c isn't consistent with its canonical terminology. g_content_type_guess uses cocoa's UTType* functions, so it returns the OSX-ish "folder". But g_content_type_from_mime_type uses hand-coded string analysis and returns the unix-ish "directory".
Created attachment 348458 [details] [review] build: Skip gdesktopappinfo tests on OSX This doesn't fix the failing content type tests but solve a related build failure.
(In reply to Daniel Macks from comment #0) > Building glib-2.52.0 on OS X 10.11, I get a test failure: > > /contenttype/guess: ** > GLib-GIO:ERROR:contenttype.c:42:test_guess: assertion failed (expected == > res): ("public.directory" == "public.folder") > > > Looks like gio/goscontenttype.c isn't consistent with its canonical > terminology. g_content_type_guess uses cocoa's UTType* functions, so it > returns the OSX-ish "folder". But g_content_type_from_mime_type uses > hand-coded string analysis and returns the unix-ish "directory". So I've been going through the list of failing content type tests and the problem is there is a lot of vague hand waiving, the function is called content_type_guess() after all... The directory vs folder issue is easy to fix as we are the one declaring that type but then we lead to other failures that have no clear answers.
Created attachment 348460 [details] [review] gosxcontenttype: Fix various tests This fixes numerous tests including the one for this issue and skips a few that don't apply. The remaining failing tests are due to icons but I didn't want to skip them as they are relevant and need fixing but are probably a bit more in-depth. Maybe I'll get around to that later.
Review of attachment 348458 [details] [review]: I'm away from my OS X machine atm, but I assume that you've found this while building on OS X.
Review of attachment 348460 [details] [review]: Other than that typo, looks good to me. ::: gio/gosxcontenttype.c @@ +219,3 @@ else if (UTTypeConformsTo (uti, CFSTR("public.script"))) ret = TRUE; + /* Our texts assert that all text can be executable... */ Our _tests_ assert, maybe ?
Attachment 348458 [details] pushed as 03c88da - build: Skip gdesktopappinfo tests on OSX Attachment 348460 [details] pushed as 206c54c - gosxcontenttype: Fix various tests I suppose we can close this as fixed but again the icon tests do still fail.
Applying 206c54c to 2.52.2 on OS X 10.11 gets gio/tests/contenttype to pass to the extent intended (PASS/SKIP 6/9, then fail at the icon tests). But now the last two tests of gio/tests/resources fail: GLib-GIO:ERROR:resources.c:476:test_uri_query_info: assertion failed (mime_type == "text/plain"): ("text/*" == "text/plain") # Start of uri tests ../../tap-test: line 5: 80585 Abort trap: 6 $1 -k --tap # GLib-GIO:ERROR:resources.c:476:test_uri_query_info: assertion failed (mime_type == "text/plain"): ("text/*" == "text/plain") ERROR: resources - too few tests run (expected 9, got 7) whereas previously they had passed.
206c54c is also confusing as to the type of the new "uncertain" variable. It's declared as int and assigned a value of -1, but the only other assignments to it are the value TRUE. It sounds like it's a boolean where -1 means false, and then crossing over into token or enum values (though I can't think of a platform where TRUE is not compatible with an int, etc). Why not make it a gboolean, assigned initially as FALSE? Then later what took me a few minutes to decipher: *result_uncertain = uncertain == -1 ? FALSE : uncertain; becomes the simple and self-documenting: *result_uncertain = uncertain;
-1 means "not explicitly set". If it defaulted to FALSE we wouldn't know when it was explicitly set to FALSE.
*** Bug 787245 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1251.