Re: [Bacula-users] [Bacula-devel] Bacula status

[Kern S. <ke...@si...>]

Hello Landon,

On Monday 04 December 2006 05:22, Landon Fuller wrote:
> 
> On Dec 3, 2006, at 12:06 PM, Kern Sibbald wrote:
> 
> >>
> >> 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.
> 
> I've committed rewrite of the block-preserving encryption restoration  
> code that fixes all outstanding issues. The encryption regression  
> script passes 100%.
> 
> I know of a few remaining release critical bugs:
> 	- HFS resource fork restoration is broken. This will be easy to fix
> 	- Signature validation on sparse files is broken. To fix this:
> 		- We'll need to either validate signatures using the volume stream  
> (and include the sparse file block lengths for security). This WILL  
> change the data format.
> or
> 		- Continue validating signatures using the on-disk stream, revert  
> your digest change. Once the change is reverted, no data format  
> modifications are necessary.
> 	- Encryption does not currently support sparse files. This will be  
> easy to fix.
> 
> Is there anything I'm missing? I'm planning on having most of this  
> done by tomorrow.

I've now created some new sparse testing regression scripts.  Namely,
sparse-encrypt-test, which includes a real sparse file in the test (works only
    on Linux/Unix machines) and as the name indicates does encryption.
gigaslam-sparse-test, which includes a real sparse file in the test (works     
    only on Linux/Unix machines), no encryption turned on.

Warning when the test fails, Bacula can write over 2GB to your harddisk -- for 
the moment, it seems to write just a bit over 1GB.

Results:

gigaslam-sparse-test performs as I expect it to.

sparse-encrypt-test fails.  Here are a few remarks:
- the backup looks OK -- even the Volume size looks good.
- the restored filesize of the sparse file is wrong -- it is restored as 1GB
  rather than 120K.
- the number of bytes restored seems to be wrong and doubly so.  It should
  be something like 60MB, and I could imagine 1GB+, but it reports 2GB+. 
  I.e. even the broken size seems to be doubled.

Bottom line: this is consistent with what you said was implemented (i.e. you 
said that encryption does not support sparse files -- actually the problem 
seems to be in the decryption end).

I'm very pleased with the progress since now, the basic encryption code seems 
to work fine barring the problems you have reported.  I've turned the code 
back on, and it will be included in the next BETA release to be made in the 
next couple of days ...

Best regards,

Kern

PS: you need to do a cvs update on both the source code and on the regression 
scripts ...