| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit 45f24e787 (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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:\`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Move to the `git_error` name in the internal API for error-related
functions.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
Update to forced checkout and untracked files
|
| | |
| |
| |
| |
| | |
Only ignore `EBUSY` from `rmdir` when the `GIT_RMDIR_SKIP_NONEMPTY` bit
is set.
|
| | | |
|
| |/
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
git_futils: don't O_EXCL and O_TRUNC
|
| | |
| |
| |
| |
| |
| | |
`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`.
|
| |\ \
| |/
|/| |
fsync all the things
|
| | |
| |
| |
| | |
Windows doesn't support it.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
Only use defaults for `git_futils_writebuffer` when flags == 0, lest
(1 << 31) be treated as the defaults.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| |\
| |
| | |
git_index_entry__init_from_stat: set nsec fields in entry stats
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`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`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Now that `git_path_direach` lets us specify an error message to report,
set an appropriate error message while linking.
|
| | |
|
| | |
|
| |
|
|
|
| |
Without this change, compiling with gcc and pedantic generates warning:
ISO C does not allow extra ‘;’ outside of a function.
|
| |\
| |
| | |
allocations: test for overflow of requested size
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Make our overflow checking look more like gcc and clang's, so that
we can substitute it out with the compiler instrinsics on platforms
that support it. This means dropping the ability to pass `NULL` as
an out parameter.
As a result, the macros also get updated to reflect this as well.
|
| | |
| |
| |
| |
| | |
Ensure that the given length to `p_read` is of ssize_t and ensure
that callers test the return as if it were an `ssize_t`.
|
| | |
| |
| |
| |
| | |
Introduce some helper macros to test integer overflow from arithmetic
and set error message appropriately.
|
