-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Q - bcMail temporary files are created under /tmp directory and not deleted #103
Comments
Thanks for the report. It seems to be very similiar to http://bouncy-castle.1462172.n4.nabble.com/Increasing-number-of-bcMail-mime-in-tmp-td1468333.html |
Ah okay. I see it. In the decryption when using |
I've created a 4.5.4 SNAPSHOT that should resolve this issue. Can you please check that? |
Hi Philip, Many thanks for the fast response! Thanks, |
Hi Avner, |
Hi Philip, Unfortunately not, I apologize for not testing it yet as we had some urgent issues. I will update you once tested. Regards, |
No worries, take your time. |
Hi Avner, |
Hi Phillip, |
Thanks for responding so quickly. |
Hi Phillip, Thank you for your patience. Thanks for the quick resolution!! Regards, |
Hi Avner, |
Hi Philip,
We use as2-lib, I noticed it is also using bcmail library.
When a file is uploaded to the as2 server (on linux), a copy of each uploaded file is created on his “/tmp” directory.
The filename pattern is “bcMail.mime”
It has the same size of the uploaded file.
The file is not deleted after the transfer is completed.
For example, if you upload 200 MB file, both the destination folder and the /tmp directory will have a file with size 200 MB.
The issue is that the /tmp directory is filled up with these files and user is concern about disk space.
I noticed SMimeUtil is generating these temporary files (but doesn’t delete them once processed or deleteOnExit). I also read that deleteOnExit doesn't always work or can cause issues (and in any case, we need the files to be cleaned before the JVM goes down, as the server is running for a long term).
We think a "use then delete-when-finished" approach is better than keeping this backup file forever.
Might it be that you should use SMIMEUtil.toMimeBodyPart(CMSTypedStream, File) instead?
IMHO, the backing file should be disposed of when it's appropriate (something like a DestroyableMimeBodyPart).
Thanks,
Avner
The text was updated successfully, but these errors were encountered: