Ralph,

The browser code is most likely throwing program exceptions. This can cause all kinds of strange and incomplete behavior in the browser window.

First, please open your Console utility and examine the system.log. Search/look for any messages from QRecall. If you find some, please copy them and e-mail to me or post them.

Secondly, send a diagnostic report in case there was anything captured by the log.

Finally, open up the archive package (control+click/right-click on the archive icon and choose Show Package Contents). If you find a view.plist file inside, throw it away and try to open the archive again.

Every volume (owner, folder, and file) in an archive is logically independent. Deleting a volume (owner, folder, or file) won't delete any other item in the archive, no matter how similar, and no matter how much data they may have in common.

Feel free to delete obsolete volumes that are no longer being captured. It won't affect any items captured for the volume that exists now.

Starting with QRecall 1.2.0(46) you now have a second option, one created specifically to address this situation. The new Archive > Combine Items... command will take two (or more) volumes in an archive, that are actually the same volume, captured at different times, and will stitch them back together into a single volume with one history in the archive.

See the release notes for 1.2.0(46) for the details.

There's a problem/bug in Lion wherein an attempt to access the /dev directory on the startup volume using the core filesystem APIs results in an I/O error.

It doesn't happen on all systems, and it doesn't happen all the time. For months I was unable to reproduce this problem, and then last week my primary development system started showing the same symptoms. I've filed a bug report with Apple a few days ago. It's such a bizarre and blatant error that I'd be surprised if they're not already aware of the problem, but I don't know what's being done about it.

I'm 80% sure that this is an innocuous problem, but I need to do more testing to be sure. Normally, there's nothing in the /dev directory for QRecall to capture, since it's populated almost exclusively with logical device files. So not capturing it shouldn't make any difference.

QRecall 1.2.0(57) will not detect whether the home folder of an account (more specifically if its ~/Library/Application Support folder) is on the same filesystem as the startup volume. If not, it installs its helper binaries in /Library/Application Support (which had better be on the startup volume!).


Adrian,

To test this out, you'll want to upgrade to 1.2.0(57), uninstall QRecall (Command+Option+Shift-Q), remove your symbolic link "hack," and then launch QRecall and let it reinstall itself.

Charles Watts-Jones wrote:QRecallC (my archive): Green Blank Red
Captured today: Green Blank Blank
Verified never: Blank Blank Red
Disk use bar(?): Green with size data below

This means that the archive has recently been captured, hasn't been verified, and you've got a reasonable amount of free space.

Being of the generation that has difficulty with pictograms, I don't understand why the first line shows green and red,

The summary line is the accumulation of the three status values. It's Green (OK) and Red (critical) because there is at least one status indicator that's OK and at least one that's critical. The idea is that you can collapse the details for a compact display of all three.

nor do I understand why the verified line shows red when the log confirms my bi-weekly verify status as OK.

You'll need to perform a verify with 1.2.0(57). The new status system doesn't use the log, and thus doesn't know about any activity prior to upgrading to 1.2.0(57). As soon as your archive verifies again, the status will turn green.

And I really don't want to start my day with a RED icon when the log confirms all is OK. Could RED be reserved for serious trouble please?

It is. In this case, it's saying that your archive has never been verified, which I consider to be pretty serious. It also lights up if there was a error with any action, or if your archive has almost completely run out of free space.

In this particular case, it's an artifact of the upgrade. If the menu bar indicator bothers you, go to QRecall > Preferences > Monitor and uncheck the Show status warnings in icon option. Now the presence of caution or critical status indicators won't show up in the menubar.

Bruce Giles wrote:I don't know how the 504 UID got added to the plist file

The UID was added to the kicker list as soon as you launched QRecall. It checked its configuration, saw that it was not on the list of UIDs to have its scheduler run as a system daemon, and added itself to the list.

... but assuming QRecall did it, then it seems like it also needs to look at any other UIDs in the file and delete any that are no longer valid.

Excellent suggestion.

Done.

When adding a new UID to the kicker list, all existing UIDs will be qualified. Any that don't appear to belong to valid user accounts are now deleted.

Similarly, the kicker process itself will check the UID before trying to launch the scheduler daemon for that user and exit cleanly if the user doesn't appear to exist. This should keep launchd from repeatedly relaunching the kicker for invalid users.

Christian Roth wrote:QRecall's new visuals seem not to be compatible with Screen Sharing:

I've noticed the same thing (Mac OS 10.7 client sharing a headless Xserve running OS X 10.6). I find that if I do anything to change the browser display (click on row to select it, scroll, resize the window, etc.) the window redraws correctly.

I assume this is a consequence of QR using the fastest graphics routines available, hence bypassing some hooks in the OS that it uses to detect changes for sending over Screen Sharing?

Alas, I'm not that clever. Most of the revamped user interface is built using Apple's Core Animation, an API introduced in OS X 10.5.

Is there anything I could do about it (some hidden pref in QR) to disable fast drawing, but enable compatibility with Screen Sharing?

I'm pretty sure this is a bug in Screen Sharing. I'll file a bug report with Apple.

Adrian,

It has occurred to me that there might be a general solution to this problem that could be added to QRecall. Let me know if the hack works. If it does, I might be able to create an equivalent workaround in QRecall.

Adrian Chapman wrote:I am not happy with QRecall running where I can't see it because if I put my Mac to sleep while it is capturing I end up with a corrupted backup.

Here's a hack to try: Create a QRecall folder on your boot volume (anywhere that makes sense). It should be owned by the user that runs QRecall and have read+write+search privileges only for the owner (i.e. disable all group and other access). Copy all of the files in ~/Library/Application Support/QRecall into the new folder. Make sure they all have the correct ownership and permissions. Delete ~/Library/Application Support/QRecall and replace it with a symbolic link to the new folder.

The QRecall code that loads and identifies the support folder in ~/Library uses (for the most part) standard UNIX paths, so the symbolic link should resolve to the executable folder on the startup volume, which should allow the QRecallHelper executable to run with elevated privileges.

Adrian Chapman wrote:I have just reconfigured my Mac so that the system and user directories are on separate disks.

Sadly, this configuration is incompatible with the current version of QRecall.

Security policy changes in OS X now prevent the system from launching executables with elevated privileges from any drive other than the boot volume. QRecall installs its privileged helper process in ~/Library/Application Support/QRecall. Since your home folder is now on another volume, the OS won't launch any executables it contains with elevated privileges.

QRecall is successfully installing its helper process as a privileged executable, but when it goes to launch it the OS runs it as regular process. Sensing this, QRecall assumes that the helper wasn't installed as a privileged executable and asks to install it again. Wash, rinse, repeat.

You could uninstall QRecall, create a new administrator account who's home folder is on the startup volume, and then install and manage QRecall from that account. (If you copy ~/Library/Preferences/com.qrecall.* and ~/Library/Preferences/QRecall to the new account before installing QRecall, it will transfer all of your preferences and actions.)

Steve Mayer wrote:I was attempting to find a file (filename contained spaces if that is of any import) within my archive and QRecall crashed with the following stack:

Steve,

Thanks for the bug report. Could you also send a diagnostic report (Help > Send Report)? The tools I have to decoding stack traces won't work with text pasted into the forum.

2. How is the search supposed to reveal the searched item? I see that there are a bunch of folders that are "greyed out", but nothing that truly points to where the file would be located.

See the release notes for 1.2.0(37).

In short, a dark gray silhouette of a folder means it's in the process of being searched.

Matching items appear normally; non-matching items are dimmed.

In search mode, folders can only be opened if they contain items that match. So a dimmed folder that can be opened means the folder doesn't match but it contains one or more items that do. A dimmed folder that can't be opened means it doesn't match and doesn't contain any items that match.

To quickly see just the matching items, select the "Only Show Matching Items" option in the search menu.

3. There seems to be no method of showing that the search is still occurring (i.e. Progress)

A folder or disk that appears as a dark grey shadow is in the process of being searched. As soon as that folder is searched, the folder and its contents will appear either as normal items (matches) or be dimmed (doesn't match).

pirem71 wrote:1. I'm still not able to tell how the instances captures differs from each other and that creates a sense of lack of control on what's going on. I must probably blame it to my scarce knowledge of Mac environment but I'm still uncomfortable with that (I hope you can understand me).

This problem isn't unique to QRecall, and I'm afraid I don't have a simple answer. What constitutes a significant change in a file is subjective. QRecall's #1 job is to capture all changes to a file over time, and almost by definition that means it's going to capture changes that you're not particularly interested in.

Restoring a specific version of file could became difficult (since usually one doesn't know the modification date of the file and maybe not even which is exactly the version he's looking for).
...

In this particular case, you shouldn't have to look far. QRecall is recapturing the item because metadata (permissions, extended attributes, ...) is changing. But that won't change the modification date of the file, which should only change if the data of the file changes. So you can simply view the most recently captured version of the file and look at its modification date. This will tell you the last time the actual contents of the file changed. All intermediate captures are probably uninteresting.

Is there any possibilities to perform an automatic recall of all versions of a file over a time range defined shading/un-shading layers (e.g. adding incremental suffix to the name)?

Not at this time. (Again, you could write probably write a simple shell script to do this once a command-line version of QRecall was available.) I have a more general solution to this kind of problem on the drawing board, which I hope to attack after 1.2.0 is released.

Adrian Chapman wrote:what, if any, files or folders are excluded by default?

Good question.

As of 1.2.0(50), the list of items the get automatically excluded from a capture are:

The action's archive [1]

/tmp directory

/var/temp directory

VM swap directory [2]

/.vol directory

/.hotfiles.btree directory

/.fseventsd directory

/.dbfseventsd directory

/.MobileBackups directory [3]

/.DocumentRevisions-* directory [4]

Mountpoints (i.e. other volumes) [5]

Named pipes (FIFOs)

Character special files (character generators)

Block special files (device files)

Sockets (communication ports)

Whiteout files

For every user's home folder:

~/.TemporaryItems directory

~/.vol directory

~/.fseventsd directory

~/.dbfseventsd directory

In addition, the capture action may specify other items to be filtered out and has canned filters for the various Trash and Cache folders.

[1] You can't capture an archive to itself.

[2] The location of the VM swap is determined by examining the dynamic pager daemon and is normally at /var/vm. If you've customized your VM swap location, you may need to set the QRVMSwapStorePath, see advanced setting.

[3] Only when running Lion (OS X 10.7) or later

[4] Only when running an OS earlier than Lion. Only Lion can understand the files in this directory; to earlier operating systems, these files are unreadable.

[5] Most of the items in the /Volumes directory are mount points. So the /Volumes directory itself gets captured, but rarely anything inside it. Similarly for the /dev folder, which contains mostly block and character special files.

pirem71 wrote:1. In one case only the capture action didn't create a layer (the log says, among other things, "Nothing captured")

In that case, nothing changed. If a capture can't find anything to capture, it doesn't create a layer.

2. 90% of the times a new layer was created capturing 1 item (log says "Action 2012-01-13 15:00:40 Minutia Capture Decision; capture file .DS_Store because content modification date different; was 2012-01-13 14:52:50 +0100, now 2012-01-13 14:59:55 +0100").

QRecall found that a .DS_Store file in the folder changed and capture it.

If I check the new layer in the main Archive window (I don't know if this is the correct name) I cannot see the modified .DS_Store file (since they are not displayed) but the folder containing the .DS_Store is marked as modified in its Timeline.

.DS_Store files are normally invisible. Choose View > Show Invisible Items in the QRecall browser to see invisible items.

3. 10% of the times a new layer was created capturing 2 item: the .DS_Store and the viewed .pdf file itself.
The log says (for .pdf only) "Action 2012-01-13 15:02:12 Minutia Capture Decision; capture file Decisione_CE_3_maggio_2000,_n._532.pdf because attribute modification date different; was 2011-11-15 21:25:01 +0100, now 2012-01-13 15:01:59 +0100.
Anyway having a look un the Finder the modification date for that file is still 2011-11-15 21:25

The data modification date and the attribute modification date of a file are different things. You normally don't see the attribute modification date, but it's one of the metadata values that QRecall checks. The attribute modification date is changed whenever some process sets the attributes, permissions, extended attributes, or other metadata for a file.

1. A folder is marked as changed if its .DS_Store file is changed even if it's not shown (since .DS_Store files are actually captured).

That's correct. In QRecall. a folder is considered to have changed if its metadata or immediate contents have changed.

Is it possible to avoid this behavior

I can't imagine why one would want to.

or even exclude .DS_Store files from capture?

Not at this time, but arbitrary file filers are on the to-do list.

Are there any advantages in capturing .DS_Store files that I'm not aware of?

.DS_Store files keep all of the display information used by the Finder. It includes the screen position and size of the folder's window, its display mode (icon, column, ...), sorting preference, and a host of other details. The Finder is constantly updating these files as you interact with Finder windows.

2. It would be nice to be able to select a Layer in the main Archive window and choose a command "Show capture log" (that shows the log in a separate window or, as an alternative, open the standard Log window and highlights the searched row) instead of manually search the Log window comparing the time column

Layers and log records do not have a one-to-one correlation.

Note: I made a copy/paste of Log file rows; is there a better way to include portions of the Log in a post?

The forum has a "code" tag that might make them easer to read, but other than that copying and pasting seems like the best way.

pirem71 wrote:I noticed that opening/closing a .pdf file (both in Preview and Acrobat) without making any modifications will anyway result in a capture of the file as if it was modified.

Something is changing.

QRecall looks a variety of information about each item to determine if it should recapture it. This includes the file's dates (creation date, data modification date, attribute modification date), permissions, ownership, extended attributes, finder information, resource forks, access control lists, and so on. If any of that has changed, QRecall will recapture the item. In this case, since the actual data of the items hasn't changed, the only thing QRecall will add to the archive is the modified metadata.

If you want to know exactly what's changing, you can temporarily set the QRLogCaptureDecisions option (see advanced setting). Perform a capture, change this setting to true, open and close a PDF, perform another capture, and then delete the setting (or set it to false). The log will record the first reason that QRecall decided to recapture each item.