[Dspam-devel] [ dspam-Bug Tracker-2943438 ] cssclean corrupts hashfile

[SourceForge.net <no...@so...>]

Bug Tracker item #2943438, was opened at 2010-01-31 15:48
Message generated for change (Comment added) made by bofh999
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=2943438&group_id=250683

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: daemon
Group: v3.9.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Enrico Scholz (ensc)
Assigned to: Nobody/Anonymous (nobody)
Summary: cssclean corrupts hashfile

Initial Comment:
cssclean.c makes

|    hash_rec_max = strtol(READ_ATTRIB("HashRecMax"), NULL, 0);
|
|  if (_hash_drv_open(filename, &old, 0, max_seek,
|                     max_extents, extent_size, pctincrease, flags))
|  ...
|  if (_hash_drv_open(newfile, &new, hash_rec_max, max_seek,
|                     max_extents, extent_size, pctincrease, flags)) {
|  ...
|  /* preserve counters */
|  memcpy(new.header, old.header, sizeof(*new.header));


This causes errors (e.g. a floating point exception due to division
by zero) or data corruption when the old file has a hash-rec size
(old.header.hash_rec_max) which is different from the configured one.

Such a situation happens e.g. when configuration has been changed or
'csscompress' has been run over the file.

Then, the hash-driver will work with 'hash_rec_max' some time but
when closing the file, the hash_rec_max value of the old file will be
written and subsequent operate on wrong hash divider and calculate
wrong offset of next extent.


----------------------------------------------------------------------

Comment By: Imposit.com Webmaster (bofh999)
Date: 2013-06-07 10:38

Message:
Many thanks

Since i switched to sbph i had to use the hashdriver
however i got major issues at first because the cssclean didnt worked in
the current version of zimbra

after adding the git version to zimbra i started to use cssclean and of
course csscompress - argh bad mistake

shot my database now 4 times to hell - well many thanks youve discovered
that one

so it means it should be fine if we not use csscompress?
whats the downsides? how big can it grow?
any safe way todo the compress at somepoint?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=2943438&group_id=250683