Is Gzip supposed to honor original filename during decompress

archivingcompressionfilenamesgzip

This question stems from a Crypto++ library question on Stack Overflow: How to add filename to archive if compressing using Gzip class?.

Gzip, as specified in RFC 1952 has an optional field for the original filename:

  (if FLG.FNAME set)

     +=========================================+
     |...original file name, zero-terminated...| (more-->)
     +=========================================+

If the FNAME bit is set in the flag field, then the original filename is present.

We added the feature to Crypto++ and tested it on OS X. On OS X, it seems the gzip program, The Unarchiver (the default archive program), and the Archive Browser (App Store purchase) do not honor the original filename. That is, each decompresses to a filename which is the archive name sans the gz extension; and not the original filename as it appears in the header.

For example, here's an image under the Archive Browser. The original filename field is set to test-filename.txt, but the tool shows the filename as gzip-test, and unpacks it to a file named gzip-test:

enter image description here

GZip (and Gunzip) is not an IEEE standard Unix Command, so I can't really figure out where to seek knowledge on the expected behavior.

Is this expected behavior? Or am I seeing a bug in three different programs?

If its expected, then what practical purpose does the original filename serve?

Best Answer

According to the gzip man page, using the -N or --name option when using gunzip recovers the original file name. -N is the default when compressing (so gzip always saves the original file name) but not when decompressing so it has to be used explicitly with gunzip.

I tested this as follows:

$ ls
test.txt

$ gzip test.txt
$ ls
test.txt.gz

$ mv test.txt.gz widget.gz

$ gunzip -N widget.gz
$ ls
test.txt

... which is the result we were looking for.

Related Question