From : Jerry Coffin                                           1:128/77.3
Subj : Physical Location of file                                             
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

 BC> Can anyone tell me how to find the physical location (head, sector,
 BC> track) of a file.

Basically you'll have to find the file yourself.  You start with the
root directory and progress through the path, one directory at a time.
(Under the circumstances, you might want to make your own life easier by
putting the file in the root directory.  To find the file, you'll start
by reading the boot sector ( sector 0 ) of the partition, which is a
record like this:

bootsector struc
    jump       db 3 dup(?) ; jump to actual boot code...
    OEMname    db 8 dup(?)
    sectorsize  dw ?        ; bytes per sector
    clustersize db ?        ; sectors per cluster
    res_sectors dw ?        ; reserved sectors.
    num_FATs    db ?        ; number of FATs.
    rootsize    dw ?        ; entries in root directory.
    sectors     dw ?        ; sectors in volume for volumes <32 Meg.
    descriptor  db ?
    FATsize     dw ?        ; sectors per FAT.
; DOS >= 3
    tracksize   dw ?        ; sectors per track
    heads       dw ?        ; heads in disk drive.
    hidden      dd ?        ; number of hidden sectors.
; DOS >= 4.
    bigsectors  dd ?        ; sectors in volume if > 32 Meg.
    drivenum    db ?
    reserved1   db ?
    EBSR        db ?        ; generally ( always ? ) has value of 029h
    volumeID    dd ?
    disklabel   db 11 dup(?)
    reserved2   db 8 dup(?)
bootsector ends

To get to the root directory, you skip over the number of reserved
sectors.  The FAT(s) follow immediately after that, so you multiply the
number of FATs by the size of each FAT, and add that number to the
number of reserved sectors.  This will give you the starting sector of
the root directory.  The root directory is made up of 32 byte records
like this one:

filename struc
    filename    db 8   dup(?)
    extension   db 3     dup(?)
    attribute     db ?
    reserved    db 10   dup(?)
    filetime    dw  ?
    filedate    dw  ?
    cluster     dw  ?
    filesize    dd  ?
filename ends

The root directory is always in contiguous clusters, so you can take the
number of root directory entries, multiply by 32, divide by the number
of bytes per sector and then by the number of sectors per cluster, and
you have the number of clusters in the root directory.  It's usually
easiest to read in the root directory at a single shot.

You then search through and find your filename in the root directory.
Assuming you start at the beginning, if you run into a file with its
first byte set to 0, this signals the last directory entry that's in
use, so your file isn't there.

Assuming you do find the file, you'll now use its cluster entry as an
index into the FAT.  Assuming a 16 bit FAT, you'll index into the FAT by
the number of words given as the cluster number.  There you'll find a
word that give the number of the next cluster in the file.  Following
the chain, you'll eventually get to a cluster number of -1 ( 0ffffh )
which signifies that you've reached the last cluster in the file.
Finding whether the file is fragmented consists of following the chain
of cluster numbers and see if if the numbers are consecutive.

Immediately following the root directory is cluster number 2 ( 0 and 1
are used as special marks in the FAT ) and clusters progress
consecutively from there to the end of the disk.  Figuring a DOS sector
to give to int 25h basically consists of subtracting 2, multiplying the
cluster number by the number of sectors per cluster and adding the
number or sectors used by the reserved area, FATs and root directory.

For the moment I've ingored 12 bit FATs, as they're more of a pain to
deal with - since each FAT entry takes up 1.5 bytes, you've got to
figure out whether the start at the beginning of middle of a byte.  To
do this, you start by multiplying the number by cluster number by 1.5,
using the integer part of the result, read in a word from that offset.
Then if the number you got from multiplying was in integer, you and with
word with 0fffh.  Otherwise, you right shift it by 4 bits.  Unless your
file might end up on a floppy disk, or you know up-front that it'll be
used on a small hard drive, I wouldn't bother with 12 bit FATs...
    Later,
    Jerry.

... The Universe is a figment of its own imagination.