DriveGetSize and DriveSpaceTotal not match

[Darien]

Hello,

 

Why do the results of the "DriveGetSize" and "DriveSpaceTotal" commands do not match, as seen in the example below?

 

MsgBox ( 0 , "" , Round ( DriveSpaceTotal ( "C:" ) / 1024 ) & Chr(13) & Round ( DirGetSize ( "C:" ) / 1024 / 1024 / 1024 ) )

Edited October 21, 2017 by Darien

[jchd]

Because the two functions don't return the same value since they don't count the same thing (total space != dir size).

And reread what you write: "DriveGetSize" and "DriveSpaceTotal" while you invoke DirGetSize and DriveSpaceTotal.

[Darien]

So how would I know if a device has the space needed to copy a particular directory?

Edited October 21, 2017 by Darien

[jchd]

DriveSpaceFree() is presumably better suited to return available free space on a drive than any other function intended to count the space used by a directory (DirGetSize) or the total size of a drive (DriveSpaceTotal).

[iamtheky]

Still my favorite, via @rover

 

[Darien]

I assume "DriveSpaceTotal" works similarly to "DriveSpaceFree", so I asked him. But if the result of "DriveSpaceFree" does not match the "DirGetSize" result of the directory I want to copy to that device, I will not know if the directory will fit or not.

Edited October 22, 2017 by Darien

[jchd]

A directory doesn't have its own free space. The unused or free or available space on a drive is returned by DriveSpaceFree.

20 minutes ago, Darien said:

I assume "DriveSpaceTotal" works similarly to "DriveSpaceFree"

Total ≥ Free ! A 16Gb USB key has around 16Gb total space once formatted but has anything between that and 0 free space, depending on the size already used by files and directories.

DirGetSize sums up the size of all files and directories found under a given path.

[RTFC]

It's also worth mentioning that the amount of space needed to store files is usually a bit more than the reported file size, due to storage granularity. Any advanced file system (e.g. FAT, NTFS) will divide a formatted storage medium into fixed-size chunks (e.g., 4 Kb or 64 Kb, usually provided as a formatting option) and allocate one or more of these chunks to a particular file as needed. You can witness this difference yourself if your right-click on a file in the file manager and select "Properties;" you'll see separate entries for "Size" and "Size on Disk." In some file systems, the content of tiny files maybe stored with the directory entry description itself, so file size on disk is reported as zero. Larger files will be  rounded up in size on disk to the next-larger integer number of chunks. So it's not as straightforward as simply adding all file sizes in a directory, and see if that will fit. Instead, to be safe, when establishing whether a bunch of files will fit, round each one's size up to the next-larger integer number of storage chunks, and sum those (do NOT add all file sizes, and round up that total once; that's not the same thing).

Edited October 23, 2017 by RTFC
correction, clarification