-
Notifications
You must be signed in to change notification settings - Fork 21
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
Path to files and folder in lowercase #252
Comments
This is intentional and is meant to remain that way. Heavy work has been done under-the-hood for v2.16 to ensure the paths of FILE items are normalized so they can be compared as safely as possible between two running sessions. How would that be an issue for you? |
Also, note that this impacts only the target property of the FILE items. Not their display name. |
Thanks for the answer. This is not a big problem so I will survive it. :) It's just a habit to get the right ways. |
Normalized paths is the right way :) |
Funny. Weird. Definitely not KP-related [1] but obviously an inconvenient issue. To circumvent that, KP can keep fully normalizing the root part of the path (i.e. drive part or UNC prefix) and just canonicalize the tail of the path without changing its case/casing. But this comes with the cost of being more CPU demanding when inserting items into KP's catalog because full normalization is required at some point to compare items. Although my guess is that it will be hardly noticeable at user-level so it is an acceptable solution. [1]: the display name of an application/control panel is not meant to change just because you invoke it with a different character casing, unless the said application relies too much on user input (that would be the issue) |
Aforementioned behavior implemented in v2.16.3 |
I noticed that in version 2.16.2 all paths to files or folders are in lowercase. No matter what actually.
In version 2.15.4, this does not happen.
Is this a mistake or is it done intentionally?
Personally, I would like to return the normal paths as it was before.
I checked this on the plugin - FileBrowser.
The text was updated successfully, but these errors were encountered: