Malcolm Weir wrote:
As a matter of fact, returning -1 *will* make *some* applications magically
work, it *won't* break anything else, and it disambiguates the situation
where you need inodes and you have zero, and you don't need them.
You're forgetting the fact that casting -1 to an unsigned returns A Large
Number...
statfs returns a pointer to a structure using a long value. statvfs
returns a pointer to a structure that uses an unsigned long value (I
think). Sometimes it'll cast and become a large number. Sometimes it
won't. I don't see this behavioral change as "disambiguating" anything.
Seems to be more ambiguous to me...
That's just a kludge to get around a deficiency in the interface.
I'd say the same of Reiser's old behavior. Apparently it used to return
(2^23)-1 as the inode count. The current behavior, and the patch I
submitted, seem to be more in line with the documented behavior.
And I'd note that the docs you refer to simply state that *undefined* values
should return zero. It is entirely reasonable to argue that the number of
available inodes on a Reiserfs is not "undefined", just unpredictable.
To-may-to, to-mah-to
I think, on balance, that Reiserfs would have been better advised to return
(bfree+1) in all cases. That would break nothing, require no special
handling, and fully conform to the wording of the docs.
Bring it up with them, then.
9 messages in net.sourceforge.lists.courier-usersRe: [courier-users] 431 Mail system full
