- 20 Jul, 2019 1 commit
-
-
Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
Patrick Steinhardt committed
-
- 11 Jul, 2019 1 commit
-
-
In commit 45f24e78 (git_repository_init: stop traversing at windows root, 2019-04-12), we have fixed `git_futils_mkdir` to correctly handle the case where we create a directory in Windows-style filesystem roots like "C:\repo". The problem here is an off-by-one: previously, to that commit, we've been checking wether the parent directory's length is equal to the root directory's length incremented by one. When we call the function with "/example", then the parent directory's length ("/") is 1, but the root directory offset is 0 as the path is directly rooted without a drive prefix. This resulted in `1 == 0 + 1`, which was true. With the change, we've stopped incrementing the root directory length, and thus now compare `1 <= 0`, which is false. The previous way of doing it was kind of finicky any non-obvious, which is also why the error was introduced. So instead of just re-adding the increment, let's explicitly add a condition that aborts finding the parent if the current parent path is "/". Making this change causes Azure Pipelines to fail the testcase repo::init::nonexistent_paths on Unix-based systems. This is because we have just fixed creating directories in the filesystem root, which previously didn't work. As Docker-based tests are running as root user, we are thus able to create the non-existing path and will now succeed to create the repository that was expected to actually fail. Let's split this up into three different tests: - A test to verify that we do not create repos in a non-existing parent directoy if the flag `GIT_REPOSITORY_INIT_MKPATH` is not set. - A test to verify that we fail if the root directory does not exist. As there is a common root directory on Unix-based systems that always exist, we can only test for this on Windows-based systems. - A test to verify that we fail if trying to create a repository in an unwriteable parent directory. We can only test this if not running tests as root user, as CAP_DAC_OVERRIDE will cause us to ignore permissions when creating files.
Patrick Steinhardt committed
-
- 24 Jun, 2019 1 commit
-
-
Edward Thomson committed
-
- 17 Apr, 2019 1 commit
-
-
Stop traversing the filesystem at the Windows directory root. We were calculating the filesystem root for the given directory to create, and walking up the filesystem hierarchy. We intended to stop when the traversal path length is equal to the root path length (ie, stopping at the root, since no path may be shorter than the root path). However, on Windows, the root path may be specified in two different ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter. `git_path_dirname_r` returns the path _without_ a trailing slash, even for the Windows root. As a result, during traversal, we need to test that the traversal path is _less than or equal to_ the root path length to determine if we've hit the root to ensure that we stop when our traversal path is `Z:` and our calculated root path was `Z:\`.
Edward Thomson committed
-
- 15 Feb, 2019 1 commit
-
-
Currently, one would use the function `git_strmap_insert` to insert key/value pairs into a map. This function has historically been a macro, which is why its syntax is kind of weird: instead of returning an error code directly, it instead has to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes. Introduce a new function `git_strmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all callers of `git_strmap_insert` to make use of it.
Patrick Steinhardt committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 26 Dec, 2017 1 commit
-
-
We want to do this in order to get FETCH_HEAD to be empty when we start updating it due to fetching from the remote.
Carlos Martín Nieto committed
-
- 03 Jul, 2017 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 10 Jun, 2017 1 commit
-
-
Only ignore `EBUSY` from `rmdir` when the `GIT_RMDIR_SKIP_NONEMPTY` bit is set.
Edward Thomson committed
-
- 08 Jun, 2017 1 commit
-
-
Patrick Steinhardt committed
-
- 12 Apr, 2017 1 commit
-
-
When the `git_futils_mmap_ro_file` function encounters an error after the file has been opened, it will do a simple returns. Instead, we should close the opened file descriptor to avoid a leak. This commit fixes the issue.
Patrick Steinhardt committed
-
- 04 Apr, 2017 1 commit
-
-
When executing `git_futils_mmap_ro_file`, we first try to guess whether the file is mmapable at all. Part of this check is whether the file is too large to be mmaped, which can be true on systems with 32 bit `size_t` types. The check is performed by first getting the file size wtih `git_futils_filesize` and then checking whether the returned size can be represented as `size_t`, returning an error if so. While this test also catches the case where the function returned an error (as `-1` is not representable by `size_t`), we will set the misleading error message "file too large to mmap". But in fact, a negative return value from `git_futils_filesize` will be caused by the inability to fstat the file. Fix the error message by handling negative return values separately and not overwriting the error message in that case.
Patrick Steinhardt committed
-
- 22 Mar, 2017 1 commit
-
-
`O_EXCL` and `O_TRUNC` are mutually exclusive flags to open(2); you can't truncate a file if you're asserting that it can't exist in the first place. Drop `O_TRUNC`.
Edward Thomson committed
-
- 09 Mar, 2017 1 commit
-
-
Don't compute the sha-1 in `git_futils_readbuffer_updated` unless the checksum was requested. This means that `git_futils_readbuffer` will not calculate the checksum unnecessarily.
Edward Thomson committed
-
- 28 Feb, 2017 4 commits
-
-
Windows doesn't support it.
Edward Thomson committed -
When fsync'ing files, fsync the parent directory in the case where we rename a file into place, or create a new file, to ensure that the directory entry is flushed correctly.
Edward Thomson committed -
Only use defaults for `git_futils_writebuffer` when flags == 0, lest (1 << 31) be treated as the defaults.
Edward Thomson committed -
Add a custom `O_FSYNC` bit (if it's not been defined by the operating system`) so that `git_futils_writebuffer` can optionally do an `fsync` when it's done writing. We call `fsync` ourselves, even on systems that define `O_FSYNC` because its definition is no guarantee of its actual support. Mac, for instance, defines it but doesn't support it in an `open(2)` call.
Edward Thomson committed
-
- 17 Feb, 2017 2 commits
-
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
- 29 Dec, 2016 1 commit
-
-
Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
Edward Thomson committed
-
- 14 Nov, 2016 1 commit
-
-
We need to save the errno, lest we clobber it in the giterr_set() call. Also add code for reporting that a path component is missing, which is a distinct failure mode.
Carlos Martín Nieto committed
-
- 04 Aug, 2016 2 commits
-
-
Since writing multiple objects may all already exist in a single packfile, avoid freshening that packfile repeatedly in a tight loop. Instead, only freshen pack files every 2 seconds.
Edward Thomson committed -
When writing an object, we calculate its OID and see if it exists in the object database. If it does, we need to freshen the file that contains it.
Edward Thomson committed
-
- 25 Feb, 2016 1 commit
-
-
Android NDK does not have a `struct timespec` in its `struct stat` for nanosecond support, instead it has a single nanosecond member inside the struct stat itself. We will use that and use a macro to expand to the `st_mtim` / `st_mtimespec` definition on other systems (much like the existing `st_mtime` backcompat definition).
Edward Thomson committed
-
- 09 Feb, 2016 1 commit
-
-
Edward Thomson committed
-
- 20 Nov, 2015 1 commit
-
-
Jacques Germishuys committed
-
- 30 Oct, 2015 2 commits
-
-
This reduces the chances of a crash in the thread tests. This shouldn't affect general usage too much, since the main usage of these functions are to read into an empty buffer.
Carlos Martín Nieto committed -
Instead of relying on the size and timestamp, which can hide changes performed in the same second, hash the file content's when we care about detecting changes.
Carlos Martín Nieto committed
-
- 02 Oct, 2015 1 commit
-
-
Axel Rasmussen committed
-
- 19 Sep, 2015 2 commits
-
-
Axel Rasmussen committed
-
Axel Rasmussen committed
-
- 17 Sep, 2015 4 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
`git_futils_mkdir` does not blindly call `git_futils_mkdir_relative`. `git_futils_mkdir_relative` is used when you have some base directory and want to create some path inside of it, potentially removing blocking symlinks and files in the process. This is not suitable for a general recursive mkdir within the filesystem. Instead, when `mkdir` is being recursive, locate the first existent parent directory and use that as the base for `mkdir_relative`.
Edward Thomson committed -
Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter assumes that we own everything beneath the base, as if it were being called with a base of the repository or working directory, and is tailored towards checkout and ensuring that there is no bogosity beneath the base that must be cleaned up. This is (at best) slow and (at worst) unsafe in the larger context of a filesystem where we do not own things and cannot do things like unlink symlinks that are in our way.
Edward Thomson committed
-
- 17 May, 2015 1 commit
-
-
We set an error if we get an error when reading, but we don't bother setting an error message for write failing. This causes a cryptic error to be shown to the user when the target filesystem is full.
Carlos Martín Nieto committed
-
- 15 May, 2015 1 commit
-
-
Now that `git_path_direach` lets us specify an error message to report, set an appropriate error message while linking.
Carlos Martín Nieto committed
-
- 11 May, 2015 1 commit
-
-
J Wyman committed
-