[File] Regression in zip-archive detection

[Christos Zoulas]

I believe this has been fixed on HEAD.

Best,

christos

> On Sep 3, 2021, at 12:37 AM, Torsten Landschoff <torsten at debian.org> wrote:
> 
> Am 2021-09-02 23:24, schrieb Torsten Landschoff:
> 
>> PPS: I bisected this using a simple C program. Looks like this commit
>> introduced this bug:
>> commit c21152a62f9a62cdb67e462e66fb35d06435fa84 (HEAD, refs/bisect/bad)
>> Author: Christos Zoulas <christos at zoulas.com>
>> Date:   Sun Jun 7 17:27:10 2020 +0000
>>    Handle EPUB documents that have no mimetype
> 
> 
> FWIW, reverting that commit and resolving conflicts gave me this diff:
> 
> diff --git a/magic/Magdir/archive b/magic/Magdir/archive
> index d4fd3c92..f7f5d207 100644
> --- a/magic/Magdir/archive
> +++ b/magic/Magdir/archive
> @@ -1417,15 +1417,11 @@
> >>>>38         search/64       .app/   iOS App
> !:mime application/x-ios-app
> 
> -# Dup, see above.
> -#>30   search/100/b application/epub+zip       EPUB document
> -#!:mime application/epub+zip
> 
> # Generic zip archives (Greg Roelofs, c/o zip-bugs at wkuvx1.wku.edu)
> #   Next line excludes specialized formats:
> >(26.s+30)     leshort !0xcafe
> ->>30   search/100/b !application/epub+zip
> ->>>26    string          !\x8\0\0\0mimetype    Zip archive data
> +>>26    string          !\x8\0\0\0mimetype     Zip archive data
> !:mime application/zip
> >>>>4  beshort         x                       \b, at least
> 
> 
> With that change zip files are again reported correctly.
> 
> I have to admit that I don't understand what this search/100/b command actually does.
> 
> 
> Greetings, Torsten
> 
> --
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20210903/af7e10f6/attachment.asc>