It looks like in version 0.4.0, the behavior of NativeLoader.cleanup() method changed considerably: it used to delete files matching "webp-imageio-0.5.0*" in java.io.tmpdir, but now it recursively deletes everything matching that pattern.
This has unintended consequences... If you happen to set java.io.tmpdir to $HOME, all copies of webp-imageio-0.5.0.jar and webp-imageio-0.5.0.tar.gz also disappear. Or if you had set java.io.tmpdir to $XDG_RUNTIME_DIR (/run/user/:uid/), the cleanup might take forever, because slow/huge network file systems might be mounted under /run/user/:uid/gvfs/...
Maybe just restore the previous, non-recursive behavior?
Thanks for the report and sharing context 👍 Looking at the code I think I misunderstood where the tmp files are extracted to. Previous behavior should be now restored in 0.5.1 ✅
It looks like in version 0.4.0, the behavior of NativeLoader.cleanup() method changed considerably: it used to delete files matching "webp-imageio-0.5.0*" in java.io.tmpdir, but now it recursively deletes everything matching that pattern.
This has unintended consequences... If you happen to set java.io.tmpdir to $HOME, all copies of webp-imageio-0.5.0.jar and webp-imageio-0.5.0.tar.gz also disappear. Or if you had set java.io.tmpdir to $XDG_RUNTIME_DIR (/run/user/:uid/), the cleanup might take forever, because slow/huge network file systems might be mounted under /run/user/:uid/gvfs/...
Maybe just restore the previous, non-recursive behavior?