ZipReader unpacks in ./temp

[Pfeil]

• should be unpacked in subfolder so different imported crates do not interfere
• the content should be removed at some point, currently it is "on java exit"? Question is who is responsible for deletion. The reader may create a Crate Object, and it does not directly have a relation to the folder. So, as soon as one (or multiple) crates have been created, it is not anymore in the readers responsibility. We need to add some control on this, I think, and we need to see which possibilities we have in Java. Thoughts:
  • Recently we fixed an issue that a reader can not be used multiple times to read a crate. This might have been on purpose, though? Is this why the content is being deleted so late, because now the reader can live so long? @Code42Cate
  • Responsibility could be given by some kind of file lock, which is initially at the reader, and then at the exported crate. Further crates on the same folder then can not be created.