| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Make p_getcwd match the rest of our win32 path handling semantics.
(This is currently only used in tests, which is why this disparity went
unnoticed.)
|
| |
|
|
| |
Make some syntax change to follow coding style.
|
| |\
| |
| | |
GCC C11 warnings
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Instead of buf->"typeofbuffer"ReparseBuffer the members will be
referenced with buf->ReparseBuffer."typeofbuffer"
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_reparse_data_buffer?redirectedfrom=MSDN
calls the union DUMMYUNIONNAME but that looks a bit cluttered.
|
| |\ \
| | |
| | | |
Introduce GIT_WARN_UNUSED_RESULT
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the location of `GIT_WARN_UNUSED_RESULT` was causing it to
be included _after_ a bunch of other headers (namely `src/vector.h`),
which broke the build.
This change does two things:
* Moves the `GIT_WARN_UNUSED_RESULT` above most of the `$include`s in
`src/common.h`.
* Stops including `vector.h` from `src/win32/path_w32.c` since the
header itself does not use it.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Even on systems without C99 where long long and stdint are both
missing, we can shim stdint and point it to any compiler-specific
type (i.e long long, _int64, etc.).
Also next is constant suffixes and determining what needs to
include stdint.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
* Use pread/pwrite to avoid updating position in file descriptor
* Emulate missing pread/pwrite on win32 using overlapped file IO
|
| |
|
|
|
|
|
| |
Provide more clarity for Win32 calling conventions - now that we always
compile to __cdecl on Win32, we'll define that as the the libgit2
calling convention. Also offer NTAPI (__stdcall) calling conventions
for things that need callbacks from NTAPI code (eg fiber-local storage).
|
| | |
|
| | |
|
| |
|
|
|
| |
Move leak check initialization into git_win32_leakcheck_global_init, and
call it on library initialization.
|
| |
|
|
|
| |
msvc crtdbg is a mouthfull that is not particularly indicative of what
it does. Let's rename it to "win32 leakcheck".
|
| |\
| |
| | |
Refactor "global" state
|
| | |
| |
| |
| |
| | |
Provide a mechanism for system components to register for initialization
and shutdown of the libgit2 runtime.
|
| | |
| |
| |
| |
| |
| | |
We want to store a pointer to emulate `pthread_exit` on Windows. Do
this within the threading infrastructure so that it could potentially be
re-used outside of the context of libgit2 itself.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our "global initialization" has accumulated some debris over the years.
It was previously responsible for both running the various global
initializers (that set up various subsystems) _and_ setting up the
"global state", which is actually the thread-local state for things
like error reporting.
Separate the thread local state out into "threadstate". Use the normal
subsystem initialization functions that we already have to set it up.
This makes both the global initialization system and the threadstate
system simpler to reason about.
|
| | |
| |
| |
| |
| | |
Instead of treating win32 thread initialization specially in the win32
git_libgit2_init function, add a git_global_threads_init function.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change:
* Increases MY_ROW_LIMIT to 2M, since it has been failing in #5595's
tests since it's _super_ close to the limit.
* Calls `git_repository_free()` on a `git_repository` that was being
leaked only in Windows.
* Marks the global `git_repository` on `tests/repo/init.c` as `NULL`
after being freed to make any accidental access more noisy.
* Uses `cl_assert_equal_i()` in `test_trace_windows_stacktrace__leaks`
to make the test failures more actionable.
* Renames the globals in `tests/repo/init.c` so that they don't start
with an underscore.
|
| |
|
|
| |
Fix the default LIBGIT2_FILENAME for GNU windres
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We've accumulated quite some functions which are never used outside of
their respective code unit, but which are lacking the `static` keyword.
Add it to reduce their linkage scope and allow the compiler to optimize
better.
|
| |
|
|
|
|
|
|
|
|
|
| |
Don't canonicalize symlink targets; our win32 path canonicalization
routines expect an absolute path. In particular, using the path
canonicalization routines for symlink targets (introduced in commit
7d55bee6d, "win32: fix relative symlinks pointing into dirs",
2020-01-10).
Now, use the utf8 -> utf16 relative path handling functions, so that
paths like "../foo" will be translated to "..\foo".
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows platforms, we need some logic to emulate symlink(3P) defined
by POSIX. As unprivileged symlinks on Windows are a rather new feature,
our current implementation is comparatively new and still has some
rough edges in special cases.
One such case is relative symlinks. While relative symlinks to files in
the same directory work as expected, libgit2 currently fails to create
reltaive symlinks pointing into other directories. This is due to the
fact that we forgot to translate the Unix-style target path to
Windows-style. Most importantly, we are currently not converting
directory separators from "/" to "\".
Fix the issue by calling `git_win32_path_canonicalize` on the target.
Add a test that verifies our ability to create such relative links
across directories.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows platforms, we automatically clean up the thread-local storage
upon detaching a thread via `DllMain()`. The thing is that this happens
for every thread of applications that link against the libgit2 DLL, even
those that don't have anything to do with libgit2 itself. As a result,
we cannot assume that these unsuspecting threads make use of our
`git_libgit2_init()` and `git_libgit2_shutdow()` reference counting,
which may lead to racy situations:
Thread 1 Thread 2
git_libgit2_shutdown()
DllMain(DETACH_THREAD)
git__free_tls_data()
git_atomic_dec() == 0
git__free_tls_data()
TlsFree(_tls_index)
TlsGetValue(_tls_index)
Due to the second thread never having executed `git_libgit2_init()`, the
first thread will clean up TLS data and as a result also free the
`_tls_index` variable. When detaching the second thread, we
unconditionally access the now-free'd `_tls_index` variable, which is
obviously not going to work out well.
Fix the issue by converting the code to use fiber-local storage instead
of thread-local storage. While FLS will behave the exact same as TLS if
no fibers are in use, it does allow us to specify a destructor similar
to the one that is accepted by pthread_key_create(3P). Like this, we do
not have to manually free indices anymore, but will let the FLS handle
calling the destructor. This allows us to get rid of `DllMain()`
completely, as we only used it to keep track of when threads were
exiting and results in an overall simplification of TLS cleanup.
|
| |
|
|
| |
Prefer `off64_t` internally.
|
| |
|
|
| |
Prefer `off64_t` to `git_off_t` for internal visibility.
|
| |
|
|
| |
64 bit types are always 64 bit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a symlink in Windows, one needs to tell Windows whether
the symlink should be a file or directory symlink. To determine which
flag to pass, we call `GetFileAttributesW` on the target file to see
whether it is a directory and then pass the flag accordingly. The
problem though is if create a symlink with a relative target path, then
we will check that relative path while not necessarily being inside of
the working directory where the symlink is to be created. Thus, getting
its attributes will either fail or return attributes of the wrong
target.
Fix this by resolving the target path relative to the directory in which
the symlink is to be created.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When deleting a symlink on Windows, then the way to delete it depends on
whether it is a directory symlink or a file symlink. In the first case,
we need to use `DeleteFile`, in the second `RemoveDirectory`. Right now,
`p_unlink` will only ever try to use `DeleteFile`, though, and thus fail
to remove directory symlinks. This mismatches how unlink(3P) is expected
to behave, though, as it shall remove any symlink disregarding whether
it is a file or directory symlink.
In order to correctly unlink a symlink, we thus need to check what kind
of file this is. If we were to first query file attributes of every file
upon calling `p_unlink`, then this would penalize the common case
though. Instead, we can try to first delete the file with `DeleteFile`
and only if the error returned is `ERROR_ACCESS_DENIED` will we query
file attributes and determine whether it is a directory symlink to use
`RemoveDirectory` instead.
|
| |
|
|
|
|
|
|
|
| |
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 both `git_win32__stack_format` and `git_win32__stack`, we handle
buffer lengths via an integer variable. As we only ever pass buffer
sizes to it, this should be a `size_t` though to avoid loss of
precision. As we also use it to compare with other `size_t` variables,
this also silences signed/unsigned comparison warnings.
|
| | |
|
| |
|
|
|
|
|
| |
GetProcAddress is prototyped to return a `FARPROC`, which is meant to be
a generic function pointer. It's literally `int (FAR WINAPI * FARPROC)()`
which gcc complains if you attempt to cast to a `void (*)(GIT_SRWLOCK *)`.
Cast to a `void *` before casting to avoid warnings about the arguments.
|
| |
|
|
|
| |
RtlCaptureStackBackTrace is well-defined in Windows, no need to redefine
it.
|
| |
|
|
|
|
| |
Move `git_win32__file_attribute_to_stat` to a regular function instead
of an inlined function. This helps avoid header ordering issues and
declarations.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By now, we have repeatedly failed to provide a nice
cross-platform implementation of `p_fallocate`. Recent tries to
do that escalated quite fast to a set of different CMake checks,
implementations, fallbacks, etc., which started to look real
awkward to maintain. In fact, `p_fallocate` had only been
introduced in commit 4e3949b73 (tests: test that largefiles can
be read through the tree API, 2019-01-30) to support a test with
large files, but given the maintenance costs it just seems not to
be worht it.
As we have removed the sole user of `p_fallocate` in the previous
commit, let's drop it altogether.
|