An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Page 2 of 2 < 1 2
Topic Options
#10781 - 06/28/10 10:23 AM Re: Anomalous "Restore" results? [Re: artie505]
CharlesS Offline


Registered: 05/30/10
Originally Posted By: artie505
You're correct about /sbin and /usr, Charles, but what about /System?

Those are mostly folders, so they can't be compressed anyway. But I would expect all the binary files inside those folders to end up being not compressed, if the restore tool is not preserving the compression.

Originally Posted By: artie505
> The best way to avoid all these sorts of problems is always to click the "Erase Destination" check box when cloning. When using the Restore tab, this will often result in a block copy, which is pretty much guaranteed to be exactly the same as the original.

Does that hold true even if the destination volume has been erased beforehand?

Yes it does. There are a few cases where Restore will fall back to a file copy if it's impossible to do a block copy (such as if the original volume is larger than the destination), but most of the time, if you click "Erase Destination" in Disk Utility's Restore tab, you'll get a block copy. The status bar will tell you which kind of copy it's doing while it's performing the clone, so you'll know what's going on. Since none of the cloning tools out there currently seem to play nice with the HFS+ compression, a block copy in Disk Utility is probably the best way to do a clone for now, as long as the original volume is in good working order (it's also the fastest).

One thing that I do notice, though, is that you mention that you did the clone in Leopard. Since Leopard can't know about the UF_COMPRESSED flag, I'm surprised that the files didn't become damaged. In any case, it would be interesting to try a restore while booted from the Snow Leopard disc, since Snow Leopard's version of disktool is more likely to be aware of the new compression features (if it's not, this will be a good bug report to send to Apple).

Top
#10790 - 06/29/10 02:15 AM Re: Anomalous "Restore" results? [Re: CharlesS]
artie505 Online


Registered: 08/04/09
OK...
  • While booted into a different SL volume
  • I restored my main SL volume
  • From a 25Gb volume to a 200Gb volume
  • With the "Erase..." box checked.
The progress bar showed that a block-level copy was done.

find_sl_damaged_files returned no errors.

Here are the comparative results of running du:

Code:
Source:
Artie-s-Computer-4:~ artie$ sudo du -xhd1 /
Password:
4.0M	/.fseventsd
4.0K	/.Spotlight-V100
  0B	/.Trashes
  0B	/.vol
902M	/Applications
3.9M	/bin
  0B	/cores
4.5K	/dev
1.0K	/home
1.5G	/Library
1.0K	/net
  0B	/Network
744M	/private
2.6M	/sbin
1.7G	/System
174M	/Users
392M	/usr
4.0K	/Volumes
5.4G	/
Artie-s-Computer-4:~ artie$ 

and

Code:
Destination:
Artie-s-Computer-4:~ artie$ sudo du -xhd1 /
4.0M	/.fseventsd
4.0K	/.Spotlight-V100
  0B	/.Trashes
  0B	/.vol
902M	/Applications
3.9M	/bin
  0B	/cores
4.5K	/dev
1.0K	/home
1.5G	/Library
1.0K	/net
  0B	/Network
745M	/private
2.6M	/sbin
1.7G	/System
129M	/Users
392M	/usr
4.0K	/Volumes
5.4G	/
Artie-s-Computer-4:~ artie$ 


Edited by artie505 (06/29/10 05:05 AM)
Edit Reason: Changed "Destination" info to reflect correct procedure as per dkmarsh (and cleaned up some)
_________________________
The new Great Equalizer is the SEND button.

Top
#10791 - 06/29/10 02:52 AM Re: Anomalous "Restore" results? [Re: artie505]
dkmarsh Offline

Moderator

Registered: 08/04/09

Originally Posted By: artie505
OK...
  • While booted into SL
  • I restored my SL volume
  • From a 25Gb volume to a 200Gb volume
  • With the "Erase..." box checked (Since it's checked by default, my earlier "Restores" were done with it checked [but to a smaller volume].)

But were you booted from the volume you were restoring from? Because if that's the case, as I mentioned above, you won't get a block-level copy.

From man asr:

Originally Posted By: manpages for asr
restore restores a disk image or volume to another volume
(including a mounted disk image)

--source can be a disk image, /dev entry, or
volume mountpoint. In the latter two cases,
the volume must be unmountable or mounted read-only
in order for a erase blockcopy to occur (thus, one
cannot erase blockcopy the root filesystem as the
source, unless it happened to be mounted read-only).

_________________________

dkmarsh • member, FineTunedMac Co-op Board of Directors

Top
#10792 - 06/29/10 02:57 AM Re: Anomalous "Restore" results? [Re: dkmarsh]
artie505 Online


Registered: 08/04/09
> But were you booted from the volume you were restoring from? Because if that's the case, as I mentioned above, you won't get a block-level copy.

Aaargh!!!

I forgot about that... More staring at progress bars.

See my edited original post for an update.

(I've done so many clones and "Restores" recently that I now watch progress bars, rather than count sheep, when I'm trying to fall asleep.)
_________________________
The new Great Equalizer is the SEND button.

Top
#10796 - 06/29/10 03:04 PM Re: Anomalous "Restore" results? [Re: CharlesS]
artie505 Online


Registered: 08/04/09
If this isn't a bug it's certainly a major OS X shortcoming. (The first time it happened I thought I had for sure misremembered what I had done, but it's reproducible.)

While booted into my SL volume I did a CCC file-level clone and a DU file-level "Restore" of the volume into which I was booted, with these results:

Code:
Source:
Artie-s-Computer-4:~ artie$ sudo du -xhd1 /
Password:
4.0M	/.fseventsd
4.0K	/.Spotlight-V100
  0B	/.Trashes
  0B	/.vol
902M	/Applications
3.9M	/bin
  0B	/cores
4.5K	/dev
1.0K	/home
1.5G	/Library
1.0K	/net
  0B	/Network
746M	/private
2.6M	/sbin
1.7G	/System
155M	/Users
392M	/usr
4.0K	/Volumes
5.4G	/
Artie-s-Computer-4:~ artie$ 

Code:
Destination (CCC clone):
Artie-s-Computer-4:~ artie$ sudo du -xhd1 /
Password:
416K	/.fseventsd
 39M	/.Spotlight-V100
  0B	/.Trashes
  0B	/.vol
902M	/Applications
3.9M	/bin
  0B	/cores
4.5K	/dev
1.0K	/home
1.5G	/Library
1.0K	/net
  0B	/Network
745M	/private
2.6M	/sbin
1.7G	/System
155M	/Users
392M	/usr
4.0K	/Volumes
5.4G	/
Artie-s-Computer-4:~ artie$ 
(Elapsed time: 00:11:54)

Code:
Destination (DU "Restore"):
Artie-s-Computer-4:~ artie$ sudo du -xhd1 /
4.4M	/.fseventsd
 36M	/.Spotlight-V100
  0B	/.Trashes
  0B	/.vol
1014M	/Applications
9.0M	/bin
  0B	/cores
4.5K	/dev
1.0K	/home
1.6G	/Library
1.0K	/net
  0B	/Network
220M	/private
6.8M	/sbin
3.4G	/System
155M	/Users
937M	/usr
4.0K	/Volumes
7.3G	/
Artie-s-Computer-4:~ artie$ 
(Restore took 15 minutes)

and, by way of example:

Code:
Destination (CCC clone):
Artie-s-Computer-4:~ artie$ /Volumes/HD2/3rd\ Party\ Stuff/Apps/Pacifist/hfs_comp_tool /bin/*
File /bin/[ is compressed
File /bin/bash is compressed
File /bin/cat is compressed
File /bin/chmod is compressed
File /bin/cp is compressed
File /bin/csh is compressed
File /bin/date is compressed
File /bin/dd is compressed
File /bin/df is compressed
File /bin/domainname is compressed
File /bin/echo is compressed
File /bin/ed is compressed
File /bin/expr is compressed
File /bin/hostname is compressed
File /bin/kill is compressed
File /bin/ksh is compressed
File /bin/launchctl is compressed
File /bin/link is compressed
File /bin/ln is compressed
File /bin/ls is compressed
File /bin/mkdir is compressed
File /bin/mv is compressed
File /bin/pax is compressed
File /bin/ps is compressed
File /bin/pwd is compressed
File /bin/rcp is compressed
File /bin/rm is compressed
File /bin/rmdir is compressed
File /bin/sh is compressed
File /bin/sleep is compressed
File /bin/stty is compressed
File /bin/sync is compressed
File /bin/tcsh is compressed
File /bin/test is compressed
File /bin/unlink is compressed
File /bin/wait4path is compressed
File /bin/zsh is compressed
Artie-s-Computer-4:~ artie$ 

Code:
Destination (DU "Restore"):
Artie-s-Computer-4:~ artie$ /Volumes/HD2/3rd\ Party\ Stuff/Apps/Pacifist/hfs_comp_tool /bin/*
File /bin/[ is not compressed
File /bin/bash is not compressed
File /bin/cat is not compressed
File /bin/chmod is not compressed
File /bin/cp is not compressed
File /bin/csh is not compressed
File /bin/date is not compressed
File /bin/dd is not compressed
File /bin/df is not compressed
File /bin/domainname is not compressed
File /bin/echo is not compressed
File /bin/ed is not compressed
File /bin/expr is not compressed
File /bin/hostname is not compressed
File /bin/kill is not compressed
File /bin/ksh is not compressed
File /bin/launchctl is not compressed
File /bin/link is not compressed
File /bin/ln is not compressed
File /bin/ls is not compressed
File /bin/mkdir is not compressed
File /bin/mv is not compressed
File /bin/pax is not compressed
File /bin/ps is not compressed
File /bin/pwd is not compressed
File /bin/rcp is not compressed
File /bin/rm is not compressed
File /bin/rmdir is not compressed
File /bin/sh is not compressed
File /bin/sleep is not compressed
File /bin/stty is not compressed
File /bin/sync is not compressed
File /bin/tcsh is not compressed
File /bin/test is not compressed
File /bin/unlink is not compressed
File /bin/wait4path is not compressed
File /bin/zsh is not compressed
Artie-s-Computer-4:~ artie$ 

CCC retains compression...DU does not.

Hmmm...
_________________________
The new Great Equalizer is the SEND button.

Top
#10823 - 07/02/10 10:54 PM Re: Anomalous "Restore" results? [Re: artie505]
artie505 Online


Registered: 08/04/09
I did one last (I hope!) experiment, a DU file-level "Restore" of my SL volume while booted into a different SL volume, and DU ran true to form, i.e. did not retain compression.
_________________________
The new Great Equalizer is the SEND button.

Top
Page 2 of 2 < 1 2

Moderator:  alternaut, dkmarsh, joemikeb