On Wednesday, March 24, 2021 at 5:33:27 PM UTC-7, Paul wrote:
Robert in CA wrote:
I don't quite know what you mean by I must stop using
the partition?

I just had a folder named 'Shopping' and I had files in it of
things like books, DVD's etc that were on my list. I have lots
of folders/files like that. You're saying it's bad? Isn't that what
Favorites/folders/files are for?

Hmmmm, I already downloaded CCleaner on the 8500
but I haven't opened it. I then removed them from the
download history.

When I click your link it doesn't give me any option to
download in another location, then the dialog box pops up
to save it or open. So how do I download it to a USB flash
drive?

Then I run a scan from there correct?

Thanks,
Robert
The objective, is to treat the partition that had the accident,
as read-only.

The C: partition, while the machine is booted and Windows
is running, is constantly writing to C: . Maybe the search
indexer is running and doing writes.

If files are lost (accidental delete), you would shut down
the machine immediately. Now, we're not doing read or write.

You have other drives with a copy of the OS on them.
Imagine that drive is used to boot the computer. Now
the C: writes are happening to a partition you don't
care about. Using that drive, you download Recuva Free.
Install Recuva Free on that drive. Now you are ready to scan.

Now, connect the original drive, using a USB enclosure. There
is no constant activity to the enclosure when it is connected.
It's ready to do what you wish to it. It is treated as a data
drive, because it has not been used to boot the computer.

If you were to look in Disk Management, the swapped in drive has

+-----+-----------------+------------+
| MBR | ..."System" | ..."Boot" } === the drive being used to boot
+-----+-----------------+------------+ Windows writes to this C:
Recovered files go to this drive,
until recovery from the other drive
is complete.
+-----+-----------------+------------+
| MBR | | } === no special designations,
+-----+-----------------+------------+ now a "data" drive and ready
to be scanned with Recuva

Once you are sure you've Un-Deleted as many
files as the job requires, then it is "safe"
to write to the bottom drive, so that when
that drive becomes the main boot drive again,
the recovered materials are there for you to use.

You don't write to the bottom drive, until
you're absolutely sure each and every file
is intact, and no further forensics on the
bottom drive are needed. At that point, the
bottom drive is safe to write and update as
you wish.

Then, shut down the computer, and the bottom
drive can be put back inside the machine.

There is nothing special about being inside
or outside the machine. I'm just taking your
usual usage pattern into account. On my machines
here, pretty well all drive activity is
internal. If I needed to do this...

+-----+-----------------+------------+
| MBR | ..."System" | ..."Boot" }
+-----+-----------------+------------+
+-----+-----------------+------------+
| MBR | | } === needs UnDelete
+-----+-----------------+------------+

it would be done with two adjacent trays that
slide in. I would need to know the names and
sizes of the drive, so I booted from the
correct one (the un-damaged one) and not
boot from the damaged one. We don't want
writes on the bottom one.

When a file is deleted, its resources can be
reused at any time. We seek to stop writing to the
drive, to protect those resources. If the resources
have not been tampered with, Recuva simply flips
a single byte value in the $MFT and the file is
instantly available again.

If you continue to write to the drive and
don't act quickly enough (use the drive for the
rest of the day), the freed-up clusters from the
files that were deleted, they get overwritten.
Even if you flipped the byte in the $MFT, the
file is corrupt. It is for this reason that
the filenames have the colored dots next to them.
A file with a "red dot", is unfit for recovery.
A file with a "green dot" or all the files having
"green dots", means you stopped usage of the
drive soon enough to keep them green. All it
would take, is writing one giant movie file,
to overwrite all the deleted files and turn
all the dots "red" and nothing could be recovered.

You can flip the byte on a "red" file and make
the file appear again in the listing. But if you
do that, practically none of the original data
is inside it. It contains portions of other files
that have been stored. Thus, if you open the file,
your picture viewer crashes or there are other
anomalies. You have to check the files. If the
files had green dots next to them, testing the
files should take only a short time. If the
files are red, expect trouble, and the testing
is likely to fail (and hopefully, in not too
spectacular a fashion - *don't* run tools with
built-in automated repair capability because
they can make a mess of a file with random bits
of other files in it). To test a file, you want
dumb tools that don't take liberties with the files.

Your data is there, but it is only there until
the clusters get overwritten. Every write operation
on the partition with the problem, risks overwriting
the freed-up resources. That's why there is a rush
to stop using that drive for writes. And the OS
loves to write to the drive. The more modern the
version of Windows, the more it likes to write.
An accidental deletion then, the files will be
unrecoverable in a short time, if the OS is
writing stuff to C: . That's why, if you notice
files are missing several days or a week later,
it's not very likely they're coming back. They'll
all have red dots next to their name. Or, if the
$MFT entries get reused (which happens!), not even
the file names will be locatable by Recuva. I've
watched how the $MFT is used, and it really doesn't
take that long for the filename to disappear either.

The other technique is scavenging. That's when Recuva
doesn't work, the filename is missing or the filename
is there but has a red dot. You can use Photorec and
scan the drive for "fragments of files". But the
output is such a mess, don't waste the time. I tried
once. I got 100,000 chunks of stuff, that when opened
were all corrupted and useless. It's wishful thinking
to think doing more work than the Recuva approach,
is going to pay off. If the file is still mostly intact,
flipping the $MFT byte brings it back. If it's damaged,
there's a good chance it is never coming back.

I've tested undelete, by deleting a JPEG and immediately
doing a scan, and the file was located and had a green dot.
So it can work. But don't be "testing it", until your
recovery project is complete. Then you can be messing
around if you want. You'll only get the one chance to
get these back, so concentrate on that.

Paul


OK, I understand now,.....
I did do a search after reading John's post
and I did find the missing Folder/files

https://postimg.cc/0M83SSP7

I opened the one highlighted to confirm they were there.

If I understand you I'm suppose to remove the HD and put in another
HD then download Recuva then attach my original HD via USB
and scan it that way? Is that correct? Ok,.. here I go I hope I
don't screw this up.

Thanks,
Robert