|
f2b114ba
|
2020-03-08T18:11:45
|
|
win32: introduce relative path handling function
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.
|
|
|
fb7da154
|
2020-03-08T16:34:23
|
|
win32: clarify usage of path canonicalization funcs
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.
|
|
b5e8272f
|
2019-01-06T08:29:56
|
|
Attempt at fixing the MingW64 compilation
It seems like MingW64's size_t is defined differently than in Linux.
|
|
bbf9f5a7
|
2018-11-21T11:20:14
|
|
tests: path: only compile test_canonicalize on Win32 platforms
The function `test_canonicalize` is only used on Win32 platforms. It will thus
result in an unused function warning if these warnings are enabled and one is on
a platform different than Win32.
Fix the issue by only compiling in the function on Win32 platforms.
|
|
|
16fd9ba9
|
2018-10-17T11:34:38
|
|
win32: more tests for `git_win32_remove_path`
|
|
|
b2e85f98
|
2018-10-17T08:48:43
|
|
win32: rename `git_win32__canonicalize_path`
The internal API `git_win32__canonicalize_path` is far, far too easily
confused with the internal API `git_win32_path_canonicalize`. The
former removes the namespace prefix from a path (eg, given
`\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given
`\\?\UNC\server\share`, it returns `\\server\share`). As such, rename
it to `git_win32_path_remove_namespace`.
`git_win32_path_canonicalize` remains unchanged.
|
|
3f096ca5
|
2018-10-04T13:03:25
|
|
Fix comment style and update test code
|
|
8ab11dd5
|
2018-09-30T16:40:22
|
|
Fix issue with path canonicalization for Win32 paths
|
|
07c989e9
|
2015-02-03T20:01:24
|
|
win32: further cleanups for 8.3 disabling
|
|
|
5f28ec84
|
2015-02-03T12:16:11
|
|
win32: cleanup 8.3 disabled tests
|
|
9dcc4a36
|
2015-01-28T23:04:50
|
|
Fix test failures when 8.3 is disabled
|
|
|
a64119e3
|
2014-11-25T18:13:00
|
|
checkout: disallow bad paths on win32
Disallow:
1. paths with trailing dot
2. paths with trailing space
3. paths with trailing colon
4. paths that are 8.3 short names of .git folders ("GIT~1")
5. paths that are reserved path names (COM1, LPT1, etc).
6. paths with reserved DOS characters (colons, asterisks, etc)
These paths would (without \\?\ syntax) be elided to other paths - for
example, ".git." would be written as ".git". As a result, writing these
paths literally (using \\?\ syntax) makes them hard to operate with from
the shell, Windows Explorer or other tools. Disallow these.
|
|
|
cceae9a2
|
2014-12-01T13:09:58
|
|
win32: use NT-prefixed "\\?\" paths
When turning UTF-8 paths into UCS-2 paths for Windows, always use
the \\?\-prefixed paths. Because this bypasses the system's
path canonicalization, handle the canonicalization functions ourselves.
We must:
1. always use a backslash as a directory separator
2. only use a single backslash between directories
3. not rely on the system to translate "." and ".." in paths
4. remove trailing backslashes, except at the drive root (C:\)
|