tests/path


Log

Author Commit Date CI Message
Dimitris Apostolou 90df4302 2022-01-05T12:18:05 Fix typos
Edward Thomson fc42c28e 2021-11-19T09:36:03 util: don't include unnecessary system libraries Remove some unnecessary includes from utility code.
Edward Thomson ca14942e 2021-11-11T13:28:08 tests: declare functions statically where appropriate
Edward Thomson 1728e27c 2021-11-01T18:19:56 path: length validation respecting core.longpaths Teach `git_path_is_valid` to respect `core.longpaths`. Add helper methods to validate length and set the error message appropriately.
Edward Thomson 315a43b2 2021-11-01T17:37:06 path: introduce `git_path_str_is_valid` Add a `git_str` based validity check; the existing `git_path_is_valid` defers to it.
Edward Thomson dd748dbe 2021-11-01T13:04:40 fs_path: make empty component validation optional
Edward Thomson bef02d3e 2021-11-01T10:57:28 fs_path: introduce `str_is_valid` Provide a mechanism for users to limit the number of characters that are examined; `git_fs_path_str_is_valid` and friends will only examine up to `str->size` bytes. `git_fs_path_is_valid` delegates to these new functions by passing `SIZE_MAX` (instead of doing a `strlen`), which is a sentinel value meaning "look for a NUL terminator".
Edward Thomson 63e36c53 2021-11-01T09:34:32 path: `validate` -> `is_valid` Since we're returning a boolean about validation, the name is more properly "is valid".
Edward Thomson 434a4610 2021-11-01T09:31:32 fs_path: `validate` -> `is_valid` Since we're returning a boolean about validation, the name is more properly "is valid".
Edward Thomson 95117d47 2021-10-31T09:45:46 path: separate git-specific path functions from util Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
Edward Thomson f0e693b1 2021-09-07T17:53:49 str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson 4bd17208 2021-05-06T02:28:14 Merge pull request #5858 from libgit2/ethomson/memleaks test: clean up memory leaks
Edward Thomson b31795ef 2021-05-06T01:46:19 test: clean up memory leaks
Ian Hattendorf 69c65b9a 2019-12-31T12:38:03 path: bump most Win32 unicode buffer sizes from MAX_PATH to GIT_PATH_MAX
Edward Thomson dc1ba018 2021-03-20T13:01:00 path: introduce ondisk and workdir path validation Introduce `git_path_validate_filesystem` which validates (absolute) on-disk paths and `git_path_validate_workdir` to perform validations on (absolute) working directory paths. These functions are useful as there may be system limitations on on-disk paths, particularly on Windows (for example, enforcing MAX_PATH). For working directory paths, these limitations may be per-repository, based on the `core.longpaths` configuration setting.
Edward Thomson 88323cd0 2021-03-20T09:52:17 path: git_path_isvalid -> git_path_validate If we want to validate more and different types of paths, the name `git_path_validate` makes that easier and more expressive. We can add, for example, `git_path_validate_foo` while the current name makes that less ergonomic.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 14ff3516 2019-12-03T23:15:47 path: support non-ascii drive letters on dos Windows/DOS only supports drive letters that are alpha characters A-Z. However, you can `subst` any one-character as a drive letter, including numbers or even emoji. Test that we can identify emoji as drive letters.
Johannes Schindelin e1832eb2 2019-09-18T16:33:18 path: also guard `.gitmodules` against NTFS Alternate Data Streams We just safe-guarded `.git` against NTFS Alternate Data Stream-related attack vectors, and now it is time to do the same for `.gitmodules`. Note: In the added regression test, we refrain from verifying all kinds of variations between short names and NTFS Alternate Data Streams: as the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it is enough to test one in order to know that all of them are guarded against. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Patrick Steinhardt f7c6795f 2019-06-07T10:20:35 path: only treat paths starting with '\' as absolute on Win32 Windows-based systems treat paths starting with '\' as absolute, either referring to the current drive's root (e.g. "\foo" might refer to "C:\foo") or to a network path (e.g. "\\host\foo"). On the other hand, (most?) systems that are not based on Win32 accept backslashes as valid characters that may be part of the filename, and thus we cannot treat them to identify absolute paths. Change the logic to only paths starting with '\' as absolute on the Win32 platform. Add tests to avoid regressions and document behaviour.
lhchavez 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.
Patrick Steinhardt 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.
Edward Thomson 16fd9ba9 2018-10-17T11:34:38 win32: more tests for `git_win32_remove_path`
Edward Thomson 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.
Gabriel DeBacker 3f096ca5 2018-10-04T13:03:25 Fix comment style and update test code
Gabriel DeBacker 8ab11dd5 2018-09-30T16:40:22 Fix issue with path canonicalization for Win32 paths
Edward Thomson 3be73011 2018-06-11T18:26:22 Merge pull request #4436 from pks-t/pks/packfile-stream-free pack: rename `git_packfile_stream_free`
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Patrick Steinhardt 92159bd4 2018-05-30T12:18:04 path: unify `git_path_is_*` APIs Right now, there's quite a lot of different function calls to determine whether a path component matches a specific name after normalization from the filesystem. We have a function for each of {gitattributes, gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks. In the long time, this is unmaintainable in case there are e.g. new filesystems with specific semantics, blowing up the number of functions we need to implement. Replace all functions with a simple `git_path_is_gitfile` function, which accepts an enum pointing out the filename that is to be checked against as well as the filesystem normalizations to check for. This greatly simplifies implementation at the expense of the caller having to invoke a somewhat longer function call.
Carlos Martín Nieto 57e343d7 2018-05-24T21:58:40 path: hand-code the zero-width joiner as UTF-8
Carlos Martín Nieto a7168b47 2018-05-22T16:13:47 path: reject .gitmodules as a symlink Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
Carlos Martín Nieto 02c80ad7 2018-05-22T15:21:08 path: accept the name length as a parameter We may take in names from the middle of a string so we want the caller to let us know how long the path component is that we should be checking.
Carlos Martín Nieto 177dcfc7 2018-05-18T15:16:53 path: hide the dotgit file functions These can't go into the public API yet as we don't want to introduce API or ABI changes in a security release.
Carlos Martín Nieto 9de97ae7 2018-05-16T15:42:08 path: add a function to detect an .gitmodules file Given a path component it knows what to pass to the filesystem-specific functions so we're protected even from trees which try to use the 8.3 naming rules to get around us matching on the filename exactly. The logic and test strings come from the equivalent git change.
Edward Thomson 318b825e 2016-02-16T17:11:46 index: allow read of index w/ illegal entries Allow `git_index_read` to handle reading existing indexes with illegal entries. Allow the low-level `git_index_add` to add properly formed `git_index_entry`s even if they contain paths that would be illegal for the current filesystem (eg, `AUX`). Continue to disallow `git_index_add_bypath` from adding entries that are illegal universally illegal (eg, `.git`, `foo/../bar`).
Edward Thomson 07c989e9 2015-02-03T20:01:24 win32: further cleanups for 8.3 disabling
Edward Thomson 5f28ec84 2015-02-03T12:16:11 win32: cleanup 8.3 disabled tests
Linquize 9dcc4a36 2015-01-28T23:04:50 Fix test failures when 8.3 is disabled
Edward Thomson 1fbfcdfc 2015-01-12T15:48:53 git_path_join_unrooted: return base len The documentation for `git_path_join_unrooted` states that the base length will be returned, so that consumers like checkout know where to start creating directories instead of always creating directories at the directory root.
Linquize 6987a580 2014-12-19T23:54:42 Add more Windows reserved filenames
Linquize 6fd00266 2014-12-19T23:54:01 COM0 is a valid path, although Windows Explorer does not allow to create this
Edward Thomson ec74b40c 2014-12-16T18:53:55 Introduce core.protectHFS and core.protectNTFS Validate HFS ignored char ".git" paths when `core.protectHFS` is specified. Validate NTFS invalid ".git" paths when `core.protectNTFS` is specified.
Edward Thomson 11d67b75 2014-12-10T19:12:16 checkout: disallow bad paths on HFS HFS filesystems ignore some characters like U+200C. When these characters are included in a path, they will be ignored for the purposes of comparison with other paths. Thus, if you have a ".git" folder, a folder of ".git<U+200C>" will also match. Protect our ".git" folder by ensuring that ".git<U+200C>" and friends do not match it.
Edward Thomson 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.
Edward Thomson 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:\)
The rugged tests are fragile bbb988a5 2014-09-17T14:52:31 path: Fix `git_path_walk_up` to work with non-rooted paths
Ciro Santilli 1d20092c 2014-09-16T18:36:49 Remove unused buf variable from path/core test.
Sam Clegg ccd8ba9b 2014-09-08T16:45:57 Fix warnings in thread-utils.h when building without -DTHREADSAFE=ON The compiler was generating a bunch of warnings for git_mutex_init and git_mutex_lock when GIT_THREADS was not defined (i.e. when not using -DTHREADSAFE=ON). Also remove an unused variable from tests/path/core.c.
Edward Thomson 0ee9f31c 2014-08-20T10:23:39 Introduce git_path_make_relative