Open EskeRahn opened 3 years ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
What would this flag do if there were two file name in the zip that differed only in casing?
Note that Windows isn't case insensitive in deep. Case sensitivity can be turned on.
Thanks for the quick reactions.
What would this flag do if there were two file name in the zip that differed only in casing?
As suggested then the optimal would be to have an Exception, telling that an ambiguous name have been requested. So people would either have to access the archive case-sensitive OR to access by index (or foreach).
IF you also added a method returning a collection, for usage with wildcards, That could also return all variants matching, if case sensitivity was turned off.
Note that Windows isn't case insensitive in deep. Case sensitivity can be turned on.
I'm aware, but frankly never came across anyone exploiting that. So at the least an option would be nice.
Thanks for the suggestion. Could you update your top post to match the API proposal template? There is a special new issue template for it.
ADD: Just noticed by an accident, that it is allowed today to add several entries with identical names, so the duality looking op a single name would be the same as an case-insensitive lookup of entries that differed by case only
Background and Motivation
ZipArchive.GetEntry is always case sensitive. In a OS (like windows) that is insensitive, the input cannot be expected to be provided case sensitive.
Similar to #1553 this is OS dependent.
Proposed API
A new option, to force it to be case insensitive would solve it. An easy way could be to add a bit to ZipArchiveMode
Usage Examples
This is additional functionality, so not changed usage
Alternative Designs
It could be implemented as a separate function, but would not recommend that.
Risks
As this would be an addition no risk for existing usage
Remarks
Optimally throwing an exception if the provided name matches more than one entry case insensitive. (Of course a workaround is just browsing through all entries, and check manually case insensitive)
ADD: Noticed by an accident, that it is allowed today to add several entries with identical names, so the duality looking op a single name would be the same as an case-insensitive lookup of entries that differed by case only. So handling this scenario should already exist in the code.
area-System.IO.Compression