On Thursday 5 September 2024 11:53:16 BST Dale wrote: > Michael wrote: > > On Thursday 5 September 2024 09:36:36 BST Dale wrote: > >> I've ran fsck before mounting on every file system so far. I ran it on > >> the OS file systems while booted from the Live image. The others I just > >> did before mounting. I realize this doesn't mean the files themselves > >> are OK but at least the file system under them is OK. > > > > This could put your mind mostly at rest, at least the OS structure is OK > > and the error was not running for too long. > > That does help. > > >> I'm not sure how > >> to know if any damage was done between when the memory stick failed and > >> when I started the repair process. I could find the ones I copied from > >> place to place and check them but other than watching every single > >> video, I'm not sure how to know if one is bad or not. So far, > >> thumbnails work. o_O > > > > If you have a copy of these files on another machine, you can run rsync > > with --checksum. This will only (re)copy the file over if the checksum > > is different. > > I made my backups last weekend. I'm sure it was working fine then. > After all, it would have failed to compile packages if it was bad. I'm > thinking about checking against that copy like you mentioned but I have > other files I've added since then. I figure if I remove the delete > option, that will solve that. It can't compare but it can leave them be.
Use rsync with: --checksum and --dry-run Then it will compare files in situ without doing anything else. If you have a directory or only a few files it is easy and quick to run. You can also run find to identify which files were changed during the period you were running with the dodgy RAM. Thankfully you didn't run for too long before you spotted it.
signature.asc
Description: This is a digitally signed message part.
