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
