*sigh* Obviously, I have yet to figure out how this forum software works. I have no idea why all the HTML tags appeared in the above reply. It previewed just fine.

-- Bruce

James Bucanek wrote:The solution is annoying, but simple: Open the folder containing the offending item in the Finder. When the Finder displays an item for the first time it does something to update the local .DS_Store file and the Launch Services database which permanently fixes the problem for that item.

For example, when I install a fresh OS I find I must open up the Applications and Utilities folder once to display all of the applications it contains. Once I do that, QRecall can capture the /Applications folder without any problem.

Ah HA! That explains something else. The first couple of times this happened (prior to the logs I sent), it seemed to happen in exactly the same place. I got curious and started opening folders in the area where the capture stopped, looking to see if I could see anything amiss. I didn't, tried another capture, and the next capture got much further in the process before the capture stopped. Now I know why.

James Bucanek wrote:If you find it difficult to locate which item(s) is having problems, create a test archive and manually capture folders one at a time until you find the one that crashes.

Hmmm... This could be quite a job. I seem to have a number of such folders. Do I understand correctly that this only happens with folders containing applications? I wonder if I could create an AppleScript, or perhaps an Automator action, that would search the hard drive for folders containing Applications, then open and close those folders?

Normally, I do keep my "working" applications in the main /Applications folder (or its subfolders), but I do know that one of the folders where this happened was a folder containing an app I had created in REALbasic, which I probably never opened in the Finder, and another contained an app I had downloaded and unzipped, but the folder was still on my desktop, unopened.

James Bucanek wrote:As for why your QRecall application is crashing, I'll have to investigate that. The crash appears to be associated with a window. Does it crash when you open a specific kind of window (like the log or actions window) or when you open a specific archive?

To be honest, I don't know. I didn't actually realize I had had any QRecall application crashes lately, until I found the crash logs. Since I'm away from home so much lately, I tend to start a backup and then leave, and it might be a day or two later before I get back to the computer to see what happened. I don't recall any system dialogs informing me of an application crash, but I've noticed I don't always get those. I'll try to keep a closer eye on that.

-- Bruce

Suppose I'm archiving my entire home folder daily. This includes a number of files (mail files, for instance) which will change daily, but for which shifted quanta detection would be useful. (Many mailboxes will change only in the last few messages added or deleted.) This also includes a large iTunes Music Library. I daily add and delete a number of podcasts, but most of the library is songs, which don't change except for the tag data (play count, last play date, etc.) Again, I think shifted quanta detection would be useful here.

The problem is that if the home folder is large (10 to 20 GB), and I crank shifted quanta detection in the archive settings all the way to the "slower smaller" end of the scale, it'll take hours, if not longer, to do the initial capture. Backing up an entire hard drive (several hundred GB) would be even worse.

As it happens, however, I believe that I have very few duplicate (or even partial duplicate) files in my home folder. If that is correct, then on the initial capture, wouldn't QRecall be mostly wasting its time looking for shifted quanta?

Assuming I have adequate space for the archive, would it not be better, for the inital home folder (or entire hard drive) capture, to move all the sliders to the "faster larger" end of the scale? This would allow the initial capture to proceed as quickly as possible while not wasting time looking for shifted quanta that probably don't exist. Then, AFTER the initial capture, move the shifted quata detection slider (and possibly the compression sliders as well) to the "slower smaller" end of the scale. That way, subsequent recaptures, where the liklihood of shifted quanta is great, would be optimized. Yes, the recaptures would run much slower, but there would likely be far fewer files that need to be recaptured, as compared to the initial capture. We're probably talking only a few minutes per day at that point.

Is this a good scheme, or am I missing something?

Also, regarding the two compression sliders, suppose capture compression is set to "faster larger", and compact compression is set to "slower smaller". Would a capture, followed by a compact, produce the same results as if I had set the capture compression to "slower smaller", and then not performed a compact?

-- Bruce

I've noticed that when QRecall displays files and folders captured in the archive window, it seems to be able to go only one layer deep when reporting folder sizes. That is, a captured folder that contains only files will have a folder size displayed, but a folder that contains other files AND FOLDERS, will display only "--" for the size.

Is this correct? Any way to get QRecall to report the correct size on all folders?

-- Bruce

Ack! I intended to post this in the Bugs forum, but I guess this one is appropriate as well. Also, it seems to have lost the attachments when I did a preview. Let's try this again...

-- Bruce

Recently I bought a larger external hard drive, and I decided to start fresh with some new archives. Unfortunately, I'm unable to do much, because QRecallHelper, and sometimes QRecall itself, keeps crashing.

A backup of my Eudora Mail folder worked fine. It's about 275 MB in size, and I've continued to recapture it every hour for a week without any probems.

When I try to archive my entire home folder, however, which is about 16 GB in size, it proceeds only so far (varies between about 2 GB and 6 GB) before I get a message that QRecall has lost connection with the process. Checking the logs shows that QRecallHelper has crashed.

I can open the archive it was working on, but a repair is required first. If I try to add additional files to the archive after that, QRecallHelper crashes again within a few seconds to a few minutes.

Any idea what the problem is? Anything I can do to help you track it down? I'm attaching the log files.

-- Bruce