René Scharfe <l.s.r@xxxxxx> writes:
>> Wow. The choice of %07o is as old as the very original of tar-tree
>> implementation in our codebase, starting at ae64bbc1 ("tar-tree:
>> Introduce write_entry()", 2006-03-25).
>
> Actually it's already in 731ab9ccf2 ("[PATCH] create tar archives of
> tree on the fly", 2005-04-28).
Yup, after viewing "git show ae64bbc1" I found out the commit added
a new helper to do %07o without touching the existing one that did
the same. Problem with relying on "git blame" too much X-<.
>> I think the updated behaviour matches Wikipedia [*1*] where it
>> spells out that 6 octal is followed by a NUL and a SP; it also says
>> various implementations do not adhere to this format---perhaps they
>> meant us ;-)
>
> OpenBSD's pax(1) does the same if I read
> https://github.com/openbsd/src/blob/master/bin/pax/tar.c correctly.
What's more interesting is that their verifier in tar_id() compares
the ulong value read from textual checksum with the ulong value
computed. I agree with you that it would be the more robust way
than what is done by squshfs tools (ng).
