You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is maybe related to #280, but in my case, the archive doesn't just have its order changed, but is completely corrupted. Here is a complete example, including the archive embedded (Just a simple zip with a file foo.txt with the contents "FOO!\n" and bar.txt with the contents "BAR?\n"):
This fails on attempting to read the second time, because the buffer has been corrupted:
$ ./corrupt.rb
First read worked
/usr/lib64/ruby/gems/2.6.0/gems/rubyzip-2.3.2/lib/zip/file.rb:406:in `get_entry': No such file or directory - bar.txt (Errno::ENOENT) from /usr/lib64/ruby/gems/2.6.0/gems/rubyzip-2.3.2/lib/zip/file.rb:259:in `get_input_stream' from /usr/lib64/ruby/gems/2.6.0/gems/rubyzip-2.3.2/lib/zip/file.rb:295:in `read' from corrupt.rb:14:in `block in <main>'
from /usr/lib64/ruby/gems/2.6.0/gems/rubyzip-2.3.2/lib/zip/file.rb:156:in `open_buffer' from corrupt.rb:13:in `<main>'
I'm not against the buffer being rewritten for whatever purpose, and I know that you can avoid this by either duplicating the buffer or freezing it to cause the write to fail, but it definitely shouldn't be corrupted and unable to be treated as an equivalent zip buffer after opening, especially when no changes have been made. In my production use-case, I got a zip file that was unable to be read at all, and I didn't even know it was corrupt until long after the initial zip read, when it had been stored in a database and later retrieved. I'm currently working around this by just freezing the buffer, which is an effective solution for me.
The text was updated successfully, but these errors were encountered:
Hi @Taywee, many thanks for this, and for your comprehensive report.
This is a bug. Just reading a buffer shouldn't rewrite anything, and even if it did, if nothing changes it should just write out the same data. So maybe it's two bugs.
Stopping it changing the buffer if there's no change to the archive is easy enough, so I'll get that sorted ASAP.
Right, this is basically fixed in master now. The buffer is no longer rewritten if nothing in the archive changes.
I'm going to leave this issue open though, because I want to debug why the data was changing even if nothing in the archive had changed. It's going to take a bit more investigation.
This is maybe related to #280, but in my case, the archive doesn't just have its order changed, but is completely corrupted. Here is a complete example, including the archive embedded (Just a simple zip with a file
foo.txt
with the contents"FOO!\n"
andbar.txt
with the contents"BAR?\n"
):This fails on attempting to read the second time, because the buffer has been corrupted:
I'm not against the buffer being rewritten for whatever purpose, and I know that you can avoid this by either duplicating the buffer or freezing it to cause the write to fail, but it definitely shouldn't be corrupted and unable to be treated as an equivalent zip buffer after opening, especially when no changes have been made. In my production use-case, I got a zip file that was unable to be read at all, and I didn't even know it was corrupt until long after the initial zip read, when it had been stored in a database and later retrieved. I'm currently working around this by just freezing the buffer, which is an effective solution for me.
The text was updated successfully, but these errors were encountered: