Restoring to a folder

[ericob]

I want to back up a small(~14GB used) volume, then restore its contents to a folder. Unless I'm mistaken, there is no way to restore to a folder when using SuperDuper.

Do I have any better options than backing up to an image, mounting the image and then copying the contents of that image into a folder? Using the Finder to then copy tens of thousands of files seems very unpleasant.

Is there some nice little terminal command or utility that would be a better choice for this copy? Is there some nice little terminal command or utility that would be able to read directly from the disk image file and copy into a folder I designate?

[dnanian]

Why are you trying to store its contents in a folder, Eric? Would a sparse image suffice, since it can be opened and managed like any other volume?

If you're just going to copy out of the image into a folder, you could do the *whole* operation with Finder... but since you probably can't authorize to copy that much data, it's unlikely to work...

[ericob]

There are several issues embedded in my comment.

First, to reply: It is not that I want to "store" the contents of a disk image in folder. I want to REstore a disk image TO a folder. Currently, we can backup volumes to images and folders to images. And we can restore images to volumes. But we cannot restore an image to a folder. Realize than an image will not always contain a bootable volume: it may contain only a folder (a collection of files), just a single very large file, a data-only volume, etc.

I realize I can open an image and use the Finder to copy everything (or pick and choose) to another location. That will often be useful, but also is not what I'm looking for.

I really do not want to have to rely on the Finder to copy these files. And I'd prefer to not even let the Finder see the files before they appear in my target folder. (I don't want Spotlight or some other "service" grabbing for things on a mounted image.) Also, there may be invisible files on the image. A mounted image will not show those files in the Finder, and therefore they cannot be selected for copying. For another thing, I want all the file information preserved during the process. I do not want permission settings or modification dates of the files changing, for instance. It's also difficult to believe that the Finder is going to be very efficient copying thousands and thousands of files. And how good it its validation checking?

As I say, I'd prefer a solution that will restore the contents of a disk image file to a folder (without needing to mount that image). As a second choice I'll settle for mounting the image and using a command or tool in the terminal to do the copy task. Which one(s) will preserve all the "Macintosh stuff" in files?

In your reply you wrote "...but since you probably can't authorize to copy that much data...." I've never heard of this sort of limit. Are you saying that the Finder will refuse to copy more than a certain number of files at a time??


In case anyone wonders why I would want to keep a collection of file in a disk image (instead of simply in a copy of the folder), it is because in an image the files are "hermetically sealed." I can safely have a disk image visible to my file system without exposing its contents to the file system. I won't mistakenly begin working inside my "backup" folder, iTunes or iPhoto or Spotlight or WHATever will not notice the contained files and feel bound to do something with them, etc. Also, again, the image should be an exact copy of my files, not the simply the Finder's idea of what the current user can see or do.

[dnanian]

First, I used the wrong term -- sorry. I didn't mean "much" in quantity terms, I meant for permissions -- trying to copy a whole system, and authorizing against the whole thing.

But, regarding the rest -- sorry. We can't do that... and even if we could, they'd be seen by Finder anyway, since you'd have to mount (or we would)... and Spotlight sees the files as soon as they hit the file system, since that's all done with kqueues.

Block restore -- the only real way to avoid mounting -- couldn't be done to a folder either, because it happens at far too low a level. You'd have to replace the *entire* drive with the restoration... and then it gets seen, and indexed. Etc.

So, unfortunately, we don't look to be the solution to your needs. Sorry, Eric!

[ericob]

Originally Posted by dnanian

First, I used the wrong term -- sorry. I didn't mean "much" in quantity terms, I meant for permissions -- trying to copy a whole system, and authorizing against the whole thing.

Gotcha. Note that I'm not intending to (try to) copy a entire bootable system by dragging files in the Finder. (To copy a bootable volume I'd of course use SuperDuper! ) But neither do I expect to be able use the Finder to drag around files that are owned by other users (the System included). However, I can get around the permissions problems at the point of creating the image... I use SuperDuper!

But, regarding the rest -- sorry. We can't do that... and even if we could, they'd be seen by Finder anyway, since you'd have to mount (or we would)... and Spotlight sees the files as soon as they hit the file system, since that's all done with kqueues.

Block restore -- the only real way to avoid mounting -- couldn't be done to a folder either, because it happens at far too low a level. You'd have to replace the *entire* drive with the restoration... and then it gets seen, and indexed. Etc.

Well, I didn't know the limitations of reading from an image directly. It appears that there's no way to just reach in there and pull files out, one at a time, sequentially. And you write "You'd have to replace the *entire* drive with the restoration." That's exactly what I'm trying to avoid. Hence the concept of "restoring to a folder." Apparently, if the backup file was some form of archive file (instead of an image file) I could then copy out of the archive to another destination without exposing the files inside the archive directly to the file system. Hmm...

So, unfortunately, we don't look to be the solution to your needs. Sorry, Eric!

Not entirely... I can get the data backed up completely and accurately (to a disk image) using SD. To then copy the contents of that image to a folder, it looks like I will have to mount the image (ugh), then do the copy operation from the Terminal with "sudo cp" or some such so that I can completely and accurately restore all the files, including invisible ones and ones I don't own.

*sigh* Not exactly one-stop shopping.

[dnanian]

Well, you can reach inside an image and pull files out, but since it's a volume like any other, it gets mounted and used. The *advantage* to an image is that it's just like any other volume, and restoration is easy. You have rather unique requirements here, which is why it seems to be a problem... but I truly don't understand the problem with "exposing" the files to the file system, because it can't really do any "harm"... what could possibly happen?