Happy New Millennium Joerg, L.D., and everyone else:
>"Joerg Dietze" <[EMAIL PROTECTED]> wrote:
>>Hi L. D. and all,
>
>>On Fri, 29 Dec 2000 18:47:24 -0500, L.D. Best wrote:
>
>> Dave,
>
>> I didn't quote the long explanation of how the FAT is, or is not,
>> involved in a search for files on a HDD ...
>
>> You refer to the OS searching the "Directory" to find a file address,
>> and state that the search of the directory entry does NOT involve the
>> FAT in any way.
>
>> -----------
>
>> My question(s) is/are:
>
>> Isn't a directory no more than just another file? Aren't all the
>> directories kept track of by the FAT? If directories are not kept track
>> of by the FAT, how *are* they kept track of?
>
>Yes, with one exception: the root directory of a FAT formated drive is
>no file but a special area located between boot sector and first copy of
>FAT. So the root directory of a FAT16 drive has a limited number of
>directory entries. All subdirectories are indeed a special kind of file
>(there is a special subdir attribute to indicate this).
>
So, since the root directory is in a fixed location, the OS already knows
where to find it, so there's no need to look in the File Allocation Table.
>> I know that the files referred to as Directories can be written anywhere
>> on the HDD that there is space, so how can accessing the FAT be avoided?
>
>It can't be avoided. Let's have an example:
>Assuming You have a directory named "parents" which contains a subdir
>named "children" OS will do as follows when "children" is to be accessed:
>OS will search root directory for the name "parents". It will find the
>"subdir" attribute so it will know that the entry referes to a subdir.
>It looks in root dir for the first entry in FAT belonging to "parents"
>to locate the first cluster on the disk containing first part of the
>subdir. Tracking the FAT entries (a chain of numbers refering to the
>clusters on the drive) it reads content of "parents". This will be
>searched for the name "children" and the game sarts from the beginning.
>
L.D. - As Joerg says, it is the DIRECTORY that gets searched. The accesses
to the File Allocation Table are indexed, either by the FAT # in the
directory entry, or the FAT # in the previous FAT entry. Again, the ONLY
time the FAT is SEARCHED is when the OS is extending a file, and even then
it is searched sequentially, starting at the current entry.
>> I also know that directory size can change, grow when more files are
>> moved "to" a specific directory. That would indicate to me that even a
>> Directory can become fragmented ... which would, AFAIK, then seem to
>> require the FAT to tell the OS where to search for the rest of it.
>
>Seems very correct for me.
Yes, SUBdirectories CAN grow, and if they exceed the size of a single
Allocation Unit ("Cluster") then there will have to be multiple AUs
allocated to that subdirectory. Each time this happens, the OS will search
the File Allocation Table ONCE, sequentially, starting at the current AU. And
when the number of files in the subdirectory diminishes, the extra
space at the end of the directory remains.
Also, most Operating System / File System implementations cache some or
all of the directory structure, for more rapid access. This includes the
AU numbers of the various subdirectories.
Finally, a badly fragmented file system slows down access, regardless of the
file system. Even the Windows NT file system, NTFS, which supposedly
never needs defragmenting, gets fragmented eventually, and benefits from
the application of a third-party defragmenter.
Some file systems defragment on-the-fly - This doesn't mean they don't
fragment, just that they do their best to hide it and its bad effects
from the end-user.
>
><snip>
>
>Regards Joerg
Dave
____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1
