Skip to content

Inconsistent behaviour of Zip::File#get_entry and Zip::File#find_entry exposes options out of sync. #422

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hainesr opened this issue Oct 31, 2019 · 1 comment · Fixed by #486
Assignees
Milestone

Comments

@hainesr
Copy link
Member

hainesr commented Oct 31, 2019

This is a funny one that has been exposed by fixing #395...

The defaults for restore_times, restore_permissions and restore_ownership are separately specified in both Zip::File and Zip::Entry and they are out of sync.

Current defaults for each option:

Option/Class Zip::File Zip::Entry
restore_times false true
restore_permissions false false
restore_ownership false false

This isn't generally an issue as whatever is set in Zip::File is percolated through to Zip::Entry - except not always 😬

The following example shows how this can get confused:

zip = ::Zip::File.open('test/data/globTest.zip')

e1 = zip.find_entry('globTest/food.txt')
e1.extract('f_test.txt')

e2 = zip.get_entry('globTest/food.txt')
e2.extract('g_test.txt')

zip.close

f_test.txt has a timestamp of 18 May 2012; g_test.txt has the current time and date for its timestamp.

This all occurs because the default for the above options are stored twice - and (kind of) need to be due to there not always being a Zip::File parent for every Zip::Entry - but also because while Zip::File#get_entry and Zip::File#find_entry are ostensibly doing the same thing, they are implemented very differently.

The quick fix for this is fairly easy, and I'll work up a PR for it later.

The main reason I am documenting this in a detailed issue is to ask: should these options be moved up to the top level, alongside validate_entry_sizes, et al? Or do we leave them where they are and risk them being out of sync again in the future? @jdleesmiller, @simonoff, I'd appreciate your thoughts, but I reckon moving them up is the right way to go - this would have the happy side-effect of simplifying various interfaces in Zip::File. Happy to also work this up as a PR if you agree.

@jdleesmiller
Copy link
Member

Good find. PR approved.

should these options be moved up to the top level

I feel like the same (large) application might want to treat zips differently in this regard for one feature vs another, so I am not sure about moving them to top level.

A small improvement might be to move the hash with the defaults to top level and then use it in both Zip::File and Zip::Entry to look up the defaults. That eliminates one way in which they can get out of sync, but it does still require File to remember to always pass them to its Entrys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants