Re: tar(1) File is too long for ustar
On Mon, Jan 02, 2006 at 11:31:13PM +0100, Otto Moerbeek wrote: OK, then the cpio man page in -current is in error. That's my mistake, I asked jmc@ to change it to 64GB where it is actually 8GB, cpio doesn't add a space or null termination on the 12th digit so it should be ok, only tar and ustar were off. When I looked at it I must have looked at tar_rd() and saw it use asc_ul() which doesn't care much for the terminator and didn't look at tar_wr() which uses uqd_oct() that adds the terminator thus shortening the amount of digits for the octal value. Here is the updated patch: Index: cpio.1 === RCS file: /cvs/src/bin/pax/cpio.1,v retrieving revision 1.22 diff -u -r1.22 cpio.1 --- cpio.1 15 Nov 2005 00:00:28 - 1.22 +++ cpio.1 3 Jan 2006 16:54:12 - @@ -292,8 +292,8 @@ .It bcpio Ta 4 Gigabytes .It sv4cpio Ta 4 Gigabytes .It cpio Ta 8 Gigabytes -.It tar Ta 64 Gigabytes -.It ustar Ta 64 Gigabytes +.It tar Ta 8 Gigabytes +.It ustar Ta 8 Gigabytes .El .Sh BUGS The CUT HERE --- BTW, to solve the OP problem: try using dump(8) instead of tar(1). -Otto Sorry for the misinformation which was caused by me. -peter
Re: tar(1) File is too long for ustar
On Tue, Jan 03, 2006 at 06:03:16PM +0100, Peter Philipp wrote: Index: cpio.1 === RCS file: /cvs/src/bin/pax/cpio.1,v retrieving revision 1.22 diff -u -r1.22 cpio.1 --- cpio.1 15 Nov 2005 00:00:28 - 1.22 +++ cpio.1 3 Jan 2006 16:54:12 - @@ -292,8 +292,8 @@ .It bcpio Ta 4 Gigabytes .It sv4cpio Ta 4 Gigabytes .It cpio Ta 8 Gigabytes -.It tar Ta 64 Gigabytes -.It ustar Ta 64 Gigabytes +.It tar Ta 8 Gigabytes +.It ustar Ta 8 Gigabytes .El .Sh BUGS The ok, fixed now. jmc
Re: tar(1) File is too long for ustar
On Mon, Jan 02, 2006 at 05:35:28PM +, Nuno Morgadinho wrote: How to use tar(1) to compress ridiculous large files? #tar cvfz /dev/rst0 /fitabackup /fitabackup/server1.tgz /fitabackup/server3.tgz * tar: File is too long for ustar /fitabackup/server3.tgz * server3.tgz has 10.0Gb. Use another tar format. OpenBSD tar does not seem able to do this; you may wish to look at other archivers. star has a lot of options in this direction, at least - it may have one which will do what you want. Of course, you don't need to use tar(1), per se. Specifically, in the case mentioned above, there's no reason not to just cat twice unless the original compression was done very inefficiently - and even then, just piping through gzip is more efficient. (Though I'm no more than 'fairly certain' that gzip will handle files this large.) Joachim
Re: tar(1) File is too long for ustar
On Mon, 2 Jan 2006, Nuno Morgadinho wrote: How to use tar(1) to compress ridiculous large files? #tar cvfz /dev/rst0 /fitabackup /fitabackup/server1.tgz /fitabackup/server3.tgz * tar: File is too long for ustar /fitabackup/server3.tgz * server3.tgz has 10.0Gb. I must be stupid or this error message is not generated by tar. Please provide the EXACT message, and an ls -l of the /fitabackup dir. ustar is supposed to handle files up to 64G. -Otto
Re: tar(1) File is too long for ustar
On Mon, 2 Jan 2006, Matthias Kilian wrote: On Mon, Jan 02, 2006 at 08:44:02PM +0100, Otto Moerbeek wrote: * tar: File is too long for ustar /fitabackup/server3.tgz * [...] server3.tgz has 10.0Gb. I must be stupid or this error message is not generated by tar. Please provide the EXACT message, and an ls -l of the /fitabackup dir. It's in /usr/src/bin/tar/tar.c, line 1028. Ok, I'm stupid, sorry. ustar is supposed to handle files up to 64G. If I don't misinterpret the code, the problem is that the size for a 10GB file needs 12 octal digits, which doen't fit 0-terminated into hd-size. Wonder if hd-size should be 0-terminated, but no time to check now. -Otto
Re: tar(1) File is too long for ustar
On Mon, Jan 02, 2006 at 08:44:02PM +0100, Otto Moerbeek wrote: * tar: File is too long for ustar /fitabackup/server3.tgz * [...] server3.tgz has 10.0Gb. I must be stupid or this error message is not generated by tar. Please provide the EXACT message, and an ls -l of the /fitabackup dir. It's in /usr/src/bin/tar/tar.c, line 1028. ustar is supposed to handle files up to 64G. If I don't misinterpret the code, the problem is that the size for a 10GB file needs 12 octal digits, which doen't fit 0-terminated into hd-size. Ciao, Kili
Re: tar(1) File is too long for ustar
On Mon, Jan 02, 2006 at 10:05:21PM +0100, Otto Moerbeek wrote: If I don't misinterpret the code, the problem is that the size for a 10GB file needs 12 octal digits, which doen't fit 0-terminated into hd-size. Wonder if hd-size should be 0-terminated, but no time to check now. IMHO, it should. Quoting 1003.1 (2004 ed.): [The last sentence is important] The fields magic, uname, and gname are character strings each terminated by a NUL character. The fields name, linkname, and prefix are NUL-terminated character strings except when all characters in the array contain non-NUL characters including the last character. The version field is two octets containing the characters 00 (zero-zero). The typeflag contains a single character. All other fields are leading zero-filled octal numbers using digits from the ISO/IEC 646:1991 standard IRV. Each numeric field is terminated by one or more space or NUL characters. It's POSIX, thus it's odd. Ciao, Kili
Re: tar(1) File is too long for ustar
On Mon, 2 Jan 2006, Matthias Kilian wrote: On Mon, Jan 02, 2006 at 10:05:21PM +0100, Otto Moerbeek wrote: If I don't misinterpret the code, the problem is that the size for a 10GB file needs 12 octal digits, which doen't fit 0-terminated into hd-size. Wonder if hd-size should be 0-terminated, but no time to check now. IMHO, it should. Quoting 1003.1 (2004 ed.): [The last sentence is important] The fields magic, uname, and gname are character strings each terminated by a NUL character. The fields name, linkname, and prefix are NUL-terminated character strings except when all characters in the array contain non-NUL characters including the last character. The version field is two octets containing the characters 00 (zero-zero). The typeflag contains a single character. All other fields are leading zero-filled octal numbers using digits from the ISO/IEC 646:1991 standard IRV. Each numeric field is terminated by one or more space or NUL characters. It's POSIX, thus it's odd. OK, then the cpio man page in -current is in error. BTW, to solve the OP problem: try using dump(8) instead of tar(1). -Otto
