Recovering deleted files on FAT32 and NTFS partitions

I've noticed that if I delete a file (like a video file, or whatever), and
then immediately try to recover it, for some strange reason, the chance of
recovery depends dramatically on whether or not the file was stored on a
FAT32 partition or an NTFS partition:

If it was on a FAT32 partition, it has some clusters immediately overwritten
after deletion and thus usually can't be recovered, but yet if I do the same
test on an NTFS partition, it does not. Why would that be?

You can verify this yourself, with an unerase program like Recuva (or
whatever) which indicates this, and thus whether or not the file has a good
chance of recovery.

It doesn't seem to matter what unerase program you use: if the deleted file
was on an NTFS partition, it usually has a good chance of recovery, but if
it was on an FAT32 partition, then right after its deleted some of its
clusters are immediately overwritten, for some strange reason (even though
you've done nothing else in that partition)

I assume the problem is due to something different in the way Windows XP
handles its NTFS and FAT32 volumes. But the point is, if you delete a file
on any partition, and then *immediately* try to recover it, you should be
able to, assuming you or the system hasn't written anything new to that
partition (and the only time that should ever happen if at all is on the
windows system partition)

I tried a similar test on my Win98SE computer (with FAT32), and did NOT get
this immediate overwritten cluster problem, so apparently it has something
to do with the way WindowsXP handles FAT32 partitions.

If someone has an explanation for this it would be interesting to hear.

Bill in Co wrote:
I've noticed that if I delete a file (like a video file, or whatever), and
then immediately try to recover it, for some strange reason, the chance of
recovery depends dramatically on whether or not the file was stored on a
FAT32 partition or an NTFS partition:

If it was on a FAT32 partition, it has some clusters immediately overwritten
after deletion and thus usually can't be recovered, but yet if I do the same
test on an NTFS partition, it does not. Why would that be?

You can verify this yourself, with an unerase program like Recuva (or
whatever) which indicates this, and thus whether or not the file has a good
chance of recovery.

It doesn't seem to matter what unerase program you use: if the deleted file
was on an NTFS partition, it usually has a good chance of recovery, but if
it was on an FAT32 partition, then right after its deleted some of its
clusters are immediately overwritten, for some strange reason (even though
you've done nothing else in that partition)

I assume the problem is due to something different in the way Windows XP
handles its NTFS and FAT32 volumes. But the point is, if you delete a file
on any partition, and then *immediately* try to recover it, you should be
able to, assuming you or the system hasn't written anything new to that
partition (and the only time that should ever happen if at all is on the
windows system partition)

I tried a similar test on my Win98SE computer (with FAT32), and did NOT get
this immediate overwritten cluster problem, so apparently it has something
to do with the way WindowsXP handles FAT32 partitions.

If someone has an explanation for this it would be interesting to hear.

The file system software, needs an algorithm to locate the next
empty cluster to write to. FAT32 has no free space bitmap in it,
which is a disadvantage for that purpose.

I get the impression, it starts from the left and works to the right.
In the case of a freshly deleted file, if the OS needed to make some directory
change, perhaps it locates the now freed up clusters, and uses a few from
the very left of that area, for its needs.

What you can try, for your next experiment, is the following.

1) Take the "contig" program, which is a "pure defragmenter", and
move the file before deleting it. In my experiments, I've seen files
moved well to the right. If there is other write activity on the
computer at the time (like system restore), that can defeat contig
and fragment the written file before the write can be finished. The
system has to be "quiet" for this to work.

http://technet.microsoft.com/en-us/s...rnals/bb897428

What contig does, or is supposed to do, is locate the next
continuous chunk of clusters, to the right of the area already written.
It then writes the file out to that area, and deletes the original clusters.
Being a "pure defragmenter", it's job is done if the new location for
the file is in one piece. No attempt is made to push the file to the
left, unlike most any other defragmenter you might own. (Moving to the
left, is an optimization function, and not defragmentation as such.)

Using contig, should create a "hole" to the left of the file.

2) Now, delete the file, then attempt recovery. If any space was
needed immediately after the deletion, maybe it will come out of
the "hole" artificially created by "contig". Rather than coincidentally
overwriting the freed-up space.

It's also possible, you're running some real-time defrag software,
which is continuously shifting stuff to the left. In which case,
I can't predict what will happen :-)

Paul

Paul wrote:
Bill in Co wrote:
I've noticed that if I delete a file (like a video file, or whatever),
and
then immediately try to recover it, for some strange reason, the chance
of
recovery depends dramatically on whether or not the file was stored on a
FAT32 partition or an NTFS partition:

If it was on a FAT32 partition, it has some clusters immediately
overwritten
after deletion and thus usually can't be recovered, but yet if I do the
same
test on an NTFS partition, it does not. Why would that be?

You can verify this yourself, with an unerase program like Recuva (or
whatever) which indicates this, and thus whether or not the file has a
good
chance of recovery.

It doesn't seem to matter what unerase program you use: if the deleted
file
was on an NTFS partition, it usually has a good chance of recovery, but
if
it was on an FAT32 partition, then right after its deleted some of its
clusters are immediately overwritten, for some strange reason (even
though
you've done nothing else in that partition)

I assume the problem is due to something different in the way Windows XP
handles its NTFS and FAT32 volumes. But the point is, if you delete a
file
on any partition, and then *immediately* try to recover it, you should be
able to, assuming you or the system hasn't written anything new to that
partition (and the only time that should ever happen if at all is on the
windows system partition)

I tried a similar test on my Win98SE computer (with FAT32), and did NOT
get
this immediate overwritten cluster problem, so apparently it has
something
to do with the way WindowsXP handles FAT32 partitions.

If someone has an explanation for this it would be interesting to hear.

The file system software, needs an algorithm to locate the next
empty cluster to write to. FAT32 has no free space bitmap in it,
which is a disadvantage for that purpose.

I get the impression, it starts from the left and works to the right.
In the case of a freshly deleted file, if the OS needed to make some
directory
change, perhaps it locates the now freed up clusters, and uses a few from
the very left of that area, for its needs.

What you can try, for your next experiment, is the following.

1) Take the "contig" program, which is a "pure defragmenter", and
move the file before deleting it. In my experiments, I've seen files
moved well to the right. If there is other write activity on the
computer at the time (like system restore), that can defeat contig
and fragment the written file before the write can be finished. The
system has to be "quiet" for this to work.

http://technet.microsoft.com/en-us/s...rnals/bb897428

What contig does, or is supposed to do, is locate the next
continuous chunk of clusters, to the right of the area already written.
It then writes the file out to that area, and deletes the original
clusters. Being a "pure defragmenter", it's job is done if the new
location for the file is in one piece. No attempt is made to push the
file
to the left, unlike most any other defragmenter you might own. (Moving
to
the left, is an optimization function, and not defragmentation as
such.)

Using contig, should create a "hole" to the left of the file.

2) Now, delete the file, then attempt recovery. If any space was
needed immediately after the deletion, maybe it will come out of
the "hole" artificially created by "contig". Rather than coincidentally
overwriting the freed-up space.

It's also possible, you're running some real-time defrag software,
which is continuously shifting stuff to the left. In which case,
I can't predict what will happen :-)

Paul

Nope, not running any real time defrag software (thanks, but no thanks!
:-)

I ran contig, but it didn't change the end result (so evidently defragging a
file before deleting it has no effect in these test cases).

Again, this issue appears only on the FAT32 partitions; if I use a NTFS
partition and delete a file (and try to immediately recover it), I can
usually recover it (i.e., no overwritten clusters).

What is interesting is that just after I've deleted a file on a FAT32
partition and try to recover it, the unerase utility (Recuva or whatever),
reports clusters were overwritten by a file or folder which hasn't been
touched by me (i.e., and NOT by something new by the XP OS. So it's like
XP is "rearranging" things so that file recovery is near impossible here by
deliberately overwriting some of the erased file table entries with an
existing file (or directory) table entries.

Again, this issue does NOT arise on my Win98SE computer (which uses Win98 as
the OS, instead of XP). I just don't get it. Somehow XP isn't playing
very nice here! (Hmmm, maybe this "anomoly" was carefully built-into WinXP
in yet another attempt to get people to use NTFS partitions with WinXP! :-)

If you have any other ideas as to what's going on, I'd be glad to hear them.
Or if you have a FAT32 partition you could try out this experiment yourself.

Bottom line: if you accidentally erase a file on a FAT32 partition with XP,
you can just about kiss it goodbye forever. But not so on a Win98 computer.
Go figure.

Bill in Co wrote:
Paul wrote:
Bill in Co wrote:
I've noticed that if I delete a file (like a video file, or whatever),
and
then immediately try to recover it, for some strange reason, the chance
of
recovery depends dramatically on whether or not the file was stored on a
FAT32 partition or an NTFS partition:

If it was on a FAT32 partition, it has some clusters immediately
overwritten
after deletion and thus usually can't be recovered, but yet if I do the
same
test on an NTFS partition, it does not. Why would that be?

You can verify this yourself, with an unerase program like Recuva (or
whatever) which indicates this, and thus whether or not the file has a
good
chance of recovery.

It doesn't seem to matter what unerase program you use: if the deleted
file
was on an NTFS partition, it usually has a good chance of recovery, but
if
it was on an FAT32 partition, then right after its deleted some of its
clusters are immediately overwritten, for some strange reason (even
though
you've done nothing else in that partition)

I assume the problem is due to something different in the way Windows XP
handles its NTFS and FAT32 volumes. But the point is, if you delete a
file
on any partition, and then *immediately* try to recover it, you should be
able to, assuming you or the system hasn't written anything new to that
partition (and the only time that should ever happen if at all is on the
windows system partition)

I tried a similar test on my Win98SE computer (with FAT32), and did NOT
get
this immediate overwritten cluster problem, so apparently it has
something
to do with the way WindowsXP handles FAT32 partitions.

If someone has an explanation for this it would be interesting to hear.
The file system software, needs an algorithm to locate the next
empty cluster to write to. FAT32 has no free space bitmap in it,
which is a disadvantage for that purpose.

I get the impression, it starts from the left and works to the right.
In the case of a freshly deleted file, if the OS needed to make some
directory
change, perhaps it locates the now freed up clusters, and uses a few from
the very left of that area, for its needs.

What you can try, for your next experiment, is the following.

1) Take the "contig" program, which is a "pure defragmenter", and
move the file before deleting it. In my experiments, I've seen files
moved well to the right. If there is other write activity on the
computer at the time (like system restore), that can defeat contig
and fragment the written file before the write can be finished. The
system has to be "quiet" for this to work.

http://technet.microsoft.com/en-us/s...rnals/bb897428

What contig does, or is supposed to do, is locate the next
continuous chunk of clusters, to the right of the area already written.
It then writes the file out to that area, and deletes the original
clusters. Being a "pure defragmenter", it's job is done if the new
location for the file is in one piece. No attempt is made to push the
file
to the left, unlike most any other defragmenter you might own. (Moving
to
the left, is an optimization function, and not defragmentation as
such.)

Using contig, should create a "hole" to the left of the file.

2) Now, delete the file, then attempt recovery. If any space was
needed immediately after the deletion, maybe it will come out of
the "hole" artificially created by "contig". Rather than coincidentally
overwriting the freed-up space.

It's also possible, you're running some real-time defrag software,
which is continuously shifting stuff to the left. In which case,
I can't predict what will happen :-)

Paul

Nope, not running any real time defrag software (thanks, but no thanks!
:-)

I ran contig, but it didn't change the end result (so evidently defragging a
file before deleting it has no effect in these test cases).

Again, this issue appears only on the FAT32 partitions; if I use a NTFS
partition and delete a file (and try to immediately recover it), I can
usually recover it (i.e., no overwritten clusters).

What is interesting is that just after I've deleted a file on a FAT32
partition and try to recover it, the unerase utility (Recuva or whatever),
reports clusters were overwritten by a file or folder which hasn't been
touched by me (i.e., and NOT by something new by the XP OS. So it's like
XP is "rearranging" things so that file recovery is near impossible here by
deliberately overwriting some of the erased file table entries with an
existing file (or directory) table entries.

Again, this issue does NOT arise on my Win98SE computer (which uses Win98 as
the OS, instead of XP). I just don't get it. Somehow XP isn't playing
very nice here! (Hmmm, maybe this "anomoly" was carefully built-into WinXP
in yet another attempt to get people to use NTFS partitions with WinXP! :-)

If you have any other ideas as to what's going on, I'd be glad to hear them.
Or if you have a FAT32 partition you could try out this experiment yourself.

Bottom line: if you accidentally erase a file on a FAT32 partition with XP,
you can just about kiss it goodbye forever. But not so on a Win98 computer.
Go figure.



I have another experiment you can try, but this is too involved.

I move files off WinXP C: (FAT32) using Robocopy. If I then zero
the partition, and reformat it, and move the file back, all the spare
area is zeroed. Then, try your experiment again, and see whether recuva
finds actual files, or finds zeros in the remaining spaces. If it finds zeros,
it's looking at some uninitialized space, as far as this problem is concerned.

To do that, you need a second OS. I may be able to do this from BartPE,
as I included robocopy when I built my BartPE, but since I was doing
other experiments at the time, never got around to trying it out.
Normally, when I move C: to another disk, and then move the files
back, I'm using the Win2K OS on the computer to do it.

This is the condensed version of what I do from Win2K, to the
WinXP partition. The drive letters correspond to the letters that
Win2K is using. Fat32format is the Ridgecrop formatter. VolumeID
is the Sysinternals utility. Robocopy is version XP026.

robocopy E:\ J:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v /log:robocopy_e_to_j.log

fat32format E:

volumeid E: 492A-AC63

robocopy J:\ E:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v /log:robocopy_j_to_e2.log

recovery console, fixboot

"Fixboot" is needed, because formatting the WinXP partition, removes
the partition boot sector.

To "zero" the partition, that step would be inserted just before the
"fat32format E:" step. I could try something like "dd" for that.
dd if=/dev/zero of=...

By zeroing the entire partition, any part of the partition never
touched by the file system, will still contain zeros, and Recuva
won't be finding anything there.

HTH,
Paul

Paul wrote:
Bill in Co wrote:
Paul wrote:
Bill in Co wrote:
I've noticed that if I delete a file (like a video file, or whatever),
and
then immediately try to recover it, for some strange reason, the chance
of
recovery depends dramatically on whether or not the file was stored on
a
FAT32 partition or an NTFS partition:

If it was on a FAT32 partition, it has some clusters immediately
overwritten
after deletion and thus usually can't be recovered, but yet if I do the
same test on an NTFS partition, it does not. Why would that be?

You can verify this yourself, with an unerase program like Recuva (or
whatever) which indicates this, and thus whether or not the file has a
good chance of recovery.

It doesn't seem to matter what unerase program you use: if the deleted
file
was on an NTFS partition, it usually has a good chance of recovery, but
if it was on an FAT32 partition, then right after its deleted some of
its
clusters are immediately overwritten, for some strange reason (even
though you've done nothing else in that partition)

I assume the problem is due to something different in the way Windows
XP
handles its NTFS and FAT32 volumes. But the point is, if you delete a
file
on any partition, and then *immediately* try to recover it, you should
be
able to, assuming you or the system hasn't written anything new to that
partition (and the only time that should ever happen if at all is on
the
windows system partition)

I tried a similar test on my Win98SE computer (with FAT32), and did NOT
get this immediate overwritten cluster problem, so apparently it has
something to do with the way WindowsXP handles FAT32 partitions.

If someone has an explanation for this it would be interesting to hear.
The file system software, needs an algorithm to locate the next
empty cluster to write to. FAT32 has no free space bitmap in it,
which is a disadvantage for that purpose.

I get the impression, it starts from the left and works to the right.
In the case of a freshly deleted file, if the OS needed to make some
directory
change, perhaps it locates the now freed up clusters, and uses a few
from
the very left of that area, for its needs.

What you can try, for your next experiment, is the following.

1) Take the "contig" program, which is a "pure defragmenter", and
move the file before deleting it. In my experiments, I've seen files
moved well to the right. If there is other write activity on the
computer at the time (like system restore), that can defeat contig
and fragment the written file before the write can be finished. The
system has to be "quiet" for this to work.

http://technet.microsoft.com/en-us/s...rnals/bb897428

What contig does, or is supposed to do, is locate the next
continuous chunk of clusters, to the right of the area already
written.
It then writes the file out to that area, and deletes the original
clusters. Being a "pure defragmenter", it's job is done if the new
location for the file is in one piece. No attempt is made to push the
file
to the left, unlike most any other defragmenter you might own.
(Moving
to the left, is an optimization function, and not defragmentation as
such.)

Using contig, should create a "hole" to the left of the file.

2) Now, delete the file, then attempt recovery. If any space was
needed immediately after the deletion, maybe it will come out of
the "hole" artificially created by "contig". Rather than
coincidentally
overwriting the freed-up space.

It's also possible, you're running some real-time defrag software,
which is continuously shifting stuff to the left. In which case,
I can't predict what will happen :-)

Paul

Nope, not running any real time defrag software (thanks, but no thanks!
:-)

I ran contig, but it didn't change the end result (so evidently
defragging a
file before deleting it has no effect in these test cases).

Again, this issue appears only on the FAT32 partitions; if I use a NTFS
partition and delete a file (and try to immediately recover it), I can
usually recover it (i.e., no overwritten clusters).

What is interesting is that just after I've deleted a file on a FAT32
partition and try to recover it, the unerase utility (Recuva or
whatever),
reports clusters were overwritten by a file or folder which hasn't been
touched by me (i.e., and NOT by something new by the XP OS. So it's
like
XP is "rearranging" things so that file recovery is near impossible here
by
deliberately overwriting some of the erased file table entries with an
existing file (or directory) table entries.

Again, this issue does NOT arise on my Win98SE computer (which uses Win98
as
the OS, instead of XP). I just don't get it. Somehow XP isn't playing
very nice here! (Hmmm, maybe this "anomoly" was carefully built-into
WinXP
in yet another attempt to get people to use NTFS partitions with WinXP!
:-)

If you have any other ideas as to what's going on, I'd be glad to hear
them.
Or if you have a FAT32 partition you could try out this experiment
yourself.

Bottom line: if you accidentally erase a file on a FAT32 partition with
XP,
you can just about kiss it goodbye forever. But not so on a Win98
computer.
Go figure.



I have another experiment you can try, but this is too involved.

I move files off WinXP C: (FAT32) using Robocopy. If I then zero
the partition, and reformat it, and move the file back, all the spare
area is zeroed. Then, try your experiment again, and see whether recuva
finds actual files, or finds zeros in the remaining spaces. If it finds
zeros,
it's looking at some uninitialized space, as far as this problem is
concerned.

To do that, you need a second OS. I may be able to do this from BartPE,
as I included robocopy when I built my BartPE, but since I was doing
other experiments at the time, never got around to trying it out.
Normally, when I move C: to another disk, and then move the files
back, I'm using the Win2K OS on the computer to do it.

This is the condensed version of what I do from Win2K, to the
WinXP partition. The drive letters correspond to the letters that
Win2K is using. Fat32format is the Ridgecrop formatter. VolumeID
is the Sysinternals utility. Robocopy is version XP026.

robocopy E:\ J:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v
/log:robocopy_e_to_j.log
fat32format E:

volumeid E: 492A-AC63

robocopy J:\ E:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v
/log:robocopy_j_to_e2.log
recovery console, fixboot

"Fixboot" is needed, because formatting the WinXP partition, removes
the partition boot sector.

To "zero" the partition, that step would be inserted just before the
"fat32format E:" step. I could try something like "dd" for that.
dd if=/dev/zero of=...

By zeroing the entire partition, any part of the partition never
touched by the file system, will still contain zeros, and Recuva
won't be finding anything there.

HTH,
Paul

Hi, well that would be a pretty time-consuming test, so I haven't tried it!

However, I did try another, but simpler, test, and that was to use a FAT
formatted flash drive. Somewhat surprisingly, but not completely
surprisingly, there was no problem here in this case (i.e., no overwritten
clusters problems).

So I'm getting the impression that this weird file recovery issue (due to
some immediately-overwritten clusters for that erased file after its file
deletion) only shows up on hard drives (not external flash drives).

And possibly that is only true if it is on the primary drive which has the
OS installed, but I don't know.

Again, this is related somehow to using WindowsXP (and perhaps its
successors for all I know) - it doesn't happen on my Win98SE computer).

Thus, for some mysterious (and shall I say, insipid) reason, WindowsXP
insists on overwriting some clusters on an erased file on a FAT32 partition
hard drive, it seems. (I'm not guaranteeing it always does that in all
such cases, but it sure does it often enough, as one can easily verify an
unerase program like Recuva, or the like)

Bill in Co wrote:


Hi, well that would be a pretty time-consuming test, so I haven't tried it!

However, I did try another, but simpler, test, and that was to use a FAT
formatted flash drive. Somewhat surprisingly, but not completely
surprisingly, there was no problem here in this case (i.e., no overwritten
clusters problems).

So I'm getting the impression that this weird file recovery issue (due to
some immediately-overwritten clusters for that erased file after its file
deletion) only shows up on hard drives (not external flash drives).

And possibly that is only true if it is on the primary drive which has the
OS installed, but I don't know.

Again, this is related somehow to using WindowsXP (and perhaps its
successors for all I know) - it doesn't happen on my Win98SE computer).

Thus, for some mysterious (and shall I say, insipid) reason, WindowsXP
insists on overwriting some clusters on an erased file on a FAT32 partition
hard drive, it seems. (I'm not guaranteeing it always does that in all
such cases, but it sure does it often enough, as one can easily verify an
unerase program like Recuva, or the like)

Could it be System Restore ?

If this is C:, repeat the experiment using a file located in 'My Documents".

System Restore doesn't track the contents of "My Documents".

If you delete from another folder, such as C:\Downloads, then System
Restore tracks that, and there may be a copy hiding in a restore
point (which means doing writes to the disk).

Currently, I have System Restore turned off, to save space.
And also, to stop fouling up "guest" drives I connect occasionally.

Paul

Paul wrote:
Bill in Co wrote:


Hi, well that would be a pretty time-consuming test, so I haven't tried
it!

However, I did try another, but simpler, test, and that was to use a FAT
formatted flash drive. Somewhat surprisingly, but not completely
surprisingly, there was no problem here in this case (i.e., no
overwritten
clusters problems).

So I'm getting the impression that this weird file recovery issue (due to
some immediately-overwritten clusters for that erased file after its file
deletion) only shows up on hard drives (not external flash drives).

And possibly that is only true if it is on the primary drive which has
the
OS installed, but I don't know.

Again, this is related somehow to using WindowsXP (and perhaps its
successors for all I know) - it doesn't happen on my Win98SE computer).

Thus, for some mysterious (and shall I say, insipid) reason, WindowsXP
insists on overwriting some clusters on an erased file on a FAT32
partition
hard drive, it seems. (I'm not guaranteeing it always does that in all
such cases, but it sure does it often enough, as one can easily verify an
unerase program like Recuva, or the like)

Could it be System Restore ?

Nope - see below.

If this is C:, repeat the experiment using a file located in 'My
Documents".

System Restore doesn't track the contents of "My Documents".

If you delete from another folder, such as C:\Downloads, then System
Restore tracks that, and there may be a copy hiding in a restore
point (which means doing writes to the disk).

Currently, I have System Restore turned off, to save space.
And also, to stop fouling up "guest" drives I connect occasionally.

Paul

I only have System Restore monitoring my C: (NTFS) windows partition, and
only that one. I've turned it off for ALL the other partitions - and keep
it off those other ones :-).

Which reminds me: To anyone else reading this: it's best to periodically
check on that every so often, because after you install some programs,
System Restore may get reset to monitoring all the partitions again, no
matter what you had it set to beforehand. That's happened to me on a very
few occasions (and when it happens, it generally happens with the "heavier"
programs, and not with the lightweight ones).

In message , Bill in Co
writes:
[]
Thus, for some mysterious (and shall I say, insipid) reason, WindowsXP
insists on overwriting some clusters on an erased file on a FAT32 partition
hard drive, it seems. (I'm not guaranteeing it always does that in all
such cases, but it sure does it often enough, as one can easily verify an
unerase program like Recuva, or the like)


I suspect you meant invidious - though I rather like the idea that XP
might have insipid reasons for doing things (-:!
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

.... his charming, bumbling best, a serial monogamist terrified of commitment,
who comes across as a sort of Bertie Wooster but with a measurable IQ. - Barry
Norman on Hugh Grant's persona in certain films, Radio Times 3-9 July 2010

J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
[]
Thus, for some mysterious (and shall I say, insipid) reason, WindowsXP
insists on overwriting some clusters on an erased file on a FAT32
partition
hard drive, it seems. (I'm not guaranteeing it always does that in all
such cases, but it sure does it often enough, as one can easily verify an
unerase program like Recuva, or the like)


I suspect you meant invidious - though I rather like the idea that XP
might have insipid reasons for doing things (-:!

LOL. Thanks for the correction. :-) Invidious it is.
BTW, you've been kinda quiet on this one. Have you tried it out? (I'm
assuming you have a computer with XP and FAT32 partitions on it somewhere).

In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
[]
Thus, for some mysterious (and shall I say, insipid) reason, WindowsXP
insists on overwriting some clusters on an erased file on a FAT32
partition
hard drive, it seems. (I'm not guaranteeing it always does that in all
such cases, but it sure does it often enough, as one can easily verify an
unerase program like Recuva, or the like)


I suspect you meant invidious - though I rather like the idea that XP
might have insipid reasons for doing things (-:!

LOL. Thanks for the correction. :-) Invidious it is.
BTW, you've been kinda quiet on this one. Have you tried it out? (I'm
assuming you have a computer with XP and FAT32 partitions on it somewhere).


I just don't have the time (-:! I've got lots of genealogy stuff I'm
supposed to be doing, but I have been on this usenet (in several
newsgroups) from 09.xx this morning (it is now 23:13), solid - I haven't
even eaten! I fear I'll have to drop some newsgroups if I'm ever going
to do anything - including eat!

I don't actually have a mixed computer: this netbook has the NTFS
partitions it came with (XPSP3 preloaded - let me choose partition sizes
for C: and D: on first use); my old laptop, and my desktop, are all
FAT32.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

.... his charming, bumbling best, a serial monogamist terrified of commitment,
who comes across as a sort of Bertie Wooster but with a measurable IQ. - Barry
Norman on Hugh Grant's persona in certain films, Radio Times 3-9 July 2010

"Bill in Co" wrote in
:

However, I did try another, but simpler, test, and that was to use
a FAT formatted flash drive. Somewhat surprisingly, but not
completely surprisingly, there was no problem here in this case
(i.e., no overwritten clusters problems).


Keep in mind that Flash drives have a limited number of write cycles
and in order to extend the life of a flash drive, many drives implement
a "wear leveling" scheme in which subsequent writes are made to a
different sector of the drive in order to spread the writing over the
entire drive. This may affect or explain the results you are getting.

http://en.wikipedia.org/wiki/Wear_leveling

HTH,
JW