Bugzilla Bug 201656

The housekeeping jobs (dspam.cron) calls cssclean and csscompress to clean the
*.css files. 

1. csscompress gives an error when /tmp is mounted seperately cause the
temp-file is just renamed:
rename(/tmp/12233.css, /var/spool/dspam/data/local/dirk/dirk.css): Invalid
cross-device link

Solution: Save the temp css file in the same directory as the real css file.
The temp file has the name PID.css so it will not conflict with any other file
name (see cssclean.c).

2. csscompress: no lock file is written. Is that needed

3. cssclean: lock file is in wrong directory:
open("/var/spool/dspam/data/local/data/local/dirk/dirk.lock",
O_WRONLY|O_CREAT|O_APPEND, 0666) = 3
open("/var/spool/dspam/data/local/dirk/dirk.css", O_RDWR) = 4

4. cssclean: File permissions of *.css files are wrong after usage:
-rw-r--r-- 1 root root  4837344  8. Dez 08:44 dirk.css

Before running cssclean it was: -rw-rw---- 1 dirk dspam

5. cssclean re-initializes the header counters thus causing dspam to return to
training mode even though there is a good history remaining. 
dirk
    TP:     0 TN:     0 FP:     0 FN:     0 SC:     0 NC:     0

Solution: 
> filepos += sizeof(struct _hash_drv_header); 
> } 
> + bcopy (old.header, new.header, sizeof(struct _hash_drv_header)); 
> _ hash_drv_close(&new);


Reproducible: Always

Steps to Reproduce:

*** Bug 201660 has been marked as a duplicate of this bug. ***

1 and 2) csscompress should probably be removed.

3) I will attach a patch shortly

4) that is impossible. cssclean preserve owner, group and mode of css files.

Created an attachment (id=138068) [details]
cssclean.patch

Please do the following:
  ebuild dspam-3.8.0-r8.ebuild unpack
  apply this patch
  ebuild dspam-3.8.0-r8.ebuild merge
and see if it solves cssclean's problems.

Created an attachment (id=138070) [details]
cssclean.patch

Improved patch.

1. solved
3. lockfile is in same directory as *css
4. csscompress is changing permissions -> my fault
5. headers are fine

If cssclean is doing the job we should remove csscompress from dspam.cron?

csscompress still lacks lock file, preserve owner, .... and header. At least
the delete header bug should be fixed.

Thanks for your help!

Fixed in -r9, which no longer installs csscompress.

Why so fast?

cssclean and csscompress do not do the same.
cssclean: rebuilds the hash database, omitting hapaxes.
csscompress: compresses a hash databases extents.

Using cssclean degenerates the learning because hapaxes tokens get deleted.
csscompress on the other hand just compresses the hash databases extents.

It is not exactly the same.

The only difference between cssclean and csscompress is hapaxes removal,
therefore the csscompress execution in cron script was of no consequences. 
While I agree that hapaxes shouldn't be removed on a daily basis, having
another program that simply don't do that is hardly a solution. The solution
would require a "last update" field stored in hash records.

(In reply to comment #8)
> The only difference between cssclean and csscompress is hapaxes removal,
> therefore the csscompress execution in cron script was of no consequences. 
> While I agree that hapaxes shouldn't be removed on a daily basis, having
> another program that simply don't do that is hardly a solution. The solution
> would require a "last update" field stored in hash records.
> 
The CSS (CRM114 Sparse Spectra) storage does not have that feature. Date/time
is irrelevant for CSS.

(In reply to comment #9)
> The CSS (CRM114 Sparse Spectra) storage does not have that feature. Date/time
> is irrelevant for CSS.

This field would be used only for deciding if hash records can to be removed or
not. Otherwise you get stuck with this half baked cssclean.

(In reply to comment #10)
> (In reply to comment #9)
> > The CSS (CRM114 Sparse Spectra) storage does not have that feature. Date/time
> > is irrelevant for CSS.
> 
> This field would be used only for deciding if hash records can to be removed or
> not. Otherwise you get stuck with this half baked cssclean.
> 
I know but this would break the compatibility to CRM114.