Hello Dan, Monday, July 23, 2007, 9:35:05 PM:
DL> Devel is aware of the issue as it was originally raised in the bug DL> tracking system. The consensus was it is not a bug, or more DL> correctly, there was no information supplied which permitted DL> reproduction of the bug. If we can't reproduce the bug, we sure DL> can't test for it, and we sure can't confirm it's been fixed. Can you provide some guidance on how and what to test? As I personally don't have any idea what data is stored in the Catalog, what is in the Volumes, regarding the problem of wrong file size: - does Bacula store the file size somewhere and if so where? how to extract that/those numbers if they are at more than one place? - how then the file could have larger size? (for example there is a GZIP stream, you unpack it and you get larger result or what? or the second (wrong) number is the number stored in the volume?) - do you agree that it is strange that while the stream is gzipped, the appended data is part of a real file? If the volume were damaged, I guess the additional data should be some garbage? Also is it possible that the file is restored OK, but only its size is set to a wrong mumber and we've seen some data previously existed in the disk? Or bacula has some internal buffer this additional part was from a file restored just before the wrong one? Regards. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
