QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Steven M. Alper
Forum Index » Profile for Steven M. Alper » Messages posted by Steven M. Alper
Author Message
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, James!


Hi, James.

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

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

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

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

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

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:

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


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:

    which leads to:

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:

And on a different archive, a capture lead to:

which lead to:

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.


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:

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.

James Bucanek wrote:The reinstall may be the source of the problem, and some of the similar messages you've gotten from other software. My first question is "do you have a user account with a UID of 501?"

The message would appear to indicate that you do not. Since UID 501 is assigned to the first account create by the system, this might happen if you installed a new OS, create a new account, then delete the original one created by the system.

The original problems occurred before my egregious sin, but you've hit the nail on the head. I did a clean install of the OS, creating a new user so that I could do all the updates prior to migrating my old data. Setup Assistant wants to do the migration immediately after the install, and since my quicklook and mdworker issued had not been repaired when I followed that path I wanted a completely "modern" version of the OS to start on.

And then I went ahead and deleted that first user. DOH!

If you have no user 501, the solution might be simple. You'll need to edit the file /Library/LaunchDaemons/com.qrecall.scheduler.kickstart.plist.

That may solve the QRecall problem, which I assume is only a symptom of the much larger problem I discovered shortly after I wrote you: because of the client uid validation problem, the existing users don't have proper permissions. Meaning no write permissions, despite appearing as if they do. If I figure out how to restore those, which I'm guessing has to do with renumbering the users or shifting my primary one to the 501 slot, won't the QRecall problem go away?

I'm off in search of that solution. (Of course, I'll be checking here in case you've got one for me

Thanks, James!
Forum Index » Profile for Steven M. Alper » Messages posted by Steven M. Alper
Go to:   
Powered by JForum 2.1.8 © JForum Team