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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > >> Sent: 22 November 2005 20:35 > >> To: Jakarta Commons Developers List > >> Cc: [email protected] > >> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
