On Sunday 03 December 2006 20:57, Landon Fuller wrote: > > 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, the > > digest/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.
No, sorry, but you have it backwards. You were passing blocks of zeros to the digest subroutines during the backup process. Those blocks are *not* written to the Volume, and thus they are not written to the disk during the restore. If they were written to the disk during restore some sparse files that have only one or two blocks could suddenly become monsterous. > > > 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. OK, thanks. I missed connecting your fix to the original reports. I'm pleased to see this fixed. > > > 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 data > > on 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 records > > twice. > > 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. OK, thanks. ------------------------------------------------------------------------- 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
