[File] offset directicve for file size detection not working! BUG?

[Christos Zoulas]

Committed, thanks!

christos

> On Sep 10, 2022, at 9:35 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> some weeks ago send patch of Magdir/images for X Window Dump images
> (*.XWD). And some times ago i send patch for Atari DEGAS Elite bitmap
> (*.PI1). When running file command (version 5.42 containing both
> patches) with -k option on such images i get an output like:
> 
> abydos.xwd:   Atari DEGAS Elite bitmap 320 x 200 x 16,
> 	      color palette 0065 0000 0007 0000 0002 ...
> 	      X-Window screen dump image data, version X11,
> 	      800x600x24, order 1, 256 colors 0 entries
> alf33.pi1:    Atari DEGAS Elite bitmap 320 x 200 x 16,
> 	      color palette 0000 0700 0111 0070 0222 ...
> betyboop.dmp: Atari DEGAS Elite bitmap 320 x 200 x 16,
> 	      color palette 006d 0000 0007 0000 0000 ...
> 	      X-Window screen dump image data, version X11,
> 	      "betyboop", 576x720x1, 2 colors 2 entries
> dissseq.pi1:  Atari DEGAS Elite bitmap 320 x 200 x 16,
> 	      color palette 0004 0025 0037 0057 0060 ...
> input.xwd:    Atari DEGAS Elite bitmap 320 x 200 x 16,
> 	      color palette 006e 0000 0007 0000 0002 ...
> 	      X-Window screen dump image data, version X11,
> 	      "input.xwd", 70x46x24, order 1, 256 colors 0 entries
> 
> Most XWD images are also described wrong and first as Atari DEGAS
> Elite low-res uncompressed bitmap (*.PI1). Luckily the displaying
> part is done by sub routine degas-bitmap. So only test line must be
> changed. The current looks like:
> 0		beshort		0x0000
>> 2		quad		!0
>>> 4		ubeshort&0xF000	0
>>>> 0		use		degas-bitmap
> The first line test for weak 2 starting magic bytes. That is also
> true for XWD samples and others. By next lines misidentified samples
> like plpbt.iso and g3test.g3 are skipped by checking for valid
> values of color palette entries. Unfortunately for most XWD samples
> this looks also valid here.
> 
> According to referenced URL the low resolution Atari DEGAS
> bitmap variant (*.pi1 with 320x200, 16 colors) in standard form has
> an exact file size of 32034 bytes (like: 8ball.pi1 teddy.pi1
> sonic01.pi1). The Elite variant contains after image data a footer
> part, which is used for color animations. So such variant samples
> have a file size of 32066 (hexadecimal 7D42). On my system i found
> about 61 such examples (like: spider.pi1 pinkgirl.pi1 frog3.pi1).
> Unfortunately there exist some samples with bigger size. That means
> such samples contain additional bytes after animation footer. I
> found 55 examples with file size 32128 ( that is hexadecimal 7D80,
> like: mountain.pi1 bigspid.pi1 alf33.pi1). Maybe that software is
> acquiring
> disk space as multiple of paragraphs or something like that and does
> release unused bytes at the end finally. And i found on example
> kenshin.pi1 with the highest size 44834. Maybe this is triggered by a
> bad file transfer operation, but all images are valid ( verified by
> graphic recoil software).
> 
> According to man page magic(4) i can use offset directive to
> show/test for a file size. So i insert after last test a line like:
>>>> -0		offset	x	FILE_SIZE=%lld
> That show the expected sizes. Then i tried to insert additional
> test lines before calling sub routine. For standard case these
> additional lines fragment look like:
> 
> #>>>0		beshort	x	1ST_VALUE=%x
>>>> -0		offset	=32034	VARIANT_STANDARD
> #>>>>0		beshort	x	1st_VALUE=%x
>>>>> 0		use		degas-bitmap
> 
> Now the sub routine prints other and wrong values. When i try to
> display the first value instead of sub routine, the line with
> "1st_VALUE=" is never executed whereas the line with "1ST_VALUE" is
> executed and show correct value. So i think this is a BUG in file
> command.
> 
> After applying the above mentioned modifications by patch
> file-5.42-images-pi1.diff then for my Atari DEGAS bitmap values
> are wrong.
> 
> Unfortunately i am no c programmer. So maybe somebody can look at
> mentioned item and fix this.
> 
> Thanks
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYx07WwAKCRCv8rHJQhrU
> 1vSrAJ9UgICzDASnlf0XhCVnyi8/oKa+pwCfX9iqZORvXbsjz0A7QHb12wdTmz8=
> =xoUi
> -----END PGP SIGNATURE-----
> <file-5_42-images-pi1_diff.DEFANGED-49383><file-5_42-images-pi1_diff_sig.DEFANGED-49384>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>

-------------- 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/20220911/b5714565/attachment.asc>