Ticket #20 (assigned defect)

Opened 3 years ago

Last modified 3 months ago

Temp files not getting deleted

Reported by: anonymous Owned by: decoder
Priority: minor Milestone:
Component: Don't know Version: 3.4
Keywords: Cc:

Description

Under certain conditions (that I have yet to discover) the temp directories created in /tmp are not getting deleted when FuzzyOcr? is done with its scans. This happens both with the 3.4.2 devel release and the 3.4.3 version of FuzzyOcr?.pm from the Source tree. The following are examples of successful deletion entries in the logfile and unsuccessful:

2006-12-05 15:34:58 [81691] Saved: /tmp/.spamassassin81691t9BsTytmp/raw.eml
2006-12-05 15:34:58 [81691] Wrote: /tmp/.spamassassin81691t9BsTytmp/be.png
2006-12-05 15:34:58 [81691] Errors to: /tmp/.spamassassin81691t9BsTytmp/raw.err
2006-12-05 15:34:58 [81691] pfile => /tmp/.spamassassin81691t9BsTytmp/be.png.pnm
2006-12-05 15:34:58 [81691] efile => /tmp/.spamassassin81691t9BsTytmp/be.png.err
2006-12-05 15:34:58 [81691] Calculating the image hash: /tmp/.spamassassin81691t9BsTytmp/be.png.pnm
2006-12-05 15:35:09 [81691] Remove DIR: /tmp/.spamassassin81691t9BsTytmp
2006-12-05 15:32:45 [81691] Saved: /tmp/.spamassassin81691MhW8rEtmp/raw.eml
2006-12-05 15:32:45 [81691] Wrote: /tmp/.spamassassin81691MhW8rEtmp/moiety.gif
2006-12-05 15:32:45 [81691] Errors to: /tmp/.spamassassin81691MhW8rEtmp/raw.err
2006-12-05 15:32:45 [81691] pfile => /tmp/.spamassassin81691MhW8rEtmp/moiety.gif.pnm
2006-12-05 15:32:45 [81691] efile => /tmp/.spamassassin81691MhW8rEtmp/moiety.gif.err
2006-12-05 15:32:45 [81691] Calculating the image hash: /tmp/.spamassassin81691MhW8rEtmp/moiety.gif.pnm

As seen the last message I receive regarding the files in that directory are that they are being scanned. No scan error messages are getting logged for these files.

Change History

Changed 3 years ago by decoder

  • status changed from new to assigned

What database backend are you using? If you are using the mldbm module, try disabling it, someone else reported a problem with mldbm causing something similar, but we weren't able to find out what happens there so far.

So your logfile on the one side shows in a successful case that the dir was removed, and in an unsuccessful case you get the "Calculating the image hash" line and then it dies (i.e. no more log)?

Best regards,

Chris

Changed 3 years ago by anonymous

I was using MLDBM; I went ahead and changed focr_enable_image_hashing to 1 instead of 2 and the problem disappeared; it would appear that the MLDBM routine(s) is/are causing the issue. And yes, you are correct with the logfile question: in the successful case it logs the Remove DIR event and removes the directory, in the unsuccessful case, the last event seen for the message is "Calculating the image hash" and the directory is left behind.

Changed 3 years ago by decoder

ok there is a problem with MLDBM then, which we will investigate. Additionally there is a known problem with images containing multiple images, that also causes leftovers. I will try to fix this asap :)

Changed 3 years ago by flimzy@…

This happens on multiple installations we have using FuzzyOCR 3.5.1 (from Debian etch) with image hashing completely disabled.

Changed 5 months ago by julien.combes@…

Hello,

I have the same problem of temporary directory not deleted with FuzzyOcr? 3.5.1.

I have added some infolog in FuzzyOcr?. The problem seems to be in MLDBM in the function Lock (MLDBM/Sync.pm).

The perl function "die" is used twice in function Lock. So I think that, in some cases, the function Lock die and Fuzzy temporary directory are not deleted.

Regards,

Note: See TracTickets for help on using tickets.