Recovered .txt Files Have Scrambled Code and Meta Data in Contents.  

This file might be a key to figuring out how many bits things got pushed to the left or right. It contains the name of itself, as well as the names of other files and/or the folder "NOTEBOOKS"(?) which it was in. So... If anyone ever gets any guesses as to how many bits the titles and path directory of near by documents would roughly be from the file, perhaps that could be helpful. It certainly should not contain what it has in it. https://mega.nz/file/15diTbqA#2LkEM-...9oEuPsm-UE4qN4

---

That said, I've discovered audio albums are in perfect working order, photographs, PDFs, ODT (Open Document Format), seemingly all good. In the link I posted that was mentioning the bits being pushed left and right, they mentioned that .txt files are more vulnerable to data loss; however, 1 photo and a couple .rtf documents do seem out of order or damaged beyond usability. So... is the data really lost on the text documents if the vast majority of all other formats is just fine?

Sure a few images are dead, but that might have been because of the brief copying of data over them before I cancelled the file moving onto the drive. The oddity is, that almost everything is okay, it's mostly the .txt and a few .rtfs which are seemingly dead. Again, it's not that the TXTs are unrecoverable, because many are also recovered just fine. Why are many okay, and some are not? If it's really a problem with TXT being more vulnerable and harder to recover, wouldn't they all be corrupt?

I noticed, that opening some of the documents in Libre Office prompted a "Choose Character set" option. I tried with Unicode, Unicode 7, Unicode 8, and a few of the "Western" or English based character sets and all I got was the same well spaced paragraphs with different unreadable characters.

Remember one of those files posted, and a few others I've found, had contents which said the file's program(?) could not be used in DOS. The Linux recovery software I was using was on a DOS environment (I believe -- not sure). So... Was the Linux (DOS based?) recovery software simply unable to read them because it didn't have the linguistic support? Can they be recovered correctly and in intact form if we use a non-DOS recovery process, or something which support the format(character set) of the text files.
All of the text files were created with these settings:
That is "Format (Line ending):
Windows (CR LF)"
and "Encoding:
UTF-8"
and set to "Apply UTF-8 to opened ANSI files" which I guess means they'd be saved in UTF-8.

Based on my Sherlock Holms detective-clue-spotting skills, the Linux (DOS Based) recovery software could not read the Windows CR LF format. Am I wrong? I don't know, that's beyond my skill set.

Do I need a recovery software that can detect "Windows CR LF"? Perhaps I should try EaseUse again, or Disk Drill, or MiniTool, or any of the others with unhelpful help sections. Maybe if I offer to pay them they will be able to inform me about these technical details before purchase. ...Which of these companies uses expert tech-support instead of sales-people support?

- - - Updated - - -

This is one... The gibberish. I recognize this note because I was playing with it a week ago. The small note within, is the same size as the English note which was supposed to be there.
Can anyone translate this note? https://mega.nz/file/Zo1mgRZQ#Gd781M...6GxdpmHnbcysOU

Never mind if your English translation is not related to the the file name; the English text within is expected to be different as that's how it was originally saved.

"Help me Onlyone Kinobe
You're my only hope."

- - - Updated - - -

Trying out some character set detection... It's not going well.

Face it. The storage space previously occupied by the deleted files has been overwritten.
So the "recovered" contents are just gibberish. It's hopeless.

While I may disagree with your reasoning, I have been coming to the same conclusion.

Next steps:

Organize a few thousand files, verify each of them manually.
Sort-out the corrupted files.
Use recovery software with search and preview to find the originals; see if the results are better.
Keep attempting to save the files with various softwares until all are restcued, or the scans destroy the data.

Only then are these hopes lost ... @margrave55.

Are you a droid? Your name sounds like a droid.
"I hate droids." -ManDeLorean

Okay. Update for Educational Purposes:

Previously in this thread I had used my simpleton understanding to assume that if file meta data was seen so too should the the file contents -- I had ass-um-ed that the meta data was carried with the file, as a part of the file.

According to this, all the identifying meta data seen within the "rescued" files is probably discovered using i-nod data, not the file's own data.

File Metadata
The name of a file is metadata because it is a piece of information about
the file that is not in the stream of bytes that make up the file. There are
several other pieces of metadata about a file as well—for example, the owner,
security access controls, date of last modification, creation time, and size.
The file system needs a place to store this metadata in addition to storing
the file contents. Generally the file system stores file metadata in an i-node.
Figure 2-1 diagrams the relationship between an i-node, what it contains, and
its data.
The types of information that a file system stores in an i-node vary depending on the file system. Examples of information stored in i-nodes are the last
access time of the file, the type, the creator, a version number, and a reference
to the directory that contains the file

SOURCE: https://www.haiku-os.org/legacy-docs...tem-design.pdf

I am still wondering why i-nod meta got into the .txt, .doc, and .rtf files during rescue with various apps but the .jpg and .pdf which would be bigger and more scattered have no data loss.

The most important information stored in an i-node is the connection to
the data in the file (i.e., where it is on disk). An i-node refers to the contents
of the file by keeping track of the list of blocks on the disk that belong to this
file. A file appears as a continuous stream of bytes at higher levels, but the
blocks that contain the file data may not be contiguous on disk. An i-node
contains the information the file system uses to map from a logical position
in a file (for example, byte offset 11,239) to a physical position on disk.

It's weird to me that the small text based files with less chance of damage (smaller area for targeted damage) are the ones missing their data, while the large .jpg, .pdf, and .mp3 take up the biggest area on the disk and would be the most scattered on the disk yet are the least damaged and most easily rescued. Why is that?

Is there a txt i-node that was broken while all the .pdf and .mp3 i-nodes are not damaged?
I don't know, I wish I-knowed correctly. .