Minor oddities following full restore

[jmsgwd]

Hi, recently my startup disk failed and I had to do a full restore on to my replacement startup disk using a backup previously created by SuperDuper!, and I noticed a few minor oddities. Nothing disastrous, just strange; the restore was basically a success.

Here are the oddities I noticed:
• Users' wallpaper not displaying - I noticed this before when testing backups by booting them
• After booting the restored drive, an application I've never seen before called "Interface Builder" was bouncing in my Dock, which then popped up a dialog:
The document "GoToMarker.nib" could not be opened. An instance of NSProTextField could not be decoded.
• Some songs in my iTunes library had broken references - e.g. instead of referencing the original mp3 file, a song would reference some random file like "/System/Library/Automator/Open Finder Items.action/Contents/Resources/fi.lproj/main.nib/keyedobjects.nib"
• Some of the shortcuts in Finder's Sidebar were broken, possibly due to the same underlying cause

As mentioned above, none of these issues were showstoppers. I could easily reset my wallpaper, rebuild my iTunes library, and recreate the shortcuts in Finder's Sidebar, so everything is working great now.

I just wondered if these are known issues, and if so what causes them?

[dnanian]

The wallpaper is likely an alias that is not resolving as expected - simply repoint to that.

The IB issue was because you had bad (deleted) entries in your Login Items (again, aliases) that resolved to actual files.

The broken iTunes references, well, I'm not sure, but it sounds like the same thing - a bad alias to a file that was moved/different/deleted.

In fact, all of these seem to be that to me...

[jmsgwd]

OK but why does the process of cloning the drive result in good aliases going bad? The path of the file hasn't changed.

It's as if the alias is referring to the file by some kind of id, rather than its path, and this id can change as part of the cloning process, resulting in the alias referring to a completely different file on the cloned drive that happens to have the same id.

Could it be, for example, that the aliases are using hard links (as apparently used by Time Machine (http://arstechnica.com/apple/2007/10/mac-os-x-10-5/14/)) and the inodes of the files (sometimes?) change in the backup, or something weird like that?

[dnanian]

It's basically a very unusual situation. Because they were already "bad" - that is, what they were pointing to was different then their original target (by name/path, or even deleted), and they were using the "file number" to do a secondary reference (which may have been missing/empty). This can be made worse by a different volume name, since the alias includes the volume (so if your restored drive is called "Magic SSD" rather than "Macintosh HD", the situation often triggered).

When the alias finds itself on a different volume with the same conditions, the file number (which can't be recreated with a file-by-file copy) may be reused by some other file, and thus the alias can resolve itself to "something from nothing" or to something different on rare occasion.

Hard links to both files and folders are recreated as expected by SuperDuper, even if the inodes change (as they will). But aliases, being actual files themselves, are copied as-is. Why aliases don't use hard links on OS X is a mystery to me.