tests/core/filebuf.c


Log

Author Commit Date CI Message
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Patrick Steinhardt c10ce7c2 2017-03-20T12:11:05 tests: filebuf: test writing to symlink with absolute paths
Jacques Germishuys 87428c55 2015-11-20T20:48:51 Fix some warnings
Edward Thomson 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.
Edward Thomson ea3f2c29 2015-09-08T14:35:53 filebuf: ensure we can lock a hidden file
Carlos Martín Nieto 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.
Carlos Martín Nieto 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.
Carlos Martín Nieto 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.
Ben Straub 17820381 2013-11-14T14:05:52 Rename tests-clar to tests