Chris Caouette wrote:Just a little FYI I made the move and so far Qrecall is performing like a champ in case anyone else is curious.

Thanks, Chris, I was just about to ask about Lion myself. I haven't installed it yet, but plan to do so on at least one computer this weekend.

Question for anyone who knows: Some of the information I've read about the Versions feature of Lion implies (or in some cases, says) that Versions uses Time Machine to work its magic. So, if I have Time Machine turned off, because I'm using QRecall for backup, does Versions still work?

-- Bruce

James Bucanek wrote:

defaults write com.qrecall.client QRPhysicalMemoryMB -integer 2048

Note that QRecall will ignore any setting smaller than 512MB or larger than 6GB.

Thanks, James. I just made the change, so we'll see how it does.

Earlier today, I started a new archive on the MB Pro, and the first full backup under b38 ran without error and verified perfectly. It was pretty fast, too, in spite of having all the archive settings set to "slower, smaller".

-- Bruce

James Bucanek wrote:

Bruce Giles wrote:With b38, I'm seeing the return of a bug I thought you had squashed.

Not squashed, just semi-random. I have not addressed this bug because I plan to replace it with a different mechanism soon.

OK, I hadn't seen it in a while, so I assumed it was fixed. Anyway, it's obviously pretty minor, and I'll wait to see what you come up with.

By the way, I thought I read something in the update description about being able to set the RAM that QRecall uses, which I wanted to do on one of my computers that usually has a virtual machine loaded. But I can't find anything in the user interface to do this, and I can't get to the update description any more either. Did I mis-remember, or is it just hiding, or what?

-- Bruce

James,

With b38, I'm seeing the return of a bug I thought you had squashed. After installing it, on two different systems, I got the dialog asking me about pre-authorizing. (Sorry, I didn't write down the exact words.) I clicked the button to indicate I wanted to do that, and next I was prompted for my username and password, as expected. But when I went to Authorization section of the preferences, on both systems, the checkbox was checked, but the button said "Preauthorize...", not "Cancel Preauthorization". I clicked the "Preauthorize..." button, and it immediately switched to "Cancel Preauthorization", without asking for username and password again (since this was only a few seconds after I had entered my username and password the first time).

After seeing this on the first system, before I did the beta update on the second system, I double-checked to make sure it was preauthorized first, and it was.

I didn't try to do a capture before correcting the preference, so I don't know if it was purely a cosmetic issue, or if doing the update really did cancel the preauthorization.

-- Bruce

James Bucanek wrote:Your system's ratio of RAM to archive size will impact the frequency of this kind of thing a lot. If you have a lot of physical RAM, QRecall will allocate really big caches for many of these tables and indexes. That reduces the frequency that they need to be flushed, sorted, or read again from disk.

I'll bet that's the problem. This is a MBPro with 4 GB RAM, but I'm nearly always (as I was today) running VMWare Fusion and Windows 7 in a 2 GB partition, so that leaves only 2 GB for everything else, including QRecall. I probably don't need a full 2 GB for the things I'm doing in Win 7, so I'll see if I can cut that back a bit and give QRecall some more room when it needs it. And I knew QRecall did occasional housekeeping before and after archives, but I wasn't sure if it also did that *during* archives. Now I know. Thanks! You might consider adding some kind of notification in the activity window just so we have a better idea of what's going on when it appears to stall.

Sometimes QRecall is just looking for the next thing to capture. QRecall displays the item that it's capturing, but once it's done it goes looking for the next thing to capture. Until it finds the next item, the status line continues to display the previous item. In the future I might change this so that a prolonged scan for the next item is a little more transparent.

For the times I've noticed it, that's probably not what's happening. After it finally started moving again today, I watched it go through the rest of my Applications folder, and the rest of my hard drive, pretty quickly.

-- Bruce

Here's a problem that I've noticed -- occasionally -- for quite some time. I've been running the betas of QRecall for months, so I can't say if this was happing in the non-beta versions or not.

Sometimes, while an archive operation is executing, I'll notice in the activity window that a certain file is currently being archived. I'll go away and do something else for a while, and I come back 20 or 30 minutes later, and the activity window is still "stuck" on the same file. When it happens, I'm never sure if QRecall is still actually working on the same file, or if it's just that the activity window isn't updating the information for some reason.

I've never seen it happen on the same file more than once, and I can't see any pattern to explain when it does happen. Today it happened while archiving Adobe Reader in my Applications folder. I've also seen it get "stuck" for many minutes on a small data file (less than 10K). Eventually, QRecall always goes on, and there's no indication of any problem in the log window.

When this happens, is it because QRecall is doing some kind of time-consuming housekeeping in the middle of an archive? If not, do you have any idea what *is* happening?

-- Bruce

This is a very minor issue, and I'm not sure if this qualifies as a bug, or just a "feature".

I'm archiving to an external drive via the USB interface. I have some actions defined with the condition set to "Hold While No Archive". Sometimes an action will start to run when the drive isn't plugged in, which is perfectly normal, of course. QRecall puts up a notification in the Activity Monitor window and notes "waiting". Usually, I just plug the drive in and then everything proceeds normally. Occasionally, however, I decide I don't want the action to run right then, so I click the little round "X" in the monitor window to cancel it. As soon as I do that, Growl pops up a notification stating that the action was "complete". Would it be possible, in this circumstance, for Growl to note that the action was "canceled", or "terminated", or something other than "complete"?

-- Bruce

James Bucanek wrote:

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.

Ah! That's what I'm looking for.

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

You'll have to wait for the next version.

Any forecast on when we'll see the new UI?

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.

OK, that makes sense. I hadn't really thought about that before.

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.

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.)

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.

Intuitively, I know I can do a drag-and-drop, but for some reason, I just never think of that.

Thanks for the response!

-- Bruce

Today, I needed to restore a file on our server that had been accidentally deleted. I knew the filename, and I knew the path to it. I also knew it had been modified one day last week. I didn't know when it had been deleted. I tried using the search field in QRecall, and initially, it found nothing. I had to start dragging the windowshade up from the bottom, one layer at a time, until eventually the file appeared in the archive. 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?

If so, is there a way to search all layers? If I had had no idea when the file was last modified or deleted, I might have spent a long time looking for it. (The archive has 69 layers, going back to March 2009).

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. So I did the recall, and of course QRecall told the Finder to open the temp folder where the file was recalled to. I then had no trouble dragging the file into the folder where it had originally resided. But is that normal? Why couldn't QRecall restore directly to this folder?

-- Bruce

Johannes wrote:

I also don't see that here. In the screen shot, your font is bigger than what I see on any of my test systems. Have you used a utility to alter the system fonts or their default sizes?

I have not used a utility to alter the system font (but my eyes are quite happy that the font is not smaller). A simple solution would be to allow the user to adjust the column width.

I do not see the problem Johannes reported about the log window on my system either. However, from Johannes' name, as well as the name he gave to the screen shot, I'm guessing he's using a non-US system. Could that account for a slight difference in the font size?

-- Bruce

I've noticed two issues with recent betas. I'm not sure if these are actually problems, or just due to the fact that these are betas.

1. In the QuickStart menu, the Check for Updates pop-up menu defaults to blank. If I click on the menu, I see "Manually", "Every Startup", "One a Day", and "Once a Week". There's a blank line below "Once a week", with a checkmark beside it. I can choose one of the other options, and it appears to work. If I click on the menu again, the blank line is gone, and the option I selected is checked, but after quitting and restarting QRecall, the blank option is selected again. Despite that, QRecall does notify me of new updates.

2. The second issue is that after every installation of a new beta, I get asked to authorize with my username and password. No problem so far. But then when I check Preferences, Authorization, the "Capture and recall items using administrative privileges" checkbox is checked, as I wanted, but the button below always says "Preauthorize..." So I click it, and it changes to "Cancel Preauthorization". It does not ask for my username and password again. I presume this is because it's only been a few seconds since I initially entered them, so that authorization is still in effect. My question is why the "Preauthorize" setting appears not to stick between installs. Should it, or is this expected behavior? Once I've set it to Preauthorize, it retains that setting until I install the next beta.

-- Bruce

James Bucanek wrote:I suspect that this won't work. While the file system differences between Tiger (10.4) and Leopard (10.5) are not at huge as those between Leopard and Snow Leopard (10.6), Leopard introduced access control lists (ACLs) that I believe are critical for a few key OS files. Tiger lacks the APIs for restoring ACLs, so QRecall will ignore ACLs captured by a Leopard system.

That's what I was afraid of. I guess I should mention that when I booted off the external drive, the internal was still accessible. Since QRecall did its last capture at 2:00 AM today, if I restore from that, everyone loses all the work they did today. So before I left this afternoon, I started a capture of the Groups and Users folders, to a new archive file, hoping that I might be able to capture all the work that was done today. Sounds like I'm going to need to re-do that capture, after I get a bootable Leopard Server system running.

My suggestion would be to install a minimal Leopard system—it can be a 10.5 client, it doesn't have to be a server—on an external drive, copy over a copy of QRecall, bo use that to restore the 10.5 server.

If you don't have a spare external drive, install Leopard on the Xserver, install QRecall, perform a "live" restore, and then immediately reboot.

Hmmm... It hadn't occurred to me to install a non-server version. That would be faster and easier than trying to install Leopard Server, just to get a restore going. I've got several spare drives, so that shouldn't be a problem. I knew I could do a live restore, and if necessary I'll resort to that, but that always makes me nervous. I'd rather restore to a volume that I'm not booted from, if possible.

Thanks!

-- Bruce

I have an Xserve running Leopard Server (10.5.x) whose internal drive crashed hard this afternoon. I suspect I'm going to have to reformat the drive and restore it (using QRecall, of course) from my backups.

The external backup drive is bootable, but it's running Tiger Server (10.4.x). I have the latest version of QRecall installed on both drives. If I boot from the external drive, running Tiger Server, will there be any problems with using that system to restore Leopard Server onto the internal drive? If necessary, I can boot from the Leopard Server install disc and use it to reformat the internal drive.

-- Bruce

I've recently installed VMWare Fusion on our Xserve, which launches Windows XP Pro on bootup, so now our server is simultaneously running Leopard Server and XP Pro, at all times. The Windows virtual machine file, which includes the virtual hard disk as well as snapshots, etc., is stored in my home directory, and is backed up every night.

The virtual machine file is currently about 60 GB in size, and is actually a package. The virtual disk itself is broken up into numerous chunks, each no larger than 2 GB in size. (That's one of the options for how Fusion segments and stores its virtual disk.) There are probably large chunks of the virtual disk that rarely change. But some of the chunks that do change, such as those parts that contain Windows log files, caches, temp files, etc., probably change fairly constantly.

So, I'm wondering how QRecall deals with this. Even though QRecall is backing up only the parts of the virtual disk files that change, it still takes significant time to back them up, and they're continuing to change during the backup. If I ever have to use QRecall to restore the virtual machine file from a backup, is it (the VM file) even likely to work? Or do I end up with a virtual disk inside the VM file in which the various chunks are no longer consistent with each other, because they were backed up at different times during the archive session?

Would I be better off to not back up the VM file until the virtual machine is not running? That would probably be tricky to implement, since the server needs to run unattended, but I might be able to come up with something if necessary.

john hampson wrote:Can anybody see any flaws in this approach?

Is there any suggestion for a better method?

I'm not quite sure if this will do what you want, but you can use TrueCrypt (free disk encryption software from <http://www.truecrypt.org/> ) to create an encrypted partition on an external drive.

You need to supply a password to mount the partition, but once it's mounted, reads and writes are encrypted/decrypted on-the-fly. I ran some brief tests with QRecall and it seemed to work just fine with an archive on an encrypted partition. It is a little slower, because of the on-the-fly encryption.

Once the partition is unmounted, no one can access anything on it without the password.

-- Bruce