Pre-POSIX.1-1988 (i.e. v7) tar header

[Xflofoxx]

Hi, is it possible to add the headers for Pre-POSIX.1-1988 (i.e. v7) tar recognition?

Reference here: https://en.wikipedia.org/wiki/Tar_(computing)#cite_note-2

Thanks in advice!

stroncium earned $40.00 by resolving this issue!

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on Issuehunt to raise funds.

[mifi]

Should be simple. Can libmagic (file cmd) recognize this?

[Xflofoxx]

Yes, here the output:

xflofoxx@mypc:~% file compressed.tar.bz2
compressed.tar.bz2: bzip2 compressed data, block size = 900k

[mifi]

BZ2 is another format with its own magic header, right?

[Xflofoxx]

Yes, sorry, let me explain better.
I'm using the library https://github.com/kevva/decompress from @kevva and it correctly bzip the file but then the file-type recognition of the unzipped data (that should be tar) is not identified correctly.

My first idea was to ask the library file-type. If correct identification wasn't possible then I would have asked the decompress lib to introduce a check such as "bypass tar check".

So, the bz2 format is correctly identified but the nested tar content not.

[mifi]

Ok, then please try to run "file" on the nested tar content instead of the bz2

[Xflofoxx]

xflofoxx@mypc:~% bunzip2 compressed.tar.bz2

xflofoxx@mypc:~% file compressed.tar
compressed.tar: tar archive

[mifi]

as far as i can see, file-type should already recognize tar, are you sure that it does not?

[Xflofoxx]

At line 102 there is this check:
if (buf[257] === 0x75 && buf[258] === 0x73 && buf[259] === 0x74 && buf[260] === 0x61 && buf[261] === 0x72) { return { ext: 'tar', mime: 'application/x-tar' }; }
and accordingly to Wikipedia it recognize perfectly UStar format (as I can see it checks byte 257-261 UStar indicator "ustar").

If I create a new tar I get the right format. The one I try to untar is a file taken from a fire detection system. The strange thing is that I can untar it like the one I create but the checked bytes have the following values:
buf[257] = 0
buf[258] = 0
buf[259] = 0
buf[260] = 0
buf[261] = 0
This is why I think the file was compressed with an old version, and I assume it was "Pre-POSIX.1-1988 (i.e. v7) tar"

The fields defined by the original Unix tar format are listed in the table below. The link indicator/file type table includes some modern extensions. When a field is unused it is filled with NUL bytes. The header uses 257 bytes, then is padded with NUL bytes to make it fill a 512 byte record. There is no "magic number" in the header, for file identification. - Wikipedia

Do you think it's possible to identify the file the same?

[Xflofoxx]

For completeness, if I save the buffer from the library into a tar file "manually" the response of the file cmd is "data" and not "tar archive".

[mifi]

From https://github.com/threatstack/libmagic/blob/master/magic/Magdir/archive:
pre-POSIX "tar" archives are handled in the C code.

I found some code here:
https://github.com/threatstack/libmagic/blob/master/src/is_tar.c

however i don't have time to analyze how it works now, feel free to try :)

[Xflofoxx]

Wow... thanks a lot!

[noisyui]

Actually the code can be borrowed from node-tar to decode the header of tar buffer and check the value of cksumValid, if there is no magic bytes at offset 257 in the header.

[IssueHuntBot]

@IssueHunt has funded $40.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[IssueHuntBot]

@sindresorhus has rewarded $36.00 to @stroncium. See it on IssueHunt

• 💰 Total deposit: $40.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $4.00