Today had some important markdown file that accidentally deleted on my SSD and had to go over the recovery of it.

All I did was this:

run sudo systemctl status fstrim.timer to check how often TRIM runs on my system (apparently it runs weekly and the next scheduled run was in 3 days)

run sudo pacman -S testdisk

run sudo photorec

choose the correct partition where the files were deleted

choose filesystem type (ext4)

choose a destination folder where to save recovered files

start recovery

10-15 minutes and it’s done.

open nvim in parent folder and grep for content in the file that I remember adding today

That’s it - the whole process was so fast. No googling through 10 different sites with their shitty flashy UIs promising “free recovery,” wondering whether this is even trustworthy to install on your machine, dealing with installers that’ll sneak in annoying software if you click too fast, only to have them ask for payment later. No navigating complex GUIs either.

I was so thankful for this I actually donated to the maintainers of the software. Software done right.

  • redjard@lemmy.dbzer0.com
    24·
    2 days ago

    Last time I deleted a plaintext file I just grepped for it.
    cat /dev/nvme0n1 | strings | grep -n "text I remember"

    Had to hone in on the location with head -c and tail -c after I found it, then simply did a cat /dev/nvme0n1 | tail -c -123456789012 | head -c 3000 > filerec and trimmed the last filesystem garbage from the ends manually.

    • Gobbel2000@programming.dev
      5·
      2 days ago

      That was so eye-opening for me when I figured out you can just grep a block device for files unlinked by the file system but not yet physically overwritten. Magically reanimating lost files can be such an incredibly simple operation.

      • redjard@lemmy.dbzer0.com
        2·
        2 days ago

        I don’t like to use < in combination with pipes, I find it harder to read. One is left to right the other right to left, and < is also just plain weird in its specifics.
        cat is a stylistic choice avoiding needless notational complexity

        • MonkderVierte@lemmy.zip
          2·
          2 days ago

          strings /dev/nvme0n1 | grep -n "text I remember"

          tail -c -123456789012 /dev/nvme0n1 | head -c 3000 > filerec

          No need for < complexity either.

          • redjard@lemmy.dbzer0.com
            2·
            2 days ago

            Oh right I misunderstood.
            I didn’t do that because I was planning to switch out strings in that line. First inserting the tail and head before it to hone in on the position, then removing it entirely to not delete “non-string” parts of my file like empty newlines.

            cat /dev/nvme0n1 | strings | grep -n "text I remember"
            cat /dev/nvme0n1 | tail -c -100000000000 | head -c 50000000000 | strings | grep -n "text I remember"
            cat /dev/nvme0n1 | tail -c -123456789012 | head -c 3000 > filerec

            This would be the loose chain of commands I went through, editing one into the next. It’s nice keeping the “constants” like the drive device that are hard to type static. That way mentally for me the command starts only after the first pipe.