Copy directories with tar

rharder

rharder

Do not read this sign.
Here's an old *nix trick I rediscovered for copying entire folders from one place to another.

We're going to create a new command and call it "tp" (you can call it whatever you want, really).

Put these two lines in the file:
Code: 
#!/bin/sh
tar cvf - $1 | ( cd $2; tar xvf - )
The fastest way to do this is like this:
Code: 
% cat > tp
#!/bin/sh
tar cvf - $1 | ( cd $2; tar xvf - )
Ctl-D
where Ctl-D is the Control-D character.

Make the file executable with
Code: 
% chmod +x tp
and move the tp file to someplace like /usr/bin. You'll need to open a new terminal window to reset the command list.

Now you can copy one directory to another place. Suppose you want to copy the folder /Users/Joe/Pictures into /Library/WebServer/Documents/, you might type
Code: 
% tp ~/Pictures /Library/WebServer/Documents

Enjoy.

-Rob
 
You can copy whole filesystems, preserving the ownerhsip and groups into other areas by using the following, although I haven't tested dump and restore on MacOSX yet, tonight maybe.

MacOSX
----------
cd (to target filesystem)
dump 0uf - (from-filesystem) | restore -rf -

The 0 is a zero.


Other variants of similar commands under other UNIXs might help to solve any syntax problems with the above.

You can clone whole disks this way and is faster than
dd.


Solaris
--------
cd (to target filesystem)
ufsdump 0uf - (from-filesystem) | ufsrestore -rf -


IRIX
----
cd (to target filesystem)
xfsdump -l0 - (from-filesystems) | xfsrestore - .

There is a space between the last - and the . (dot)
 
When you say file system are you referring to a /dev item or a directory? I'm unfamiliar...

-Rob
 
dump (and their ilk) all operate on an entire filesystem as opposed to a single directory, as they're full backup programs. However, when I try it, it looks like it doesn't like HFS+:

# dump 0f /Volumes/MacOS Drive/xroot.hfs /dev/rdisk0s10

DUMP: Date of this level 0 dump: Fri Apr 20 10:56:22 2001
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdisk0s10 to /Volumes/MacOS Drive/xroot.hfs
DUMP: bad sblock magic number
DUMP: The ENTIRE dump is aborted.

Looks like, from this error, it likes only ufs/ffs.
 
So it images an entire drive to a file. Could this be used to make an image of a CD? An ISO image? Or does anyone know if there are header elements to such an image?

-Rob
 
You do know that tar wipes the resource fork on older files, don't you? I know most of the files in X don't rely on resource forks, but Classic does. If you use this be careful or you could destroy your Classic layer.
 
Yeah, the tar trick doesn't work too well with resource files.

I heard about an hfstar utility but haven't found it. Do you know anything about it?

-Rob
 
dump will add its own information to the output, including information about the filesystem layout, so it can't be used to make an image readable by just anything. Usually it's just used by restore.
However, if you want an exact image, you may be looking for what dd can do. dd should be able to make a perfect image of a CD (done it before on Solaris just fine).
 
I made up this command line to dump one filesystem, as follows:

dump -0uf - /Users | restore -rf -

This starts ok but I just found that my MacOSX UNIX does not have "restore". Is restore just missing in my install, or is it missing for all of you too.

I issued the following from root to look for restore, no luck
(dump is in dump):

which restore
whereis restore
find / -name restore -print

NO LUCK for any of them.

I wonder how much else is missing from this distribution of UNIX?

Might be a good idea to make a list and send it all back to Apple.
 
That's odd, no restore here either (but the manpage for it is installed in /usr/share/man/man8/restore.8). Maybe they think we only need to do backups and not restores...
 
I'm just glad NONE of you are backing up my data or else all of it would have been lost already!

The only sure-fire way to backup an HFS+ volume is to perform a device copy. A copy mechanism which understands all UNIX meta-data and MacOS meta-data simply does not exist yet. I know because I've been looking for it for months. It really sucks because MacOS is easy to backup (drag all files into another volume and viola, you have a bootable backup) and UNIX is harder but at least possible to backup using rync or something (although it doesn't set your boot clock like the MacOS copy does).

The way I do it is boot to MacOS and use HDT to device copy one volume to another then change the volume name of the backup to something else so nothing gets confused, like the Alias Manager.

The same thing could probably done using dd, but I did not have good results with dd.

a modified rsync which understood mac meta-data or a modified Carbon sync utility like SyncX which understood all UNIX meta-data will eventually be desireable. Currently it doesn't exist (SyncX doesn't know fifos and some unix flags (man chflags) while hfstar could not make a bootable backup...maybe somebody else can try).

OS X supports a superset of meta-data and we just don't have the right tool for the job yet.
 
HFS is not our problem and its not our problem that Apple didn't come up with a proper RESTORE, just that we have to bloody well deal with it.

We are having to get around what are "non-problems", APPLE didn't do the work simple as that.

"dump" does exist why?, if other vendors get of their arses to do a RESTORE, because they have implemented DUMP, so can bloody well APPLE!

All UNIX(s) have dump and restore, albeit their own version to reflect their own filesystem types. i.e. ufs SUN, xfs SGI, ext linux, ufs/hfs Apple etc to the dawn of time.

What I do know about dump (under a particular UNIX), is that it is programmed to understand the filesystem the data originates from and restore understands the reverse (under that UNIX), thats all you should need to know. I don't want to buy a product if UNIX can do it for me.

Does anyone know if restore exists in their MacOS X Server server version?

So I agree its bo11ocks if the work hasn't been done by Apple on the HFS+ but it should have done, and it should also work transparenly on the MacOSX unix filesystem and RESTORE should be present for that purpose.

UNIX is a piece of cake to backup using "dump", you can script one a liner into cron, end of story, and have it CLONE to another disk, backup to tape or to /dev/null if you like, all at the same time.

DD under UNIX sux to hell and gone from disk to disk, as the entire surface is duplicated, including the format, even if the disk has no data on it, so 10Gb of nothing could be copied taking forever.

If HFS is the "weakest link" it whould go "goodbye".

I am responsible for 2.5+ terrabytes of data haven't lost any yet, however I don't use dump/restore for that, I use a third party product that can understand, UFS, XFS, AFS, DFS etc, if they can do it so can Apple.





 
tell me about it! Where is pppd. How does one connect from the command line. I've got the Darwin 1.3.1 binary and I'm wondering how is someone using it meant to connect? They don't have Internet Connect. Is there a replacement?

peter
 
I think you missunderstood, what I meant by "using dump is easy" is the following command line in the crontab for root.

30 2 * * 0,1,2,3,4,5,6 /xyz/dump_script

The "dump_script" is the file containing anything you want to do, in the case dump the filesystem properly.

"dump" is different from tar, in that it preserves all the original ownerhship & group, date & time, permissions data and other such good stuff.

cpio should also work for this, but not tested as yet. nice thing about cpio, as well as tar, is that you can do them over the net.


 
You must log in or register to reply here.
Back
Top