how often must file store space attributes be read?
Alan Bateman
Alan.Bateman at oracle.com
Tue Jun 21 07:16:55 PDT 2011
Salter, Thomas A wrote:
>
> FileStore.getUsableSpace says the following (with similar wording in
> FileStore.getUnallocatedSpace):
>
>
>
> The returned number of available bytes is a hint, but not a guarantee,
> that it is possible to use most or any of these bytes. The number of
> usable bytes is most likely to be accurate immediately after the space
> attributes are obtained. It is likely to be made inaccurate by any
> external I/O operations including those made on the system outside of
> this Java virtual machine.
>
>
>
> The phrase "after the space attributes are obtained" seems leftover
> from the earlier implementations that contained a
> readFileStoreSpaceAttributes method.
>
>
>
> Is the intent of this phrase that an implementation could choose to
> read the attributes only when the FileStore object is instantiated?
> Both the UnixFileStore and the WIndowsFileStore objects currently
> reread the attributes on every access to the three space methods.
>
>
>
> We're porting to a system we're it's somewhat expensive to get the
> space attributes and we get all three at once. We'd prefer to read
> them only once. Yet experience has shown that portable applications
> assume that the behavior on Windows or Linux is the behavior they'll
> find everywhere, so unless the docs are very clear, we're force to
> match the Windows and Linux implementations.
>
>
>
The intent is that these methods return an up-to-date result so the
returned values could be different from the values returned if these
methods were involved immediately after obtaining the reference to the
FileStore. Looking at it now, then this could be clearer. I'll create a
bug to make this clearer but it will have to be jdk8 as it's impossible
to change anything in jdk7 now.
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20110621/d042491c/attachment.html
More information about the nio-discuss
mailing list