James,

I have a capture action setup that archives my Documents folder. Yesterday, at 1:09 PM....I performed the capture as I do daily. At 1:42 PM...I edited a Word document in the Documents folder...and also modified a PDF document in the same folder.

I ran the capture again early this morning...and the 2 updated documents were not captured. I recall from our previous conversations that captures targeting folders and not entire volumes...do not use FSEvents, but, perform a directory "crawl" to locate items that have changed.

Any ideas on why these 2 items were not captured this morning? One additional detail...I did create a disk image of the entire volume between the capture yesterday at 1:09 and the capture this morning...could this have caused the capture this morning to miss the 2 file changes?

Thanks,

GKG

Gary K. Griffey wrote:I ran the capture again early this morning...and the 2 updated documents were not captured.

Clearly, that's not supposed to happen.

I recall from our previous conversations that captures targeting folders and not entire volumes...do not use FSEvents, but, perform a directory "crawl" to locate items that have changed.

If I gave that impression, I apologize. QRecall always uses file system history—when it can—to determine which folders might contain changes.

There's a subtle hole in Apple's implementation of FSEvents, which make it possible to miss changes, but editing a Word or PDF document shouldn't fall through that particular hole.

So either OS X is reporting changes in your Documents folder and QRecall is missing it for some reason, or the OS is failing to report that your Documents folder contains changes since the last capture. It's (almost) impossible to tell after the fact, because QRecall doesn't normally log detailed information about which folders were reported to have changed.

If you want to investigate this, there are a couple of QRecall advanced settings that can help. You can set these with the following Terminal commands:

defaults write com.qrecall.client QRLogFSEvents -boolean true

defaults write com.qrecall.client QRLogCaptureDecisions -boolean true

When both of these options are set, QRecall will log the entire list of folders reported by FSEvents to have changed since the last capture. These two settings can produce a tremendous amount of log file activity, so I won't recommend leaving them on for long periods of time. But they can be useful in determining why a particular item is, or is not, being captured.

defaults delete com.qrecall.client QRLogFSEvents

defaults delete com.qrecall.client QRLogCaptureDecisions

One additional detail...I did create a disk image of the entire volume between the capture yesterday at 1:09 and the capture this morning...could this have caused the capture this morning to miss the 2 file changes?

I can't see how that would have made any difference, but I can't definitively say "no" either.

James,

Looking back in my notes...I remember the ""defaults write com.qrecall.client QRAuditFileSystemHistoryDays -float 0.0" option to disable using FSEvents entirely.

I ran that Terminal command...then updated a Word document in the Documents folder...ran a re-Capture on the entire Users folder...once again, the capture missed the changed Word document...even though the log clearly states "Action 2012-02-15 04:30:40 Minutia Filesystem change history ignored"

What do you think is going on here? My understanding is that when you disable FSEvents that a Directory "crawl" is used to determine modified date/time. The Word document clearly shows a Modified date of this morning...

Thanks

James,

I have now re-run the capture several times...and it still does not see any changes in the entire Users folder...

Each time the log is as follows:

Action 2012-02-15 06:45:53 ------- Capture to Lion User
Action 2012-02-15 06:45:53 archive: /Volumes/WD 1 TB Green 2/Lion User.quanta
Action 2012-02-15 06:45:54 Capture Users
Action 2012-02-15 06:45:54 OSX Lion:Users
Action 2012-02-15 06:45:54 Minutia Filesystem change history ignored
Action 2012-02-15 06:45:55 Captured 2 items, Zero KB
Action 2012-02-15 06:45:55 captured: Zero KB (0 bytes)
Action 2012-02-15 06:45:55 written: 1 KB (488 bytes)
Action 2012-02-15 06:45:55 duplicate: Zero KB (0 bytes) 0.00%
Action 2012-02-15 06:45:55 rate: Zero KB/min
Action 2012-02-15 06:45:55 files: 0
Action 2012-02-15 06:45:55 folders: 2
Action 2012-02-15 06:45:55 icons: 0
Action 2012-02-15 06:45:55 ------- Capture finished (00:00)


Now I am concerned about the integrity of all of my QRecall archives...

Any input would be appreciated...

Gary K. Griffey wrote:I have now re-run the capture several times...and it still does not see any changes in the entire Users folder...

It's a bug.

It turns out that the new "ignore items" feature added in 1.2.0(56) and the QRAuditFileSystemHistoryDays were getting their wires crossed. It's a complicated relationship, but the upshot was that when the QRAuditFileSystemHistoryDays period finally expired, instead of scanning every folder for changes, it scanned nothing. Of course, setting QRAuditFileSystemHistoryDays to 0.0 just makes it happen all the time...

The fix was one line of code. The updated version, 1.2.0(59), should be built and ready within the hour.

Thanks for sticking with this. This is why I value my beta testers so much!

James

Thanks James!!!!

I will wait for the new 59 release and give it a try!!

As always...thanks for the quick turnaround..it is much appreciated!!!!!

Ok...

I installed the beta 59 release...and the QRAuditFileSystemHistoryDays = 0 now works fine.

I will use this setting until I find out what corrupted the FSEvents on that volume. The degrade in capture performance is secondary at this point to the archive integrity.

Thanks again for your help.

GKG

Gary K. Griffey wrote:I will use this setting until I find out what corrupted the FSEvents on that volume.

Just to be clear, the FSEvents on the volume are just fine. QRecall doesn't write or change these events. It either ignores them or asks them to be replayed from a certain point in the past.

The bug was not the gathering, interpretation, or ignoring of the system's FSEvents. The bug occurred when QRecall was ignoring all FSEvents (i.e. didn't even ask for them). It was supposed to switch to a mode where it scanned every folder, but instead ended up in a mode where it ignored every folder.

Now that you've run your capture once with QRAuditFileSystemHistoryDays=0.0, everything will now be up-to-date going forward. The only legacy will be earlier layers that did not capture items they should have, which you can eliminate by merging the layers from the past few days with the one you just captured.

Understood...

One possible enhancement request....and I believe I have seen this request from other users...

Would be the ability to "toggle" the use of FSEvents on or off as part of a specific defined Capture Action...instead of globally for all captures after the PList is changed. It would also be helpful to do this for the capture decision logging too...

Thanks...

I take my hat off to you James. Not only do you always respond to questions and problems expeditiously but you are also very quick to come up with solutions, and I wish every developer was as conscientious.

This particular incident serves to remind all of us that while QRecall 2 is a rock solid application most of the time, it is still in beta and we shouldn't grumble if just once in a while it throws a bit of a wobbly. There is still nothing else that comes anywhere close to this application.


Thank you again
Adrian

Gary K. Griffey wrote:Would be the ability to "toggle" the use of FSEvents on or off as part of a specific defined Capture Action...

Yes it would, and I'll put that on the to-do list.

I have plans for other per-action options, which requires some new plumbing and changes to the action document interface. But once those pieces are in place, adding that particular option would be easy.

Adrian Chapman wrote:This particular incident serves to remind all of us that while QRecall 2 is a rock solid application most of the time, it is still in beta and we shouldn't grumble if just once in a while it throws a bit of a wobbly.

Thanks, Adrian, for the high praise.

QRecall wouldn't be half the application it is today without the patience and insight provided by its beta testers. I have over 300 diagnostic reports that have been filed during the 1.2 beta program, along with countless e-mail messages and forum posts, which says a lot about the dedication of the QRecall beta users.

This particular incident was a tad unsettling, because I'm winding down development of 1.2, and one hopes not to see any major issues at this stage. QRecall 1.2 is currently feature complete. I'm focusing only on bugs and compatibly issues, moving towards a release candidate later this month.

So a shout out to all my beta peeps: Please run it hard and report anything you find.

Thanks!

James,

One more question...

I am running QRecall with the Capture decision logging options turned-on...I see the informational messages when I am capturing a local volume directory...however, when I mount an SMB share from a remote server...and then kick-off a capture for that share...I do not see these capture decision logging messages.

Why?

Thanks,

GKG

James,

After I restored the use of the FSEvents for QRecall and the re-ran the SMB share capture...I now do see the capture decisions log messages...

I'm not sure why...but it appears to be working as expected now. Sorry for the confusion.

Just one question though...obviously, when QRecall is capturing a mounted SMB share...it could not use the FSEvents method since the data is actually housed on a remote device...does QRecall just crawl through the directories on the SMB share and look for changes? I also noticed that the SMB capture never has the "Locating Changes Since XXX" message in the log...does this message only apply to FSEvents enabled captures?

Thanks,

GKG

Gary K. Griffey wrote:obviously, when QRecall is capturing a mounted SMB share...it could not use the FSEvents method since the data is actually housed on a remote device...does QRecall just crawl through the directories on the SMB share and look for changes?

Correct.

I also noticed that the SMB capture never has the "Locating Changes Since XXX" message in the log...does this message only apply to FSEvents enabled captures?

Also correct.

The message "Locating changes since..." indicates that QRecall is using FSEvents to determine what folders contain changes. There are lots of reasons it won't/can't do this: The OS doesn't support FSEvents, the volume format doesn't support FSEvents, the FSEvent information on the volume is incomplete or incompatible, and so on.

If any of these reasons prevent it from using FSEvents, it falls back to performing an exhaustive search of the directory structure.