Re: [Mingw-msys] How to find MSYS
- Date: Fri, 03 Sep 2010 18:01:28 -0400
- From: Charles Wilson <cwilso11@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-msys] tar outputs errors when extracting boost_1_44_0.tar.bz2
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.
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
Mingw-msys mailing list