On Dec 3, 2006, at 11:41 AM, Kern Sibbald wrote:
On Sunday 03 December 2006 19:46, Landon Fuller wrote:It would be negligent of me if this feature isn't ready for release; what are the remaining blockers that you are concerned about?Well, for example, the digest/signature routines were passing sparse blocks (blocks that do not exist and are read as zeros) to the digest routine.These blocks are not written to the tape, so in doing a restore, thedigest/signature will not match because those sparse blocks are never seen.I fixed this particular problem.
Signature validation is done on what is actually written to disk (upon restore). Thus sparse blocks will be read() as zeros, and the signature would be correct.
There were also reports from some users (and if I am not mistaken, you confirmed them or were at least going to look into it) that reported digest/signature problems.
This was due to attaching empty digests to directories, which obviously couldn't be validated. I committed a fix for this last weekend, IIRC.
There is also a sort of inconsistency in how the new record size is prepended to records written to the Volume. Each record that is passed to update is prepended with the length, but there is no such length prepended to the finalize call, which means that when reading the records back, the last block length for a data record will not point to a block length but into encrypted data (if all goes well, it will point past the last real byte of data).What is the remaining (potential?) volume format incompatibility?The current algorithm that is implemented in restore.c is not working -- possibly because of the problem with prepended record lengths, or possibly due to the fact that the code decrypts at times in 16 byte chunks, which has nothing to do with the actual records it is getting. In any case, some data is not restored correctly. This means that there is a possibility that the data is not being written to the volume correctly or that we need more dataon the volume (i.e. the last length record I mentioned above).As far as I can tell the restore code decodes the same data for some recordstwice.
These two issues appear to be due to some bugs in Robert Nelson's new blocking encryption restore code. I'm going to spend today fixing remaining issues there.
-landonf
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
