Is diskspace() limited by the 2gb limits?

[stanlyn]

Hi,

When testing
?DISKSPACE("\\mymachine\r-drive$",2)

it returns 7.068E+11

Is there a way to convert that to a meaningful number?

If I map it to R:, and run ?DISKSPACE("R:",2)
I get -1

The drive has about 400gb free...

Thanks,
Stanley

 

[stanlyn]

Yes it looks like its a VFP 2gb limitation.

Found a solution at UT...

https://www.universalthread.com/ShowHeaderArticleOneItem.aspx?ID=7847

Thanks,
Stanley

 

[Olaf Doschke]

You're answering your own question 7*10^11 is much larger than 2GB.

And quoting the help "If an error occurs when reading the hard disk drive or volume, DISKSPACE( ) can also return a value of –1." So there is some problerm retrieving the disc space of a mapped drive for you. It's not a general limitation of VFP, but could be due to timeouts, for example.

Using API should solve that, true. (The UT code is making use of GetDiskFreeSpaceEx besides other API functions).

Bye, Olaf.

 

[stanlyn]

>> it returns 7.068E+11

Is there a way to convert this into an absolute number, instead of an approoximation? If so, please explain as I need to understand this as I ran into it at other places. I now this much... 7.068 * (10^11) Does the E have a value of just an expression?

Thanks,
Stanley

 

[Olaf Doschke]

Don't you know scientific notation? E+11 means *10^11 and it is a number, there is no conversion needed.

This neverhteless IS a number. If you know the number of bytes needed, you can simply compare, if DISKSPACE()>bytesneeded, there is no conversion needed.
For display in kB divide by 1024, in MB another division by 1024, in GB another division by 1024. But it's not necessary to convert this at all, it's a number of bytes.

Bye, Olaf.

 

[Mike Lewis]

If you want to display a number such as 7.068E+11 in a more familiar format, you could so this:

[tt]x = 7.068E+11 && or whatever
? TRANSFORM(x, "999,999,999,999,999,999")[/tt]

But it won't give you any more information, and I'd argue that 7.068E+11 is easier to understand, because you can see at a glance the order of magnitude.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dbMark]

E represents "exponent". The value 2 GB would be represent as approximately 2.1*10^9

The reason VFP files are limited to 2 GB (2^31-1)is that VFP is a mostly a 32-bit system. (Over 10 years ago Microsoft decided to end development and not to upgrade it to 64-bit.) Since VFP uses signed 32-bit numbers that means only 31 bits is available for file size and a number of other system limits.

 

[Olaf Doschke]

Indeed, dbMark,

7*10^11 already is about 350 times as much, about 700G. And that should be clear by now.

The file size limitations are only limitations about files VFP can create or work with. It's an address space limitation of 32bit addressing, but it's not at all a limitation of how large numbers can be, which VFP can work with. See "Visual FoxPro Data and Field Types", float: up to 1E20, or double float: up to ~ 1E308. Thats not only a factor of 34, it is 299 magnitudes larger than 10^9.

Besides you can work with larger files than 2GB as I also already showed in thread184-1613571. Look at the second last post. Win API WriteFile can work on and create larger files. You still can't do >2GB DBFs without changing file specifications in certain places to use 64bit instead of 32bit offsets. THAT is what limits the DBF file size. You could easily write out headers having 2 bytes more at certain places and create records with 8 byte per memo field as address offsets in fpts. etc etc, but the VFP runtime couldn't work with such files.

Bye, Olaf.

 

[Mike Lewis]

Besides you can work with larger files than 2GB .... Win API WriteFile can work on and create larger files.

I've successfully used the File System Object (part of Windows Scripting Host) to create, read and write files larger than 2 GB. It's very easy to use, but rather slow. I've published some sample code on HexCentral.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Now, if you TRANSFORM both the DISKSPACE result and the number of bytes needed to avoid the scientific notation with exponents, you should be aware, that the result of the TRANSFORMS are strings, and strings of numeric values compare in "strange" ways, if you look at it from the human perspective, but in very straight forward mechanic ways, if you look at the mere character byte values.

Concrete:

? 2>10
? "2">"10"

The first comparison obviously is .F., the second comaparison is .T., because the "2" is larger than "1" and the next character of the longer string doesn't matter. If you imagine letters instead of digits and think of names, they are not first sorted by length and then by alphabet, and you also expect that. That means you are not surprised to see "c">"ba", though it is the same situation as with "2" and "10".

So if you convert numbers to strings, make 110% sure you pad both string representations to the same string length, ie padding the short "2" to either " 2" or "02" help, as " 2">"10" and "02">"10" are correctly returning .F. again.

Bye, Olaf.

 

[Mike Lewis]

if you TRANSFORM both the DISKSPACE result and the number of bytes needed to avoid the scientific notation with exponents, you should be aware, that the result of the TRANSFORMS are strings,

Correct. That's why I was careful to say "If you want to display a number such as 7.068E+11 ..."

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

For display of disk space I would test, whether the magnitude of the number is larger than 1024 and if so convert to the magnitude in kB, MB, GB, TB, or PB where the numeric part is lower than 1024.

eg like that:

lnDiskSpace = DISKSPACE(somepath)

lnDisplay = lnDiskSpace
lcUnits = "Bytes kB MB GB TB PB EB ZB YB"
lnWordNum = 1
Do While lnDisplay>1024 and lnWordNum<GETWORDCOUNT(lcUnits)
   lnDisplay = lnDisplay/1024
   lnWordNum = lnWordNum + 1
EndDo
lcUnit = GETWORDNUM(lcUnits,lnWordNum)

? lnDisplay, lcUnit

For comparison you might display lnDiskSpace.

The digits of lnDisplay and lnDiskspace don't match, as I divide by 1024 instead of 1000, so the number does not only shift, but also shrinks a bit. You might make the difference between MB and MiB, GB and GiB etc., which I am rather computing here, but I doubt users normally make that distinction or know the more correct units and their short and actually think of a GB as being a GiB (GiB means 2^30 Bytes vs 10^9 Bytes of a GB).

Bye, Olaf.