chown (GNU fileutils) 4.0.27 : problem with --dereference ?

[Maxime Froment]

Our QA team had reported a strange behaviour with chown when using the
--dereference option on a symbolic link in a particular situation. 

Namely, when trying to give ownership of the referenced file to the
owner of the symbolic link by using chmod --dereference on the symbolic
link, nothing even occurs.

For instance (logged in as root):

  # chown --version
  chown (GNU fileutils) 4.0.27
  Written by David MacKenzie.

  Copyright (C) 2000 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  # ls -l
  total 4
  -rw-r--r--   1 user1    users           5 Oct 26 14:33 regularfile
  lrwxrwxrwx   1 user1    users          11 Oct 26 14:34 symlink -> regularfile

  # chown -v user2 symlink ; ls -l
  owner of symlink changed to user2
  total 4
  -rw-r--r--   1 user1    users           5 Oct 26 14:33 regularfile
  lrwxrwxrwx   1 user2    users          11 Oct 26 14:34 symlink -> regularfile

  # chown -v --dereference user2 symlink; ls -l
  owner of symlink retained as user2
  total 4
  -rw-r--r--   1 user1   users           5 Oct 26 14:33 regularfile
  lrwxrwxrwx   1 user2   users          11 Oct 26 14:34 symlink -> regularfile

If my understanding of the option is correct, the last command should
have changed the owner of 'regularfile' to 'user2'.

A quick inspection of the source shows that the ownership of the file
specified on the command line is checked by a call to lstat before the
call to lchown or chown is done; the call to (l)chown is only actually
performed if the new ownership differs from the original ownership. 
It seems that the problem resides in the fact that when the --dereference
option is specified with a symbolic link for argument, the new
ownership will then be compared to the original ownership of the symbolic
link, instead of the original ownership of the target referenced file.

I have included a small patch that seems to correct the above
behavior, but I am not entirely confident on how it rates in terms in
correctness and cleverness (it adds a supplementary call to stat...).

If this is expected behaviour, it is a little puzzling, and it
does not seem to get a justification on the info page. I surely would
like to be enlightened a little bit about it.

Regards,

Maxime Froment

fileutils-4.0.27-chown_dereference.patch
Description: Binary data