Hi Ronni, HeHe... Yes, I¹ve always been wary of the ³expert² tag I used to work in an industry with lots of ³experts² and the standing joke was something about a ³spurt² being a drip under pressure and ³ex² meaning has-been ;o)
However, all on the list appreciate your experience and the time you put into your (very comprehensive) answers to various problems. Yes, of course, either approach will require Adam to have a complete backup of his old drive and we agree that approach A is preferable, if more time-consuming. It would be interesting to know just how approach B gets around the change of UID I always thought that ³repair permissions² would just change the actual read/write/execute permissions I didn¹t think it would change the UID. It occurs to me that a ³B2² approach, that would cover this, would be to create a temporary account to free up UID 501, eg: B2. Steps 1 to 4 are additional steps to free-up UID 501, steps 5 to 10 are basically as your original approach B: > 1. Create a NEW temporary Administrator Account (should have UID 502) > 2. 'Log out' of the OLD Administrator (wrong) Account (UID 501) > 3. 'Log In' to the TEMP Account (UID 502) > 4. DELETE the OLD Account (UID 501) > 5. Create a NEW Administrator Account with exact details of the User Account > that you have on the backup drive (should be allocated UID 501, which is now > free) > 6. 'Log out' of the TEMP Account. (UID 502) > 7. 'Log In' to the NEW Administrator Account (UID 501) > 8. DELETE the TEMP Account (UID 502) > 9. Transfer your Data across from the Backup Drive. This should achieve the same as approach B but allow the new account to have UID 501 One problem might be at step 5 if deleting the old UID 501 user account has not deleted ALL files with owner 501 then the new account may be allocated a new UID (503) - I think this sort of situation is where you can see the ³unknown² user when looking at permissions in finder. Just my thoughts as I say, I still find many aspects of permissions confusing I am basing the above on bits and pieces of my (failing) memory from sorting out past problems I had. Cheers Neil -- Neil R. Houghton Albany, Western Australia Tel: +61 8 9841 6063 Email: n...@possumology.com on 19/5/10 2:19 PM, Ronda Brown at ro...@mac.com wrote: > Hi Neil, > > I have not been avoiding your questions, just time has not permitted me to > answer as yet. I will get back with a more thorough answer to 'Permissions' in > Snow Leopard when possible. Also I don't profess to be an expert on > Permissions, I don't profess to be an expert in anything ;-) > > When you start up a brand new Mac, or start up after an Erase and Install, you > will be asked if you want to migrate. > That is the preferred time to migrate from your old Mac or backup to your New > Mac or New Hard Drive. > > I would prefer Adam to do A. To do and Erase & clean Install of SL & then let > Migration Assistant run & migrate everything across, which will bring his User > Account / Settings & Files across. > > With way B. You DELETE the OLD (wrong) Administrator Account BEFORE you > transfer the data across from the backup drive. > This way, when you then 'Repair Permissions', the User should (hopefully) have > the correct permissions on his data. > I have done it this way before and I'm fairly sure the UID was 501 At least > I did not experience any permission problems. > But, I'm open to anyone disagreeing with this. > > Of course neither of these ways will be possible if Adam doesn't have a > complete backup of his old drive! > > Cheers, > Ronni > > On 19/05/2010, at 10:47 AM, Neil Houghton wrote: > >> Hi Ronni & Adam, >> >> I have been following this with interest I have had to sort out permissions >> problems in the past, I generally get there in the end, but I still find many >> aspects of permissions confusing. >> >> >> I am hoping that Ronni could clarify how one area works: >> >> >> I can see how approach A works this is basically just like taking home a >> new computer and migrating the data over from the old computer. >> >> With approach B, however how does the UID get back in sync or does OSX work >> around that? >> >> To elaborate on my query: >> >> * It sounds like the old computer was set up with just the primary user >> account, which would have had the default UID of 501 for the main account >> this is the account now on the back-up disk that we want to restore. >> * The technician set-up one main account on the new HD which is therefore >> also UID 501 but with other details wrong (as per Adam¹s id printout: >>>> admins-imac:~ adam3$ id >>>> uid=501(adam3) .............. >> * If Adam creates a NEW Administrator Account with exact details of the User >> Account that he has on the backup drive it will presumably get a UID of 502 >> (501 is already taken) - so the exact details may be the same but the UID >> will be different. >> * When Adam DELETES the OLD Account he is deleting the account currently >> with UID 501. >> >> >> So this is where I am unclear as to how things proceed: >> >> * Would deleting account UID 501 result in the new account getting its UID >> re-assigned from 502 to 501? or >> * Would migrating over the OLD account UID 501 result in the new account >> getting its UID re-assigned from 502 to 501? or >> * Would the new account retain the UID 502 but the migrated files get their >> ownership modified to suit this? or >> * I¹m missing the point, what happens is ........ >> >> If the (new) main account has UID 502, would there be any problems at the >> next migration to a new computer (with main account UID 501)? >> >> >> Ronni, I hope you don¹t mind me jumping in with these questions but I know >> that many of us find permissions intricacies somewhat confusing. >> >> >> I know I had big problems in the past when I set up a new computer with an >> account that was ALMOST the same as the old one! (I can¹t remember now >> whether the short names were the same but the user names different, or >> vice-versa, or names the same but UIDs different) - I remember it was a >> painful process sorting it out. >> >> >> Cheers >> >> >> >> Neil -- The WA Macintosh User Group Mailing List -- Archives - <http://www.wamug.org.au/mailinglist/archives.shtml> Guidelines - <http://www.wamug.org.au/mailinglist/guidelines.shtml> Unsubscribe - <mailto:wamug-unsubscr...@wamug.org.au>
