The Sinclair QL Forum

How can I find/calculate the free space and total space of a drive?

In SMSQ/E I can use the functions DMEDIUM_FREE and DMEDIUM_TOTAL which return the number of free sectors / total sectors available on the medium.
I presume that the returned value is a signed integer, so if the value is negative I will have to add 4294967296 to it to get the real value.
This is ok for drives up to about 1Tb or so, even if it is not really exact as SBASIC will write 4294967296 as 4.294967E9.

But what can I use in QDOS?
DIR will return the number of free sectors and total sectors on a medium, so one solution would be to DIR win1_ to a temporary file and then parse the file to extract the values.
This would be rather slow sometimes.
Is there any other (faster) way to find the free space and the total space on a medium?

Stat dev1_ comes to mind

hope its helps
Markus

Per Witte has a small set of extensions which can do this https://www.knoware.no/zip/MDINF08.zip

Look for the extension MDFREE in the zip file.

Personally, if using DIR or STAT to send the output to file, I'd probably use a pipe instead if you are using Turbo or QLib which might be faster than outputting to a file and avoid any risk of a temporary file already existing.

EDIT: updated link to recently updated version. https://www.knoware.no/zip/MDINF09.zip

Thanks Dilwyn - and Per!

What a brilliant toolkit! I had missed that one when trawling Knowhere - another gem from Per - and weighing-in at only 1KB

What is extra useful is that these functions even work over the Network (once FSERVE is running on the target station).

For example, I was able to query one of my QL's from QPC (MDINFO was only loaded on QPC, not on the target QL), thus:

PRINT MDLEVEL("N1_sdc1_") -> returned 2, as expected
PRINT MDLEVEL("N1_mdv1_") -> returned 1, also as expected! (of course, there has to be a cartridge in MDV1_ before this works)
and
PRINT MDNAME$("N1_mdv1_") -> returned the cartridge name as expected

This will help to determine whether MAKE_DIR can be expected to work on the target station/device, for example...

Great stuff, Per!

Im glad you find it useful, Martyn.

If it must work with "standard" toolkits (TKII, TurboTK, QLiberator Extensions) the current version of TurboTK's DEVICE_STATUS() seems to be compatible with large drives:
free_space will hold the available space in bytes.

Note that early versions do not work with large (e.g. WIN) drives, cause internally the sectors a 512 bytes are returned and the maximum number of sectors is limited to 65535.

Thank you all for the answers!
I don't know how I missed Per's MDINFO tookit! I searched his site yesterday evening, and I still missed that toolkit

MDINFO works great for QL drives
DMedium_free(\win1_) , STAT win1_ and MDFREE(win1_) will report the same free space

But in QPC it reports wrong size for large DOS drive.
I have mapped as DOS2 a drive with 543Gb free.
DMedium_free(\dos_) , STAT dos_ both report 543Gb free
But MDFREE(dos2) reports only 9244 kb free

Background: I am working on a new QLCommander version and, among other new features, it will show the free space on a drive.
MDINFO makes life a lot easier - but I am not sure if the users will be annoyed by the fact that DOS drives are reported incorrectly
DMedium - only works on SMSQ/E and I want QLC to rork also on QDOS
STAT works - but then I will have to use temporary files or pipes.
DMedium and STAT will report corectlly (more or less) for drives up to 1.5-2Tb

What solution would you use?
Would you be annoyed if DOS drives are not reported correctly?

Andrei,

Its obvious, isnt it? MDxxx returns bytes, and 543Gb is not a figure that can be represented as a 32bit number. Silly me, I recently changed the "short" MD toolkit to return bytes too, because I found that more convenient, and I didnt think anyone would notice.

You could do a number of different things, for example use DMEDIUM_xxxx if running on SMSQ and MDxxxx (the "long version") on Qdos - or find another toolkit.

In the mean time I'll consider updating my toolkit in some way that maintains backward compatibility.

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

If I might dare share my thoughts on bytes vs sectors/allocation units...

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.

But none of that takes away from.the usefulness of this dinky toolkit, which I shall now add to all my various QDOS/Minerva BOOT files

(Which, using Andrei's great QLC, is now a breeze to do over the network!)

pjw wrote: Fri Feb 07, 2025 6:28 pm 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"