Coda File System

a "compatibility" feature which achieves the opposite of its goals :-/

From: Ivan Popov <>
Date: Tue, 31 Jan 2006 17:49:59 +0100

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!

Received on 2006-01-31 11:53:03