|
93d37a1d
|
2019-06-29T09:59:36
|
|
tests: core: improve symlink test coverage
Add two more tests to verify that we're not deleting symlink targets,
but the symlinks themselves. Furthermore, convert several `cl_skip`s on
Win32 to conditional skips depending on whether the clar sandbox
supports symlinks or not. Windows is grown up now and may allow
unprivileged symlinks if the machine has been configured accordingly.
|
|
|
9994cd3f
|
2018-06-25T11:56:52
|
|
treewide: remove use of C++ style comments
C++ style comment ("//") are not specified by the ISO C90 standard and
thus do not conform to it. While libgit2 aims to conform to C90, we did
not enforce it until now, which is why quite a lot of these
non-conforming comments have snuck into our codebase. Do a tree-wide
conversion of all C++ style comments to the supported C style comments
to allow us enforcing strict C90 compliance in a later commit.
|
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
|
c10ce7c2
|
2017-03-20T12:11:05
|
|
tests: filebuf: test writing to symlink with absolute paths
|
|
87428c55
|
2015-11-20T20:48:51
|
|
Fix some warnings
|
|
ec50b23a
|
2015-11-03T17:02:07
|
|
filebuf: detect directories in our way
When creating a filebuf, detect a directory that exists in our
target file location. This prevents a failure later, when we try
to move the lock file to the destination.
|
|
|
ea3f2c29
|
2015-09-08T14:35:53
|
|
filebuf: ensure we can lock a hidden file
|
|
d83b2e9f
|
2015-09-05T03:54:06
|
|
filebuf: follow symlinks when creating a lock file
We create a lockfile to update files under GIT_DIR. Sometimes these
files are actually located elsewhere and a symlink takes their place. In
that case we should lock and update the file at its final location
rather than overwrite the symlink.
|
|
|
19d9beb7
|
2015-07-24T19:22:41
|
|
filebuf: remove lockfile upon rename errors
When we have an error renaming the lockfile, we need to make sure
that we remove it upon cleanup. For this, we need to keep track of
whether we opened the file and whether the rename succeeded.
If we did create the lockfile but the rename did not succeed, we
remove the lockfile. This won't protect against all errors, but
the most common ones (target file is open) does get handled.
|
|
|
668053be
|
2015-07-24T18:44:29
|
|
filebuf: failing test for leaving the lockfile when failing to rename
When we fail to rename, we currently leave the lockfile laying
around. This shows that behaviour.
|
|
17820381
|
2013-11-14T14:05:52
|
|
Rename tests-clar to tests
|