Steps to reproduce problem from $Summary: # useradd -u 160000000 biguid # su biguid $ cd /tmp $ touch testfile $ tar --posix -cf test.tar testfile tar: value 16777216 out of uid_t range 0..2097151 tar: Exiting with failure status due to previous errors $ echo $? 2 After quick looking at the problem, this seems to be temporary regression in latest released version of GNU tar fixed this by the commit: http://git.savannah.gnu.org/cgit/tar.git/commit/?id=df7b55a8f6354e30e8da62eec7f706df033d0c81 Pavel
Well actually tar does store the big (In reply to comment #0) > Steps to reproduce problem from $Summary: > > # useradd -u 160000000 biguid There should be ^^^^^^ 16777216 of course.. > # su biguid > $ cd /tmp > $ touch testfile > $ tar --posix -cf test.tar testfile > tar: value 16777216 out of uid_t range 0..2097151 > tar: Exiting with failure status due to previous errors > $ echo $? > 2 > > Subject: > GNU tar is unable to store UID into posix format when UID > 2^21 Well, the problem is quite smaller than it could look like. GNU tar is able to store UID/GID to the file-related record archive - but when it tries to store extended headers in a special record in tarball, tar fails to set owner of that record. By default, this does just throws error code 2 but the file is created OK. > After quick looking at the problem, this seems to be temporary regression in > latest released version of GNU tar fixed this by the commit: > > http://git.savannah.gnu.org/cgit/tar.git/commit/ > ?id=df7b55a8f6354e30e8da62eec7f706df033d0c81 These comments are just to better track the issue in Fedora: I looked at older releases and even in tar 1.15 this problem existed (I haven't tried older releases). Mentioned upstream commit fixes this problem by setting the owner of extended header record to '0' (root) hardly. This should not make problems because if the unpacking tar implementation is aware of xattrs (e.g.), information about owner is trashed. If there is tar implementation not aware of xattrs, the special record is unpacked as a special file - during this phase the info about user must not be used anyway as the source UIDs/GIDs may not exist on target system. So when user wants to unpack it with incompatible tar - it is possible. The pax specification says that gid/uid are not meaningful: http://pubs.opengroup.org/onlinepubs/007904875/utilities/pax.html#tag_04_100_13_02 So in general there shouldn't be a problem. ==== As for Fedora - I'll extract the part --- a/src/create.c +++ b/src/create.c @@ -514,8 +514,8 @@ start_private_header (const char *name, size_t size, time_t t) TIME_TO_CHARS (t, header->header.mtime); MODE_TO_CHARS (S_IFREG|S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH, header->header.mode); - UID_TO_CHARS (getuid (), header->header.uid); - GID_TO_CHARS (getgid (), header->header.gid); + UID_TO_CHARS (0, header->header.uid); + GID_TO_CHARS (0, header->header.gid); MAJOR_TO_CHARS (0, header->header.devmajor); MINOR_TO_CHARS (0, header->header.devminor); strncpy (header->header.magic, TMAGIC, TMAGLEN); .. and push to rawhide. Pavel
Commit: http://pkgs.fedoraproject.org/cgit/tar.git/commit/?id=fc99fb3b0ade2ca6af4d7070edde750f7746aaa6
tar-1.26-12.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/tar-1.26-12.fc18
tar-1.26-12.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.