Find Drive Free space and Total space

[pjw]

<>
Whilst bytes-free is arguably more human readable (say, in a formatted DIR listing), as far as determining whether or not your next file will 'fit' (not withstanding the potential growth in the directory), the sector/allocation unit free measure is actually more meaningful from a.prigramatic perspective.
<>

You may not yey have seen that there is a function in the MDINFO toolkit that does that calculation for you

Code: Select all

        usize = MDFSIZE(<device>, fsize)

        Returns the size taken up by a file of size fsize on a given medium, in bytes.

To be quite safe, one should add an additional allocation unit to this in case the directory grows as a result of adding a new file.

The reason I changed from returning the size in allocation units (or was is sectors? I dont recall) was that I was always calculating the result in bytes in the end. Perhaps this was a mistake. It should be simple enough to do something about it in a future version.

It might be interesting to figure out how to convert a 64 bit unsigned integer to QL floating point.. or perhaps not. Does anyone have any ideas on that? The 128bit conversion I'll leave to the next generation of QL users, if any..

[pjw]

I wonder what the chances are of QUBIDE or whatever hard disks for Qdos exceeding 4Gb per partition. Probably zero.

Less than zero
But I guess that many use emulators and have a DOS drive mapped in emulator, like I do ...
I wouldn't mind that the free space on a DOS drive is reported incorrectly, I already know that's plenty, but I want to know what others feel about it.
My choice would be to use MDINFO and put a disclaimer in the manual: "Only drives up to 4Gb capacity are reported correctly"

Yes, but large host filesystem devices will still be limited to 2 or 4 GB for Qdos, I presume. For SMSQ/E DMEDIUM_xxxx is built in.

[martyn_hill]

Hi Per!

You may not yey have seen that there is a function in the MDINFO toolkit that does that calculation for you

Code: Select all

        usize = MDFSIZE(<device>, fsize)

        Returns the size taken up by a file of size fsize on a given medium, in bytes.

To be quite safe, one should add an additional allocation unit to this in case the directory grows as a result of adding a new file.

It's moot really, as we end up in the same place, but the approach I have come to take goes like this:

For a file of known byte-size, add-on the FS header size for the target FS (being 64 bytes for QDOS-like FSs), then divide by the target medium allocation-unit size.
Then take the value of the free allocation-units of the target medium and compare (and, as you suggest, allow for the +1 allocation unit for the potential DIR growth.)

It leaves me of the view that 'allocation units' are the key, rather than bytes.

I also get confused (old age???) with those ridiculously large 'bytes free' values that DIR attempts to display, and end up counting digits to make sense of the value. When sectors/allocation-units are displayed, the values are more readable to my ageing eyes!

In any case, whichever way around we go, it amounts to the same

M.

[pjw]

Ive uploaded a new version of MDINFO at Knoware/toolkits. This should now work with large disks.
Let me know if you encounter any problems! (Or not).

[Derek_Stewart]

Ive uploaded a new version of MDINFO at Knoware/toolkits. This should now work with large disks.
Let me know if you encounter any problems! (Or not).

Hi Per,

This MDINFO is great, really nice programming.

[pjw]

Ive uploaded a new version of MDINFO at Knoware/toolkits. This should now work with large disks.
Let me know if you encounter any problems! (Or not).

Hi Per,

This MDINFO is great,

Thanks Derek

..really nice programming.

I cant agree there! The code has been stretched, fiddled, tickled, bent and folded over the past 30+ years. This not least of all due to the ever changing environment.

[pjw]

Ive uploaded a new version of MDINFO at Knoware/toolkits. This should now work with large disks.
Let me know if you encounter any problems! (Or not).

Hi Per,

This MDINFO is great,

Thanks Derek

..really nice programming.

I cant agree there! The code has been stretched, fiddled, tickled, bent and folded over the past 30+ years. This not least of all due to the ever changing environment.

This version should take us up to 2048 Gb, although I guess other parts of one's system may start to creak before we get there!

[Andrew]

Ive uploaded a new version of MDINFO at Knoware/toolkits. This should now work with large disks.
Let me know if you encounter any problems! (Or not).

Thank you Per, it works great!
The only question I have is how on earth can I convert the negative value (returned for very large drives) to something more meaningful?
What is the largest positive value returned by MDGOOD and MDFREE ? about 2Tb?

[pjw]

Ive uploaded a new version of MDINFO at Knoware/toolkits. This should now work with large disks.
Let me know if you encounter any problems! (Or not).

Thank you Per, it works great!
The only question I have is how on earth can I convert the negative value (returned for very large drives) to something more meaningful?
What is the largest positive value returned by MDGOOD and MDFREE ? about 2Tb?

Well, I had to get me a 4Tb backup drive to see what was going on!

So it should now work with up to 4Tb (or perhaps even 8Tb?) disks. But that may very well be the limit without a change to SMSQ/E itself and/or the emulators that run on it.

Ive re-upped MDINFO to Knoware/Toolkits. I havent dignified it with a new version number; the only way to distinguish between the two latest versions are by the dates in the text file and that the code is fatter and more untidy than before. It could do with a rewrite, but perhaps I'll wait for the petabytes hard disks..

[Andrew]

Well, I had to get me a 4Tb backup drive to see what was going on!

So it should now work with up to 4Tb (or perhaps even 8Tb?) disks. But that may very well be the limit without a change to SMSQ/E itself and/or the emulators that run on it.

Ive re-upped MDINFO to Knoware/Toolkits. I havent dignified it with a new version number; the only way to distinguish between the two latest versions are by the dates in the text file and that the code is fatter and more untidy than before. It could do with a rewrite, but perhaps I'll wait for the petabytes hard disks..

Thank you Per!
I can confirm that it works great on drives up to 4Tb!
(My QL Dev environment resides on a 4Tb drive with a hot mirror on a 2x12Tb RAID)