I discovered something nasty today that I want to warn you about.
The scene:
I am testing the issue where updating GPGOS causes a loss of functionality. As a consequence I have accumulated a lot of files and directories on my project files partition.
Today, I decided to organize things to make things easier to find so I created a “SSD” directory and then tried to move all the directories that had subdirectories with all the rsync’d data in them.
Silly me, I did NOT use a root-level file manager and used the default user level file manager to do the move.
Result: A bunch of permission errors.
Second result: Even though the vast majority of the files did not copy properly to the destination, they were deleted from the source! - resulting in a whole lot of work lost.
I immediately shut down Charlie and moved the SSD to a different Linux system where I installed a utility called “testdisk” which - supposedly - can find and restore lost files and directories. It’s currently churning and appears to be finding at least something.
Fair warning! COPY first on a Raspberry Pi and then delete!
What’s amazing is that the files didn’t copy because they were owned by root; ergo, permission errors. What I want to know is how the were they erased!
Magic word: “testdisk”
I don’t know how, but it actually can, and does, try to undelete things from ext2/3/4 filesystems. You can install it using apt install testdisk.
The filesystem wasn’t actually damaged, but things DID get cross-linked in interesting ways, causing some of the attempts to restore to contain what was, for all intents and purposes, a recursive link to the content of the entire partition. (ouch!) I got around that by selectively undeleting things.
Just to make sure “there ain’t no bears in them-thar woods”, I moved everything off the partition, reformatted it, and then put everything back.
Though I was able to recover much, these files are, (IMHO), “tainted”, since I cannot guarantee that they are 100% pristine. Therefore I am going to:
Go back and re-create the original operating system test-sets. I am also going to try to document things, (in my test notebooks), more carefully.
Use a different SSD, (of the same type), to act as a backup repository for everything I do.
Remember to re-enable TRIM on all the SSD data sets.
Because I have a “99 & 44/100% pure” copy of the original data, I can recover much of the work I did which will save a lot of time.
One of the things on my “Bummer!” list is the fact that, while trying to recover the data, I may have inadvertently smoked my small e-ink display HAT by plugging it in incorrectly, (and yes Alan, I even checked!). Depending on the technology involved it may be well and truly smoked, or it might just be “jammed”.
I am going to wait and see what happens and - if necessary - replace the part. However, this isn’t a high priority right now.
We will see. . . .
Update:
The display WAS “jammed”. (Whew!) Letting it sit overnight and all day today appears to have cleared up the problems.
were they erased!