Created attachment 767791 [details] Reproducer Description of problem: magic_file() detects "application/octet-stream; charset=binary" instead of "application/x-gzip; charset=binary" for gzip, "application/x-bzip2; charset=binary" for bzip and "application/x-xz; charset=binary" for xz. For text files detection works fine. No other file types tested. Version-Release number of selected component (if applicable): Name : file Arch : i686 Version : 5.14 Release : 9.fc20 How reproducible: always Steps to Reproduce: Reproducer appended Actual results: application/x-xz; charset=binary for every tested compressed file.
It looks like in File-5.14, magic_check/magic_load/magic_compile/magic_list are mutual exclusive. If you use magic_load(), it loads magic patterns from file and you can use them later, but if you call magic_check(), it will reload the patterns, check them and free them. So next magic_* functions will not return sane value, because magic patterns are not loaded (they have been freed by magic_check function). Solution could be calling magic_check before magic_load (I've tested it and it works). I'm not sure it's the good decision to change behaviour like this and I will raise it upstream, but we have to stay consistent with upstream in question of API semantics.
Hi, I've thrown magic_check() away. Probably, it has been useless for my usage anyway (I've always load a default mime-type db). All createrepo_c unittest are green now. Thank you.
I'm closing this bug as NOTABUG. It's intended upstream behaviour.