Date: Fri, 2 Nov 2001 15:50:13 -0600 From: David Kelly <dkelly@hiwaay.net> To: Jim Arnold <jim@ohio.com> Cc: Cliff Sarginson <cliff@raggedclown.net>, freebsd-questions@FreeBSD.ORG Subject: Re: Splitting a tar archive Message-ID: <20011102155013.B60019@grumpy.dyndns.org> In-Reply-To: <a05100313b808ba9bc433@[206.128.102.10]>; from jim@ohio.com on Fri, Nov 02, 2001 at 04:16:31PM -0500 References: <3.0.5.32.20011102113219.00f94888@mail.sage-american.com> <20011101160655.O92340-100000@bsd.smnolde.com> <20011101222033.C53366-100000@jodie.ncptiddische.net> <3.0.5.32.20011102113219.00f94888@mail.sage-american.com> <3.0.5.32.20011102124221.00f94888@mail.sage-american.com> <a05100310b808b104839b@[206.128.102.10]> <20011102204953.D6967@raggedclown.net> <a05100313b808ba9bc433@[206.128.102.10]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 02, 2001 at 04:16:31PM -0500, Jim Arnold wrote: > >> > >What do you mean it doesn't work !? > >What happens then..? > > > The file size that gets created when I cat the files > is smaller than the original file. Here's what I did to test > this out: Well, lets first check the split files. As others have commented you should be using the -b option to split so that it knows the files are binary. Otherwise its trying to break on line count thinking the files are text. For homework dig into the source of split and see how it handles text. Wonder if there is a goof where it might assume a null is end of line when processing in text mode. In the Bad Old Days I had one heck of a time on machines administered by NASTRAN users. The NASTRAN (or was it PATRAN?) package had its own split command which was for splitting models (created in PATRAN). The administrator got bit trying to use the Unix split and "solved" the problem by replacing it with the other split. Back in those days SGI's IRIX split didn't know binary. So I'd use dd in a shell script. And stashed it in ~/bin at the front of my $PATH. Back to the current thread. If the file (movie?) you are splitting is only to be used between Unix machines via CDROM and no need of Windows of Mac access then you might skip the mkisofs step. And you might not. Use burncd or cdrecord to write the split image directly to the CD-R. Then you might resurect the file using "cat /dev/cdrom > movie.mov" for the first segment, then "cat /dev/cdrom >> movie.mov" for each of the remainder. The problem with this method is (I've noticed) some CD drives report end of media with the block of data which has touched EOM and possibly the read returned less than a full buffer, and others report EOM only after one has attempted to read past EOM and no data was returned. So its possible to lose the last block with some drives. Noticed this when I wanted to verify a FreeBSD ISO by lifting it raw off of the disk with dd. Philips ATAPI CD-RW read short. HP SCSI CD-RW read correctly. Believe Sony ATAPI CD-RW read correctly. Same sort of thing applies with tar. Skip the mkisofs step. Then to read the CD-R simply, "tar -tvzf /dev/cdrom". Saves the fuss of mounting. This is exactly the way we use tape. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011102155013.B60019>