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

Sun Sep 11 01:35:23 UTC 2022

-----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-----
-------------- next part --------------

--- file-5.42/magic/Magdir/images.old	2022-05-22 00:50:17.000000000 +0200
+++ file-5.42/magic/Magdir/images	2022-09-11 03:22:58.509370100 +0200
@@ -1456,11 +1456,29 @@
 0		beshort		0x0000
 # skip some ISO 9660 CD-ROM filesystems like plpbt.iso by test for 4 non black colors in palette entries
 >2		quad		!0
 # skip g3test.g3 by test for unused bits of 2nd color entry
 >>4		ubeshort&0xF000	0
->>>0		use		degas-bitmap
+#>>>0		beshort	x	1ST_VALUE=%x
+>>>-0		offset	x	FILE_SIZE=%lld
+# standard DEGAS low-res uncompressed bitmap *.pi1 with file size 32034
+>>>-0		offset	=32034	VARIANT_STANDARD
+#>>>>0		beshort	x	1st_VALUE=%x
+# like: 8ball.pi1 teddy.pi1 sonic01.pi1 
+>>>>0		use		degas-bitmap
+# about 61 DEGAS Elite low-res uncompressed bitmap *.pi1 with file size 32066
+>>>-0		offset	=32066	VARIANT_ELITE
+# like: spider.pi1 pinkgirl.pi1 frog3.pi1
+>>>>0		use		degas-bitmap
+# about 55 DEGAS Elite low-res uncompressed bitmap *.pi1 with file size 32128
+>>>-0		offset	=32128	VARIANT_3
+# like: mountain.pi1 bigspid.pi1 alf33.pi1
+>>>>0		use		degas-bitmap
+# 1 DEGAS Elite low-res uncompressed bitmap *.pi1 with file size 44834
+>>>-0		offset	=44834	VARIANT_4
+# like: kenshin.pi1
+>>>>0		use		degas-bitmap
 # DEGAS mid-res uncompressed bitmap *.pi2 (strength=50) after GEM Images like:
 # BEETHVEN.IMG CHURCH.IMG GAMEOVR4.IMG TURKEY.IMG clinton.img
 0		beshort		0x0001
 #!:strength +0
 # skip many control files like gnucash-4.8.setup.exe.aria2 by test for non black in 4 palette entries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.42-images-pi1.diff.sig
Type: application/octet-stream
Size: 856 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220911/63a8b1f7/attachment-0001.obj>
