Greywolf wrote:
> This is a Feature of NetBSD -- a point where value is actually added.
> IIRC, code was put in where we treat symlink permissions differently
> than standard file permissions.  see symlink(7).

... and that manual page says (on a 1.5 system):

     There are three separate areas that need to be discussed.	They are as
     follows:

	   1.	Symbolic links used as file name arguments for system calls.
	   2.	Symbolic links specified as command line arguments to utili-
		ties that are not traversing a file tree.
	   3.	Symbolic links encountered by utilities that are traversing a
		file tree (either specified on the command line or encountered
		as part of the file hierarchy walk).

   ...

   Commands not traversing a file tree.
     The second area is symbolic links, specified as command line file name
     arguments, to commands which are not traversing a file tree.

     Except as noted below, commands follow symbolic links named as command
     line arguments.  For example, if there were a symbolic link "slink" which
     pointed to a file named "afile", the command "cat slink" would display
     the contents of the file "afile".

|    It is important to realize that this rule includes commands which may op-
|    tionally traverse file trees, e.g.	 the command "chown file" is included
|    in this rule, while the command "chown -R file" is not (The latter is de-
|    scribed in the third area, below).

So by my reading 'chmod file' should also covered by this case, but
'chmod -R directory' would not be.  There are exceptions listed later
in the manual page, but chmod is not one of them.

Also, chown and chgrp get special mention as commands that were
changed to follow symbolic links in 4.4BSD.  Presumably this change
was for consistency with this rule.  Was chmod overlooked?

chmod(1) is certainly implemented as if it is always traversing a file
tree. Charles says that the current chmod(1) behaviour is documented.
Is there more documentation that I've missed, or do I misunderstand
what I've read?

(I still consider the *behaviour* wrong.  If it doesn't match the
current documentation this is easier to argue though than if it does
match the documentation, so the documentation issue is worth resolving
first.)

Regards,

Giles

P.S. If the behaviour has been this way since 4.4BSD there can't be
too many people bitten by this, so I suppose it's a minor issue,
really ...