In article <1992Aug2.201320.9109@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes:
quoted text
>
>Hm, this is strange (and seems to happen only on my machine??), anyone
>seen anything similar?
>
>This happens with 0.96bpl2 and 0.96cpl2 (haven't tried 0.97 yet).

It's standard, and it happens on 0.97 too. Explanation to follow...

quoted text
>I make a new group, 'test', give it number - say - 1000, ok, make a
>file, and chgrp it to test. 'ls -l' (or 'v') correctly shows 'test' in
>the group field. But not for long, suddenly (after 30 sec?) it changes
>to something else, gid = oldgid%512; it seems. Which is _very_
>strange. The most remarkable thing about my machine is that it has a
>aha1542 scsi disk controller.

It's not the controller, it's the minix filesystem.  Minix uses only an
8-bit value for the gid value of a file - so although linux internally
(and the extended-fs) can handle real gids, the minix fs cannot.  There
was nothing I could do about it - there simply isn't any room in the
minix inode on the disk.  So when the inode is eventually read back,
only the low 8 bits are correct.  The solution is either to use the
extended filesystem (which is still alpha, might change and might have
bugs) or only use gid's in the 0-255 range. 

Another similar problem you can see with the minix filesystem is that
only the modify-time of a file can be stored on the disk (for the same
reason as the gid problem).  So again, after the inode is read in from
disk, the other times are reset (to the same time as the modification
time).  This problem is harder to see, and as programs seldom use the
other times it's not likely to be a problem. 

                Linus