dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.35k stars 4.74k forks source link

ZipArchive.GetEntry case sensitive, even on case insensitive OS #48267

Open EskeRahn opened 3 years ago

EskeRahn commented 3 years ago

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

dotnet-issue-labeler[bot] commented 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.

danmoseley commented 3 years ago

What would this flag do if there were two file name in the zip that differed only in casing?

huoyaoyuan commented 3 years ago

Note that Windows isn't case insensitive in deep. Case sensitivity can be turned on.

EskeRahn commented 3 years ago

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.

danmoseley commented 3 years ago

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.

EskeRahn commented 3 years ago

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