Johannes wrote:I played a little bit with the new views.
...
Nice work.

Thanks!

Some observations:
- I find myself always looking up when searching for the path bar. I know the Finder has it on the bottom too. But for me the top of the browser feels more natural.

I struggled with that myself. The problem is that if you put the path control above the item pane, it ends up between the item browser and the layers. The interface is already pretty busy there, and it gets obscured by the timelines. If you put it at the very top, now it's well away from the item views and feels disconnected from it.

- Hoovering over a dot in the browser no longer displays the Playback controls. Are they simply not jet implemented or is there a new way to reveal previous/next captured instances?

The individual item playback controls have not been (re)implemented. I was debating whether to keep them or not. With the ability to automatically hide uninteresting layers, their utility is considerably lessened. As an alternative, I've considered a keyboard short-cut that hides/reveals the layers based on the currently selected items. Functionally, that would be identical to the old playback controls. It would be less intrusive (interface wise), and ultimately more flexible, since one could select multiple items and navigate them as a group.

- What is the meaning

42

- Hiding irrelevant Layers is a good idea. But I would suggest to place the Show hidden layers command in the layers menu as well.

Good suggestion.

- In time view I can't select a certain instance in time. QRecall always selects all instances (the whole lance of pierced instances). When I ercall I get the last captured instance.

I originally wanted to allow one to select individual items in the time view, but when it came time to implement the recall actions it became clear that such a selection would create some serious problems for QRecall. QRecall's database model centers around the concept of a single range of time, within which one can operate on one or more items. If you select a file from layer 4 and a folder from layer 19, there's no way for QRecall to frame that selection in terms of a single operation.

But just like the playback controls, it would also be easy to create a short-cut that would let you click on an item in the time view and automatically shade the layers so that the item you clicked on is now the latest item, ready to be recalled or restored. This would be vaguely similar to Photoshop's Command+Option+click shortcut, which jumps to the layer of whatever you click on.

- What is the meaning of the different colours of the layer labels in time view?

It means they happened on different days. QRecall arbitrarily color codes the layers so that it's easy to pick out layers from different days/weeks/months, and see groups of layers that occurred on the same day. Also, the depth of each layer is (logarithmically) proportional to amount of time encompassed by that layer. So week layers are thicker than day layers, which are thicker than hour layers.

Ralph Strauch wrote:Before I install v1.2.0(35) beta on the Snow Leopard machine I want to confirm that it's OK to run different versions on the two OSs.

Yes, you can use different versions.

If you want to open archives written with the lastest version (b35) on a system running Leopard, I recommend that you upgrade the computer running Leopard to version 1.2.0b34. This is a special release of b33 that accepts the larger icon data records written by b35. See the release notes for the gory details.

The new version (b35) doesn't change the format or structure of the archive in any way. It does, however, capture a lot more icon data than earlier versions. This had an unexpected consequence for earlier versions that assume a file's icon data record would never exceed 32K. The new icon data can easily exceed that (by several times), which causes versions earlier than b34 to be grumpy; they won't display icons of items with the large records (even though the icon data is compatible) and they refuse to verify the archive. Version b34 simply accepts that some data records can be larger than 32K; everything else works the same as it did before.

Other than that, the versions are interoperable. All of the really important actions (capture, recall, merge, compact) work across all versions. That's because a file's icon data record is only used for display purposes and is not considered to be an essential part of the file. QRecall, therefore, ignores any problems that it might encounter with a file's icon record and just keeps going.

Thanks, Steve. QRecall is supposed to insert the new "Browser Style" control into the toolbar once the first time you run the new version. Clearly, it's getting overzealous.

Scott,

When you restore (or recall) a folder, QRecall reconstructs all items contained in that folder, including invisible files, to the state that they existed when that folder was captured.

If you've used the layer shades in the archive browser to hide more recent incremental captures (i.e. rewind time), the entire folder will be restored the point in time being viewed. In this respect, QRecall works just like Time Machine. You can rewind entire folders (even entire volumes) to any captured point in time.

You always have the option, of course, of picking through the folder and retrieving individual items. But anything you do with a folder (capture, recall, restore, delete, ...) always means that folder and every item and subfolder it contains.

Scott Elliott wrote:Would Time Machine be a better solution? Why would I select QRecall over Time Machine?

While conceptually similar, QRecall does a number of things that Time Machines doesn't. Principally, QRecall intelligently compares every block of data being capture to what's already in the archive, and never duplicates any data. This makes it vastly more efficient than Time Machine, which blindly copies every file it finds and makes an additional copy of each whenever it changes.

In addition, QRecall is scrupulous about data integrity. Every block of data, and every bit of file metadata, is protected by data checksums and cross-checks. QRecall fanatically examines every block of data for consistency and possible damage during every phase of operation. QRecall lets you verify that your captured data is correct, has not been corrupted or altered, and can be successfully restored. Time Machine, and similar file-copy backup solutions, can make no such claim.

Steven M. Alper wrote:... I'm attaching an excerpt from the log with the rather sad sounding exception, "Failure failed."

Thanks, Steven, for the post.

Yes, you did encounter an internal error, but one I'm at a loss to explain. I can tell you what happened, just not way.

There's a temporary table build during the verify process that's used to verify that the number of the bytes in every file agrees with the length that it's supposed to be. It writes this information incrementally while it's busy checking other things.

When it comes time to verify the file lengths (you'll see the message "Checking file lengths"), it reads this information back into memory. In your case, the file read back was 16 bytes shorter than it was supposed to be:

Details shortListData.length (12179240) disagrees with shortListCount (1522407*8)

I can't suggest any reason why this would happen. I suggest repairing your startup volume and trying again.

Mikael wrote:What is so special about the structure of wizard actions that the can't be treated like usermade actions?

There's nothing different about them. Actions created by the capture assistent are no different than manually created ones, and should be fully editable.

Please describe what is preventing you from editing these actions.

I should point out that the action window is divided into sections (Archive, Action, Schedule), and in the title of each section is a disclosure triangle. Click on the triangle to expand the section and edit the details.

I point this out because, depending on which version of QRecall and OS X you are using, you might have one of the combinations where the color of the disclosure triangle the the color of the section title's background are the same, making the disclosure triangle all but invisible. (Apple is always fiddling with the colors of the UI.) Look hard, or just click to the left of the title, if you don't see it.

Offhand (i.e. without looking at that code), I don't see why a "cancel" Growl notification couldn't be added. I've added this to the to-do list for 1.2.

Damian Huxtable wrote:What does a red exclamation mark to the left of an action in the actions window mean?

Hover the cursor over a status icon in the actions window and a help tag will describe its status and/or its problem(s).

Typically, it's because the action hasn't been fully defined or the destination archive can't be found. Sometimes the latter is misleading because QRecall can automatically mount some external and network volumes before starting the action, which means the archive doesn't have to be on-line now for the action to run successfully—but the actions window can't know that.

More generally, is there a part of the manual or help pages that details what all the symbols on each window mean?

No, I just realized that there isn't! I'll put that on the to-do list.

Bob Tyson wrote:If I keep backing up to the same archiive I worry that corruption will creep in.

There are lots of good reasons to split (or combine) your backups amongst archives, but trying to protect against corruption isn't one of them. The important information in an archive is stored in the primary repository file. When you capture files, new data is added to this file, but the existing data is never overwritten. The data already captured is just as safe whether it's in the archive you're capturing to or another archive on the same volume. If you're worried about data integrity, schedule a verify action to run regularly.

It's true that some archive index files get rewritten whenever you capture new items, and the more often you capture, the greater the chance there is for something to go wrong and trash one of them. But all of the information in the index files is redundant and can be reconstructed from the data in the primary repository file.

I prefer not to back up the whole volume because if I do the time to do incremental updates may become long, with QRecall picking up on a zillion new changes through the System, Library, Applications and such.

Unless you've just run a major system upgrade, your core OS and application files don't really change that much.

There are clear advantages, and disadvantages, to subdividing your backups. But it's hard to make any broad recommendations. Instead, I suggest you develop a backup workflow. I like to start by considering what could go wrong:
- Accidental damage, overwrite, or deletion of my files
- Failure of working system or drive
- Failure of backup storage device
- Failure of secondary backup storage device (if any)

Then, for each of these situations, consider what steps you'd have to take to recover the files you need, restore you boot system, replace you backup drive, and so on.

Then consider what steps or processes you'll need to perform every day to maintain your backups.

Every decision you make will impact one or more of these three areas. For example, consolidating all of your backups into a single archive simplifies every aspect of your backup workflow, but puts "all of your eggs in one basket." Conversely, separately backing up your system and user documents might make it quick and easy to restore your OS in the case of a total system failure, but that might be little comfort if you can't also restore all of your documents.

Josh,

I looked at the code for this this morning, and another thought occurred to me. It's the QRecallMonitor process (the invisible app that runs the QRecall Activity monitor window) that loads the history. Following a capture, it reloads the history for every known archive. This gives it a "bird's eye" view of what's been captured in every on-line archive. So the error might not be from either of your rotating archives. Again, you can test this by discarding all of the aliases in the Recent Captures folder, and waiting to see when the problem reoccurs.

Josh Davenport wrote:I'm getting this "? warning": Could not load capture history from /volumes/the volume/name.quanta

That's odd that you continue to get this error. Normally, a bad capture history file will be rewritten on the next capture so this doesn't repeat. Please send a diagnostic report (Help > Send Report...) so I can look for any other capture history related errors in the log.

Anything I should do?

Ignore it.

Capture history is non-essential information about the top-level items that have been captured in your archive. So, as an example, if you capture your Applications folder to an archive named MyStuff, two things happen: a tiny file named outline.index is written inside the archive package that records that this archive may contains items in your Applications folder. At the same time, an alias to that archive is created and written to <your home folder>/Library/Preferences/QRecall/Recent Captures.

Now what's all this good for? When you use the QRecall contextual menu (OS X 10.5) or the QRecall Service (OS X 10.6) to recall or recapture an item directly in the finder, QRecall scans the archives in the Recent Captures folder and quickly reads their history (outline.index) files in order to determine which archive(s) the item you've selected might be captured. So if you selected the iTunes application in the Finder and choose the "Reveal in Archive" command, the history information would tell QRecall that the archive MyStuff might contain that application.

It's superfluous information as far as the integrity of your archive or captured data is concerned. Why it's repeated failing is somewhat of a mystery, because the alias and outline.index files gets rewritten every time you complete a capture. So anything that I can image that would go wrong should get fixed after the next capture.

If you want to try to fix this, start by opening the archive package (select the archive in the Finder, control/right+click on the icon, and choose Show Package Contents). Locate and trash the outline.index file.

If that doesn't do the trick, try discarding all of the alias files in ~/Library/Preferences/QRecall/Recent Captures.

You might also consider repairing the volume that contains your archives using Disk Utility. A lot of strange file system problems (like the infamous "cannot obtain FSRef") can be caused by subtle errors in the volume's structure.

Bruce Giles wrote:Any forecast on when we'll see the new UI?

Real soon! Of course, I've been saying and thinking "real soon" for the past four months, but now I believe it's really true.

The re-imagined UI is suffering a little from the "second system syndrome" (for fans of the Mythical Man Month), where the developer throws everything, including the kitchen sink, into the next version of the product. But it's slowing coming together. A lot slower than I'd hoped, but I can see light at the end of the tunnel now.



New UI features include

icon, list, column, and a new 3D view

extensive use of animation

256x256 icons

browsing history

unified items browser (no more owners and volumes drawer)

Quick Look

X-Ray view

That wasn't the "Recall" command, that was the "Instant Recall" command, which you can get by double-clicking an item or through the menu.

Right. That's the thing I keep doing by accident, when what I really wanted to do was open a folder in the archive. (Yeah, I know, click the triangle.)

In the new UI, double clicking a folder opens the folder.

Gary K. Griffey wrote:I created a new archive...changed its settings for maximum capture compression...

Whenever the compact compression setting for an archive is increased (which will likely happen if you increased the capture compression setting), the archive gets marked as "compactable." That's because, until QRecall examines every record in the archive, it doesn't know what data could potentially be compressed. Once it's marked as "compactable," it stays that way until the compact action has had a chance to compress it.

In general, an archive gets marked as potentially needing a compact after

a merge

items are deleted

an increase in the compact compression setting

a reindex or repair

Luciano,

Thanks for posting. I agree that file format longevity is a serious issue, particularly in how it pertains to backup and archiving solutions.

Your idea of being able to export the contents of a QRecall archive directly to a ZIP archive is intriguing. I'm adding this to the wish list as something to explore for a future version. I already have plans for making QRecall archives accessible via other means, but the idea of a direct-to-ZIP export does have some merit and might not be terribly difficult to implement. It's food for thought.

Bruce Giles wrote:I'm guessing that the shaded layers were the ones added after the file had been deleted, which would mean that the search function only searches the most recent unshaded layer. Is that correct?

In a nutshell, yes. The new user interface?yes, it's still in development?will have an "X-Ray" mode that will display, and let you search for, every item that's ever been captured, regardless of whether it exists in last visible layer or not.

If so, is there a way to search all layers?

You'll have to wait for the next version.

Also, I was able to successfully recall the file, but the restore function was "grayed out", even though the preference to capture and recall using admin privileges was turned on, and the pre-authorization option was enabled.

The restore action is disabled when any earlier layers are hidden.

When you hide recent layers (using the bottom shader), you're hiding recent activity and displaying the items as they were captured in the past. When you hide earlier layers (using the top shader) you hide the history of the items and show only the changes, or deltas. Restoring items with earlier layers hidden could result in existing items being deleted, which is too scary to allow, so QRecall disables the command. For an individual file it won't make any difference, but for a package or folder the results could be quite unexpected.

So I did the recall, and of course QRecall told the Finder to open the temp folder where the file was recalled to.

That wasn't the "Recall" command, that was the "Instant Recall" command, which you can get by double-clicking an item or through the menu. Instant recall recalls the item to the temporary folder and then opens it in the Finder. It's intended as a quick, and informal, way of accessing captured items.

Why couldn't QRecall restore directly to this folder?

It can. Select the items and choose Archive > Recall. QRecall will prompt you, using a standard save dialog, for the location to recall the items to.

Or, use the much simpler method of dragging one or more items directly from the archive window to a window in the Finder.