Incorrect mtime serialization in tar archives #45

Closed
VladRassokhin opened this Issue Sep 18, 2013 · 6 comments

Projects

None yet

2 participants

Header produced by console tar archive

0000000: 626c6f636b732f7363726f6c6c626172  blocks/scrollbar
0000010: 2f5f7363726f6c6c6261722e73637373  /_scrollbar.scss
0000020: 00000000000000000000000000000000  ................
0000030: 00000000000000000000000000000000  ................
0000040: 00000000000000000000000000000000  ................
0000050: 00000000000000000000000000000000  ................
0000060: 00000000303030303634340030303031  ....0000644.0001
0000070: 37353000303030313735300030303030  750.0001750.0000
0000080: 30303030343532003132323136303732  0000452.12216072
0000090: 30363200303135373732002030000000  062.015772. 0...
00000a0: 00000000000000000000000000000000  ................
00000b0: 00000000000000000000000000000000  ................

Header produced by node-archiver:

0000000: 626c6f636b732f616c6572742f5f616c  blocks/alert/_al
0000010: 6572742e736373730000000000000000  ert.scss........
0000020: 00000000000000000000000000000000  ................
0000030: 00000000000000000000000000000000  ................
0000040: 00000000000000000000000000000000  ................
0000050: 00000000000000000000000000000000  ................
0000060: 00000000303030303636342030303030  ....0000664 0000
0000070: 30303020303030303030302030303030  000 0000000 0000
0000080: 30303030373330203031323231363037  0000730 01221607
0000090: 32303632303136313633002030000000  2062016163. 0...
00000a0: 00000000000000000000000000000000  ................
00000b0: 00000000000000000000000000000000  ................

Files are different, but have same mtime == "12216072063" (in hex format)

In node-archove variant mtime prerended with '0' for some strange reason (in HeaderTarFile.prototype._prepNumeric function).

Some programs (apache commons compress java library) fails to read such tar files. (It assumes that mtime is null or space ended string).

So it would be nice to fix mtime serializing.

Owner

thanks for the report. will investigate this weekend.

Owner

im wondering if its a difference in specs. I have been going by gnu tar specs here:

http://www.gnu.org/software/tar/manual/html_node/Standard.html

The name, linkname, magic, uname, and gname are null-terminated character strings. All other fields are zero-filled octal numbers in ASCII. Each numeric field of width w contains w minus 1 digits, and a null.

Owner

Looking at what I believe is the project your talking about:

http://commons.apache.org/proper/commons-compress/tar.html

The tar package does not support the full POSIX tar standard nor more modern GNU extension of said standard.

Hm. Ok.
Yes, it's about reading tar with apache-commons-compress.

BTW: Each numeric field of width w contains w minus 1 digits, and a null
So i believe my request still actual :)

Owner

ah seems I must of left out the null part. most tar parsers are too forgiving and verify even if they don't match spec exactly. working on few aspects but should get an update out this week to resolve the issue.

Owner

sorry for the delay. v0.4.10 has been pushed out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment