Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.linux    |    Getting to be as bloated as Windows!    |    107,822 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 106,502 of 107,822    |
|    Paul to bad sector    |
|    Re: Different directory file sums    |
|    20 Sep 24 18:41:49    |
      From: nospam@needed.invalid              On Fri, 9/20/2024 5:53 PM, bad sector wrote:       > On 9/20/24 16:06, bad sector wrote:       >       >> I'll have to re-check if those source/target numbers were not ack bassward       :-)       >       > This was bothering me so I checked and it's as reported       > source 6.1 GiB (6,595,100,080)       > target 6.1 GiB (6,595,108,272)       > with 2466 files and it IS my photo collection so there may well be some       images that are incomplete, you know like when you pull a usb stick too soon       while copying from it because some dumfuck uti says 'copy complete' when it       isn't.       >       >       >              Is there a way to do a sparse check, on the tree of files on the source end ?               https://unix.stackexchange.com/questions/612888/tell-if-a-fil       -is-a-sparse-file              The checksum or hash check should be correct if this is just a case of sparse       expansion.              This is an example of converting a non-sparse file, into a sparse one.       It requires that portions of the source file contains sufficient zeros       for sparse to remove them. If you want to make a test item, you can make       it that way. If you "cmp" these two files, there are byte-identical.               cp --sparse=always srcFile dstFile              If you want to make a file with some zeros in it, thee are various ways.       On some platforms, "mkfile" is a quick way (some make sparse files, some make       expanded files). dd if=/dev/zero of=testfile count=2048       would make a file you could "cp --sparse=always" to play with.              Any of the more complicated hash checks, is sensitive to how many       bytes go through the checker. md5sum, sha1sum, sha256sum will give a       radically different result, if a single character is missing. Only       sha256sum should currently be trusted for "suspected alteration" cases.       Whereas you're looking for trivial hardware failures, which any of the       three should detect for you. It's when a Black Hat sets out to deceive       you, knowing which checker you like to use, that you should be using       sha256sum. You will know when it is time to stop using "sha256sum",       because "Bitcoin will have just collapsed" and there will be a news article :-)               Paul              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca