commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcelo Nery dos Santos <marcelo.n...@gmail.com>
Subject Re: [io] FileSystemUtils
Date Tue, 22 Nov 2005 22:11:57 GMT
Most I/O developers are used to deal with "byte[]"s, "int"s and
"long"s in a very strict way. It seems to me that the "long" version
of freeSpace() should really exist to fit more strict needs.

I was wondering what would be the result of a
FileSystemUtils.freeSpace() call over a path with 2GB+ freeSpace. In
fact, I realized that I was wrong from the beginning. Sorry for that.
I was thinking about "int" when saying "long". The 2GB issue would
rise only if we were dealing with "int". As the "long" range is from
-(2^63) to (2^63)-1, there is no issue at all.

However, I saw another point: the "dir /-c" command returns the
available space in bytes, while df on linux return in 1-K blocks (df
default). In other to have well defined semantics, the freeSpace()
method should return the value in an OS independent manner, let say:
in bytes.

Please, check this point, so we do not discuss about unreal data. Once
more, my sincerelly apologies.

Best Regards,

Marcelo

On 22/11/05, Frank W. Zammetti <fzlists@omnytex.com> wrote:
> Would there be, or should I ask, how strong, objections to just changing
> it to return BigInteger, period?  No overloaded versions, no
> artificially-meaningful (although perfectly reasonable) "special" values,
> etc.?  I know it's a change to the public interface and that's not
> generally something that should be done, but it's a fairly new release,
> can we get away with it this time?
>
> If no one beats me to it, I'll try and open a ticket and submit a patch in
> the next day or two, pending thoughts on the question above.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> On Tue, November 22, 2005 4:38 pm, Stephen Colebourne said:
> > This should be raised as a bug in bugzilla, as the existing code will
> > just break if the free space is too large. I propose it should return -1
> > if the free space is too large.
> >
> > To deal with large drives, we should add either a BigInteger returning
> > method, or a freeSpaceMB method (that returns the value in MB!)
> >
> > Patches welcomed to the bugzilla call...
> >
> > Stephen
> >
> >
> > Tim Roberts wrote:
> >> You may be able to use BigInteger (arbitrary precision).
> >>
> >> -----Original Message-----
> >> From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> >> Sent: 22 November 2005 20:35
> >> To: Jakarta Commons Developers List
> >> Cc: commons-dev@jakarta.apache.org
> >> Subject: Re: FileSystemUtils
> >>
> >> Your welcome :) (I wrote that function :) )
> >>
> >> I think your right, a double version would certainly be appropriate.
> >> Kind
> >> of ashamed I missed that actually :(
> >>
> >> I wonder though, what would be the down-side to just having a double
> >> version only? (aside from backward-compatibility at this point)... Would
> >> it really result (potentially) in a loss of precision?
> >>
> >> Feel free to submit a patch, it seems, to me anyway, like an obvious
> >> thing
> >> to commit, although I am not a committer, so you'll have to convince
> >> others :)
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message