What are FAT Folder Parts

In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 22:03:30
-0500, micky 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? :-)

micky wrote:
In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 22:03:30
-0500, micky 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 for non-existent terminology, what kind of
answer would you like ? :-)

The notion implies folders come in an Ikea box,
with a tiny hex wrench, and "some assembly required".
And I don't think that's how it works. A file system
has files and folders, but a folder is just a file
with special properties or identifiers. Data storage
is in clusters. A cluster consists of some number
of sectors or blocks or similar terms.

The Wikipedia article on FAT should have the detail
you need.

https://en.wikipedia.org/wiki/File_Allocation_Table

"...In much the same way, sub-directories are
implemented as special files containing the
directory entries of their respective files."

Or maybe an article like this.

https://www.pjrc.com/tech/8051/ide/fat32.html

Paul

In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 23:46:20
-0500, Paul wrote:

micky wrote:
In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 22:03:30
-0500, micky 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 for non-existent terminology, what kind of
answer would you like ? :-)

A simple one. But really, both minitools and easeus use the term.
And there seem to be prior searches in google for
FAT folder parts followed by either minitools or easeus.

So I'm not the first one to ask this!

The notion implies folders come in an Ikea box,
with a tiny hex wrench, and "some assembly required".
And I don't think that's how it works. A file system
has files and folders, but a folder is just a file
with special properties or identifiers. Data storage
is in clusters. A cluster consists of some number
of sectors or blocks or similar terms.

The Wikipedia article on FAT should have the detail
you need.

https://en.wikipedia.org/wiki/File_Allocation_Table

I knew quite a bit about FAT befoer tonight, and I looked at this page
before I posted.

"...In much the same way, sub-directories are
implemented as special files containing the
directory entries of their respective files."

Or maybe an article like this.

https://www.pjrc.com/tech/8051/ide/fat32.html

Paul

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.

micky wrote:
In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 23:46:20
-0500, Paul wrote:

micky wrote:
In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 22:03:30
-0500, micky 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/88597...ion-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/datarecoverywi.../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

On Sun, 05 Mar 2017 22:57:29 -0500, micky wrote:
In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 22:03:30
-0500, micky 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? :-)

That's Easeus' terms, IMO. It's not an official term from FAT
specifications.

My guess as what "parts" means in this context, is one or more clusters
which contains subdirectory data (i.e. file/subdirectory entries).
Subdirectory consume disk cluster(s) too. If a subdirectory contains large
enough number of file/subdirectory entries, it will consume more than one
disk clusters.

In alt.comp.os.windows-10, on Mon, 6 Mar 2017 18:43:58 +0700, JJ
wrote:

On Sun, 05 Mar 2017 22:57:29 -0500, micky wrote:
In microsoft.public.windowsxp.general, on Sun, 05 Mar 2017 22:03:30
-0500, micky 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? :-)

That's Easeus' terms, IMO. It's not an official term from FAT
specifications.

My guess as what "parts" means in this context, is one or more clusters
which contains subdirectory data (i.e. file/subdirectory entries).
Subdirectory consume disk cluster(s) too. If a subdirectory contains large
enough number of file/subdirectory entries, it will consume more than one
disk clusters.

Thanks both of you.

Mini Data Recovery finished without crashing on a 1.5 gig drive that had
about 270 Gig data. AT the end it didnt' repeat the numbers it gave
in the middle, and I wrote down the numbers at 3 points, but I see I
never wrote down the labels that wen with them. Stil, I think folder
parts was the biggest of them at it as at
934,111 at 1:30 PM, and
992,605 at about 11 PM
1,026,090 at noon the next day
and it fiinished at 1PM

It found a total of 1.47TB in 1376966 bytes on a 1.5T drive, though
there appeared to be some duplication in reporting what it found.

I selected 175gigs in 289171 files out of that to restore, and that's
been running for about 2 hours and is about half way done.

Looking at the files I remembered mroe about the drive. I got it from a
friend who'd used it for windows, and I kept his windows installation
and used some of the files. But it's clear someone had used it for
Macintosh earlier. The prior guy, and I, should have wiped it because
in this situation, data recovery recovers everything. But the results
were sorted so it was easy to not save the potentially recovered Mac
data. ,


(OTOH, Easeus did crash, and later only found 147,000 files, the before
it crashed, maybe for lack of memory (4gigs), it had found 440,000
files. I don't know what happened, but after several tries with Easeus,
I gave up and bought Mini. There's a new version of easeus but I'm
dubious it will make a difference. if I remember when I get back from
out of town, I'll run it on the bad partition and see if does better
than the last few times. Their forum was some help but many of my
simple questions were unanswered by the two people who answered.

One used the term "we" like she worked there, but she was labeled a
newbie by the software. Another is called a Patriarch Member whatever
that is. They both sign that there on the Customer Support Team.

The second one said "After that, you should select the right lost
partitoin in the "Lost Partition Drives" to start the scan"

Well, duh. I figured that out myself, that I should select the right
one and not the wrong one. My questions were about other thigns.

"If it still does not work, you can contact us by online chat to get
more help:" I doubt I woudl like online chat in this situation. I
took my tmie to right questions off line and paste them into the web
forum. I don't know how fast I'd have to reply with chat, though I
appreciate their desire to answer questions one at a time.

I'm curious if easesus could get it too work**, but now that I have the
data, it will be hard to generate the energy to do it again, just for
curiosity.


**The first time I used it it worked great, but it was a smaller drive.

micky wrote:
In alt.comp.os.windows-10, on Mon, 6 Mar 2017 18:43:58 +0700, JJ
wrote:


Thanks both of you.

Mini Data Recovery finished without crashing on a 1.5 TB drive that had
about 270 Gig data.

That's a huge disk for data recovery purposes.
No wonder it took so long.

And now you probably have some idea why "whitening"
the disk occasionally is an option. Again, it takes
longer than it should, but it could potentially make
data recovery easier.

Now, this method would be thorough... You would use
this, to zero out no-longer-existent file number entries
in the $MFT, as well as cleaning bulk white space with
zeros. This should do a good job of "hiding old secrets".
None of your current data would be harmed.

https://technet.microsoft.com/en-us/...ernals/sdelete

Versus doing it by creating a big file on an NTFS
partition, to whiten most of the white space on the
drive.

dd if=/dev/zero of=M:\TEMP\big.bin bs=1048576
del M:\TEMP\big.bin

That would create a file using up all the empty space
on the drive. You would then delete that right afterwards.
The example would be whitening partition M: .

http://www.chrysocome.net/dd

Then, if the disk is having trouble, and you want to
run a recovery utility, it won't be "finding files from 1959"
on the disk.

I don't propose running that daily. However, if you have a
drive which is "mostly quiescent", one that doesn't change
much, it might help a bit in your current situation. There
would potentially be less to sort through later.

I have a couple scratch drives, that I find myself cleaning
pretty regularly. That's because they've been used in RAID
and GPT experiments, and it's nice to start from a completely
clean slate during the (next) experiment. For the rest of my
drives, I don't have time to clean them. And my failure rates
here, don't really suggest I need to do it. But it remains
an obscure option.

And while the fsutil program has a "createfile" option, it
only actually writes all the clusters on FAT32. On NTFS
partitions, "createfile" uses sparse file technology. The
file is created instantly for you, but no erasure results
from the creation of the file. This is the definition of
"useless". I first ran into "mkfile" on Unix, many years
ago, and got great usage out of that while testing programs
I wrote, as "mkfile" writes all the sectors of any files
you create with it. On Windows, "dd.exe" is the closest
thing to "mkfile" for my purposes. Fsutil is a very nice
utility, but not for this particular purpose.

HTH,
Paul

micky wrote:

Mini Data Recovery finished without crashing on a 1.5 gig drive that had
about 270 Gig data.

Wow, I didn't realise 'Stacker' had improved that much :-)

In microsoft.public.windowsxp.general, on Mon, 06 Mar 2017 21:16:16
-0500, Paul wrote:

micky wrote:
In alt.comp.os.windows-10, on Mon, 6 Mar 2017 18:43:58 +0700, JJ
wrote:


Thanks both of you.

Mini Data Recovery finished without crashing on a 1.5 TB drive that had
about 270 Gig data.

That's a huge disk for data recovery purposes.
No wonder it took so long.

True. I didn't mind the time, and fwiw, I thought Mini was quicker than
Easeus too. I posted abou tthis on the Easeus forum and for the first
time they said it would have to be reviewed before being posted. I
guess I was too explicit! But at least they'll read it, probably.

And now you probably have some idea why "whitening"
the disk occasionally is an option. Again, it takes
longer than it should, but it could potentially make
data recovery easier.

emailed to myself. No time to read it today.

But one question. Would this method work to get rid of Mac files after
the drive has been ... I guess it was Quick Reformatted for Windows?

It didn't occur to me there was a whole Mac Partition out there and
somehow Easesus found it first, oh, and so did Mini. The difference is
that Mini doesn't show you anything it's found until it's done. And
also that when it retrenched to 140,000 files, they were all macintosh.

I guess if I had done this when I first got the drive (not that I'm
going to use used drives anymore) even easeus would have diplayed a lot
of Windows.

In fact Mini found 7 partitions (including 3 tiny ones) totalling a
little more than the drive is big, and it put them all in one main
directory, but under a subdirectory for each partition, named after the
partition number and size and format. So that's pretty good. I
selected what I thought was enough for XP, but maybe not. At least I
got all my data, almost all of which I have full copies of in the Vista
and 10 backups too.

Now, this method would be thorough... You would use
this, to zero out no-longer-existent file number entries
in the $MFT, as well as cleaning bulk white space with
zeros. This should do a good job of "hiding old secrets".
None of your current data would be harmed.

https://technet.microsoft.com/en-us/...ernals/sdelete

Versus doing it by creating a big file on an NTFS
partition, to whiten most of the white space on the
drive.

dd if=/dev/zero of=M:\TEMP\big.bin bs=1048576
del M:\TEMP\big.bin

That would create a file using up all the empty space
on the drive. You would then delete that right afterwards.
The example would be whitening partition M: .

http://www.chrysocome.net/dd

Then, if the disk is having trouble, and you want to
run a recovery utility, it won't be "finding files from 1959"
on the disk.

I don't propose running that daily. However, if you have a
drive which is "mostly quiescent", one that doesn't change
much, it might help a bit in your current situation. There
would potentially be less to sort through later.

I have a couple scratch drives, that I find myself cleaning
pretty regularly. That's because they've been used in RAID
and GPT experiments, and it's nice to start from a completely
clean slate during the (next) experiment. For the rest of my
drives, I don't have time to clean them. And my failure rates
here, don't really suggest I need to do it. But it remains
an obscure option.

And while the fsutil program has a "createfile" option, it
only actually writes all the clusters on FAT32. On NTFS
partitions, "createfile" uses sparse file technology. The
file is created instantly for you, but no erasure results
from the creation of the file. This is the definition of
"useless". I first ran into "mkfile" on Unix, many years
ago, and got great usage out of that while testing programs
I wrote, as "mkfile" writes all the sectors of any files
you create with it. On Windows, "dd.exe" is the closest
thing to "mkfile" for my purposes. Fsutil is a very nice
utility, but not for this particular purpose.

HTH,
Paul