CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data 
Author Message
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data



Quote:
>> The main problem with your code is that you assume that every file
>> system type has some kind of "cluster" information.

> Sure it has, any block orientated device has a block size, and
> everyfilesystem driver calls it differently (e.g. Ext2fs from Linux
> calls it INODE size), but in the end it is all the same:

> Clustersize in a broader sense is the amount of space the free space of
> the drive decreases when you enlarge a zero byte file to a 1 byte file.

> This definition is not perfect (some filesystems might allocate blocks
> for 0 bytes files, and also compressed filesystems can act funny), but
> quite adequate to grasp the concept.

In addition, some file systems may not use a FAT but instead store
file allocation info for each file in a block of its own.  On such a
file system, increasing the file size from 0 to 1 bytes will case TWO
new blocks to be allocated: one foe the file contents, and another
one for the file alloc info.  A file system can even store the file
in the directory entry itself if the file is very very small -- on
such a file system, increasing the file size from 0 to 1 bytes would
cause no additional disk space to be allocated, creating an illusion
of a cluster size of zero bytes!

The bottom line becomes: you need to know your file system well before
you can make any reliable conclusions about the "cluster size".  A
simple-minded scheme like the one suggested above is guaranteed to
fail on some file systems.

Quote:
> Also this definition does not cover certain historical reasons. (like a
> maximal number of clusters on FAT16)

>> But this is not  true. In the case of NTFS, CHKDSK just returns the
>> sector size (which is 512 bytes as some kind of standard independend
>> from the operating system, if someone has other informations, please
>> let me know).

> Hmm. IIRC the default clustersize of NTFS is much higher (which it is
> good, it is already (relatively) slow enough already), so I think the
> 512 bytes size is too optimistic.

> However it doesn't matter, since even if it was 512 bytes, that would be
> the clustersize, only in that case it happens to be the same as the disk
> size.

That was an AWFULLY small disk!!!!  The smallest disk I've heard about
before was at least 50 Kbytes, i.e. some 100 times larger.... :-)

Quote:
>> The
>> same goes for other drives with non-FAT filesystems like CD-ROMs or
>> network drives.
>> The code you posted will only work for a FAT16 drive, for FAT32 or
>> no-FAT file systems it just can't show any thing "correct". CHKDSK
>> assumption to show the sector size is as close as it gets...

> For cdroms, the minimal size is always 2048 afaik, except maybe for
> Adaptec DirectCD stuff.

For CD-ROM's there's no need to use "clusters" at all, since "blocks"
cannot be "freed" -- once they're written they'll remain written
"forever" (or, in the case of a CD-RW, until the entire disk is
erased).  Thus, on a CD-ROM, it's perfectly adequate to pack the files
to the byte. yielding a "cluster soze" of 1 byte,

Of course the cluster size may be smaller than the sector size.
Already good ol' CP/M-80 implemented this, by using a "logical sector
sise" of 128 bytes (which would be equal to the cluster size on a
disk small enough), even when implemented on systems with physical
sectors of 256 or 512 bytes.

Quote:
> For other filesystems you can also do it, but not in a dosbox under NT.
> However with a win32 call (getdiskfreespacea or so) you can get it even
> under NT, but that is not possible from a dosprogram without certain
> really heavy workarounds. (like loading VXDs that act as intermediate)

--
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://www.*-*-*.com/ ;   http://www.*-*-*.com/


Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data

Quote:

>>> The main problem with your code is that you assume that every file
>>> system type has some kind of "cluster" information.

>> Sure it has, any block orientated device has a block size, and
>> everyfilesystem driver calls it differently (e.g. Ext2fs from Linux
>> calls it INODE size), but in the end it is all the same:

>> Clustersize in a broader sense is the amount of space the free space of
>> the drive decreases when you enlarge a zero byte file to a 1 byte file.

>> This definition is not perfect (some filesystems might allocate blocks
>> for 0 bytes files, and also compressed filesystems can act funny), but
>> quite adequate to grasp the concept.

>In addition, some file systems may not use a FAT but instead store
>file allocation info for each file in a block of its own.  On such a
>file system, increasing the file size from 0 to 1 bytes will case TWO
>new blocks to be allocated: one foe the file contents, and another
>one for the file alloc info.

That is true. Also more dynamic tables may expand unpredictably. It was a
first approximation, to show what a cluster is: the smallest allocation
unit.
But there are some fundaments in common in at least most filesystems.
Still, that can be avoided with a slightly longer procedure.

Do the 0->1 expansions. The decrease in free space is x.

Check if x is a power of two. If not, try to split it into two powers of
two. (the filestructure doesn't necessarily grow at the same pace as files,
though it probably will). The larger one is z, the lower one is y

if x already was a power of 2:

x is a multiple of the clustersize. So enlarging from x to x+1 will give the
right result.

if not:

create a file with size y, and enlarge to y+1;  y is clustersize if free
space decreases with exactly y. Else
create a file with size z, and enlarge to z+1;  z is clustersize if the free
space decreases with exactly z.

Quote:
> A file system can even store the file
>in the directory entry itself if the file is very very small -- on
>such a file system, increasing the file size from 0 to 1 bytes would
>cause no additional disk space to be allocated, creating an illusion
>of a cluster size of zero bytes!

That is also testable. Simply start increasing files until a new block is
allocated. Keep on grow the file until you get the next block.

Quote:
>The bottom line becomes: you need to know your file system well before
>you can make any reliable conclusions about the "cluster size".  A
>simple-minded scheme like the one suggested above is guaranteed to
>fail on some file systems.

Yes. But with plain and simple thinking, and some testing, you can quickly
establish a good routine.

It also seriously depends on what you want it for.
I only use the clustersize to make an estimate when moving or decrunching
large directory structures, not to create a generic filesystem editor or so
:-)

Quote:
>> Hmm. IIRC the default clustersize of NTFS is much higher (which it is
>> good, it is already (relatively) slow enough already), so I think the
>> 512 bytes size is too optimistic.

>> However it doesn't matter, since even if it was 512 bytes, that would be
>> the clustersize, only in that case it happens to be the same as the disk
>> size.

>That was an AWFULLY small disk!!!!  The smallest disk I've heard about
>before was at least 50 Kbytes, i.e. some 100 times larger.... :-)

Sector size of course ;-)

Quote:
>>> no-FAT file systems it just can't show any thing "correct". CHKDSK
>>> assumption to show the sector size is as close as it gets...

>> For cdroms, the minimal size is always 2048 afaik, except maybe for
>> Adaptec DirectCD stuff.

>For CD-ROM's there's no need to use "clusters" at all, since "blocks"
>cannot be "freed" -- once they're written they'll remain written
>"forever" (or, in the case of a CD-RW, until the entire disk is
>erased).  Thus, on a CD-ROM, it's perfectly adequate to pack the files
>to the byte. yielding a "cluster soze" of 1 byte,

No. It is my fault, I should have said ISO 9660 FS instead of CDROM (a HD
has no clustersize, it's filesystems has)

But in practice, the bulk cdfs is iso 9660 fs, which doesn't pack files per
byte, but per 2048 sector.

And you can write a cdfs. Mount an image over loopback :-)

Quote:
>Of course the cluster size may be smaller than the sector size.
>Already good ol' CP/M-80 implemented this, by using a "logical sector
>sise" of 128 bytes (which would be equal to the cluster size on a
>disk small enough), even when implemented on systems with physical
>sectors of 256 or 512 bytes.

Sure, but I think for every modern FS, most will work with at least 16kb
allocation sizes. Simply because higher granularity increases fragmentation,
and space wasted for administration.


Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data

Quote:




>>>>I need to write a procedure which will return the
>>>>correct "Bytes Per Allocation Unit (Cluster)" whether
>>>>running in native DOS or a DOS box under any flavor
>>>>of Windows.

>>>>I wrote the following procedure:

>>[snip]

>>>The main problem with your code is that you assume that every file
>>>system type has some kind of "cluster" information.

>>Hi Ralf,

>>I really don't assume anything, except perhaps that whoever wrote the "DOS
>>box" interface for Win NT would make an attempt to return valid information
>>for the DOS API calls.

>Well, i think it was omitted as in NT you don't have access to the
>drive at a sector/cluster level. Direct disk read/writes are not
>possible (at least without special drivers)

That may be true, but it does not stand as a logical reason for not returning
correct information for Int21/36.  There are valid file-oriented reasons for
wanting the SectorsPerCluster information.  For example, reporting the actual
disk space used by a file (as opposed to the file size).

- Show quoted text -

Quote:

>>If Win NT with NTFS has no clusters - i.e. it allocates at sector
>>resolution - then one might reasonably expect the authors of the DOS box
>>under Win NT to make the DOS API return "1" as the answer for "Sectors per
>>Cluster".  

>That might have been a possible solution...

>>>The code you posted will only work for a FAT16 drive, for FAT32 or
>>>no-FAT file systems it just can't show any thing "correct".

>>"can't" is the wrong word.  there's no reason why it couldn't show the
>>correct value for FAT32.

>Because the INT21 function you used is limited to 64K clusters, while
>a FAT32 drive usually has more than that (a 512MB partition, the
>smallest size for a FAT32 partition has already 128K clusters, which
>exceeds the maximum value of a 16bit register!)

Yes, we know that.  So instead of returning some totally false value and
"success" for the status, the DOS box designers could have chosen to return 0 or
0xFFFFh with a non-zero status indicator.

Besides, your point is not directly relevant to the question.  The OP asked
about SectorsPerCluster.  Int21/36 returns a 16-bit value for SectorsPerCluster.
None of the Microsoft operating systems uses anywhere near that many sectors per
cluster.  The designers of the DOS box could have chosen to return the correct
value for that parameter.  They chose not to (or perhaps they didn't think about
it).



Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data

Quote:

>>Well, i think it was omitted as in NT you don't have access to the
>>drive at a sector/cluster level. Direct disk read/writes are not
>>possible (at least without special drivers)

>That may be true, but it does not stand as a logical reason for not returning
>correct information for Int21/36.  There are valid file-oriented reasons for
>wanting the SectorsPerCluster information.  For example, reporting the actual
>disk space used by a file (as opposed to the file size).

But this is a file system related information and the filesystem is
NON-DOS. I think it's very reasonable that the DOS "Simulation" is not
returning this info. If you need the information in a NT console
application, you can access it with an NT aware compiler/library.....
Quote:

>>Because the INT21 function you used is limited to 64K clusters, while
>>a FAT32 drive usually has more than that (a 512MB partition, the
>>smallest size for a FAT32 partition has already 128K clusters, which
>>exceeds the maximum value of a 16bit register!)

>Yes, we know that.  So instead of returning some totally false value and
>"success" for the status, the DOS box designers could have chosen to return 0 or
>0xFFFFh with a non-zero status indicator.

Ok, it's a "flaw", but this is a known problem AT LEAST since NT 4.0
came out and this is 5 years ago. And if someone nowadays is writing
DOS programs, he needs to be aware that not every environment might be
100% compatible. Write a NT console apps and you don't have this
problem.
Quote:
>Besides, your point is not directly relevant to the question.  The OP asked
>about SectorsPerCluster.  Int21/36 returns a 16-bit value for SectorsPerCluster.
>None of the Microsoft operating systems uses anywhere near that many sectors per
>cluster.  The designers of the DOS box could have chosen to return the correct
>value for that parameter.  They chose not to (or perhaps they didn't think about
>it).

But this is useless information on a different filesystem,specially
when the function is not able to return the proper number of clusters.

Ralf



Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data


Quote:
> On Sat, 30 Sep 2000 20:23:55 +0200, Marco van de Voort

> >NT doesn't support the extra (LFN/FAT32'ish) dos ints in dosboxes.

> Not out of the box, but check this:
>   http://www.goof.com/pcg/djgpp/ntlfn.html

Mean this that djgpp libs use also win32 services-calls and put those
services-calls into every compiled Dos file just for case ?

PS!!!  In what language are written djgpp libraries (what compiler) ?
          Example BC++3.1 runtime-libs are written in half of  BC
          and TASM.

--
 Ivar, (c)RMSoft.
 http://my.tele2.ee/rmsoft
 http://my.tele2.ee/rmsoft/electric



Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data

Quote:



>> On Sat, 30 Sep 2000 20:23:55 +0200, Marco van de Voort

>> >NT doesn't support the extra (LFN/FAT32'ish) dos ints in dosboxes.

>> Not out of the box, but check this:
>>   http://www.goof.com/pcg/djgpp/ntlfn.html

>Mean this that djgpp libs use also win32 services-calls and put those
>services-calls into every compiled Dos file just for case ?

No. The TSR seems to intercept the regular dos calls.

Quote:
>PS!!!  In what language are written djgpp libraries (what compiler) ?
>          Example BC++3.1 runtime-libs are written in half of  BC
>          and TASM.

djgpp in djgpp and as.


Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data


Quote:
>Well, i think it was omitted as in NT you don't have access to the
>drive at a sector/cluster level. Direct disk read/writes are not
>possible (at least without special drivers)

That's not correct. Though I'm normally using Win95, I had to use NT to access
a damaged partition on my harddisk. NT allows for full access to a physical
drive or partition, through appropriate CreateFile calls. Afterwards the whole
disk can be read and written like a file. I tried the same with Win95, and also
tested various interrups, but had no luck :-(

DoDi



Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data

Quote:
>Of course it is.  The whole point of the DOS box is to run DOS programs.  

Under NT or other Windows, every non-GUI program runs in a "console window",
which you seem to associate with DOS. Any program without a GUI will run in
such a console window, which handles character oriented I/O.

You seem to mean 16 bit DOS programs, which under Windows run in a virtual
(V86) machine. Then it's up to that machine, which DOS functions are supported,
and how they are supported.

Quote:
>>So, back to original question:  Is there, or is there not, a DOS function

call which is properly supported in all flavors of Windows DOS boxes which
returns the size of the disk allocation units?  Yes or no?<<

Obviously not, at least not a single function.

Quote:
>>If the answer is no, then it's because Microsoft either 1) chose not to.

for reasons which have not been articulated, or 2) was incompetent.<<

Or 3) you have an old BIOS on your system, which produces the wrong results.

Who will know?

Some reasons are obvious. When a program uses legacy functions, which *cannot*
return the correct values due to the usage of too small arguments (registers),
then such programs cannot work correctly with nowadays big drives. Initially
the specs of some DOS interrupts (in detail INT13) have been changed, so that
the correct arguments and returned information can reside in special extended
data structures. But this was only a temporary workaround, which was replaced
soon by more appropriate system calls, which should be used in newer software
instead of the legacy interface.

If you were Microsoft, how would you treat calls to legacy functions
(interrupts), which cannot accept or return arguments of an appropriate size?
Would you return an error (CF set), and consequently disallow any further use
of such programs, or how else would you handle such exceptional situations?

Admittedly some of the legacy functions could return more correct information,
but then you should ask Microsoft for the reasons, which cause such wrong
results. Perhaps they'll ask you to provide and support a better
implementation, which works consistently throughout all DOS and Windows
versions?

You should accept that extended support for legacy applications is of little
benefit for any OS provider. If somebody wants to use legacy programs, then he
can use the according legacy OS. Otherwise he'll have to update all programs,
so that these conform to the standards of the intended OS version. You
currently are such a user, which wants to use legacy DOS code in a newer OS
version. So it's your problem to restrict yourself to a legacy OS, or to become
familiar with the standards of the actual Windows versions.

DoDi



Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data

Quote:


>>Well, i think it was omitted as in NT you don't have access to the
>>drive at a sector/cluster level. Direct disk read/writes are not
>>possible (at least without special drivers)

>That's not correct. Though I'm normally using Win95, I had to use NT to access
>a damaged partition on my harddisk. NT allows for full access to a physical
>drive or partition, through appropriate CreateFile calls. Afterwards the whole
>disk can be read and written like a file. I tried the same with Win95, and also
>tested various interrups, but had no luck :-(

>DoDi

But this doesn't work by using Borland Pascal in a "NT console"
windows!!! That is what the original post was about and he just
doesn't understand that he can get the right information only as a "NT
console" program, as BP7 as a DOS compiler doesn't allow access to the
NT API.

Ralf



Wed, 18 Jun 1902 08:00:00 GMT  
 CHKDSK, Win NT, and DOS Int21 Function 1Ch Get Drive Data

Quote:
> >Well, i think it was omitted as in NT you don't have access to the
> >drive at a sector/cluster level. Direct disk read/writes are not
> >possible (at least without special drivers)

> That's not correct. Though I'm normally using Win95, I had to use NT to access
> a damaged partition on my harddisk. NT allows for full access to a physical
> drive or partition, through appropriate CreateFile calls. Afterwards the whole
> disk can be read and written like a file. I tried the same with Win95, and also
> tested various interrups, but had no luck :-(

NT allows certain applications (like MsSQL and Exchange) to direct
manipulate NTFS dir structs. Probably you found their access points :-)

--




Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software