>> This appears to be intended to prevent non-root from setting sticky
>> bits (except on directories).  However, it has the side effect that
>> given a file owned by non-root with its sticky bit set, then even
>> its owner cannot chmod that file without (irrevocably) clearing the
>> sticky bit.

>> Is it supposed to work this way?  It produces some very odd-looking
>> failure messages from chmod(1).

Incidentally, the resulting failure (EFTYPE) is not one of the
documented-as-possible failures in the manpage for chmod(2).

> Hmm, sticky(8) says the following about directories.  I assume your
> comments was more pointed at directories than at files, and in
> general the behavior is not much different anyway.

No, I was talking entirely about files.  The code specifically exempts
directories from that check.

What happened was, I had a big tree of stuff, only some of which I
owned.  I wanted to make sure the group write bits were set on all the
things I owned....

find . -type f -user mouse ! -perm 010/010 -print | xargs chmod g+w

(this is my private find, which has a souped-up -perm option that takes
a mask and a compare value.)  The chmod fell over on four files, files
which proved to be mode 1444.  I have no idea how they got that way,
but seeing those EFTYPE errors from chmod(1) got me curious, so I went
looking.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B