James,

Today I performed a full System volume restore of OSX 10.6.6 using the most recent beta version of QRecall. The restore completed OK....however, after the restore was complete...several applications, like 1Password, begin to experience automatic backup failures with the following error:

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

After researching the error a bit...it seems the following Terminal command will correct this issue:

sudo update_dyld_shared_cache -force

So...all seems well now...however, this error is something I have not seen before after a QRecall restore. I thought you may like to know...

Thanks,

GKG

Gary,

Thanks for that information. I haven't encountered that particular problem, but it makes sense. The dynamic library cache contains resolved copies of the various dynamic libraries in the operation system. As a sanity check, the cache remembers the modification date and the inode (nodeID) of each library file. Following a restore, the nodeIDs of the libraries will be different, causing the OS to ignore the version in the cache.

I need to investigate this a little. Given that the files in /var/db/dyld are cache files, it might make sense for QRecall to simply exclude them from the capture and let the OS rebuild them following the restore.

The man page for update_dyld_shared_cache says

This tool is normally only run by Apple's Installer and Software Update, as they are the only official ways for OS dylibs to be updated. But if for some reason you used another mechanism to alter an OS dylib, you should manually run update_dyld_shared_cache.

Restoring a startup volume from a backup would certainly fall into this category, but it's impractical for QRecall to try and run update_dyld_shared_cache tool following a restore.

James,

I re-ran the same restore using my 2nd favorite backup utility, , Super Duper....and the log clearly indicates that they do indeed fire-off the forced cache update command at the end of their restore routine...I have attached the excerpt from the SD log indicating this activity.

Therefore, the restored system did not, obviously, exhibit the same errors after the SD restore completed...so...I guess incorporating this forced boot cache update in a QRecall restoration, as you referred to before, may be in order...if possible.

Thanks,


GKG