Elektrine lite

← Feed

@keirFox@tiggi.es

Post #630727

2026-03-11 23:37 UTC

Help. Please. I have a terrifying thing happening and I don't know how to deal with it -- files on my Linux Mint install are having their contents replaced with NULs. Just... everything. Now and then it's an image here and an image there, but things are slowly being eaten. And it seems to happen to completely random things -- not just stuff I have open at any given moment, but random files buried in folders from ages ago. I've already lost at least a dozen images from my archives and have no idea how to prevent it. Edit: think I found it after checking for a pattern. Don't hold the power button down unless you absolutely have to, kids.

Replies (14)

  • @keirFox@tiggi.es 2026-03-11 23:41

    The files still have the original size as far as I can tell, but there's not any actual content. "You should keep backups!" I do. The problem is that I don't have enough storage space to keep many copies of all my files over and over. I don't have any way to catch this happening -- the files don't zero out in size so I get no warning until I attempt to open them.

    Open ##1555921

  • @sutter@meemu.org 2026-03-11 23:38

    @keirFox Yikes. I've got nothing, but I'll boost in case anyone following me knows.

    Open ##1555923

  • @keirFox Might be something with your disk? I'm on Ubuntu now, but doesn't the disk utility give SMART diagnostics? I guess malware could be a possibility too.

    Open ##1555948

  • @herzenschein@furry.engineer 2026-03-11 23:52

    @keirFox I can only imagine three things (and people already mentioned them): failing hardware, filesystem corruption, malware. I'd check for them in that order according to likelihood.

    Open ##1555963

  • @qualia@floofy.tech 2026-03-11 23:53

    @keirFox in addition to the other suggestions below, silent data corruption like this could also be a byproduct of bad RAM. memtest86+ is the go-to tool here, you can likely do sudo apt install memtest86+ and then it will show up in your GRUB boot menu next time you reboot; letting it run for 24H is the ideal but usually seriously misbehaving RAM reveals itself in just one run what filesystem are you using? what kind of hard drive is all this happening on? (e.g. ssd, nvme ssd, spinning rust) do all the affected files exist in one specific directory (e.g. a photo library) and do you know if you have any kind of indexing scanner thing running on them? is it affecting any non-image files?

    Open ##1555964

  • @keirFox that's scary. i've heard of stuff getting zeroed on ext4 but it's always open files during a crash, this is a complete wtf to me i don't have any good suggestions. if you have a folder full of files you know should never change, run chattr +i * on them (might need sudo, be careful where you run it). that's as close to permanently read-only as you can make things without touching really esoteric stuff, so if it keeps happening you'll at least know for certain it's not some regular program

    Open ##1555967

  • @bipolaron@scholar.social 2026-03-12 00:27

    @keirFox that's horrible. If you do 'sudo dmesg' it may find a clue. My recommendation is to prioritize remounting the filesystem as read only and not touch it, the below should forcibly remount it as read only. mount -f -o remount,ro /mount/point I wouldn't suggest this except experience rebooting or shutting down is often that it never starts back up. Read only mode may buy you time to get a replacement drive and external drive enclosure so that you can copy over your files.

    Open ##1555972

  • @FleurC@jam.xwx.moe 2026-03-12 00:30

    @keirFox Would suggest you access the files from a Linux Live Image on a USB so you can save the remaining files. Then reformat. This could be a virus or a bugged update.

    Open ##1555980

  • @rakslice@mastodon.social 2026-03-12 01:16

    @keirFox what kind of storage device is this on? what filesystem are you using?

    Open ##1555982

  • @compucat@im-in.space 2026-03-12 01:35

    @keirFox Basic info: what is the model of the disk, and what filesystem is in use?

    Open ##1555993

  • @baralheia@dragonchat.org 2026-03-12 02:11

    @keirFox In addition to other ideas that have been mentioned, one thought from experience - are you using any sort of automatic cloud backup software? I once had an issue with my cloud sync software nuking files (which then the software dutifully synced the then changed file up to the cloud corrupting the cloud backup too). Worth checking if you do.

    Open ##1555994

  • @cy@fedicy.us.to 2026-03-12 02:50

    If the file system supports extended attributes you can (as root) change your files to be immutable like... # cd archive; find -type f -exec chattr +i {} + Under no circumstances ever are programs supposed to remove immutable, and while it's there, nothing can write to or delete the file. Another (more portable) way to prevent naive programs trying to modify files is like: # cd archive; find -type f -exec chmod a-w {} + In that case, the superuser can modify the file (which is why you never run programs as superuser) but everyone else (even the owner) can't modify it without adding write access back.

    Open ##1555996

  • @Canageek@wandering.shop 2026-03-12 02:57

    @keirFox Oh yikes, I thought modern file systems were designed to avoid that sort of problem

    Open ##1555997

  • @ljwrites@writeout.ink 2026-03-12 04:18

    @keirFox I'm glad you found the issue! Any luck on recovering the affected files?

    Open ##1555998