Page 1 of 1 1
Topic Options
#213991 - 2021-06-04 05:12 PM GetDriveSize cannot handle current large drives?
Eduard Offline
Fresh Scripter

Registered: 2003-08-09
Posts: 16
Loc: Amsterdam
I am not sure whether KiXtart still is maintained, but I still use it extensively at home for running several system checking scripts.
This morning I added a new SSD to my Windows PC, a 4TB version, with drive letter D.
And it appears that my syscheck script returns a negative value as free space for this drive.
So I made a very simple check script:

$DriveSpace = GETDISKSPACE("D:\")
?? $DriveSpace

And indeed a negative value is returned.
The returned value should be 3,675,641,319,424 bytes, but I get -705,473,820 KB
Sounds this familiar to anybody?

#213992 - 2021-06-07 07:00 AM Re: GetDriveSize cannot handle current large drives? [Re: Eduard]
Allen Administrator Online   shocked
KiX Supporter

Registered: 2003-04-19
Posts: 4536
Loc: USA
I haven't confirmed your test, but you might try a UDF that does something similar.


How to use UDFs -

The rest of the UDFs are here -

Kixtart is still supported, and used by at least a few more soles like yourself. If we confirm this bug we'll need to pass this along to Ruud and hope he will include the fix in the next release.

#213993 - 2021-06-07 03:23 PM Re: GetDriveSize cannot handle current large drives? [Re: Allen]
ShaneEP Moderator Offline
MM club member

Registered: 2002-11-29
Posts: 2119
Loc: Tulsa, OK
Both the built-in function (GetDiskSpace), and the UDF (Diskspace) return the same value for me.

My guess is, the built-in function wasn't design to account for values over GBs. I'd suspect that if I had free space in the TBs, I might also see weird results. But that's only a guess. Curious to see if the UDF version works for you or not.

#213994 - 2021-06-07 11:48 PM Re: GetDriveSize cannot handle current large drives? [Re: ShaneEP]
Eduard Offline
Fresh Scripter

Registered: 2003-08-09
Posts: 16
Loc: Amsterdam
Thanks for your answers Allen and Shane.

Meanwhile I did some more digging into this myself, and I found out that the problem is that KiXtart v4.67 cannot handle integers larger than 2,147,483,647.
And 2,147,483,647 KB is 2 TB.
The value has to be between ‑2,147,483,648 and 2,147,483,647
This is a 32bit restriction.
See: Wikipedia: 2,147,483,647
When an integer value becomes larger than 2,147,483,647 it will wrap and start from zero ‑2,147,483,648 again.

At first I tried to solve it with the GetDiskSpace function by taking this restriction into account: to get the correct value I tried to first converting the result from KB to MB (dividing by 1024), and then add a fixed number.

This works for drives up to 4TB:
$DriveSize = INT(CREATEOBJECT("Scripting.FileSystemObject").GetDrive($Drive).TotalSize/1048576)
$DriveSpace = INT(GETDISKSPACE($Drive+':\')/1024)
IF $DriveSpace < 0                ; Drivespace is larger then 2TB
	$TBsize = INT($DriveSize/1048576)
	$DriveSpace = INT(((GETDISKSPACE($Drive+':\')-2147483648)/1024)+($TBsize-1)*1048576)
$DrivePrSpc = INT(100*$DriveSpace/$DriveSize)

This returns the DriveSize and DriveSpace in MB and the DriveSpace in % of DriveSize.
But that does not work reliably for drives larger then 4TB because it is not sure how much has to be added to correct the value: this depends on the true amount of rounded available TBs and the total drive size.

So this is how I solved it in the end:
$DriveSpace = INT(CREATEOBJECT("Scripting.FileSystemObject").GetDrive($Drive).AvailableSpace/1048576)

This returns the correct available space of the drive $Drive in MB.

But it would be great if Ruud would release a new version that copes with this problem.
Probably we need a 64bit version?

Edited by Eduard (2021-06-08 08:37 AM)
Edit Reason: A small correction and some additional info

Page 1 of 1 1

Moderator:  ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
1 registered (Allen) and 219 anonymous users online.
Newest Members
travel, SHEBLU_HOSSAIN, JohnShearer, sam_white, Luuraap
17801 Registered Users

Generated in 0.054 seconds in which 0.024 seconds were spent on a total of 13 queries. Zlib compression enabled.