WARNING! Move/Copy NOT atomic! (Actually it is, but in a bad way)


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 :face_with_symbols_over_mouth: were they erased!

1 Like


  1. 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.

  2. 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.
  3. 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. . . .


The display WAS  “jammed”.  (Whew!)  Letting it sit overnight and all day today appears to have cleared up the problems.