I finally got to the bottom of it
gnu tar added extensions to the octal format fields to handle large data types
I already had code in place for the size field
I just needed to extend the code to all of the other fields
thanks again
On Thu, 10 Sep 2009 14:56:50 -0400 Glenn Fowler wrote:
> thanks for the details
> there is a difference between how GID==-1 is displayed and stored in the
> archive
> the display is 4294967295
> but the storage in the header seems botched
> the tar format header value should be 7 ascii octal digits
> here are the actual bytes:
> (p) dd if=bug.tar bs=1 skip=116 count=7 2>/dev/null | od -c
> 0000000 200 \0 \0 \0 377 377 377
> 0000007
> offset 116 is the start of the numeric GID field
> I consulted the tar-1.22 src and this is one of two extension formats
> for numbers that overflow the 7 digit unsigned octal format
> else if (*where == '\200' /* positive base-256 */
> || *where == '\377' /* negative base-256 */)
> {
> /* Parse base-256 output. A nonnegative number N is
> represented as (256**DIGS)/2 + N; a negative number -N is
> represented as (256**DIGS) - N, i.e. as two's complement.
> The representation guarantees that the leading bit is
> always on, so that we don't confuse this format with the
> others (assuming ASCII bytes of 8 bits or more). */
> thanks
> On Thu, 10 Sep 2009 12:33:45 -0400 wrote:
> > OK. I'm always willing to help fix a linux bug. :-)
> > Here's the scoop. I created the shell script on linux (Red Hat). I
> > used a GUI program (FTP Voyager) to transfer it to my PC, which is
> > running Windows XP and cygwin. When I look at the file with cygwin, it
> > has a group ID of -1. I have group -1 set in my /etc/group to "UNKNOWN"
> > so I don't see all those ugly 4294967295's in my ls -l listings (which
> > is the actual ID assigned to this file). Then, on cygwin:
> > $ ls -l
> > total 28
> > -rwxrwxrwx 1 jrw UNKNOWN 24597 Sep 4 23:58 bug.sh
> > $ grep UNKNOWN /etc/group
> > UNKNOWN::-1:-1:::
> > $ tar cvf bug.tar bug.sh
> > bug.sh
> > $ echo $?
> > 0
> > $ tar --numeric-owner -tvf bug.tar
> > -rwxrwxrwx 63018/4294967295 24597 2009-09-04 23:58 bug.sh
> > $ echo $?
> > 0
> > So, I'm not getting any errors from gnu tar running under cygwin. When
> > I transfer the tar file back to linux, I am able to un-tar it without
> > any errors, both as root and as an unprivileged user. When I un-tar it
> > as root, it receives the GID of 0 (the UID is the same as my cygwin
> > UID). On my Red Hat linux, uname -a gives:
> > Linux thusmneagdbc05 2.6.9-78.ELsmp #1 SMP Wed Jul 9 15:46:26 EDT 2008
> > x86_64
> > I hope that helps. I think the bottom line is:
> > - Apparently Windows XP assigns "groups" to files which are interpreted
> > by cygwin as GID -1 or GID 4294967295.
> > - Neither of my tar or un-tar commands has any problem dealing with
> > those GIDs, either on 64-bit linux (where it's mapped to 0 by root) or
> > on cygwin (where's it's stored as 4294967295 in the tar file).
> > -- John
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]] On Behalf Of
> > > Glenn Fowler
> > > Sent: Thursday, September 10, 2009 11:24 AM
> > > To: [email protected]; [email protected];
> > > [email protected]; Wiersba, John (Healthcare USA)
> > > Subject: [ast-developers] RE: Position-dependent ksh bug
> > >
> > >
> > > for gnu tar this command
> > > tar --numeric-owner -tvf your-archive
> > > shows
> > > -rwxrwxrwx 63018/4294967295 24597 2009-09-04 19:58:57 ./bug.sh
> > > ^^^^^^^^^^
> > > that gid corresponds to the header bytes
> > > 200 \0 \0 \0 377 377 377
> > > which is not a valid ascii octal number
> > > gnu tar merrily convert that anyway and fails, showing -1
> > >
> > > so I'm not interested that I didn't get your gid
> > > I'm interested in knowing how the bytes for gid got corrupted
> > > was it the gnu tar write, or the posting process, or unposting process
> > >
> > > why? because if the is a widespread gnu tar bug then I will have to
> > > add a workaround to ast pax to handle it (with a warning)
> > >
> > > I know this is off course for your ksh bug
> > > thanks for following up
> > >
> > > On Thu, 10 Sep 2009 10:21:10 -0400 wrote:
> > > > That was a simple tar cvf TAR_FILE TARRED_FILE, but not as
> > > the root user
> > > > (as my own ID). I would not expect my UID or GID to necessarily be
> > > > present on your server, but that doesn't normally cause a
> > > problem when
> > > > running tar -x as an unprivileged user.
> > >
> > > _______________________________________________
> > > ast-developers mailing list
> > > [email protected]
> > > https://mailman.research.att.com/mailman/listinfo/ast-developers
> > >
> > >
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
