home bbs files messages ]

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