Hello Otto,
Philip is right. It's embarrassing I haven't checked the case with hard
quota myself.
We'll look into it. Philip is actually suggesting the way. I suppose he
doesn't have time to implement it himself, does he? Don't want to work on
something he is already working on.
What about our second patch?
Friday, January 2, 2015, 2:38:23 PM, you wrote:
OM> On Tue, Dec 30, 2014 at 02:37:58PM -0600, Boris Goldberg wrote:
>> Hello tech,
>>
>> Is there a particular reason why that path hasn't been committed? It's
>> not in the cvs tree and the bug is reproducible on the latest snapshot.
>> It's the first patch we are trying to commit and we might not understand
>> some internal development mechanics.
OM> Hi,
OM> we discussed the first diff and Philip Guenther made this comment
OM> below. Although I was originally ok with the diff, I now think
OM> Philip's point is valid. Care to investigate this further and comment
OM> on this?
>> It doesn't make sense to me. The creds argument is used here to control
>> things like whether to uprintf() a "write failed, %s disk limit reached"
>> message. With this change, won't root be unable to chown a file to a user
>> that would putting them over a hardlimit? That seems wrong.
>>
>> I think the issue is that when run as root,
>> ufs_quota_alloc_{blocks,inode}2() skip the calls to chk[di]qchg() where
>> the dq_[bi]time values are reset. We need those times to be reset, even
>> when the chown is being done by root, right?
>>
>>
>> Philip
--
Best regards,
Boris mailto:[email protected]
