gzip: creates wrong header on FAT file systems

[ak120]

By using gzip 1.4 to compress a given file on an OS/2 native FAT filesystem a wrong header is written to the resulting gzip compressed file. According to RFC 1952 and gzip documentation the offset 9 should contain the value 0 (00h "FAT filesystem (MS-DOS, OS/2, NT/Win32)") but with the version from netlabs rpm repo it is 6 (06h for HPFS). Using gzip 1.2.4 for DOS (running under OS/2's DOS-window) writes the correct value 0.

I didn't test the behaviour with JFS or VFAT (fat32) filesystems, but I would assume the same issues.

[Silvan Scherrer]

according to the rfc ​https://tools.ietf.org/html/rfc1952 the value of 6 is perfect as well. This code is a fixed value and is set to 0x06 since ages.

From the changelog

Fri Mar 10 13:27:18 1993  Jean-loup Gailly  (jloup@chorus.fr)

	* version 1.0.6
	  Let gzexe detect executables that are already gzexe'd.
	  Don't try restoring record format on VMS (the simple 1.0.5 code
	    worked correctly only on fixed-512 files). Suppress text_mode.
	  Added asm version for 68000 in amiga/match.a.
	  Use asm version for Atari TT.
	  Fix "make clean" in vms/Makefile.vms.
	  For OS/2, assume HPFS by default, add flag OS2FAT if necessary.

[ak120]

Replying to diver:

according to the rfc ​https://tools.ietf.org/html/rfc1952 the value of 6 is perfect as well. This code is a fixed value and is set to 0x06 since ages.

Strange, the mentioned document doesn't include your "perfect". And the only "fixed values" from this RFC are the first two bytes.

This will bring us directly to the next problem: a gzip archive created on an OS/2 FAT filesystem can only be created by redirection and only be correctly extracted to the original filename by -N switch.