Hi,
The isFailedFile is set in the decrypt function, basically it is a
flag to that is set to true if the file can't be decrypted or opened.
I originally only had the close in one location in the function, but
when I realized that my problem seems to be tied into a pdf document
left open, I ended up putting it wherever there was a possibility that
the function exits before closing.
Upon investigating further, it looks like a temporary scratch file
that pdfBox creates while loading the document is not always closed or
deleted after calling doc.close(). For every instance I see of a
temporary pdfBox file, I get a corresponding warning that I did not
close the PDF Document.
For example, when I call the function 10 consecutive times on a list
of files, I find that there are two pdfBox[some numbers]tmp files
created and I get 2 warning messages. However, with 10 consecutive
calls to the function, all files open fine.
When those same 10 files are located further in a the list of 112
files, i.e. 30 and is the 30th call to the function, it no longer
opens and IOException is thrown when I try to decrypt the file and
most all of the subsequent calls to the function also fail likewise.
Occasionally one of the temp files is closed (I'm not sure how or
where) and the next call to the function works fine.
Here is the code for my decrypt:
if( doc.isEncrypted() ) {
try {
doc.decrypt( "" );
}
catch( InvalidPasswordException e ) {
failedReason = FailedReason.PASSWORD;
isFailedFile = true;
}
catch(CryptographyException e ) {
failedReason = FailedReason.PASSWORD;
isFailedFile = true;
} catch (IOException e) {
failedReason = FailedReason.BADFILE;
isFailedFile = true;
}
}
Is there anywhere to force pdfBox to clear it's temp files? I've
tried to delete the files after they are created while I am in debug
mode, and I am not allowed to as pdfBox is still maintaining some tie
to the temp files although they should have been closed.
-Sophia
--
~~~~~~~~~~~~~~~~~~~~~~~~~
Aim for the moon. If you miss, you may hit a star. -W. Clement Stone
