Re: [BackupPC-devel] auto-create caches on first sync -> V 4.0

[Jeffrey J. K. <bac...@ko...>]

Fresel Michal - hi competence e.U. wrote at about 20:54:01 +0100 on Wednesday, March 23, 2011:
 > hi Jeffrey,
 > 
 > > If checksum caching is on then the checksum is stored at the end of
 > > the compressed file. So the file does *not* need to be decompressed.
 > > Technically, the checksum is only added to the file the 2nd time the
 > > file is encountered which I imagine is probably due to the fact that
 > > the native rsync algorithm only transmits the block and full file
 > > checksums when the file already exists (otherwise perhaps only the
 > > full file checksum is transmitted)
 > 
 > as i like your BackupPC_digestVerify with the "-a Add rsync digests if missing" ...
 > 
 > what about to give the user the abillity to auto-create these caches on the first run (meaning that part of your script to be included in main)?
 > Maybe some users want the penalty of a longer "first initial backup"?
 > 
 > some kind of checkbox "autocreate checksums on new files" (defaults to no)
 > + FAQ-Entry: - this function will create checksums on first creation and not as usual on the 2rd sync
 > ???
 > 

I'm not sure of the purpose of this discussion. Craig is rightly
devoting his energies to 4.0. The discussion here seems to be about
adding new capabilities to 3.x. Other than bug fixes, I'm not sure you
will get much traction around adding new functionality to 3.x no
matter how simple and/or beneficial it may be.

In part, that is why I have focused on writing my own independent
routines to add functionality that I need. But I have stayed away from
changing the core 3.x code and functionality.

Some of your other emails address 4.x functionality which seems to be
a better place to have these discussions. 

Regarding your proposal of adding a .info file for each pool entry, I
have thought of similar approaches but at the end of the day I worry
that it adds additional complexity and room for error without much
benefit over a more clever encoding and naming of regular pool
entries. In particular, I am not crazy about the idea of effectively
doubling the number of pool files by adding .info files.