Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Apache Commons Compress - De Compress Zip File

 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to decompress a zip archive with a sub-directory using apache commons and commons compress. It runs with no errors, however, the files appear as folders and are empty. Not sure what is causing this...

 
Marshal
Posts: 25938
69
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Ron Ingram wrote:the files appear as folders



Because your code at lines 35 and 36 does that.
 
Ron Ingram
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree.. but now it is not iterating in the while loop. the entry = (ZipArchiveEntry) ais.getNextEntry() return null for any new file. It only seems to iterate once correctly writing the file.

new method..

 
Ron Ingram
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Finally got it working. Apache Commons FileUtils and IOUtils seem to break the loop.

Changed to FileOutputStream

 
Sheriff
Posts: 22015
108
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should close your FileOutputStreams, as well as your ArchiveInputStream, preferably in try-finally blocks or try-with-resources. Right now you have a major resource leak, and if your archive contains too many entries you will run out of file handles.

I think the issue with your original code is that FileUtils.copyInputStreamToFile closes the source input stream. I think this is a mistake, because a) it's not documented, and b) library calls shouldn't close resources that are passed as input arguments - it's the responsibility of the code that created a resource to close it again.

Anyway, your original code would work if you'd wrap the ArchiveInputStream in an CloseShieldInputStream. The resulting InputStream behaves just like the wrapped ArchiveInputStream except its close() method does nothing. As a result, FileUtils.copyInputStreamToFile would still do the correct copying but it wouldn't close your ArchiveInputStream.
 
reply
    Bookmark Topic Watch Topic
  • New Topic