(Illustration by Gaich Muramatsu)
Hi, I am using several Coda realms and many clients. It has become very annoying that the "numerical uid" corresponding to a Coda account tends to show up as the "local client idea of the so called 'owner' of corresponding files". That is, if I have got a Coda id "bob" in realm RealmA with a Coda id 888 and a Coda id "bb" in realm RealmB with a corresponding Coda id 99999, my files tend to seem to belong to a local users with uids 888 and 99999, depending on the realm. There is absolutely no useful semantics associated with these numbers for any purposes I could imagine. I am using local *nix accounts with uids 1000, 181920 and anything else, which also are totally irrelevant for me! Note, remote realm's internal numerical id is an unrelated thing which a client user (even a "superuser"!) can not override. This behaviour makes some programs and scripts totally crazy - wrong owner, abort / trying and failing to fix ownership, abort / ... I am asking - as I did for a long time - to implement a behaviour more consistent with global filesystem usage, namely stat() to return the local uid of the calling process as the file "owner". The needed change in the kernel module(s) appears to be simple, and I plea for it to be done in upstream. I am a realm administrator, I do not and can not administer Coda clients of my users. Even if I would decide to force them to use my own tweaked kernel module, I couldn't! The historical AFS-like behaviour was inspired by "ALL clients are administered together with ALL servers". That behaviour is incompatible with the global scope of Coda and is now a real pain. It was designed to make broken programs happy, but it makes them break, without any possible workarounds - if you do not administer ALL of the realms AND ALL of the clients involved. Many thanks to the Coda team for all the work, Coda is great, let's fully enjoy its advantages! Regards, -- IvanReceived on 2006-01-31 11:53:03