win32: don't canonicalize relative paths#5435
Merged
Conversation
Member
Author
|
Note that it feels a little weird to jam relative path handling into this. I considered splitting it out into two different functions, especially since this function is a bit hairy already. But in the end I just modified this one instead of trying to duplicate hairy code. |
The path canonicalization functions on win32 are intended to canonicalize absolute paths; those with prefixes. In other words, things start with drive letters (`C:\`), share names (`\\server\share`), or other prefixes (`\\?\`). This function removes leading `..` that occur after the prefix but before the directory/file portion (eg, turning `C:\..\..\..\foo` into `C:\foo`). This translation is not appropriate for local paths.
9d03aa7 to
6ee3b2c
Compare
Member
Author
|
/cc @pks-t updated with a saner approach |
pks-t
approved these changes
Mar 10, 2020
src/win32/path_w32.h
Outdated
| * @param src The UTF-8 string to convert. | ||
| * @return The length of the wide string, in characters (not counting the NULL terminator), or < 0 for failure | ||
| */ | ||
| extern int git_win32_path_relative_from_utf8(git_win32_path dest, const char* src); |
Member
There was a problem hiding this comment.
Sorry, but minor nit: the * is with the name, not with the type ;)
Add a function that takes a (possibly) relative UTF-8 path and emits a UTF-16 path with forward slashes translated to backslashes. If the given path is, in fact, absolute, it will be translated to absolute path handling rules.
Don't canonicalize symlink targets; our win32 path canonicalization routines expect an absolute path. In particular, using the path canonicalization routines for symlink targets (introduced in commit 7d55bee, "win32: fix relative symlinks pointing into dirs", 2020-01-10). Now, use the utf8 -> utf16 relative path handling functions, so that paths like "../foo" will be translated to "..\foo".
Ensure that we don't canonicalize symlink targets.
6ee3b2c to
163db8f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Our path canonicalization (beginning in cceae9a) was meant to deal with absolute paths, converting things like
C:\Foo\Barinto\\?\C:\Foo\Barso that we could avoid some of the dangers of NTFS (like eliding trailing dots in filenames). But by using those paths, we need to do canonicalization ourselves, as giving\\?\C:\Foo\..\Barto the filesystem APIs will return an error instead of resolving the path.These canonicalization function were not meant to deal with relative paths. In particular, this means that leading ".." segments at the beginning of paths were removed, to translate
C:\..\..\..\into the correct\\?\C:\. (This is despite having some tests around relative path components, they were not well thought out since they were not intended to be used.)Update the documentation on the function to point out that it's not to be used for relative paths, and remove the tests that suggest that it should be used that way.
Add a new function that will keep relative paths relative, while converting them to UTF-16 and translating
/to\\.Use this new relative path handling function when creating Windows symlinks.