With the latest James, when using the standard filestore for mail storage, messages are not deleted after retrieval by a pop3 client. If the client retieves a message, then chooses to delete it and then logs out the ".fileobjectstore" file will get deleted but the ".filestreamstore" file will not be removed because it is locked.
This is potentially serious because the mailserver, if left on for a while, could fill up the harddrive with messages, even if they should be long gone. A restart of James will clear old ".filestreamstore" files when the user checks their mail again. This seems to also be specifically a problem sparked by the pop3handler's doRETR() method. Before that, the file can be deleted and isn't yet locked in use. I looked for opened streams and didn't find any obvious ones that could cause the problem. Incidently though, I did find in MailImpl that the writeContentTo() didn't have a br.close() and maybe that should be added for times where writeContentTo() is used. Also, is anyone debugging James with an environment like JBuilder? Is it possible to run James without going through the sar loader? I would like to be able to run James in debug mode but with Avalon doing the startup I am not sure how. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
