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 attachment 138068 [details, diff] 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 attachment 138070 [details, diff] 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.
