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.
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
