Jump to content

Restoring all backed up versions of a bundle


Recommended Posts

Years ago I posted on this forum about a problem I'm having in restoring files that are actually bundles, but I never learned about a solution that actually works. What I'd like to be able to do is what Retrospect can definitely do for files that aren't bundles: retrieve every version of the file present in the backup set. You see, I have a Numbers file called "Revised Budget E 2008.numbers", and I need to retrieve prior versions. So what I do is this:

 

Immediate > Restore > Search for Files and Folders:

 

20080928-nmeare625jipef47p72u8qpi2n.png

 

When I click on OK, I'm informed that there are 17 copies of the file:

 

20080928-tn9bjqd8kgb2kp63e7tddqtix4.png

 

But when I click on "Retrieve," I get only one copy of the file:

 

20080928-e28ym82ya5gk1fhqc93yqau93b.png

 

However, this bundle actually has the contents of the several versions:

 

20080928-jeg7tea635hnttj25g6a4bdidn.png

 

This bundle must be unreadable by Numbers.

 

Under what normal circumstances is this result desirable? A bundle is supposed to appear to the user as file -- non-expert users aren't supposed to tinker with their contents.

 

In any case, is there a way for me to restore all instances of Revised Budget E 2008.numbers (of which there are presumably 17) as discrete, readable bundles that would numbered (as Retrospect does for restoring files) Revised Budget E 2008 1.numbers, Revised Budget E 2008 2.numbers, etc?

 

I can't seem to solve this problem.

 

 

Edited by Guest
Link to comment
Share on other sites

I've tried both -- it makes no difference. Should Retrospect be able to restore all versions of the Numbers bundles as separate bundles?

 

On a separate note, I hope that handling is improved in Retrospect X in another respect -- the user shouldn't have to know that bundles are actually folders. The whole point is that they're treated as files.

Edited by Guest
Link to comment
Share on other sites

A bundle is supposed to appear to the user as file -- non-expert users aren't supposed to tinker with their contents.

 

Agreed, but what you are doing is an expert activity.

 

> When I click on OK, I'm informed that there are 17 copies of the file:

 

Robin is, of course, correct when he points out that you should be using "Enclosing Folder" filter criteria, as Retrospect treats bundles as folders. How you use Retrospect in this way is the same as if you were working with a folder full of individual files, where some files have changed at different times and some files have not.

 

If you repeat your initial steps above and then click on the "Files Chosen" button, what do you see (and how do I embed graphics instead of just attaching them?)?

 

is there a way for me to restore all instances of Revised Budget E 2008.numbers (of which there are presumably 17) as discrete, readable bundles

 

So here's the meat of your problem, and why you are going about it the wrong way.

 

You are not looking to Search for an individual file. What you want is all the individual files _inside_ the bundle. But you need the collection of those files to be valid when taken as a group; you want the all files in that collection to reflect how they looked at a moment in time. A "Snapshot" if you will. Searching Restores don't use Retrospect's Snapshot technology. And you don't know what to search for; Names won't work (as you've found), and dates won't work either since you don't know what Numbers did to what files at what time.

 

You'll need to use a Files and Folders type Restore, select each Snapshot date that you want, Browse to the location of the bundle, Mark it and Restore. You might want to change the program preferences to Restore Folder Modification Dates, to facilitate keeping track of which bundle(s) you later work with, or do some Finder naming as you go through each Restore execution.

 

* Adding after seeing an additional post while I was working on this:

 

the user shouldn't have to know that bundles are actually folders. The whole point is that they're treated as files.

 

Yes, Retrospect X should provide a custom icon for Bundles in its GUI. But how it treats the contents of those bundles should not (and likely won't) change. If I have a bundle with a hundred files, and one file changes, I would expect Retrospect X to only backup the changed file, then to make a note in its Snapshot of the change. When I Restore from the most current Snapshot, I'll get the bundle as it looked at the most recent backup. If I Restore from an earlier Snapshot, I'll get the bundle as it looked at that moment in time.

 

Time Machine works exactly the same way; it just has a more glamorous way to present each Snapshot to the user. It's all about the interface, and I too am hopeful that Retrospect X will have a good one.

 

 

Dave

Link to comment
Share on other sites

I don't understand. There's nothing "expert" about wanting to restore multiple versions of a file that just happens to be a bundle; from the user's point of view it's a file, and my wife, who is trying to do this, doesn't recognize it as a folder, and why should she be expected to? Retrospect should be able to handle a Numbers file as it is intended to be handled by the vast majority of users -- as a file. And if this is all really about UI, that's fine -- I don't care what is going behind the scenes -- but what you outline is simply far too complicated a procedure to follow.

 

Finally, snapshots only seem to be available through Configure > Backup sets; within Immediate > Restore > Search for files and folders, there doesn't appear to be a way to select a particular snapshot!

Edited by Guest
Link to comment
Share on other sites

don't understand

 

I'll do my best to rephrase things, but I think I've outlined it pretty accurately up-thread.

 

> There's nothing "expert" about wanting to restore multiple versions

> of a file that just happens to be a bundle

 

A bundle is not a file. No matter how much you want for it to be, no matter that Mac OS has a pretty way of displaying a bundle as a single file, no matter that Apple has provided developers with a really smooth way to distribute software, a bundle is a collection of individual files all packaged together within a single icon. It just is.

 

> Retrospect should be able to handle a Numbers file as it is intended

> to be handled by the vast majority of users -- as a file.

 

And for the most common Retrospect activity, [color:purple]Restore files from a backup[/color], it does just that. Select the bundle (which has a standard folder icon, and I've already noted that my personal preference would be for an icon that gives the user feedback that it's a special sort of folder), click Restore, and the entire, valid bundle will be restored.

 

> what you outline is simply far too complicated a procedure to follow

 

No more complicated then what you've been trying to do (without success) so far. I'd suggest that a procedure that works will end up making more sense, and seem less complicated, then using the program incorrectly.

 

> within Immediate > Restore > Search for files and folders, there

> doesn't appear to be a way to select a particular snapshot!

Yes, as I noted in my original reply:

 

"Searching Restores don't use Retrospect's Snapshot technology"

 

Immediate->Restore->Restore files from backup->YourBackupSet/YourDesiredSnapshot

 

My comparison with Time Machine has to do with each program's interface at this point; in Time Machine, you select the date from the infinite panels going back in time, where you'll see the bundle as a file, and you can drill down and reveal its contents if you want to recover some specific files within. In Retrospect, you also select the date, but from a less dazzling list, and you'll have to click some addition buttons to get to dates farther back in time.

 

Neither program is going to be able to tell you if the bundle on March 2 is the same or different then the bundle on March 15; both programs will simply offer you the ability to Restore the bundle as it looked on that day. In fact, Retrospect is significantly more powerful, in that you _can_ search for individual items within a bundle, and Restore different versions of those files. That's not something Time Machine/Spotlight would be able to do (maybe with third party hooks, but I don't know of any).

 

(And I recognize that your posts have not included any Time Machine comparisons, I just thought that the subject might benefit from me doing so.)

Link to comment
Share on other sites

A bundle is not a file. No matter how much you want for it to be, no matter that Mac OS has a pretty way of displaying a bundle as a single file, no matter that Apple has provided developers with a really smooth way to distribute software, a bundle is a collection of individual files all packaged together within a single icon. It just is.

 

I know that a bundle isn't a file. But it's meant to appear and more importantly be handled as one -- that's the whole point of the bundle! Most users don't understand the distinction you're making nor should they be expected to.

 

No more complicated then what you've been trying to do (without success) so far. I'd suggest that a procedure that works will end up making more sense, and seem less complicated, then using the program incorrectly.

 

All I'm arguing for is consistency in restoring *all* objects that appear as files in the Finder. I'm glad that you agree that a bundle folder should have a custom icon, but the average user probably still is going to have trouble recognizing a folder as the file that s/he sees on his or her Desktop. No user should be expected to understand the internal components of a bundle -- that's for developers.

 

I want to be able to search my backup set for all instances of a bundle and be able to restore them just as I can for any other file. The problem is that the choice is between a procedure that doesn't work but should for consistency's sake and yours (and no, a comparison with Time Machine, which does treat bundles as files, isn't a propos here, because TM doesn't make it easy to restore multiple instances of the same file -- that's why we use Retrospect!).

Link to comment
Share on other sites

TM doesn't make it easy to restore multiple instances of the same file

 

It just seems as if you're being purposely obtuse here. You've made clear that you recognize that the issue is with this special class of Finder object called a bundle, yet you insist on referring to this object as a file in order to press the point that others are not as well informed as you are. That's fine, except it does little to move the discussion forward towards a solution for the very real problem that you are having.

 

Time Machine doesn't make it easy to restore multiple instances of modified bundles, only because Time Machine won't compare a bundle in situ and let the user know which versions are different from other versions. In this regard, Retrospect behaves exactly the same way; the program will maintain current versions of a bundle, but there's no way (that I can think of at this moment; perhaps others have some suggestions) for the program to help you decide which bundle to Restore (perhaps Searching a Backup Set for specific folder modification dates, and then using those dates as a basis for selecting Snapshots in a Restore files from a backup; two steps, not particularly intuitive)

 

> I want to be able to search my backup set for all instances of a bundle and be

> able to restore them just as I can for any other file.

 

Because Retrospect doesn't utilize Snapshots for Search style Restore operations, the only way this would work is if you configured Retrospect to always backup all instances of all files:

(Immediate Backup/Ready to Execute->Options->Matching)

Then you could construct an Enclosing Folder Modified Date search selection that could Restore bundles that all contain all the files that were there at the time they were backed up.

 

Dave

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...