James,

Not a big deal...but I noticed an oddity this morning while performing a capture.

In the Activity Monitor window...while a capture is running...you display the "Capturing XXXXXXX" indicating the name of the file that is currently being captured.

This file name, however, is in reality, the last file that was captured successfully...not the file that is currently being captured. Is this working as designed?

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

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

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

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

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!!!!!

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

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

FYI...

Just one last note on this for any QRecall / Fusion users...to prevent this spontaneous SMB disconnect...simply change you VM's network adapter from "NAT" to "Bridged" mode...

This will prevent the mac's SMB share from being forcefully terminated. Again...this is a VMware Fusion issue...and has nothing to do with QRecall.

Thanks,

GKG

James,

Just an update to close the original issue in this thread. To quickly restate the issue...while QRecall was writing to an archive located on an SMB share...the archive became corrupted and could not be repaired.

After performing many additional tests trying to recreate this...I have finally discovered that this is not a QRecall issue at all.

While QRecall was performing a Compact operation to this archive...I just happened to launch VMware Fusion and a Windows virtual machine that just happens to map a network drive to the same Windows server...not the same share..but the same physical server. This was causing the SMB share on the mac to spontaneously dismount Obviously, QRecall literally had the "rug ripped out from under it"...and the archive became corrupted.

I have opened a trouble ticket with VMware on this issue. I just thought other QRecall / Fusion users should be aware of this situation...sorry for the confusion...I just never made the association until yesterday..and now I can recreate it easiliy.

GKG

James,

Just a follow-up on this...I recreated the archive and have run three subsequent capture/compact/verify actions and they are now running ok.

I am not sure what occurred on the first error...but the issue is no longer present.

Thanks for you feedback...if any other issues occur I will let you know.

At this point...I am seeing no issues with beta 54.

GKG

Ok...that makes sense....

I will retry the capture and immediately verify...

Thanks,

GKG

I agree about the failures...can happen anytime...

One question though...if a data read or write error occurred on the original Capture...the Capture would have failed, correct?

In other words, if the folder being captured (on internal drive #1) OR the archive being written to (on internal drive #2) was not read/written normally...the Capture would have flagged the error.

Thanks,

GKG

James,

Thanks for the info. This Capture, Compact, Repair, etc., was run on a brand new Mac mini server with dual internal drives. The archive was stored on the second internal drive...not that it could not be simply a new drive that is bad...but I think the chances are low. I did run Disk Utility on the drive and it came back OK.

I will attempt the capture again...and this time, I will run a Verify action before running the Compact action. I just seem to remember that there was a bug with the Compact action a while back...but I have not seen it recently. I thought this may be a new "strain".

Thanks,

GKG