micky wrote:
> In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 23:46:20
> -0500, Paul <nos...@needed.invalid> wrote:
>
>> micky wrote:
>>> In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 22:03:30
>>> -0500, micky <
NONONO...@bigfoot.com> wrote:
>>>
>>> What are FAT Folder Parts?
>>>
>>> I'm running Minitools Data Recovery and it says it's found 507,000 FAT
>>> folder parts, but only 47 folder, 923 Fat Files, and 72,000 files.
>>>
>>> I think Easeus uses the same term.
>>>
>>> So what are FAT folder parts? :-)
>>>
>
> And neither this page nor the one above uses the word "parts" like I
> need it.
>
> Maybe when the program finishes it will become clear, but that's not
> until 1PM tomorrow ET. And in the past things like this take longer
> than they tell you. Not sure I'll have time to post about it, however.
> Leaving Wednesday morning, much to do yet.
>
> Thanks for your efforts.
The term "folder fragments" is used in the defragmenter API.
Fragment is used in preference to "parts". A fragment implies
a splitting of something.
http://superuser.com/questions/885975/how-does-windows-calculate-the-fragmentation-percentage
And I have to agree with the comment in there, that half the
terminology used there, I haven't seen diagrams which represent
or demonstrate the concept.
A folder should contain pointers to all the files. If the number
of pointers is larger, the sheer magnitude of the storage involved,
could cause the folder structure to be split into pieces. For example,
I have a procedure for re-laying out my FAT32 WinXP. And despite
my best efforts, file fragmentation can be zero, while there
will *still* be folders fragmented. And that's when one process,
re-writes the volume. (I put the files back on the drive with
Robocopy.)
(A couple days old...)
https://s23.postimg.org/547k58457/manual_defrag.gif
Note that, in NTFS, there is plenty of room to handle fragmentation.
However, when a file has thousands and thousands of fragments, the file
system uses a "file number extension" method. This works somewhat like
a freight train with four locomotives would work. The first file number
(pointer) is the "real" one. But it could be followed by three like-named
file pointers. Each file pointer points to a percentage of the file
fragments. An example of a severely fragmented file, is the Windows.edb
that the Search Indexer calculates. That file can exist as multiple
pointers. And it appears recent versions of Windows, the defragmenter
seems to have been adjusted to clean that one up nicely. As I can no longer
find "nice examples" of that sort (severe fragmentation), as an illustration
for people to use at home.
So if a folder were to store 30000 files, and there were two programs
writing at different places in the disk at the same time, I might
expect the metadata added to the folder to get "split" when a new
chunk needs to be allocated to extend a folder. For example, on my
relatively freshly re-laid WinXP FAT32, there are 9 folders
which are fragmented. Out of 5728 folders.
Now, is that what your recovery tools are referring to ? Who knows.
"Parts" tells me "squat".
http://www.easeus.com/datarecoverywizard/help/scan-file.htm
"While the tool is scanning the partition,
it will provide a continuous progress report.
* Partition Tables
* FAT Boot Records
* FAT Folders
* FAT Folder Parts <--- still not sure...
* NTFS Boot Records
* NTFS File Records
* Files Identified
* Total Files found
* Elapsed Time
* Remaining Time
On NTFS partitions, I could use NFI to "decode" some of
these conditions, and compare to the information the
defragmenter API seems to show. But on FAT32, I don't
have any tool for showing the cluster info. (I'm not
much of a tool collector, so this should not be
a surprise particularly. I'm very slow at collecting
them.)
Paul