hi
could you add verification when copying files something like teracopy
thee
today i discovered some bad sector while copying the hard way
i was used to use teracopy in windows and i wish if i had something a like in linux integrated in the DE
it maybe look like a trivial feature but it’s very important
i am aware of rsync but if i would use rsyc for all my workflows that wouldn’t be very practical especially on daily usage setting
this feature would help a lot detecting any bad sectors before it’s too late
in my case i was writing to encrypted container and this file is now completely unrecoverable thankfully it’s nothing important it was redundant file and can be regenerated. i know it’s on me for not using rsync it’s just it would have been nice if KDE added this in it’s copy mechanism even as a option that’s would be awesome i think it would be huge help for a lot of people
If you use a file system that include integrity checks you get this feature without needing anything special from the apps you use. For example btrfs does this.
If you mean bad sectors on the physical disk then that should have been reported to you. And you will need to replace that disk.
that’s not always a option for computability reasons
and that won’t be applicable to removable media like sd cards and flash sticks i can go on but my point still stands
The root cause of silent data corruption isn’t always identifiable, and S.M.A.R.T. doesn’t reliably catch it — bad sectors can go unreported for a long time.
I’ll use my own case to illustrate why verification needs to be a standard part of any copy tool, not an afterthought.
I was using Cryptomator, which provides a transparent encryption layer on top of FUSE. This introduces multiple points of failure:
- RAM corruption: If the corruption happens in memory before the write, the filesystem can’t detect it — the data it writes and later checks against is already corrupted. Only a verification step that compares against the original source (not the in-memory buffer) would catch this.
- Controller-level corruption: If the disk controller introduces the error, the filesystem may detect it but can’t fix it. A post-copy verification pass would at least allow a retry, or inform the user immediately instead of leaving them unaware.
- Log-based detection is too late: Filesystems will log these errors, assuming you’re even collecting logs — but by the time you discover the log entry, the damage is already done and the corrupted copy may already be in use or backed up elsewhere.
I could list more scenarios, but the underlying point stands: every copy tool should have built-in verification, not rely on the user to catch corruption after the fact via unrelated logs or S.M.A.R.T. reports.
I can’t change how storage hardware behaves, but I can help make the desktop environments we use better.
I have a programming background (not highly experienced), but if maintainers or developers are willing to give some direction, I’d like to contribute to implementing this feature myself.
Why not?
Where are the checksums that allow the corruption to be spotted going to come from if not a file system like btrfs (and xfs maybe)?
these filesystem introduce too much overhead to these drives beside the computability issues i have mentioned
like using it on non Linux machine for example
it looks like you didn’t read my post carefully
anyway i explained my point to extended degree
How do you see the corruption being detected if not by using a file system designed to do the detection?
by comparing against the original file after copy like resync do (comparing the checksum or any other method)
You use case is that you want to have the written file verified.
You do not want to be able to detect corruption at a later date.
For example if the media goes bad after the verification?
it could be used for that too if it detect the file existed.
it can ask to verify it, for example rsync do that too.
if the file exists it will compare it and if it’s corrupted it will fix it
however if you no longer have the original file that’s a completely different case you can at this point use par2 and maybe as a second irtation on highly sensitive data KDE give the option to generate par2 files
ironcly i had par2 files and checked against it but because the corruption happed before the generation of par2 files.
i couldn’t recover these files
to be honest.
i am surprised why there is not many people talk about this.
the most important thing in your computer is data
there is standing bug KDE doesn’t warn you when it uncompress corrupted zip file using Ark which it should (ask me how i discovered this) and you will end up with corrupted file without any warning and last time i checked it’s not fixed and now i need to test the integrity of every zip file manually because you never know
i feel there more attention to UX/UI than the underlying technical problems
in my opinion the DE is not just a UI, it’s a interface to how you use your system and we should strive to make it better.
I back my systems using duplicity to my RAIDed file server.
I know and trust that the data is saved matching the originals.
I test the backs to be sure of this.
Periodically I copy the backups from the file server to external HDD.
The HDD is encrypted and stored off-site.
What you are asking for does not appear to add any extra security for my data.