pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Butaye <damien.but...@gmail.com>
Subject Re: PDFBox*.tmp files not deleted by PDFParser
Date Wed, 25 May 2016 10:11:23 GMT
Hello Tilman,

 For your information I found a workaround to avoid the problem of tmp file
deletion. In the SignatureOptions object, I modified the method  *public
void setVisualSignature(InputStream is)  *with the following content :

      RandomAccessBufferedFileInputStream tmp=new
RandomAccessBufferedFileInputStream(is); --> NEW LINE
         PDFParser parser = new PDFParser(tmp);  --> NEW LINE
         parser.parse();
         visualSignature = parser.getDocument();
         tmp.close();  --> NEW LINE

Tmp files are well deleted and all unit tests passed without error on the
pdfbox maven project.
If you think it's not a good solution, don't hesitate to tell me.

Thank you.


2016-05-25 10:01 GMT+02:00 Damien Butaye <damien.butaye@gmail.com>:

> Hello Tilman,
>
>  Yes I did it. I verified in debug mode and this method (close() on
> SignatureOption) is well reached but the close() method of the object
> "RandomAccessBufferedFileInputStream" is never called, so the tmp file is
> never deleted.
> The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of
> the COSParser but this method is not called. It seems this method is called
> only in case of "xref stream" (line 286 COSParser) , why not in other case
> -> xref (line 218 COSParser)?
>
> Damien.
>
> 2016-05-24 20:10 GMT+02:00 Tilman Hausherr <THausherr@t-online.de>:
>
>> did you close the options object?
>>
>> Tilman
>>
>>
>> Am 24.05.2016 um 15:51 schrieb Damien Butaye:
>>
>>> Dear all,
>>>
>>>    I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the
>>> process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp
>>> directory (RehHat server). This file is not deleted after completion.
>>> After some checks, it seems that the object responsible of the file
>>> creation is  "RandomAccessBufferedFileInputStream(InputStream is)". This
>>> object is used by the PDFParser object which doesn't close the stream
>>> after
>>> completion.
>>>
>>> The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding
>>> the
>>> following line (see https://issues.apache.org/jira/browse/PDFBOX-2723)
>>> in
>>> the COSParser :
>>>
>>> xrefStream.close(); // <--- *** NEW LINE ***
>>>
>>> But, in debug mode, I saw this line is never reached so the stream is not
>>> closed and the tmp file is not deleted. Has anybody a workaround to
>>> handle
>>> this ?
>>> Thanks for your help!
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message