From: gtaylor@tnetconsulting.net   
      
   On 1/8/20 11:02 AM, philo wrote:   
   > I already have games.cpio.xz   
      
   Where did you create that compressed archive?   
      
   I'm sort of surprised that the SCO install has programs to work with xz.   
      
   > could you please tell me exactly how I could use TAR  to retrieve the   
   > data onto my Unix machine?   
      
   I don't know if tar, particularly on SCO, will know how to work with cpio.   
      
   I think you will need to use cpio, not tar.   
      
   > If the switches between Linux and Unix are different I might be able to   
   > figure it out   
      
   They are almost guaranteed to be different.   
      
   > here is the advice Bela gave me that worked:   
   >   
   > `sco# cd /`   
   > `sco# find u | cpio -ov | gzip -2 > /dev/hd04`   
      
   That looks like it's finding any files / directories under the /u   
   directory and piping the list into cpio, which is creating (-o) a cpio   
   archive in verbose (-v) mode to list files and piping the output into   
   gzip to compress things which are ultimately written to /dev/hd04.  (I'm   
   assuming that hd04 is partition #4 (or maybe #5 if counting starts at 0)   
   on the drive.   
      
   > `linux# cd /target/dir`   
   > `linux# gzip -dc < /dev/sdb1 | cpio -itv | less`   
      
   That will decompress the contents of /dev/sdb1 (first partition on the   
   second drive) into cpio, which is reading (-i) and testing (-t) the   
   archive while listing (-t) it's contents and sending list into less to   
   page through.   
      
   > `linux# gzip -dc < /dev/sdb1 | xz -v9e > thelma-u.cpio.xz`   
      
   This seems odd to me.  Why uncompress gzip and recompress with xz?  Is   
   it really going to save that much space?   
      
   > the 1st `gzip -dc` command is just to confirm that the format is   
   > readable; page through it a little, then quit out of `less` and ^C if   
   > necessary.   
   >   
   > the 2nd `gzip -dc` command does several things:   
   >   
   > - read the .gz off the partition   
   >   
   > - chop it off at the end of the real data rather than the end of the   
   > partition (`gzip -dc` will print an error message when it hits the end,   
   > something like: _gzip: stdin: decompression OK, trailing garbage   
   > ignored_ -- which is perfect, it means it's cutting the data at the true   
   > end)   
      
   Valid.   
      
   > - recompress it with `xz`, which will be significantly smaller   
      
   Possibly.  I question the value of it.   
      
   I think the real value of the command is to get just the gzip data off   
   of the partition.   
      
   > Do you know how I could achieve the same end result without the use of   
   > gzip?   
      
   You should be able to remove the gzip command from the command lines   
   that he gave you.   
      
   > I confirmed the Unix machine does not have gzip   
      
   I'm not completely surprised by that.   
      
   > but it does have cpio and tar   
      
   I would be surprised if it didn't.   
      
   sco# cd /   
   sco# find u | cpio -ov > /dev/hd04   
      
   linux# cd /target/dir   
   linux# cpio -itv /dev/sdb1 | less   
   linux# cpio -i /dev/sdb1		# this will extract files   
      
   You will need to create a new archive of the extracted files.  You can   
   use any standard Linux methodology.   
      
   I do wonder what cpio will do when it hits the end of the archive data   
   and starts running into other cruft on the scratch partition you are   
   using.  I guess you could minimize the problem by erasing the scratch   
   partition before you write to it in the SCO box.  I don't know how to do   
   this on the SCO box.  I'd likely do it on the Linux box.   
      
   philo:  Which SCO unix are you working with?  OpenServer or UnixWare or   
   Xenix?  Do you know what version it is?   
      
      
      
   --   
   Grant. . . .   
   unix || die   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)