Re: fs-independent quotas

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Nov 17, 2011 at 05:29:22PM +0100, Manuel Bouyer wrote:
 > I still believe proplib is better. For example, you can go from a
 > 32bit to a 64bit uid_t/gid_t without versionning (in the data structure
 > it's still <integer></integer>).

NO YOU CAN'T. Sorry for shouting, but this really annoys me.

Proplib handles all integers internally as intmax_t, so *it* won't get
confused. (Unless intmax_t gets changed, at which point all
proplib-using syscalls and ioctls need to be versioned, with no clear
way to provide compat logic; that won't be pretty.)

But what happens if you do this and then create a user with e.g. uid
2^40, and try to read its quota information out with the 32-bit quota
utilities? Well, lookee here:

        showuid((uid_t)atoi(*argv));

(quota.c line 179)

boom, silent truncation to 32 bits. If you're lucky. atoi() is allowed
to send you nasal demons in this case, too.

ok, so maybe that's just a bug. What happens if instead you dump all
quota information?

        errx(1, "can't find id in quota entry");

(repquota.c line 294)

Not very helpful, ISTM.

Granted, this is probably not markedly worse than the results if doing
compat the traditional way; but it's no better, either.

Sure, you could update all the tools to anticipate this case, and
dozens or hundreds of other unlikely but potentially possible changes
like this; or you could just send back structs the traditional way,
and when the time comes, if it ever does, version the syscall or the
command codes or whatever in the traditional way. Much less effort
overall.

-- 
David A. Holland
dholland%netbsd.org@localhost