Migrate from GitHub to SourceForge with this tool. Check out all of SourceForge's recent improvements.
Close

User Activity

  • Posted a comment on discussion Open Discussion on 7-Zip-JBinding

    Hallo Raja, sorry, I missed your previous question. Yes, it is possible and it is tested a lot within my test suite. So, you must be doing something wrong with the API. It is a little bit tricky, it gives you on the other hand a full controll over the update operation. Could you please make sure, that you follow the steps from this example? http://sevenzipjbind.sourceforge.net/compression_snippets.html#update-add-remove-items Cheers, Boris

  • Posted a comment on discussion Open Discussion on 7-Zip-JBinding

    Hi, yes with 7-Zip-JBinding you can compress files to 7-zip archives on the fly and in-memory. If you just want to compress existing files on the disk, I would suggest to use the 7-zip (Windows) and p7zip (Linux) console or GUI applications. For 7-Zip-JBinding Java solution here is the tutorial and the documentation: http://sevenzipjbind.sourceforge.net/first_steps.html Cheers, Boris

  • Posted a comment on discussion Help on 7-Zip-JBinding

    Sorry to hear that :) No problems of course. The pure Java implementation has some advantables, like smooth installation. But it is slower and you also loose potential support for many different archive formats. I will fix this initialization bug in one of the upcoming releases, so you may check 7-Zip-JBinding at some point in the future. Cheers, Boris

  • Posted a comment on discussion Help on 7-Zip-JBinding

    The purpose of the has is to make sure, that the binary in your temp directory is not broken. Now look, if you start multiple JVMs, the first one starts to write the file while the second one finds the unfinished file and proceeds with hash checking. I think, it is safe to skip it, if you can make sure, that no JVM will load the .DLLs/.so files until the first one finishes writing them :) Another solution may be to retry failed initialization after waiting for a couple of hundreds milliseconds.

  • Posted a comment on discussion Help on 7-Zip-JBinding

    Hello Zbynek, yes, it is a some kind of known bug in the initialization. It strikes, if multile JVMs trying to initialize 7-Zip-JBinding simultaneously. Workarounds: (easy) Offset the time of the start and initialization of 7-Zip-JBinding slightly (propertly) Read JavaDoc of SevenZip class and write you own initialization routine calling initLoadedLibraries() at the end (instead of 'initSevenZipFromPlatformJAR()')

  • Posted a comment on discussion Help on 7-Zip-JBinding

    Sorry, this is not a priority for me right now. Currently I have a very little of my spare time for open source projects. And there is a lot of important stuff to do for 7-Zip-JBinding. I think, you will have to wait, until some company order this feature.

  • Posted a comment on discussion Help on 7-Zip-JBinding

    Yes, hot deployment my result in an issue. Could you please issue a new bug report hier on sf.net (https://sourceforge.net/p/sevenzipjbind/bugs/) or on github (https://github.com/borisbrodski/sevenzipjbinding/issues) describing in details you environment and the error message you recieve. Thank you!

  • Posted a comment on discussion Help on 7-Zip-JBinding

    Hallo arxidiamidia, you didn't get the point. You still create (overwrite) the output file in the write() method new FileOutputStream(out) The write() method may get called mutiple times for a each output file. As an oversimplified example you may imagine 7-Zip-JBinding calling your Callback like this: // Extract file2 s1 = getStream(0, ...) s1.write(part1) s1.write(part2) s1.write(part3) // Extract small file2 s2 = getStream(1, ...) s2.write(part1) // Extract large file3 s3 = getStream(2, ...) s3.write(part1)...

View All

Personal Data

Username:
boris_brodski
Joined:
2005-06-29 12:53:02

Projects

Skills

  • No skills entered.

Personal Tools