[comp.sys.ibm.pc.programmer] First sector of the file area

acsoyuw@ubvmsd.cc.buffalo.edu (Yu Wang) (07/02/90)

In article <1990Jun27.141718.18545@contact.uucp>, yung@contact.uucp writes...
>do the sector/cluster/file calculation. Anybody know how I can find out
>the sectore number of the first sector of the file area of a hard disk
>without knowing its storage size in advance?

You can read the File Allocation Table, it's all in there.
On a 20 meg hard disk, the FAT of the root directory should be at sector 83.
And the sub-directries of the root directory should be at sector 300s.
(Please correct me if I'm wrong)
P.S. PC-Tools will help.

stever@Octopus.COM (Steve Resnick ) (07/02/90)

In article <1990Jun27.141718.18545@contact.uucp> yung@contact.uucp () writes:
>Hi, folks!
>
>I am writing a TSR program and is now in a desparate need to find out
>the best way to access hard disk. Since DOS function cannot be used in
>TSR program, therefore I will have to use BIOS, which means I have to
>do the sector/cluster/file calculation. Anybody know how I can find out
>the sectore number of the first sector of the file area of a hard disk
>without knowing its storage size in advance?
>
Wait wait wait! The same reasons for not being able to call DOS is true for
the BIOS disk I/O routines: They are non-reentrant. If you can cause your 
disk writes to wait for DOS to be finished with a DOS call, you can trap 
int 21 to your own vector and keep track of DOS' reentrancy status. There
are some undocumented ways of doing this but they are not the same accross
DOS 3 & DOS 4. As always, be carefull when doing any disk I/O for you may 
kill your disk or a portion thereof...

Cheers!
Steve


-- 
--------------------------------------------------------------------------------
Steve Resnick -<stever@octopus.COM apple!octopus!stever sun!vsi1!octopus!stever>
408/241-1533 Process Scientific, Inc.
"0x2B|~0x2B THAT is the question!"

berg@cip-s03.informatik.rwth-aachen.de (Solitair) (07/02/90)

acsoyuw@ubvmsd.cc.buffalo.edu writes:
>>do the sector/cluster/file calculation. Anybody know how I can find out
>>the sectore number of the first sector of the file area of a hard disk
>You can read the File Allocation Table, it's all in there.
>On a 20 meg hard disk, the FAT of the root directory should be at sector 83.
>And the sub-directries of the root directory should be at sector 300s.
>(Please correct me if I'm wrong)

You're wrong (well, partially anyway).
The way to follow is this: Read the partition sector on the hard-disk,
determine from it the boot sector of the partition you want to access.
Then read that boot sector, extract from it all the info you want
(i.e. sector size, cluster size, partition size, start of FAT, size of FAT,
 start of root dir, start of file data area, ...)
Look up the format of the partition and boot sector in for example
the infamous INTERRUP.LST, available at a site near you!
--
Sincerely,                             |"I code it in 5 min, optimize it in 90
           Stephen R. van den Berg.    | min, because it's so well optimized:
uunet!mcsun!unido!rwthinf!cip-s01!berg | it runs in 5 only min.  Actually, most
berg@cip-s01.informatik.rwth-aachen.de | of the time I optimize programs."

phys169@canterbury.ac.nz (07/20/90)

In article <3050@rwthinf.UUCP>, berg@cip-s03.informatik.rwth-aachen.de
 (Solitair) and others write:
>>>.. Anybody know how I can find out
>>>the sectore number of the first sector of the file area of a hard disk

>>On a 20 meg hard disk, the FAT of the root directory should be at sector 83.

> The way to follow is this: Read the partition sector on the hard-disk,

The best way is to avoid the calculation, since DOS ignores some of the
parameters in that first sector, and different versions ignore it in different
ways, putting the first sector in different places. It's better to have your
TSR program get DOS to do the work, by either doing the work inside an int 28h
routine, when it is safe to use most modern DOS calls (e.g. set a flag in your
keyboard interrupt handler, which your 28h handler looks at), and/or intercept 
int 21h and avoid conflicts by checking for work to be done after calling the 
original int 21h has been called.

Second-best is to use int 25h after checking do disk activity is in progress;
this is still pretty safe, still works with many networks (e.g. Decnet Dos, but
NOT Novell), and lets your TSR get a slice of the action a little more often
than the super-safe method above.  You shouldn't need to look at partition
information unless you want some extra-efficient print spooler or such like.

Mark Aitchison, Physics, University of Canterbury, New Zealand, Up Under.