|
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.
|
|
|
fe1fb36e
|
2019-01-13T21:10:50
|
|
win32: move type definitions for improved inclusion
Move some win32 type definitions to a standalone file so that they can
be included before other header files try to use the definitions.
|
|
|
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.
|
|
|
abb04caa
|
2018-02-01T15:55:48
|
|
consistent header guards
use consistent names for the #include / #define header guard pattern.
|
|
0c7f49dd
|
2017-06-30T13:39:01
|
|
Make sure to always include "common.h" first
Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.
This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.
This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.
|
|
35c1d207
|
2015-04-29T14:03:20
|
|
git_win32_path_dirload_with_stat: removed
|
|
1920ee4e
|
2015-03-26T18:10:24
|
|
Improvements to status performance on Windows.
Changed win32/path_w32.c to utilize NTFS' FindFirst..FindNext data instead of doing an lstat per file. Avoiding unnecessary directory opens and file scans reduces IO, improving overall performance. Effect is magnified due to NTFS being a kernel mode file system (as opposed to user mode).
|
|
629417bd
|
2014-12-19T08:08:47
|
|
Fix ming32 compilation
We need to know what wchar_t and MAX_PATH are. Including common.h takes
care of that for us.
|
|
|
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:\)
|