On 23 Jul 2007 at 21:57, Doytchin Spiridonov wrote: > 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?
Test the backups. Backup one file. Restore. Backup N files. restore. Backup N directories, restore. Find a simple and reproducible situation which demonstrates the problem. > 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? There is a section in the manual regarding database tables. I suspect you want the File Job table, but I cannot recall from memory. > - 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?) I don't know. > - 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? Someone sugested you verify your filesystem (e.g. fsck). Have you done that? I suggest avoiding trying to answer your above questions. Concentrate on the following. My suggestion, as was made by others, is to find something which can be reproduced. Developers cannot solve the problem if they cannot reproduce it. -- Dan Langille - http://www.langille.org/ Available for hire: http://www.freebsddiary.org/dan_langille.php ------------------------------------------------------------------------- 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
