The only reason I can think of that would result in a corrupt gzipped aide.db (and not in a corrupt/incomplete plaintext aide.db) is when aide exists before gzclose() is called. Plaintext aide.db is flushed after every line, for gzip this is skipped because it degrades the compression a lot. I looked through the code, and there is no way for gzclose() not to be called when aide exists normally. So I expect aide to abort() at some point without it being obvious in the output on stderr. There are too many cases where abort() is used, so I cannot find the root cause at this time.
What I did to try and work around the issue is close aide.db as soon as possible (before the reporting is done). So basically, when a report (with or without differences found) is printed you will know gzclose() has been called, and the aide.db.new normally closed. This change is now in CVS and will be in aide-0.12-rc2. Another important thing to note is that the real problem (the aide.db being corrupted) occurs in the "aide --update" before the "aide --update" (or "aide --check") that reports the many added files. It would be very interesting to see an "aide -V255 --update" that actually created the corrupt aide.db.new. Sincerely, Richard van den Berg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
