TRAIN_00047.eml

NoneNone the above (or something close to it) will work.

 however, the data will be read and written twice by the
 1st (source) `tar', and read twice by the 2nd (sink) `tar',
 albeit only written once as the sink realizes the second
 copy is a hard link to the first.  with c.60Gb of data,
 that will make a difference, at least in time and CPU
 resource consumed (albeit, in this case, not storage).

 the issue here is tar(1) (and cpio(1)) archives always
 contain the data for each name of a hard link.  this is
 (probably) for several reasons, and is not necessarily a
 bad thing.   e.g., it provides a degree of redundancy to
 help cope with bad media.

 the source `tar' is creating an archive, which is being
 written down the pipe (to be consumed by the sink `tar').
 that is why storage is not an issue per se here, as the
 full archive is not "saved" --- if it were, you'd need
 at least 2x60Gb, or over 120Gb!   (the extra is `tar's
 overhead, which is minimal but does add up, esp. when
 a "large" blocking factor is used.)

cheers!
	-blf-
--
 Innovative, very experienced, Unix and      | Brian Foster    Dublin, Ireland
 Chorus (embedded RTOS) kernel internals     | e-mail: blf@utvinternet.ie
 expert looking for a new position ...       | mobile: (+353 or 0)86 854 9268
  For a résumé, contact me, or see my website  http://www.blf.utvinternet.ie

    Stop E$$o (ExxonMobile):  «Whatever you do, don't buy Esso --- they
     don't give a damn about global warming.»    http://www.stopesso.com
     Supported by Greenpeace, Friends of the Earth, and numerous others...

-- 
Irish Linux Users' Group: ilug@linux.ie
http://www.linux.ie/mailman/listinfo/ilug for (un)subscription information.
List maintainer: listmaster@linux.ie