More info from BrianH and the esteemed Dr. Blinn, verbatim (from a couple
emails):
Note that once all the appropriate software on Tru64 UNIX had been enabled
for 32 bit UID/GID values, the restriction to 16 bits is ENTIRELY in range
checking logic that's conditionalized; all of the relevant internal data
structures are now using 32 bit data, but the implication is that some of
the values that are stored as negative values in a 16 bit signed
implementation and conflict with larger than 15 bit unsigned values (same
bit pattern) are NOT a problem in the 32 bit internal representation.
There is no real benefit to sticking to the "short" UID/GID method if you
really need the larger values. And by enabling the extended UID/GID
implementation, you have a fully supported system and are less likely to
stumble on some problem in the supported software.
You still have to deal with issues like utilities that can NOT do the 32
bit representation because of interchange requirements to work with
foreign systems (e.g., things like tar or cpio may have to truncate 32 bit
UID/GID values to 16 bits for exchange with a system that only supports 16
bit values). But that's always going to be a problem with exchanging
UID/GID values with systems that do not interpret them the same way your
system interprets them.
---
Almost any MODERN UNIX implementation is going to either already support
32 bit UID/GID values, or has plans to do so in the future. But for
interchange reasons you need to be able to pass just a 16 bit value in
some cases, and some legacy applications might be code to use pure 16 bit
values (and even treat them as signed, which is even more limiting in the
general case). So there are issues, but they are usually manageable
issues, and they are going to show up somewhere in any case. If you're on
Tru64 UNIX and the issue is getting more active user IDs, go with the
extended UID/GID implementation, and then pressure your other suppliers to
implement something compatible. It's really not rocket science :^)
---
cheers and thanks,
________________________________________________________________________
Ian 'Ivo' Veach, imail_at_nevada.edu UCCSN System Computing Services
http://www.nevada.edu/~ivo postmaster/webmaster/sysadmin
________________________________________________________________________
Received on Tue Jul 10 2001 - 16:58:31 NZST