QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Johannes
Forum Index » Profile for Johannes » Messages posted by Johannes
Author Message
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)

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.

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?

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.

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.


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

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

Confirmed: they are restored fine.

Thanks for fixing.

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?


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

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 …

Duplicating in Finder does not change anything.

Here some Terminal output:

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

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

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


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?


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?

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.

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.

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.

Forum Index » Profile for Johannes » Messages posted by Johannes
Go to:   
Powered by JForum 2.1.8 © JForum Team