The file system stores the metadata separately from the data - the drive controller tells the host machine that it has 2tb of storage; the files all look like they are stored OK on the device, but when the controller tries to retrieve them, it’s addressing nonexistent storage for the contents.
Relieved to see this isn’t a factor in the issue described in this thread.
Here’s something you can try. It’s an online character dump. You upload the file and it shows what each byte is. Upload your file here:
https://www.fileformat.info/tool/hexdump.htm
You’ll see output that looks like this:
0000-02a0: 66 20 74 68-65 20 77 61-74 65 72 20-6f 6e 20 41 f.the.wa ter.on.A
0000-02b0: 75 67 75 73-74 20 37 74-68 20 61 6e-64 20 74 68 ugust.7t h.and.th
0000-02c0: 65 20 6e 65-77 20 6f 77-6e 65 72 20-77 69 6c 6c e.new.ow ner.will
0000-02d0: 20 73 74 61-72 74 20 68-65 72 20 61-63 63 6f 75 .start.h er.accouWhat it shows is this:
The numbers will look weird since they are in hex. Hex is a number system commonly used in computers. It goes from 1-16 rather than 1-10. But you can just look at the last column to see what characters are in the file. Sometimes if a byte at the beginning gets messed up it causes the text processing to get messed up. Having a zero or certain control characters might do it. The hex dump should allow you to see each and every character in the file from beginning to end.
Thanks. I’m quite conversant in hex, so much so that each of my hands grew three extra fingers . The dumps in that case just showed garbage. No way to resolve what happened now.
What you’re describing here sounds so different from the vi versions I’ve had experience with, as to not be recognizable as the same program. The last time I used vi, you started off in command mode, and needed to use a control-key combination (that was not listed on screen) to even get into editing mode, and then once in editing mode, to do anything other than editing (like, say, save the work that you’ve done), you needed a different control-key combination (which the program also didn’t tell you) to get back to command mode. I don’t think it even supported arrow keys, and it certainly didn’t support the mouse.
Are you really claiming that you use an infinite undo function in an editor as a type of source control? Please correct me if I have misinterpreted, but not in a million years would I think to use an editor function to access a revision from months ago. That job is for Git, Perforce, etc.
Of course not. But one thing I have done is made some minor changes in a program, commented some stuff out, saved the file, and done some testing, only to decide to open up the file again and undo the changes. Not months, but let’s say 10 minutes.
Here is a screenshot of the version I was describing:
You will notice the pull-down menu tabs and the toolbar at the top, and the mouse functionality.
But it is absolutely the same program you are describing, you can run it from a text-only “terminal” environment like the Command Prompt (in which the arrow keys still work, and also the mouse depending on the terminal emulator), and, yes, it still has the concept of “modes”, which if you don’t like then you don’t like, but is explained in the first minute of the new-user tutorial (hint: the “Control” key is not involved 
Unless you want to select a rectangular block of text rather than by lines, that’s control-v)
ETA I brought up Vim in this thread because I do use it for text editing tasks in Windows, for which it is more than suitable and not hard to use. And, what is relevant here, you will immediately be able to distinguish a file full of text from one filled with null bytes or other garbage. But many other text editors can do so as well, or you can use a hex editor, eg HxD - Freeware Hex Editor and Disk Editor | mh-nexus
Yes, I know you can use arrow keys. I am just so used to hjkl that I still use them.
Have you checked that the extension on the file is .txt ?
Yes.
I also switched the default program to open txt files from Notepad to Wordpad. But when either opens it, it’s blank.
I wonder if someone changed the extension of a non-text file to “.txt” as an asinine prank.
I’ve seen it happen.
Do you have a copy of the file from the OP? If so, what are the first few lines of the hex dump?
Is it whitespace? If you try Edit->Select All do you see any visible change in highlighting?
I second filmore’s post if you are still stumped.
If you are using notepad, try looking at the status bar at the bottom of the window and report back what it reads (for example, “Ln 1, Col 16 | 100% | Windows (CRLF) | UTF-8”). If you can’t see a status bar you can enable it in View->Status bar.
~Max
I’m not the OP. It’s not my file.
And if it’s white space you can move the cursor.
Since the printout was six pages long, I’m pretty certain that the hex dump suggested earlier will probably be enlightening.
That’s pretty much a non-possibility. This is my personal computer and I’m the only person who uses it.
And it’s not a mystery file. I remember writing it and naming it and it’s the same location where I put it.
Yes, it highlights the entire text window. But no text is visible.
I tried cutting and pasting the highlighted area and opening it in a new text file. That did not produce any results.
Ln 1, Col 1 | 100% | Windows (CRLF) | UTF-8
If I use the Select All command and highlight everything, I get:
Ln 1, Col 23998 | 100% | Windows (CRLF) | UTF-8
Not sure how you got there, but I’d guess if you opened it up in a hex editor, you’d see nothing but 20s. 23998 of them.
Perhaps a find/replace with a wildcard or something similar.
It’s certainly looking like the data I had in this file is gone. It’s not a huge issue. But I wanted to make whatever attempts I could to recover it before acknowledging it’s lost and deleting the file.
What does the hex editor/dumper show?
I’ve had a busy day. I’m trying out the simple possibilities today. I’ll consider the more complicated ones later.