When I return a ISequentialInStream from the getStream(index i) in my archive create callback, the close() is not called on that stream at the end of the read process.
For the ByteArrayStream (see example snippet) this is not an issue, but I'm using a RandomAccessFileInStream(). After compression al the input files are still open.
Is this on purpose, so do I need to keep track of the streams myself?
I can simply create a wrapper that closes the stream on EOF, but I think it would be cleaner that the close would be called from the binding directly?
Kind Regards,
Silas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it is kind of on purpose. 7-Zip-JBinding is only a binding, so I try to stick with the original 7-zip engine API.
How can I be sure, that the stream will reach EOF? Ich 7-zip compressor will encounter an error, the operation will be stoped and the stream will stay opened. Although it means some additional management work from the user code, I found it much safer.
I think I should mention it in the JavaDoc.
Also a example snippet for the web page would be cool.
Btw, it you think, you have a nice looking stream management solution
you could contribute it :) Either as a snippet or as a Class in sevenzipjbinding.jar.
Kind regards,
Boris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know how the 7zip internals look like, but I think a nice way to
handle this would be to have the binding call a method on the creation
callback class with a reference to the stream (either the
ISequentialStream, or the stream index) when it has finished processing it?
Then I can decide for myself what I want to do with it?
Currently I just keep a list of created streams and close them afterwards,
but this is probably not the cleanest solution.
Can I be sure that the getStream(int index) method will be called only once
for each stream?
Is there another way to know when 7zip has finished processing a stream
from the java side?
it is kind of on purpose. 7-Zip-JBinding is only a binding, so I try to
stick with the original 7-zip engine API.
How can I be sure, that the stream will reach EOF? Ich 7-zip compressor
will encounter an error, the operation will be stoped and the stream will
stay opened. Although it means some additional management work from the
user code, I found it much safer.
I think I should mention it in the JavaDoc.
Also a example snippet for the web page would be cool.
Btw, it you think, you have a nice looking stream management solution
you could contribute it :) Either as a snippet or as a Class in
sevenzipjbinding.jar.
good questions. I think it all depends on compressors. Using lzma or zip or other compression you may get different behavior.
But I would expect following behavior:
getStream(int index) get called at most ones for each index
All streams CAN be closed in setOperationResult() both in OK and ERROR case
Due to some errors setOperationResult() may be not called, all stream SHOULD be closed in the "finally" block around the 7-zip createArchive() or updateArchive() call.
In OK case all streams will be read up to the EOF. In order to keep the amount of opened resources low, closing on EOF would be used.
Are you agree on this list? Can you confirm this behavior?
Kind regards,
Boris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I wonder if this is on purpose or not.
When I return a ISequentialInStream from the getStream(index i) in my archive create callback, the close() is not called on that stream at the end of the read process.
For the ByteArrayStream (see example snippet) this is not an issue, but I'm using a RandomAccessFileInStream(). After compression al the input files are still open.
Is this on purpose, so do I need to keep track of the streams myself?
I can simply create a wrapper that closes the stream on EOF, but I think it would be cleaner that the close would be called from the binding directly?
Kind Regards,
Silas
Hello Silas,
it is kind of on purpose. 7-Zip-JBinding is only a binding, so I try to stick with the original 7-zip engine API.
How can I be sure, that the stream will reach EOF? Ich 7-zip compressor will encounter an error, the operation will be stoped and the stream will stay opened. Although it means some additional management work from the user code, I found it much safer.
I think I should mention it in the JavaDoc.
Also a example snippet for the web page would be cool.
Btw, it you think, you have a nice looking stream management solution
you could contribute it :) Either as a snippet or as a Class in sevenzipjbinding.jar.
Kind regards,
Boris
Hi Boris,
I don't know how the 7zip internals look like, but I think a nice way to
handle this would be to have the binding call a method on the creation
callback class with a reference to the stream (either the
ISequentialStream, or the stream index) when it has finished processing it?
Then I can decide for myself what I want to do with it?
Currently I just keep a list of created streams and close them afterwards,
but this is probably not the cleanest solution.
Can I be sure that the getStream(int index) method will be called only once
for each stream?
Is there another way to know when 7zip has finished processing a stream
from the java side?
Kind regards,
Silas
Op do 23 apr. 2020 om 09:40 schreef Boris Brodski boris_brodski@users.sourceforge.net:
Hi Silas,
good questions. I think it all depends on compressors. Using lzma or zip or other compression you may get different behavior.
But I would expect following behavior:
Are you agree on this list? Can you confirm this behavior?
Kind regards,
Boris