[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header
From: |
Joerg Schilling |
Subject: |
Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents |
Date: |
Tue, 08 Jun 2010 11:17:27 +0200 |
User-agent: |
nail 11.22 3/20/05 |
"Armistead, Jason" <address@hidden> wrote:
> Dustin wrote:
>
> >The entire original email was focused on ustar functionality, by my
> >read. Perhaps you can repeat your experiment, bearing in mind that
> >you're expecting a GNU Tar archive, and let us know what happens?
>
> My original experiment WAS with GNU formatted tar archives. Some work, and
> some don't. I have far larger tar files that are working OK. But this one,
> from a very important filesystem, is not. That is what led me to look more
> closely at the bytes in the file header records.
GNU tar archives by default have vendor specific extension from a definition
in POSIX.1-1988.
As POSIX.1-1988 does not include a way to to associate extensions to a
specific vendor, implementing POSIX.1-1988 extensions cause a risk of
missinterpreting archive content.
> With regard to my e-mail, I made a newbie blunder (having never looked under
> the hood of tar before), and assumed that because the resulting files
> contained "ustar" in the header, they must have been in Ustar format.
>
> If I'm correct it my understanding, a GNU formatted achive should also
> contain "ustar" (followd by a null) at offset 257 and "00" at offset 263. Is
> this correct for GNU format archives ?
No, a GNU tar archive is not even compliant to POSIX.1-1988 as it
does not implement long path names acording to POSIX.1-1988. GNU tar
archives are identified by "ustar " and careful tar implementations
only decode GNU tar vendor specific extensions if the archive can
be identified as a GNU tar archive.
> >Also, 7-zip claims to support "TAR" format, but doesn't say which
> >format - are you sure it's designed to support GNU Tar archives? If
> >you create a tar file with --format=ustar, can you read it with 7-zip?
>
> 7-Zip is decidedly vague on what sort of TAR it supports. I now have the
> source code, but it still doesn't explain what TAR format(s) it supports.
> Time permitting, I'll try to instrument it to figure out where it's breaking,
> and to understand what format(s) it supports. 7-Zip's author didn't leave
> many comments in his code, and doesn't have the ability to conditionally add
> in debugging. It could take me some time.
I recommend to use star, star supports 7z compression.
Jörg
--
EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
address@hidden (uni)
address@hidden (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect Ustar header contents, (continued)
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect Ustar header contents, Sergey Poznyakoff, 2010/06/04
- RE: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Armistead, Jason, 2010/06/04
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Tim Kientzle, 2010/06/04
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Dustin J. Mitchell, 2010/06/04
- RE: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Armistead, Jason, 2010/06/04
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Tim Kientzle, 2010/06/04
- RE: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Armistead, Jason, 2010/06/04
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Tim Kientzle, 2010/06/04
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Joerg Schilling, 2010/06/08
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents, Dustin J. Mitchell, 2010/06/04
- Re: [Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect GNU header contents,
Joerg Schilling <=