Cédric Tabin

Hi, I changed slightly the implementation to check the Namespace name. It's safer now :-) Best, Cédric

@novalis I checked with the latest version (4.1.0) against our GitLab CE 11.8.1 and I still have the same problem... Maybe there is a difference on this between CE and...

Hi @BullyWiiPlaza, Without a test case, it will be pretty hard to help you. By default, it is true that libzippp doesn't provide any details when an open fails. However,...

@BullyWiiPlaza I made a slight [improvement](https://github.com/ctabin/libzippp#error-handling) so you can set a custom handling for errors in this case so you might have more information. Let me know if this is...

Hi @yurivict Thanks for the report. Could you please tell if it is the commenting of the install section that did the trick or the `find_package` related change ? Does...

But then, how can `find_package(libzip REQUIRED)` work ? It should also look for `Findlibzip.cmake` :thinking: I guess the install fails for the same reason, because of the path to the...

Hi @gizmocuz, thanks for the PR. Can you please explain what's wrong with the current example ? Also, can you remove the `std::` namepsace ? Thanks !

@gizmocuz I agree with you that one should avoid `using namespace ...` to avoid conflicts. However, the goal is to show some simple example without the extra-burden of handling namespaces,...

Hi @flomnes, Unfortunately it is how the underlying `libzip` library works: the data is written when the zip is closed, which is reflected through `libzippp`. I don't see any problem...

Hi @Werni2A, Actually, I don't see anything that could break the linkage in the [changes](https://github.com/ctabin/libzippp/compare/libzippp-v5.0-1.8.0...libzippp-v5.1-1.8.0) since v5.0. Maybe related to the upgrade of zlib ? :thinking: I did not have...