From: forgetski@_INVALID.net   
      
   On 9/20/24 09:25, Lew Pitcher wrote:   
   > On Fri, 20 Sep 2024 06:47:13 -0400, bad sector wrote:   
   >   
   >> Speaking of backups using rsync, I just did one and as usual I checked   
   >> the file sums to validate the results. In dolphin 'properties' I ended   
   >> up with ONE folder showing a discrepancy i.e. correct number of files   
   >> but total size being different.   
   >>   
   >> source 6.1 GiB (6,595,100,080)   
   >> target 6.1 GiB (6,595,108,272)   
   >   
   > This is not a definitive answer, but it is likely that rsync   
   > is expanding sparse files on you.   
   >   
   > To explain, you may have source files with "holes" in them;   
   > files in which the data is scattered across the file with   
   > empty space (nothing written) between blocks.   
      
      
   Thanks, this is advanced disk management mythology for me, much to rich.   
   I always thought that a file went from start marker to end marker and in   
   such a case I would think that if it were all zeros than the file was   
   all zeros, period. I did understand that similarly to windows   
   fragmenting a target could end up taking less space on disk. I'll have   
   to re-check if thos source/target numbers were not ack bassward :-)   
      
      
   > When /writing/ such a file, the system does not count the   
   > size of the "holes" in the file space allocation.   
   > When /reading/ such a file, the system substitutes a block   
   > of binary zero for each "hole" being read.   
      
   I used to use dd before but for data I'm just warming up to rsync, after   
   too many screwed up backups. The switches I use "-ahcEWXd" always gave   
   identical directories ...until now.   
      
   > rsync effectively reads the source file and writes the   
   > target file. If it reads a sparse file, it reads blocks   
   > of binary zero, When it writes the target, it writes   
   > that block of binary zero (unless you specify the -S   
   > flag), and the system counts that block not as a "hole",   
   > but as data that needs space allocated to it. In this   
   > way, /some/ files can become bigger when backed up by   
   > rsync.   
   >   
   > THIS MAY NOT BE YOUR SITUATION.   
   >   
   >> The other dozen or so folders were all exact matches.   
   >>   
   >> Doing   
   >> # perl -le 'map { $sum += -s } @ARGV; print $sum' -- *   
   >>   
   >> produced 6552446982 for both so sigh of relief.   
   >   
   > Can you explain the difference between perl's result   
   > (6552446982) and the either of the sizes reported by   
   > rsync (6595100080 and/or 6595108272)?   
      
   No, I never saw that perl line in my life before but it was a good   
   feeling that it reported the same number. Those first numbers were not   
   reported by rsync but by dolphin in 'properties'. The file sizes were   
   shown in both directories in dolphin in details view but there were too   
   many of them to compare one-by-one. If I knew of a way to isolate the   
   problem file I could maybe guess at what happened (IF I remember   
   correctly it was my photo collection and it could even be that that file   
   is just plain disposable. I do have the two directories on my desktop   
   deathstar, I'll be on it later in the evening after my daytime job ends   
   with supper.   
      
   >> I understand that disk usage is not the same as sum of file sizes but   
   >> WHY is du being used in dolphin properties dolphin being a FILE mangler?   
   >> If I want disk usage I might just click kdf instead.   
      
      
   --   
   "Computers are useless, they can only give you answers!"  Pablo Picasso   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)