After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 780384 - gio/tests/contenttype fails on OS X: "public.directory" != "public.folder"
gio/tests/contenttype fails on OS X: "public.directory" != "public.folder"
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
2.52.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 787245 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-03-22 03:23 UTC by Daniel Macks
Modified: 2018-05-24 19:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build: Skip gdesktopappinfo tests on OSX (863 bytes, patch)
2017-03-22 04:38 UTC, Patrick Griffis (tingping)
committed Details | Review
gosxcontenttype: Fix various tests (6.65 KB, patch)
2017-03-22 05:40 UTC, Patrick Griffis (tingping)
committed Details | Review

Description Daniel Macks 2017-03-22 03:23:54 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".
Comment 1 Patrick Griffis (tingping) 2017-03-22 04:38:23 UTC
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.
Comment 2 Patrick Griffis (tingping) 2017-03-22 04:39:42 UTC
(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.
Comment 3 Patrick Griffis (tingping) 2017-03-22 05:40:15 UTC
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.
Comment 4 Matthias Clasen 2017-03-26 08:43:59 UTC
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.
Comment 5 Matthias Clasen 2017-03-26 08:44:09 UTC
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.
Comment 6 Matthias Clasen 2017-03-26 08:46:13 UTC
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 ?
Comment 7 Patrick Griffis (tingping) 2017-03-26 08:58:59 UTC
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.
Comment 8 Daniel Macks 2017-04-10 03:49:00 UTC
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.
Comment 9 Daniel Macks 2017-04-10 03:58:01 UTC
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;
Comment 10 Patrick Griffis (tingping) 2017-04-10 19:00:35 UTC
-1 means "not explicitly set". If it defaulted to FALSE we wouldn't know when it was explicitly set to FALSE.
Comment 11 Philip Withnall 2017-09-08 15:14:32 UTC
*** Bug 787245 has been marked as a duplicate of this bug. ***
Comment 12 GNOME Infrastructure Team 2018-05-24 19:27:28 UTC
-- 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.