Le 04/12/2015 16:08, Brian Stansberry a écrit :
On 12/4/15 6:41 AM, Emmanuel Hugonnet wrote:
> Keeping only the relevant parts, remarks inlined :
>>> * for space availability this might depend on the different mount points:
>>> - should we provide it for every path since we wouldn't know in
advance to which mount point each path is on
>> I don't understand this question. How were you planning to get the space
>> availability information?
>> My instinct is the closer this conforms to what the standard java (n)io
>> API provides the better.
> What I mean is that since we don't know to which mount point/drive each path is
using, we would have to define the space availability per
> path instead of as a global metric/value.
I don't think we should try to do any kind of aggregation or analytical work. A path
resolves to a File and a File reports getUsableSpace().
If a user looks at two paths on the same partition and double counts by assuming he can
use that much for each path, that's a user error.
But it's kind of a "duh" kind of error, so long as we document the semantic
(including a reference to the JDK javadoc we rely upon) and are
careful about how the data is presented in any UI. The UI is probably the bigger
> So I was wondering if this is really something that makes sense. Which explains the
next question aka are these informations valuable.
That I don't know, but it seems useful. It provides information that a a user can
then reason with, either well or poorly. It's not rocket
science to reason intelligently though.
I rarely object to not including something that hasn't been specifically asked for
though, so I don't mind not including this if no one
makes a case for it.
Basically we can iterate over the filestore aka partitions/drives so we could display this
info in a centralized point.
>>> - or maybe this info is not that important