Sophie

Sophie

distrib > Mandriva > 9.1 > ppc > media > contrib > by-pkgid > 5e1cf60a1e92dccc53ea673ff3e4aa07 > files > 22

task-1.52-2mdk.ppc.rpm

This document explains how the FAT implementation was done in TASK.


INTRODUCTION
=============================================================================
TASK is based on the code and design of The Coroner's Toolkit (TCT)
and TCTUTILs.   As both of these tool packages only supported UNIX file
systems, support for Windows-based file systems, such as FAT, was added
to TASK.  The design of FAT and UNIX file systems are very different
and this document will identify how those differences were handled.
A basic understanding of FAT is assumed.

The major design "decisions" that had to be made are related to:
- Disk unit addressing
- Meta-data addressing


DISK UNIT ADDRESSING
=============================================================================
FAT saves file content in clusters.  A cluster is a grouping of
many sectors (512-bytes each).  When a file is described by some
meta-data structure, the cluster numbers are used as addresses.
The problem, is that the "first" cluster does not start at the
beginning of the partition.  It can be hundreds of sectors until
the "data area" starts and the location of the first cluster.  This
creates a problem because if TASK were to use clusters as addressable
units, then there would be no way to identify the non-"data area"
sectors.

This problem was solved by making the sector as the addressable unit.
When a "file" is described (using 'istat' for example), the sector
addresses are given.   For those familiar with the internal design of TCT,
the FS_INODE value actually contains the first cluster, but sectors are
always displayed to the user.


META-DATA ADDRESSING
=============================================================================
FAT does not have a notion of an "inode".  FAT describes its files in
a directory entry structure (contained in the sectors allocated by the
parent directory).  The directory entry structures have a fixed size of
32-bytes and these structures are basically the same as a UNIX inode,
with one major exception.  They are not numbered and can exist anywhere
on the disk.  This makes it difficult to address them efficiently.  Also,
the root directory does not have a directory entry.  In other words,
there is no descriptive information for the root directory besides its
cluster addresses.

The solution to this problem was to use the same method that is
used in the FAT support in OpenBSD.  Each sector in the "data area"
is treated as though it could be full of directory entries.  As
each sector is 512-bytes and each directory entry is 32-bytes, each
sector could contain 16 entries.  To keep things similar to UNIX,
the root directory is given the value of 2 (and its meta-data is
set to 0).  The first 32-bytes of the first sector in the data area
are addressed as 3, the second 32-bytes of the sector are 4 etc.
This makes it very easy to identify the location of a meta-data
structure given only its address.  This also means that there will
be large gaps between used address values and places a limit on the
size of the partition that can be analyzed.  The limit is:

	2^32 / 16 = 2^28 sectors

Therefore, we can handle partitions of size 137,438,953,472 bytes.
(I doubt that many people are running FAT on partitions over 128 GB)


NOTES ON TIMEZONES
=============================================================================
FAT does not store the file times in the delta format that UNIX does.
This creates some minor problems when we need to display the time
in delta format.  The way that this is handled is by converting
the actual time that FAT gives and determining its delta value.
This is stored in the generic inode structure.  This calculation
requires the time zone variable, as the FAT time does not include
a TZ.  Therefore, it can be noticed using 'istat' and 'fls -l' that
the '-z' argument only effects the Timezone Name, but not the actual
time.   On the other hand, using 'ils' or 'fls -m' where the delta
is given does make a difference.  If the '-z' argument is not given,
then the delta value will be with respect to the current time zone
and not the original.

If you are using 'ils -m' to make a timeline and will be supplying
'mactime' with a time zone, then set the 'TZ' environment variable as
well before running 'ils -m'.  


GENERAL NOTES ON TIME
=============================================================================
Each file in FAT can store up to three times (last accessed, written,
and created).  The last written time is the only 'required' time
and is accurate to a second.  The create time is optional and is
accurate to the tenth of a second (Note that I have seen several
system directories in Windows that have a create time of 0).  The
last access time is also optional and is only accurate to the day
(so the times are 00:00:00 in TASK).


The FAT spec can be found at:
	http://www.microsoft.com/hwdev/hardware/fatgen.asp

-----------------------------------------------------------------------------
Brian Carrier
April 2002
(Updated: 10/10/02)