[camner]

This is not strictly speaking a SuperDuper! issue, as I know (I'm pretty sure) that no matter what volume or user SD! is run from, it will preserve all permissions, ownership, etc. If it's an easy response, I'd appreciate the help. If it's complex, I understand that as this is beyond what SD! is doing and please feel free ignore the question

I'm copying my TM volume as part of rebuilding my system from scratch for Mountain Lion. I'm doing a clean install of Mountain Lion and after the initial install I noticed that all of my disk volumes (and their contents) [except for my new ML boot volume] showed the owner as "Fetching...." (though I still had access because the "staff" group has read/write access).

Doing a search, I learned that this means that the new system doesn't recognize the user id (UID) of these files/folders.

I think I know why. In my old Snow Leopard system, I set up a second administrative user when I was troubleshooting a problem a while back, and just started using the new user (and eventually deleted the troublesome one).

So, the UID for my Snow Leopard user (which created all these files and folders on my other volumes, including my Time Machine volume) has UID = 502. The new ML user I set up has UID = 501. That's why when booted into ML all the owners are "Fetching..." because the new ML user doesn't recognize the old SL user with UID = 502.

The question is how to fix this. I see three options:

1. Don't worry about it, as I have access. But I have read that having the OS constantly trying to figure out the owner of files can be a drag on system speed

2. Use chown to change all the ownership of all my files on the various volumes (or do it through the Finder or Batchmod to apply to enclosed folders). Perhaps I shouldn't be nervous about this, but somehow I don't like the idea of having to traverse the entire TM volume to change the owner of all the 8 million + files....

3. Set up a new administrative user on ML (that will presumably have UID=502) and delete the other user (with UID = 501)

[And yes, I did try repairing permissions with Disk Utility, but that doesn't affect volumes other than the boot volume, of course]

Any advice would be appreciated.