QRecall

So, after a few more tests with the MacBook, it turns out that its RAM is bad in a way that only bothers Leopard, but not Tiger. Which is why I never bothered to check it properly... My bad and sorry all around.

This thread is closed.

James Bucanek wrote:Could you tell me a little about how the previous version of Leopard was installed?

That MacBook's system came about like this:

(Clean) Installed Leopard from a retail family pack on a MacBook Pro (15-inch 2.4/2.2GHz), 2.2GHz Intel Core 2 Duo, 2GB RAM, onto an external Firewire harddrive. Configured the first user.

Moved the Firewire harddrive to a MacBook (13-inch Late 2006), black, 2GHz Intel Core 2 Duo, 2GB RAM, and booted from the Firewire harddrive.

Ran Carbon Copy Cloner (v3.0.1) to copy the system onto the MacBook's internal harddrive.

Booted from the internal harddrive, attached a different Firewire harddrive, which contained my previous 10.4.10 system from the MacBook, and ran the Migration Assistant to move users and applications.

I then also shrunk the internal harddrive's partition to restore a previous Windows Vista NTFS partition (using WinClone).

So, it's not an untainted system...

Hi James,

I owe you an apology. QRecall works fine on Leopard. I just retested with a different machine (Mac Pro), which was clean installed and only modified by hand. The MacBook which caused the problems was also clean installed, but then I used the Migration Assistant to move my apps and prefs over.

Sorry for the "negative" thread. I'll still send you all the logs from the previous runs.

Thanks for such a smooth product.

- Mic

I've sent the logs via email.

James Bucanek wrote:This sounds very similar to a problem reported last week by Frédéric Thomas. That problem only occurs on Mac OS X Server, so these both seem related to specific versions of the operating system.

I also thought it seemed similiar, which is why I thought you'd want the logs...

QRecall seems very well positioned to take over a whole share of backup scenarios. My (admittedly limited) experience backing up Tiger clients makes me feel very comfortable with QRecall. But I think you should make sure it works properly with Leopard soon, otherwise you might lose potential clients to Time Machine, which seems ok for backing up a single machine, but in a network (we have 6 Macs at home) QRecall fits much better, not least due to the duplicate savings.

Just my 2 cents...

I've repeated tried to capture to a MacBook running Leopard to an archive on a network share (RAID on Mac Pro running 10.4.10), but it fails everytime:

2007-11-04 11:10:40.388 +0100 Failure Could not capture SPRX700 Premium Glossy.icc [2.732984.491.15]
2007-11-04 11:10:40.396 +0100 Details File: mbhd:Library:Printers:EPSON:InkjetPrinter:PrintingModule:SPRX700Series_Core.plugin:Contents:Resources:ICCProfiles:SPRX700 Premium Glossy.icc [2.732984.491.15.1]
2007-11-04 11:10:40.396 +0100 Caution Problems processing items [2.732984.491.16]
2007-11-04 11:10:40.396 +0100 Details bad envelope checksum [2.732984.491.16.1.1]
2007-11-04 11:10:40.396 +0100 Details Data exception [2.732984.491.16.1.1.1]
2007-11-04 11:10:40.396 +0100 Details Expected: 0xcc283e3d [2.732984.491.16.1.1.2]
2007-11-04 11:10:40.397 +0100 Subrosa .DataBad: 1 [2.732984.491.16.1.1.3]
2007-11-04 11:10:40.397 +0100 Details Checksum: 0xb6be3e3b [2.732984.491.16.1.1.4]
2007-11-04 11:10:40.397 +0100 Details PkgNumber: 255351 [2.732984.491.16.1.1.5]
2007-11-04 11:10:40.397 +0100 Details Class: FileSource@0x129440(/Volumes/monstro/mic/qrec_leo.quanta/repository.data) [2.732984.491.16.1.1.6]
2007-11-04 11:10:40.397 +0100 Details Pos: 3786083248 [2.732984.491.16.1.1.7]
2007-11-04 11:10:40.397 +0100 Details Length: 32776 [2.732984.491.16.1.1.8]
2007-11-04 11:10:40.397 +0100 Details Path: mbhd:Library:Printers:EPSON:InkjetPrinter:PrintingModule:SPRX700Series_Core.plugin:Contents:Resources:ICCProfiles [2.732984.491.16.1.2]
2007-11-04 11:10:40.397 +0100 Failure Could not process folder ICCProfiles [2.732984.491.16.1]
2007-11-04 11:10:40.402 +0100 #debug# -[DataHash preloadHashCache] stopped [2.732984.491.17]
2007-11-04 11:10:40.692 +0100 #debug# -[NegativeChecksumMap dealloc] released, 67108864 bits, 170349 trues [2.732984.491.18]

Not necessarily on the same file, but it always fails. The disk is fine, so that's not it. When it fails, the console.log notes:

2007/11/04 11:10:40 AM QRecallHelper[491] *** -[NSRecursiveLock dealloc]: lock (<NSRecursiveLock: 0x11d180> '(null)') deallocated while still in use
2007/11/04 11:10:40 AM com.qrecall.scheduler[50] 2007-11-04 11:10:40.692 QRecallHelper[491:2103] *** -[NSRecursiveLock dealloc]: lock (<NSRecursiveLock: 0x11d180> '(null)') deallocated while still in use
2007/11/04 11:10:40 AM QRecallHelper[491] *** Break on _NSLockError() to debug.
2007/11/04 11:10:40 AM com.qrecall.scheduler[50] 2007-11-04 11:10:40.693 QRecallHelper[491:2103] *** Break on _NSLockError() to debug.
2007/11/04 11:10:40 AM QRecallHelper[491] *** Assertion failure in -[CacheHashTransaction dealloc], /Users/james/Development/Projects/Quantum Recall/Common/Source/Repository/Hash/HashTransaction.m:34
2007/11/04 11:10:40 AM com.qrecall.scheduler[50] 2007-11-04 11:10:40.740 QRecallHelper[491:2103] *** Assertion failure in -[CacheHashTransaction dealloc], /Users/james/Development/Projects/Quantum Recall/Common/Source/Repository/Hash/HashTransaction.m:34
2007/11/04 11:10:40 AM QRecallHelper[491] *** -[NSAutoreleasePool dealloc]: Exception ignored while releasing an object in an autorelease pool. exception: 'CacheHashTransaction not closed' invoked method: '*** -[CacheHashTransaction release]' object: 0x1af18d0
2007/11/04 11:10:40 AM com.qrecall.scheduler[50] 2007-11-04 11:10:40.742 QRecallHelper[491:2103] *** -[NSAutoreleasePool dealloc]: Exception ignored while releasing an object in an autorelease pool. exception: 'CacheHashTransaction not closed' invoked method: '*** -[CacheHashTransaction release]' object: 0x1af18d0

(Capturing to the same shared volume from 10.4.10 clients always works.)
I can send you the whole log if you want.

- Mic