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
If I try to add two files, both called test.txt, but each with different content, rubyzip produces an archive with only 1 file, the last one added via put_next_entry.
Given the underlying IO implementation in the output stream handler, it's not obvious to me that name collision should be a problem. And standard zip libraries do allow this, albeit though it's an unusual case.
The maintainers might believe this is working as intended, but I think it's surprising behaviour and that at least a warning should be generated. But I also think a case could be made for accepting multiple files with the same name.
The text was updated successfully, but these errors were encountered:
Thanks for reporting this. Yes, the ZIP specification allows for multiple entries with the same name. I can see why rubyzip isn't allowing this, so I'll mark this as a bug to be fixed.
Note to my future self: the ZIP spec doesn't explicitly say that there can be multiple entries with the same name, but it certainly doesn't rule it out either, and there's evidence (here and plenty of other places) that this is expected behaviour. Definitely a bug.
If I try to add two files, both called
test.txt
, but each with different content, rubyzip produces an archive with only 1 file, the last one added via put_next_entry.Given the underlying IO implementation in the output stream handler, it's not obvious to me that name collision should be a problem. And standard zip libraries do allow this, albeit though it's an unusual case.
The maintainers might believe this is working as intended, but I think it's surprising behaviour and that at least a warning should be generated. But I also think a case could be made for accepting multiple files with the same name.
The text was updated successfully, but these errors were encountered: