QRecall

James Bucanek wrote:The new interface is radically different, so there's not much point critiquing it. On the other hand, if there's any features you really like about the old interface that you'd like to see preserved, speak up now.

Im looking forward to see the new interface and hope that November will come soon

If you don't mind me saying it plainly: the resent interface does not really mach the excellent features and under the hood technics of QRecall (but I've seen Backup programs with worse interfaces)

Johannes

James Bucanek wrote:
Make sure you have the log detail level control moved all the way to the right.

I have. No luck. Even a string search in the logfile (within Konsole) does not reveal it.
Anyway. Not that important.

Johannes

James Bucanek wrote:Both of these features are on the way, but both require substantial changes to the user interface code—which is being rewritten right now.

Great! Any timeframe?
Are you still interested in feedback for the current UI? Or are things already settled for the new UI, so we better not waste time on the old stuff?

Johannes

James Bucanek wrote:This appears in the log as "Filesystem change history ignored."

Can't find this string anywhere in the log. But it seems that with QRLogFSEvents set the EventRootDirectory item comes up when FSEvent is used and is missing for a deep scan.

Johannes

On my testing today I thought I found an other "not captured" issue, but it turned out to be a misunderstanding on my side. I searched for a deleted file and could not find it in the Archive until I found this thread:
http://forums.qrecall.com/posts/list/217.page#955 (How can I search for a file across layers?)
So it seems, that the x-ray view mentioned there is still not available in the resent beta/alpha (1.2 b25), right? I think this is essential. People will get heart attacks when they fire up the Backup in search for an accidentally deleted file and can't find it in the backup either. QRecalls behavior is logical from the technical point of view, but confusing from a users perspective. I hope this feature will come soon.

I also discovered this thread:
http://forums.qrecall.com/posts/list/221.page#975 (Request for true "merge" operation)
This "Keep Last Version" feature would make QRecall stand out even more! This will solve an issue that no other program (at least to my knowledge) deals about in a reasonable manner. It would make archiving part of the backup without extra thoughts.

Johannes

Thanks for the explanation. I will test this. What is the indication in the Log for a deep scan?

Johannes

James Bucanek wrote: if you restore the same items using a25 they should be OK.

Confirmed: they are restored fine.

Thanks for fixing.

Johannes

James Bucanek wrote:
Set QRAuditFileSystemHistoryDays to 0.95. That will force a deep scan once a day

On what base will QRecall do the maths? Once a day for each Archive? For each Action? For each machine?

Consider the following scenario with your suggested setting:

Action 1: Folder 1+2+3 to Archive 1
running every hour backing up my three main working folders

Action 2: Folder 1+2+3+4+5 to Archive 1
running manually at the end of the day (when all files and databases are closed). This Action includes the three folders from Action and some more.

Action 3: Folder 1+2+3+4+5 to Archive 2
running when external offsite disk is connected (weekly)

Will I get a deep scan for Action 2 and 3 every time with the above setting?

Johannes

It would be interesting to find out what finder information QRecall read, and captured, when it got the file in the first place.

Here are the file records; 4 of them; difference is in # and capture time and once gid (I guess that was the re-capture after TM restore).

[   216]: #166793 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-11 10:45:01 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=20(staff) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

[   216]: #656329 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-12 00:09:36 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=20(staff) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

[   224]: #676763 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-12 15:00:05 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=99(_unknown) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

[   216]: #811433 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-12 21:42:05 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=20(staff) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

and choose Archive > Dump

Now I know what the Dump-Command is for. Is this alpha only? If not the Eclipse dots are missing in the menu. What is the diference between Archive>Dump and File>Dump??

(Are these backwards by any chance?)

I don't know. It's just what I copied from Terminal. Could this be a left over from Big/Little Endian issue between Intel and PowerPC machines? When I created this file I was on a PowerPC. Now I am on Intel. Just a thought ?

Johannes

Duplicating in Finder does not change anything.

Here some Terminal output:

ls -la@ in recall folder and in original folder (no difference):

-rwx--x--x@ 1 admin  staff  1092614 23 Mai  2002 bergkristal1.pict

	com.apple.FinderInfo	     32 



-rwx--x--x@  1 admin  staff  1092614 23 Mai  2002 bergkristal1.pict

	com.apple.FinderInfo	     32

xattr -l in recall folder and in original folder (looks like the same difference like with some other old files):

00000000  50 49 43 54 47 4B 4F 4E 01 00 00 46 FF 51 00 00  |PICTGKON...F.Q..|

00000010  00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00  |................|

00000020



00000000  50 49 43 54 47 4B 4F 4E 80 00 00 46 00 00 00 00  |PICTGKON...F....|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

GetFileInfo in recall folder and in original folder (difference: case of 1st and 8th letter in Attributes):

file: "/private/tmp/InstantRecall.501/QRecall-31387944473/bergkristal1.pict"

type: "PICT"

creator: "GKON"

attributes: Avbstclinmedz

created: 05/23/2002 10:57:09

modified: 05/23/2002 10:57:09



file: "/Volumes/Tscho/Privat/Elke/bergkristal1.pict"

type: "PICT"

creator: "GKON"

attributes: avbstclInmedz

created: 05/23/2002 10:57:09

modified: 05/23/2002 10:57:09

Johannes

While testing I recalled (and restored) three deleted .pict files (old scans). The results are Aliases - at least Finder sees them as Alias, but their size is the same as the .pict-files that I deleted (had to restore them from Time Machine backup). I tried opening those Aliases with different Applications but no luck as Finder insists in seeing them as Aliases. Any idea why they became Aliases when restoring (recalling) them?

Johannes

It seems that a deep scan cleared 70% of the affected files/folders: they are no longer recaptured.

The remaining pdf files could be redeemed by restoring them (as suggested by you)

For the remaining folder I followed your advice too (create it new and move the files over): no more recapture

Now I have only two reluctant folders left. Unfortunately the System will not allow me to fiddle with them as they are "important for the System": Sites and Music. Is there a terminal command to clear their extended finder info?

Johannes

Thanks for all the explanation. I will keep watching the issue.

Can you also tell me what application was used to change the contents of the package?

Mellel (http://www.mellel.com). The file format Mellel uses for its documents is a package containing a gziped xml and images (if any). Normally QRecall (or FSEvents) seems to be dealing fine with them.

Johannes

Thanks again for the quick response (this kind of support is really outstanding!).

OS X didn't detect the change.

Time Machine was able to detect it. Doesn't Time Machine use FSEvents too?

I have two other users who were able to document where files were changed, but never reported by FSEvents. The two things they have in common are (a) they were running Windows in a virtual machine, and (b) the changed file was inside a package.

So I am in (b) too it seems.

QRecall deals with this by periodically ignoring the FSEvent information and preforming a "deep scan" where it examines every file and folder for possible changes?obviously, a much more time consuming process.

Couldn't QRecall simply check the modification time in addition to FSEvents? As the Finder displays the correct modification time it brings up the file with a simple smart search in no time. Just a thought.

The default period is approximately once a week, but you can change this using the QRAuditFileSystemHistoryDays advanced QRecall setting.

Changing this setting to 0.0 brought home the changed file (and produced a ton of "GID different" decisions that choked up the log window).

It would be nice to have an option for a "deep scan" in the Action window. So I would have my longtime and off-site Archives run a deep scan always, while the hourly thing could do without.

Or maybe I should go for always deep scanning. Missing changes is a serious issue for backups.

Johannes

Today I found QRecall missing one file change (a Mellel text file, which is a package with gziped xml inside).

As you can see in the screenshot, the file was first captured at Layer 32 (a few minutes after I created it) and recaptured half an hour later after some changes. After 17:00 I edited the file again (only one word or so) and saved at 17:14 as the modification time of the Finder (right in screenshot) says. But QRecall does not recapture it.

The Log in the console says:
2010-12-12 16:00:03.427 +0100 #debug# CaptureProcessor(Tscho:Privat:Korrespondenz:GEZ.mellel) content assumed stable: inherit package 676866 (10 KB) [2.734118.861.192]
2010-12-12 16:30:03.297 +0100 #debug# CaptureProcessor(Tscho:Privat:Korrespondenz:GEZ.mellel) content assumed stable: inherit package 676866 (10 KB) [2.734118.918.192]
2010-12-12 17:00:03.380 +0100 #debug# CaptureProcessor(Tscho:Privat:Korrespondenz:GEZ.mellel) content assumed stable: inherit package 676866 (10 KB) [2.734118.941.192]
2010-12-12 18:00:03.741 +0100 #debug# CaptureProcessor(Tscho:Privat:Korrespondenz:GEZ.mellel) content assumed stable: inherit package 676866 (10 KB) [2.734118.1154.184]
2010-12-12 18:30:03.403 +0100 #debug# CaptureProcessor(Tscho:Privat:Korrespondenz:GEZ.mellel) content assumed stable: inherit package 676866 (10 KB) [2.734118.1293.192]

To me it looks like QRecall does not detect the change at all.

Johannes