Shirt Pocket Discussions  
    Home netTunes launchTunes SuperDuper! Buy Now Support Discussions About Shirt Pocket    

Go Back   Shirt Pocket Discussions > SuperDuper! > General
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 12-21-2009, 01:31 AM
camner camner is offline
Registered User
 
Join Date: Apr 2004
Posts: 160
a copy of a sparsebundle doesn't work?

As I rebuild my system, I want to make "snapshots" of the volume as I go along. What I thought I would do is to make a sparsebundle (say, called "bu_1.sparsebundle") then make a copy of that sparsebundle using the Finder, rename the resulting file (say to "bu_2.sparsebundle") and then use SD! with Smart Update using "bu_2.sparsebundle" as the target. This doesn't work. SS fails with a "can't set permissions" error. Is there a reason this won't work?

Also, SD describes a sparsebundle as the most efficient of images, yet making a Read only .dmg with high compression results in a far smaller image than making a sparsebundle. Why is that?

Thanks, as always.
Reply With Quote
  #2  
Old 12-21-2009, 08:33 AM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
Please send the log to me at support: I'd need the details. But it sounds like you didn't rename the volume in the image to "bu_2" (it has to match the filename).

Also, bundles are the most efficient of read/write images, but obviously read-only images are compressed. However, they're also very slow to create and impossible to update - efficiency is more than just a space thing.
__________________
--Dave Nanian
Reply With Quote
  #3  
Old 12-21-2009, 02:01 PM
camner camner is offline
Registered User
 
Join Date: Apr 2004
Posts: 160
You nailed it! I did not rename the volume. How does one rename it? (Sorry if this is a simple question...).

[As an interesting aside, I tried Googling "sparsebundle rename" and the 5th item on the list was this post! A bit unnerving...how often does Google crawl any one part of the net, anyway?]

A (somewhat related) question...as I move to a new volume (I'm rebuilding my system to upgrade to 10.6.x) I'd love to keep my SD! settings files. Can I move them over from ~/Library/Application Support/SuperDuper/Saved Settings or am I tempting fate there and I'd be better of recreating them from scratch?
Reply With Quote
  #4  
Old 12-21-2009, 02:11 PM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
You rename a volume in Finder. Open it, Control+click the volume name, choose rename, type the new name. Or, on the desktop, click the name and type the new one.

You can usually keep your settings, yes. Just make sure you delete/recreate schedules.
__________________
--Dave Nanian
Reply With Quote
  #5  
Old 12-21-2009, 03:16 PM
camner camner is offline
Registered User
 
Join Date: Apr 2004
Posts: 160
Aha. I didn't realize that by renaming a volume opened/mounted from a disk image it would update the name on the disk image. Interesting.

So, to summarize, you are suggesting I do the following:

1. Make a Finder copy of the sparseimage bundle I'm interested in updating without recreating from scratch.
2. Rename the copied sparseimage bundle file to whatever I'd like
3. Mount the now renamed/copied sparseimage bundle
4. Rename the mounted volume to whatever I named the sparseimage file in step 2.
5. Use SD! with the newly renamed sparseimage file as the target

Correct?
Reply With Quote
  #6  
Old 12-21-2009, 03:20 PM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
Yes, that's right.
__________________
--Dave Nanian
Reply With Quote
  #7  
Old 12-22-2009, 08:35 PM
camner camner is offline
Registered User
 
Join Date: Apr 2004
Posts: 160
Thanks for all of your help. This is a bit off topic (well, off SD but not off what I'm doing that caused me to run into the volume rename issue), so please feel free to not respond...

In rebuilding my system, I have Volume 1 (existing) and Volume 2 (the rebuild), on separate drives. I've created a username on Volume 2 that is the same as a username on Vol. 1. I'm trying to move doc files/folders from Vol 1 to Vol 2.

I'm running into permissions issues. If I'm booted on Vol 1 I can drag files/folders into the Shared folder on either Vol 1 or Vol 2, and then after booting into Vol 2, I can drag them out of either Shared folder to Vol 2. But the permissions are wrong. (I'm using the Shared folder because I don't have the permissions if I'm booted on one volume to directly drag/drop files/folders from the other volume)

Is there a straightforward way of getting document files/folders from one Leopard boot volume to another in such a way as not to run into permissions issues? I haven't had much luck finding info about this on the web...

Thanks again for your ongoing help.
Reply With Quote
  #8  
Old 12-22-2009, 09:30 PM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
You need the same user ID (part of the advanced options for the user)....
__________________
--Dave Nanian
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Booting from backup guruuno General 27 10-16-2009 11:53 PM
Failed to copy szygi General 3 05-08-2009 07:11 AM
Failed to copy error lmatheo General 1 03-20-2009 08:27 AM
SD! & HDD copy speed fun DaleMeyn General 3 03-20-2006 04:24 PM
Error: No space left on device tradervic General 11 06-29-2005 04:50 PM


All times are GMT -4. The time now is 09:38 AM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.