QRecall

Hi, James!

I haven't seen QRecall active for a really long time. I can't explain why I've let it slide for so long (maybe it got lost and forgotten in the "I'd better take care of that soon" section of the troubleshooting pile in my brain). I had trouble connecting to one of my hard drives last night and once I finally got it connected, I asked myself how it was being backed up. The answer was it wasn't (except online). So I thought I'd launch QRecall and see if I could get it working.

It installed some software on first launch and then reported:
Some services (Scheduler) are not responding. Quit and relaunch the QRecall app. If that doesn't resolve it, try restarting the system.

After multiple relaunches and restarts, I still get the same report. In the log, stretching back as far as it goes, are reports of: Unexpected problem; scheduler stopping immediately.

I've attached the current log file.

Thanks much,

Steve A.

Sorry, James. That's why I included the quotes around "seems" in the subject. I didn't want to imply that I was accusing QRecall, just that it occurred during QRecall processes.

Disk Utility thinks the disk is okay. I will try the Recover process again this weekend. It ran happily for 13 hours until I had to abort to bring my computer to work.

I'll let you know the results of the experiment.

Hi, James.

For a while now, 5 of my 7 archives have been in a damaged state. I attribute this primarily to the fact that the disk they are on is full and I haven't had the time to devote to pruning it. What I had hoped to do was get them functioning one at a time and then perform a Compact on each and see if that freed up enough space to continue to function.

The problem is that whenever I attempt a Repair, the process runs for a while and then multiple disks are ejected improperly?the drive on which the work is being done and one or another of others attached. (This will also occasionally occur when some scheduled action is being taken on one of the archives.) And at this point, the drives appear to be unmountable (they don't appear in Disk Utility) until after a restart.

I will probably move one of the damaged archives to another drive and see if I can repair it there and if that removal leaves enough room on the original drive to get the other archives repaired. But my point is that I don't think QRecall should ever cause a disk to unexpectedly eject, no matter what's going on.

Let me know if you want to look into this further and if my plans are appropriate.

Thanks!

Thanks, James!

Understood.

Hi, James.

Same message, different problem. And a new one. This is on a capture of my entire internal drive.

Action	2020-04-27 03:14:44	       	    volume 0

Action	2020-04-27 03:14:44	       	      Library/Application Support

Action	2020-04-27 02:03:58	       	        folder com.apple.TCC

Action	2020-04-27 02:03:58	Caution	          Unable to read extended attribute data

Action	2020-04-27 02:03:58	       	            path: /.vol/.com.qrecall.snap/0/Library/Application Support/com.apple.TCC

Action	2020-04-27 02:03:58	       	            xattr: com.apple.rootless

Action	2020-04-27 02:03:58	       	            errno: 1

Action	2020-04-27 03:14:44	       	      private/var/db/fpsd/dvp

Action	2020-04-27 02:32:30	       	        file 0x733A06F1C365790885C699239346BD73

Action	2020-04-27 02:32:30	Failure	          Could not capture file

Action	2020-04-27 02:32:30	       	            cannot open file

Action	2020-04-27 02:32:30	       	              flags: 0x0000

Action	2020-04-27 02:32:30	Minutia	              POSIXErr: 1

Action	2020-04-27 02:32:30	       	              ErrDescription: Operation not permitted

Action	2020-04-27 02:32:30	Minutia	              Path: /.vol/.com.qrecall.snap/0/private/var/db/fpsd/dvp/0x733A06F1C365790885C699239346BD73

The log tells me to "Use Capture Assistant," but not how. (I tried to use it to back up the errant folders, but got the same error message.)

Thanks!

Before deleting anything, I installed the update and did a safe mode startup and restart. Since then, all appears well.

Best wishes,

Well, my QRecall is now up to date (what, did you drop a new version after I posted? ;0)

I recently moved to a new computer, which is when the pestering to give authorization began. The disk is (and was) AFPS. Is there a way to reset the warning db's to see if QRecall still wants authorization? (Code 42 told me there was no way for Crashplan to know if I've granted permission, so I should click the don't-bug-me-anymore button; that's why I did it with QRecall.) Should I do that before I delete /Library/PrivilegedHelperTools/com.qrecall.hoist ?

Thanks, James.

Hi, James.

I was just guessing. This may have nothing to do with it: I did grant full disk access, but had this issue. So I restarted and tried again. Same issue. Removed permission, exited Preferences and then re-granted access. Same issue. Deleted QRecall from the Full Disk Access preference, then re-added. No luck. (QRecall had been asking me to grant permission every time I launched it. I click the don't nag box.)

Action	2019-04-21 01:44:01	       	  Capture issues

Action	2019-04-21 01:46:32	       	    volume /

Action	2019-04-21 01:46:32	       	      Users/xxx/Library

Action	2019-04-21 01:44:38	       	        Preferences

Action	2019-04-21 01:44:09	       	        folder Mail

Action	2019-04-21 01:44:09	Caution	          Unable to read extended attribute data

Action	2019-04-21 01:44:09	       	            path: /Users/xxx/Library/Mail

Action	2019-04-21 01:44:09	       	            xattr: com.apple.FinderInfo

Action	2019-04-21 01:44:09	       	            errno: 1

Action	2019-04-21 01:44:09	Caution	          Unable to read extended attribute data

Action	2019-04-21 01:44:09	       	            path: /Users/xxx/Library/Mail

Action	2019-04-21 01:44:09	       	            xattr: com.apple.quarantine

Action	2019-04-21 01:44:09	       	            errno: 1

Action	2019-04-21 01:44:17	       	        folder Suggestions

Action	2019-04-21 01:44:17	Caution	          Unable to read extended attribute data

Action	2019-04-21 01:44:17	       	            path: /Users/xxx/Library/Suggestions

Action	2019-04-21 01:44:17	       	            xattr: com.apple.metadata:com_apple_backup_excludeItem

Action	2019-04-21 01:44:17	       	            errno: 1

Action	2019-04-21 01:44:37	       	        folder PersonalizationPortrait

Action	2019-04-21 01:44:37	Caution	          Unable to read extended attribute data

Action	2019-04-21 01:44:37	       	            path: /Users/xxx/Library/PersonalizationPortrait

Action	2019-04-21 01:44:37	       	            xattr: com.apple.metadata:com_apple_backup_excludeItem

Action	2019-04-21 01:44:37	       	            errno: 1

Action	2019-04-21 01:44:38	       	        folder Cookies

Action	2019-04-21 01:44:38	Caution	          Unable to read extended attribute data

Action	2019-04-21 01:44:38	       	            path: /Users/xxx/Library/Cookies

Action	2019-04-21 01:44:38	       	            xattr: com.apple.quarantine

Action	2019-04-21 01:44:38	       	            errno: 1

Should I not worry about this and learn to live with the yellow light on that archive?

On another note, is there any chance you could teach the Monitor and Status Windows to remember their positions and which monitor to appear on?

Many thanks,

Hey, James!

Loving the interface changes. It's really looking beautiful.

I seem to recall seeing something in the notes about the last update that changes were made to make QRecall OS 10.8 compatible. Have you tested it under the release version?

If it's all looking good, I suggest you add QRecall the the compatibility chart at http://roaringapps.com/apps:table . It doesn't appear on the list (even for 10.7 compatibility).

Best wishes,

Hi, James.

I've been having verify failures pretty consistently on a few large archives. I haven't bothered you with them since "Repair" has taken care of the problem. This time the software asked that I contact the developer. So I'm attaching an excerpt from the log with the rather sad sounding exception, "Failure failed."

Best wishes,

Ah, yes. My eyes crossed while cross referencing the built-in log with the console log. That was the "cannot convert FSRef to path" problem. I will try the preallocation bug setting changes if it comes up again.

The permissions entries are (I think):

2010-03-29 03:27:00.425 -0400 ------- Compact G5_whole.quanta [2.733860.11416]

2010-03-29 03:27:00.427 -0400 Details archive: /Volumes/WD Green (QR)/G5_whole.quanta [2.733860.11416.5]

2010-03-29 03:27:00.427 -0400 #debug# executing [2.733860.11416.6]

2010-03-29 03:27:04.026 -0400 Failure Failed [2.733860.11416.7]

2010-03-29 03:27:04.027 -0400 Details could not create lock file [2.733860.11416.7.1]

2010-03-29 03:27:04.027 -0400 #debug# IO exception [2.733860.11416.7.1.1]

2010-03-29 03:27:04.027 -0400 #debug# API: createFileAtPath: [2.733860.11416.7.1.2]

2010-03-29 03:27:04.027 -0400 Details Path: /Volumes/WD Green (QR)/G5_whole.quanta/.lock [2.733860.11416.7.1.3]

2010-03-29 03:27:04.028 -0400 #debug# OSErr: 22 [2.733860.11416.7.1.4]

2010-03-29 03:27:04.028 -0400 Details Permissions: 0x0180 [2.733860.11416.7.1.5]

2010-03-29 03:27:04.028 -0400 #debug# Class: RepositoryPackage [2.733860.11416.7.1.6]

2010-03-29 03:27:04.029 -0400 #debug# caught exception [2.733860.11416.8]

2010-03-29 03:27:04.029 -0400 Details could not create lock file [2.733860.11416.8.1]

2010-03-29 03:27:04.029 -0400 #debug# IO exception [2.733860.11416.8.1.1]

2010-03-29 03:27:04.029 -0400 #debug# API: createFileAtPath: [2.733860.11416.8.1.2]

2010-03-29 03:27:04.029 -0400 Details Path: /Volumes/WD Green (QR)/G5_whole.quanta/.lock [2.733860.11416.8.1.3]

2010-03-29 03:27:04.030 -0400 Subrosa .Command: compact [2.733860.11416.8.1.4]

2010-03-29 03:27:04.030 -0400 #debug# OSErr: 22 [2.733860.11416.8.1.5]

2010-03-29 03:27:04.030 -0400 Details Permissions: 0x0180 [2.733860.11416.8.1.6]

2010-03-29 03:27:04.030 -0400 #debug# Class: RepositoryPackage [2.733860.11416.8.1.7]

2010-03-29 03:27:04.031 -0400         Compact failed [2.733860.11416.9]

2010-03-29 03:27:04.031 -0400         A network or disk error was encountered. [2.733860.11416.9.1]

2010-03-29 03:27:04.031 -0400 ------- Compact incomplete (00:00) [2.733860.11416.10]

Yep, that's got good-ol' 0x0180.

Thanks!

That's usually a permissions problem, but not always. Without the error code reported I can only guess.

I think I've got the relevant log portion:

2010-03-29 02:00:01.293 -0400 ------- Capture to iTunes (BB2).quanta [2.733860.11197]

2010-03-29 02:00:01.293 -0400 Details archive: /Volumes/WD Green (QR)/iTunes (BB2).quanta [2.733860.11197.4]

2010-03-29 02:00:01.293 -0400 #debug# executing [2.733860.11197.5]

2010-03-29 02:00:01.350 -0400 #debug# preallocation failed [2.733860.11197.6]

2010-03-29 02:00:01.350 -0400 Details preallocation [2.733860.11197.6.1]

2010-03-29 02:00:01.350 -0400 #debug# IO exception [2.733860.11197.6.1.1]

2010-03-29 02:00:01.351 -0400 #debug# API: FSAllocateFork [2.733860.11197.6.1.2]

2010-03-29 02:00:01.352 -0400 #debug# OSErr: -50 [2.733860.11197.6.1.3]

2010-03-29 02:00:01.353 -0400 Details Length: 33554432 [2.733860.11197.6.1.4]

2010-03-29 02:00:01.353 -0400 Details Pos: 70498842360 [2.733860.11197.6.1.5]

2010-03-29 02:00:01.353 -0400 Details File: /Volumes/WD Green (QR)/iTunes (BB2).quanta/repository.data [2.733860.11197.6.1.6]

2010-03-29 02:00:01.353 -0400 #debug# preallocation failed [2.733860.11197.7]

2010-03-29 02:00:01.353 -0400 Details preallocation [2.733860.11197.7.1]

2010-03-29 02:00:01.354 -0400 #debug# IO exception [2.733860.11197.7.1.1]

2010-03-29 02:00:01.354 -0400 #debug# API: FSAllocateFork [2.733860.11197.7.1.2]

2010-03-29 02:00:01.355 -0400 #debug# OSErr: -50 [2.733860.11197.7.1.3]

2010-03-29 02:00:01.355 -0400 Details Length: 2097152 [2.733860.11197.7.1.4]

2010-03-29 02:00:01.356 -0400 Details Pos: 70498842360 [2.733860.11197.7.1.5]

2010-03-29 02:00:01.356 -0400 Details File: /Volumes/WD Green (QR)/iTunes (BB2).quanta/repository.data [2.733860.11197.7.1.6]

2010-03-29 02:00:01.356 -0400 #debug# RepositoryPackage received kPreallocationFailedNotification [2.733860.11197.8]

2010-03-29 02:00:01.532 -0400 Failure Failed [2.733860.11197.9]

2010-03-29 02:00:01.532 -0400 Details cannot convert FSRef to path [2.733860.11197.9.1]

2010-03-29 02:00:01.532 -0400 #debug# IO exception [2.733860.11197.9.1.1]

2010-03-29 02:00:01.532 -0400 #debug# API: FSRefMakePath [2.733860.11197.9.1.2]

2010-03-29 02:00:01.532 -0400 #debug# OSErr: -35 [2.733860.11197.9.1.3]

2010-03-29 02:00:01.537 -0400 #debug# caught exception [2.733860.11197.10]

2010-03-29 02:00:01.538 -0400 Details cannot convert FSRef to path [2.733860.11197.10.1]

2010-03-29 02:00:01.539 -0400 #debug# IO exception [2.733860.11197.10.1.1]

2010-03-29 02:00:01.539 -0400 #debug# API: FSRefMakePath [2.733860.11197.10.1.2]

2010-03-29 02:00:01.539 -0400 Subrosa .Command: capture [2.733860.11197.10.1.3]

2010-03-29 02:00:01.539 -0400 #debug# OSErr: -35 [2.733860.11197.10.1.4]

2010-03-29 02:00:01.539 -0400         Capture failed [2.733860.11197.11]

2010-03-29 02:00:01.540 -0400         A network or disk error was encountered. [2.733860.11197.11.1]

2010-03-29 02:00:01.541 -0400 ------- Capture incomplete (00:00) [2.733860.11197.12]

James, I thank you again for your devotion to the software and support of your customers.

James:

I'm seeing repeated failures to multiple archives. As we've seen in the past it's probable that QRecall is not the cause, but I'm hoping we can eliminate it before I turn to other more expensive options.

The reported problems range from:

icon reference does not reference a data package

which leads to:

The archive data is damaged or incomplete....

This is, of course, my big archive at about 237gb. I have run repairs on the archive which have always completed successfully, leaving a "Damaged" layer that does not seem to be delete-able. Last night I had a verify with the "icon reference" error, followed by a successful capture. (Why doesn't a verify failure prevent further unattended actions on an archive?)

Previous to that I had a compact fail on the same archive with:

could not create lock file

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Path: /Volumes/XXX/xxx.quanta/lock

     Permissions: 0x0180

And on a different archive, a capture lead to:

cannot convert FSRef to path

which lead to:

A network or disk error was encountered.

Note that this is a different archive, but written on the same drive as the previously mentioned archive.

Like I said, I would not discount the possibility that this is a drive, enclosure, or Firewire controller -caused problem, but I need to start somewhere.

Also, at this time I don't have any disks with enough available space to do a Repair & Copy of the archive.

Thanks!

James:

Thank you for all of your extra efforts! I finally gave up trying to save the sinking ship that was that OS install and did a new Erase & Install. I kept thinking that if I could just fix this one thing it would be so much quicker than doing a new install. But then there was another thing. And a thing after that. And two days later I devoted half a day to a new install.

Things are much better now. It's always reassuring to know that it's me and not your software.

Thanks again.

A little knowledge, etc....

So, I flipped my user to 501 from 503 and then did a find command to assign 503's files to 501. Yeah me.

However, at that point all the complaints that used to be about 501 were now occuring about 503. So I created a new user and assigned it to 503.

Finally the launchd.peruser getpwuid failed messages stopped.

I'm not sure my problems are solved, though, because QRecall is now complaining about not being able to create files:

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.404 -0400 Failure could not open standard log; logging to stderr [3.733848.100.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.411 -0400 Failure recursive attempt to create LogFileLogger [3.733848.100.2] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.412 -0400 #debug# IO exception [3.733848.100.2.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.413 -0400 Failure Cannot create support folder [3.733848.100.3] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.415 -0400 Details Folder: /Users/trashed/Library/Logs [3.733848.100.3.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.426 -0400 Details Enclosing folder: /Users/trashed/Library [3.733848.100.3.2] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.454 -0400 Details NSFileReferenceCount: 23 [3.733848.100.3.2.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.464 -0400 Details NSFileModificationDate: 2010-03-17 13:10:49 -0400 [3.733848.100.3.2.2] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.485 -0400 Details NSFileSystemFileNumber: 5439999 [3.733848.100.3.2.3] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.488 -0400 Details NSFileGroupOwnerAccountName: staff [3.733848.100.3.2.4] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.489 -0400 Details NSFileType: NSFileTypeDirectory [3.733848.100.3.2.5] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.491 -0400 Details NSFileOwnerAccountID: 507 [3.733848.100.3.2.6] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.493 -0400 Details NSFileExtensionHidden: 0 [3.733848.100.3.2.7] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.498 -0400 Details NSFileCreationDate: 2008-03-31 21:52:51 -0400 [3.733848.100.3.2.8] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.502 -0400 Details NSFileGroupOwnerAccountID: 20 [3.733848.100.3.2.9] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.524 -0400 Details NSFilePosixPermissions: 448 [3.733848.100.3.2.10] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.539 -0400 Details NSFileSize: 782 [3.733848.100.3.2.11] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.555 -0400 Details NSFileSystemNumber: 234881027 [3.733848.100.3.2.12] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.556 -0400 Failure could not open standard log; logging to stderr [3.733848.100.4] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.558 -0400 Failure Cannot create support folder [3.733848.100.5] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.579 -0400 #debug# IO exception [3.733848.100.5.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.581 -0400 Details Folder: /Users/trashed/Library/Logs [3.733848.100.5.2] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.589 -0400 #debug# started Scheduler-1.1.4-Dec 11 2009 [3.733848.100.6] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.590 -0400 #debug# port: QRecallScheduler [3.733848.100.6.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.592 -0400 #debug# uid: 503 [3.733848.100.6.2] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.593 -0400 #debug# euid: 503 [3.733848.100.6.3] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.595 -0400 #debug# ppid: 95 [3.733848.100.6.4] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.613 -0400 #debug# os: Version 10.5.8 (Build 9L31a) [3.733848.100.6.5] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.615 -0400 #debug# arch: ppc [3.733848.100.6.6] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.623 -0400 #debug# DiskAppeared /dev/disk2s3 [3.733848.100.7] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.628 -0400 #debug# added volume 'WD Green (QR)' [3.733848.100.7.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.634 -0400 #debug# DiskAppeared /dev/disk2s5 [3.733848.100.8] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.642 -0400 #debug# added volume 'WD Green 2' [3.733848.100.8.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.644 -0400 #debug# DiskAppeared /dev/disk0s3 [3.733848.100.9] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.645 -0400 #debug# added volume 'New Mac G5 HD' [3.733848.100.9.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.647 -0400 #debug# DiskAppeared /dev/disk0s5 [3.733848.100.10] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.649 -0400 #debug# added volume 'TBD' [3.733848.100.10.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.655 -0400 #debug# DiskAppeared /dev/disk1s3 [3.733848.100.11] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.657 -0400 #debug# added volume 'Big Brother 1' [3.733848.100.11.1] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.659 -0400 #debug# DiskAppeared /dev/disk1s5 [3.733848.100.12] 

3/17/10 1:13:19 PM QRecallScheduler[100] 2010-03-17 13:13:19.661 -0400 #debug# added volume 'Big Brother 2' [3.733848.100.12.1] 

3/17/10 1:13:20 PM QRecallScheduler[100] 2010-03-17 13:13:20.259 -0400 #debug# user logout [3.733848.100.13] 

3/17/10 1:13:22 PM com.apple.launchd[1] (com.qrecall.scheduler[123]) Exited with exit code: 3 

3/17/10 1:13:22 PM QRecallScheduler[100] 2010-03-17 13:13:22.308 -0400 #debug# user logout [3.733848.100.14]

I can't tell if my OS is worse off or better after all my attempts. I'm not getting the recurring quicklook and mdworker crashes. I'm seeing some entries in the log that make me nervous, but I have no idea if they've been going on for years since I never before spent so much time in Console.

Yours,