Hi Ronni, Thoughts in blue ;-)
Cheers Neil -- Neil R. Houghton Albany, Western Australia Tel: +61 8 9841 6063 Email: n...@possumology.com on 20/5/10 11:23 AM, Ronda Brown at ro...@mac.com wrote: > Hi Neil, > > Quick reply your comment >>> 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. > > This will happen if you have removed an account or group from the system, and > still have files on the system that were previously associated with that > account. > Yes, that¹s what I thought in the event that there would be no UID501 account but still files associated with UID 501 that had not been cleared out. > > > This happens because the GID, UID, (user and group identifiers),or UUID > (universally unique identifiers) number associated with the file cannot be > matched to the proper account or group in the system. If the user or group is > missing, the system will associate the file to ³nobody² or ³unknown,² but > sometimes it may think the file belongs to another system account altogether, > and associate it with that one. > > I'm working on a post about Owners / Groups / Permissions will port when I can > put it together. > Looking forward to it! > > > Permissions are so interesting and confusing at the same time ;-) > Yes, I love the power and features of Snow Leopard, but sometimes miss the simplicity of Classic! Can¹t have it both ways, I guess! > > Cheers, > Ronni > > On 20/05/2010, at 10:39 AM, Neil Houghton wrote: > >> 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 -- 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>
