On 24/02/16 09:28, Stian Soiland-Reyes wrote:
That's a good question.. I think the validator was trying to check if the
zip entries match the manifest, but then it should probably do the manual
zip listing before opening the zip as a bundle.
Windows and Linux treat (open) files differently. Loosely ...
On Linux, and open file is just an increment of the link count and you
can rm a file at anytime - an rm is a decrement of the link count in the
inode. The file is still there until the link count goes to zero.
All hard links are equivalent - directory entries to the inode.
On Windows, directory entries are ptrs to an inode. They are contain
the details so there is one primary place a file "is" in the file system
and it can't be deleted from that directory until all uses go away.
Andy
Is that right, Menaka?
So then I think this is a real bug in that the validator doesn't close the
zip file, and so on Windows the file will be locked and can't be deleted as
the test finishes.
Perhaps move to a separate autoclose block just for the zip file listing? I
think it keeps the list as strings within the Validator.
On 23 Feb 2016 17:27, "Dmitry" <[email protected]> wrote:
It should.
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
The question is WHY the zip code is WITHIN bundle try/catch?
Dmitry
On 2/23/2016 6:02 PM, alaninmcr wrote:
On 23/02/2016 15:38, Ian Dunlop wrote:
Hello,
I add zip.close() to the validate code and it built ok. Code fragment
below. Shall I commit it to master and then we can start the release
process again? Or am I missing something?
If the declaration of the ZipFile is moved inside the try, Java 8 should
(from my reading of the documentation) auto-close it. Perhaps the handling
of autoclose is different according to the OS.
Cheers,
Ian
Alan
