jl42+@andrew.cmu.edu (Jay Mathew Libove) (05/02/88)
(This is not a flame, deserving of it though Mr. Haugh may be) Mr. Haugh comments on my question: | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and | I am having a bit of a problem with "tar". | I want to tar off a filesystem as: | | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - | | but when I do this I get: | | tar: blocksize must be a multiple of 2. My responses: >this must be an april's fools day joke of some kind. the person (jay libove) >who posted the original article has made too many mistakes for this to be >simple stupidity. No, not stupidity, not an april fools joke. Perfectly accurate and perfectly reasonable. >first off, last time i checked there was no 96 tpi 9 sector device. the >only 96 tpi device was 15 sectored. There most certainly is a 96 tpi 9 sector device. What is a 720K disk? 96 tracks, 9 sectors per track. I not only have it, but use it all the time. Maybe you have a slightly different Xenix. >secondly, you have two tar's with the 'c' option in the pipe line. 'c' >stands for 'create archive', so the input of the second tar is coming from >the files requested to be archived. the /dev/rfd096ds9 [sic] device is >going to be the output device, not standard output as requested with the >'-' option. I am quite aware that I am tar'ing, compressing the resulting stream, and attempting to create a new archive from that. That is exactly what I want. I want to compress a tarchive as it is created, and use it as the input to a new tar, which will simply write it out to multiple tapes for me. (SCO Xenix tar takes the 'k' option to tell it how large a tape is.) Thus, the '-' as "file to put in the archive" is a reasonable choice. The problem appears to be that tar dislikes having standard input as the file to read. It wants to and fails to stat that file. >thirdly, assuming jay meant to use 'x' on the second tar, which is the >only way for two tars in a pipe to work, the input would have been coming >from compress, which is not in tar format. you are lucky you only received >a blocksize message. I realize now that SCO Xenix tar was not written to allow what I'm trying to do. I have come up with solutions for the problem, specifically using something other than tar as the back end to the pipe, so that the program at the back end simply takes input from stdin and breaks it up among output tapes. >i suppose the correct response now would be `RTFM'. No, not at all. The correct response was "tar wasn't written to accept stdin as the file to add to an archive". As it happens, there *are* tars that can do this (Berkeley 4.3 seems to do it fine.) >- john. >-- > The Beach Bum Big "D" Home for Wayward Hackers > UUCP: ...!ihnp4!killer!rpp386!jfh jfh@rpp386.uucp :DOMAIN > "You are in a twisty little maze of UUCP connections, all alike" -- fortune Jay Libove Arpa: Jay.Libove@andrew.cmu.edu Bitnet: Jay.Libove@drycas.bitnet UUCP: ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!Jay.Libove UUCP: ...!{pitt | bellcore} !darth!libove!libove