Steve,
Many thanks for taking the time to set up the experiment:
I just tried it on a R200 running 7.0.1R1 and I didn't see a problem. I had this quota file:
- user@/vol/vol0 0 0
503 user@/vol/vol0 500M 500K
I turned on quotas
quota on vol0
I created a file as root and chowned it to user 503 and it worked fine. I ran quota report and it was correct.
Notice that the bug report says this:
This problem does not manifest when the command is executed by root.
Indeed...
Are your Unix systems and filer configured to allow non-root users to chown files? It is possible but very unusual, especially if you are using quotas, since than a user could get around a quota by giving his files away. See options wafl.root_only_chown
No, we don't allow non-root chown's, and have no desire to. It was the reference to chgrp and "cp -p" that worried me.
Usually non-root users can only chgrp files and only to a group where the user is a member. If only root can chown and you aren't using group quotas, then I think you should be OK.
Ah! It hadn't occurred to me that the problem with chgrp might only occur if one had per-gid quotas (or even more, a _default_ per-gid quota), rather than per-uid ones. The problem description doesn't actually say that, but it would certainly make sense. We don't use per-gid quotas, so maybe we are OK after all. [*]
What do you make of the reference to "cp -p"? Just that the setting of the owner and/or group might wrongly fail, not the rest of the copying?
[*] And as an afterthought, maybe it's not a new-in-7.x bug after all. My recollection is that the bug descriptions on NOW used to have "reported-in-version" and "probably-in-versions" fields in them, but they don't seem to any longer: just a "fixed-in-version" one :-(