summaryrefslogtreecommitdiff
path: root/tests/core/filebuf.c
Commit message (Collapse)AuthorAgeFilesLines
* tests: core: improve symlink test coveragePatrick Steinhardt2019-07-201-9/+6
| | | | | | | | 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.
* treewide: remove use of C++ style commentsPatrick Steinhardt2018-07-131-1/+1
| | | | | | | | | 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.
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-2/+2
|
* tests: filebuf: test writing to symlink with absolute pathsPatrick Steinhardt2017-03-201-0/+29
|
* Fix some warningsJacques Germishuys2015-11-201-1/+1
|
* filebuf: detect directories in our wayEdward Thomson2015-11-031-0/+9
| | | | | | 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.
* filebuf: ensure we can lock a hidden fileEdward Thomson2015-09-081-0/+26
|
* filebuf: follow symlinks when creating a lock filecmn/follow-symlinkCarlos Martín Nieto2015-09-051-0/+53
| | | | | | | 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.
* filebuf: remove lockfile upon rename errorscmn/filebuf-rename-errorCarlos Martín Nieto2015-07-241-1/+1
| | | | | | | | | | 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.
* filebuf: failing test for leaving the lockfile when failing to renameCarlos Martín Nieto2015-07-241-0/+27
| | | | | When we fail to rename, we currently leave the lockfile laying around. This shows that behaviour.
* Rename tests-clar to testsBen Straub2013-11-141-0/+126