tar outputs errors when extracting boost_1_44_0.tar.bz2

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

tar outputs errors when extracting boost_1_44_0.tar.bz2

Timothy Madden
Hello

When trying to extract boost_1_44_0.tar.bz2 I get hundreds of lines reading:

        Archive value 4294967295 is out of gid_t range 0..65535

from tar, and then it exits with an error and my project build process
stops (the archive is still extracted I guess, but I never checked all
files and content)

I had the same versions of tar (1.23) and bzip2 (1.0.5) as on cygwin,
but on cygwin the extraction went normal.

Anyone knows why this happens ? Is there an workaround ? Can it be fixed ?

In my project I resorted to using basic-bsdtar, but that is not as
powerful as tar...

Thank you,
Timothy Madden


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: tar outputs errors when extracting boost_1_44_0.tar.bz2

Charles Wilson-8
On 9/1/2010 4:06 PM, Timothy Madden wrote:
> Hello
>
> When trying to extract boost_1_44_0.tar.bz2 I get hundreds of lines reading:
>
> Archive value 4294967295 is out of gid_t range 0..65535
>
> from tar, and then it exits with an error and my project build process
> stops

Whoever created that tar file did so on a platform that allows gid_t
values of 32bits.  New cygwin also allows this.  However, old cygwin
(like the version MSYS forked from) does not; so, when tar sees a value
that requires more than 16 bits, its error checking kicks in when it
realizes that it is about to assign that value to a variable that will
throw away half the data.

bsdtar works around that problem by using 'long int' to store the gid
information, instead of gid_t.

> In my project I resorted to using basic-bsdtar, but that is not as
> powerful as tar...

Use the bsdtar package (instead of basic-bsdtar). It supports all the
compression features you could name.  However, the two tar
implementations ARE different; GNU tar supports somethings that even the
full bsdtar version does not -- but the opposite is also true.

--
Chuck

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: tar outputs errors when extracting boost_1_44_0.tar.bz2

Timothy Madden
On 02.09.2010 00:35, Charles Wilson wrote:

> On 9/1/2010 4:06 PM, Timothy Madden wrote:
>> Hello
>>
>> When trying to extract boost_1_44_0.tar.bz2 I get hundreds of lines reading:
>>
>> Archive value 4294967295 is out of gid_t range 0..65535
>>
>> from tar, and then it exits with an error and my project build process
>> stops
>
> Whoever created that tar file did so on a platform that allows gid_t
> values of 32bits.  New cygwin also allows this.  However, old cygwin
> (like the version MSYS forked from) does not; so, when tar sees a value
> that requires more than 16 bits, its error checking kicks in when it
> realizes that it is about to assign that value to a variable that will
> throw away half the data.
[...]

Your wording kind of implies that tar /cannot/ extract that archive on
the MinGW platform, because the platform does not support it. Is this
the case ?

Thank you,
Timothy Madden



------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: tar outputs errors when extracting boost_1_44_0.tar.bz2

Charles Wilson-8
On 9/3/2010 4:59 PM, Timothy Madden wrote:

> On 02.09.2010 00:35, Charles Wilson wrote:
>> Whoever created that tar file did so on a platform that allows gid_t
>> values of 32bits.  New cygwin also allows this.  However, old cygwin
>> (like the version MSYS forked from) does not; so, when tar sees a value
>> that requires more than 16 bits, its error checking kicks in when it
>> realizes that it is about to assign that value to a variable that will
>> throw away half the data.
> [...]
>
> Your wording kind of implies that tar /cannot/ extract that archive on
> the MinGW platform, because the platform does not support it. Is this
> the case ?

Well, it is reported as a *warning* not an error. So I expect that tar
*is* able to extract the files; it's just noisy about it, and returns a
nonzero error code.

Besides, when you extract as a non-super-user, tar ignores the gid value
specified in the archive anyway; YOUR gid is used.  What if you did:

tar ... args ... 2>/dev/null || /bin/true ?

Or, just use the "full" bsdtar program instead, if basic-bsdtar is not
sufficient.  As I said, the problem is this: GNU tar stores the gid
information in a gid_t variable (that makes sense, right?).  However,
the size of gid_t differs on various platforms, so this means it is
possible to create an archive on a platform that supports large gid_t,
that is...troublesome...on platforms that support only small gid_t.

Tar is no longer part of the posix standard, but the PAX standard
specifies that the gid field is 7 octal digits (null terminated=8
chars). So the largest gid that pax (and, previously, tar) was required
to support is 7777777 octal, or 2097151 -- without using the (pax-only,
not ustar or tar) extended header record.  So...the standard doesn't
really require support for really large gid values, and any
implementation that creates archives with them -- like GNU tar -- is
obviously using a "proprietary" extension of the format to do so, and is
inherently not fully portable. :-(


New cygwin = large gid_t
old cygwin (== msys) = small gid_t

bsdtar sidesteps the issue by storing gid information in a 'long long',
not a gid_t.

--
Chuck

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys