Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!hahn@AMES-NAS.ARPA
From: hahn@AMES-NAS.ARPA (Jonathan Hahn)
Newsgroups: net.unix-wizards
Subject: More on tar tree copy; has nothing to do with deadlock
Message-ID: <1745@brl-tgr.ARPA>
Date: Thu, 26-Sep-85 14:50:31 EDT
Article-I.D.: brl-tgr.1745
Posted: Thu Sep 26 14:50:31 1985
Date-Received: Sat, 28-Sep-85 08:16:19 EDT
Sender: news@brl-tgr.ARPA
Lines: 27

Since the tar tree copy has been getting so much attention lately,
I thought I'd bring up some tar tree copy esoterica:

	What happens when you do

		(cd $fromdir; tar cf - .) | (cd $todir; tar  xf -)

	and $fromdir and $todir refer to the same directory???

Yikes!  All files in the tree are overwritten with an equivalent
number of null bytes!  The sizes and modification dates of the files
are the same as before.  Sometimes this isn't discovered for
days or weeks.

I noticed that 4.2BSD tar at least warns you that something is
wrong: it complains that files have changed size.  Earlier versions
(e.g. V7 tar) did this job silently.

Why?  The first tar sends a file header down the pipe, the second
tar reads the header and does a creat() on the file, truncating it.
Then the first tar tries to read the file but it's empty.  The second
tar, beginning to wonder if this isn't some sort of cruel joke,
null pads the file to the length specified in the header.  It
also sets the modification date to that specified in the header.

-jonathan hahn
hahn@ames-nas.arpa


Brought to you by Super Global Mega Corp .com