-
Notifications
You must be signed in to change notification settings - Fork 82
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
Resolve colliding file names on case-insensitive file systems #7837
Comments
Sorry, I don't know much about casing. @MichaelTsengLZ @jeffmcaffer or @jeffmendoza may be able to help here. |
Resolves #7837. Signed-off-by: Sebastian Schuberth <[email protected]>
I've proposed a PR at #7838. |
Thanks @sschuberth for finding this. I vaguely recall doing a deep dive on case preservation and sensitivity and feel like there's a doc or issue around that talks about our handling strategy. Seem to recall that Dan did this work back in the day. Can't find it right now. On the surface it would appear that this curation is the right thing to do. I am however concerned about the root cause and whether this this change will either perpetuate or exacerbate the problem (the latter seems unlikely). It is entirely possible that the actual package changed their casing at some point in time. That seems especially possible in the NuGet world (seen it before). In that case (hah! pun) we'd have to fall back on the aforementioned casing analysis. My vague recollection is that we ended up at case preserving but case insensitive. The basic assumption being that we did not find any providers that were case sensitive (There were some old cases in npm land I think but they were old and appeared to addressed). /cc @nellshamrell |
clearlydefined/service#157 talks about this somewhat at the implementation level. Still feel like there was an analysis of all the supported (and some prime potential) package managers with some summarization / discussion. |
At least for NuGet, given that the API requires the package ID to be lower case, maybe it makes sense to align on all lower case file names? Or actually, does the casing of the file name ever matter? I guess not, as the |
I'm hesitant to make any concrete/general call on this without consulting the prior research. Casing is fraught with oddities. For this particular PR it should be possible to validate that with the changes merged, the curations are still applied to the relevant component/version. Stepping back a bit, @sschuberth, how did this curation come about with different casing? Is this coming from ORT tooling using lowercase? or some other workflow? |
I have no idea. To the best of my knowledge none of these curations were initially created by ORT or by myself in person. My brief checks just showed that the initial commit each was done by @clearlydefinedbot. |
yeah, that likely means that the PR was entered via the website and we are unable to do proper attribution (there was a technical challenge IIRC) Anyway, I believe that NuGet is case preserving but not case sensitive. The metadata for DiscUtils.Core has mixed case (see below) while the protocol/service, as you point out, lowercases everything. So the user view of the package is mixed case.
Reaching way back I believe we our goal was to present users with the most authentic naming so are attempting to preserve the casing. So while the protocol is all lower, the package itself and the user view is mixed. That still leaves us with the challenge of what casing to use in the underlying implementation given that Git is case-sensitive (your point here). I would have said that if the system is case IN-sensitive, we should toLower() the coordinates for storage. Again, reaching back, I recall there may have been a few places where we look at the storage layer and reverse engineer coordinates. That's not a great and we may have stopped doing that. HAH! I found the doc Path forward.
|
So, what's missing for me in the path forward is:
Then please feel free to close my PR (with a rationale pointing back to here) so that it does not accidentally get merged. |
@nellshamrell - unclear if this Issue can be closed? |
It's easy to verify the problem persists. Just try to clone this repo on Windows and you'll still get
|
@ariel11 let's keep it open. I don't know when I will have time to address this, but it's good to keep it on our backlog. |
When cloning this repo on Windows I get:
I believe the contents of these pairs of files should be merged, and the capitalization should be aligned to the spelling used in the respective registry. Would you agree with that rationale @capfei @fossygirl?
The text was updated successfully, but these errors were encountered: