summaryrefslogtreecommitdiff
path: root/src/refdb_fs.c
Commit message (Collapse)AuthorAgeFilesLines
* Make enum in src,tests and examples C90 compliant by removing trailing comma.Peter Pettersson2021-11-151-1/+1
|
* fs_path: add length with suffix validationEdward Thomson2021-11-091-1/+1
|
* path: use new length validation functionsEdward Thomson2021-11-091-1/+1
|
* path: `validate` -> `is_valid`Edward Thomson2021-11-091-2/+2
| | | | | Since we're returning a boolean about validation, the name is more properly "is valid".
* path: separate git-specific path functions from utilEdward Thomson2021-11-091-21/+22
| | | | | | 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).
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-171-132/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix coding style for pointerpunkymaniac2021-09-091-1/+1
| | | | Make some syntax change to follow coding style.
* Merge pull request #5802 from lhchavez/git-warn-unused-resultEdward Thomson2021-08-251-3/+3
|\ | | | | Introduce GIT_WARN_UNUSED_RESULT
| * Proof-of-concept for a more aggressive GIT_UNUSED()lhchavez2021-08-081-3/+3
| | | | | | | | | | | | This adds a `-Wunused-result`-proof `GIT_UNUSED()`, just to demonstrate that it works. With this, sortedcache.h is now completely `GIT_WARN_UNUSED_RESULT`-annotated!
* | bugfix: don't generate paths with empty segmentsPeter Pettersson2021-08-081-2/+3
|/
* Merge branch 'zero_oid_in_old'Edward Thomson2021-05-161-1/+4
|\ | | | | | | Manually merging #5842
| * git_reference_create_matching: Treat all-zero OID as "must be absent"David Turner2021-04-201-1/+4
| | | | | | | | | | | | | | | | | | | | | | This is pretty useful in avoiding races: I want to create a ref only if it doesn't already exist. I can't check first because of TOCTOU -- by the time I finish the check, someone else might have already created the ref. And I can't take a lock because then I can't do the create, since the create expects to take the lock. The semantics are inspired by git update-ref, which allows an all-zero old value to mean that the ref must not exist.
* | refs: ensure loose refs adhere to path validationEdward Thomson2021-04-281-30/+54
| | | | | | | | | | | | | | | | | | On Windows, we need to enforce MAX_PATH for loose references and their reflogs. Ensure that any path - including the lock file - would fit within the 260 character maximum. We do not honor core.longpaths for loose reference files or reflogs. core.longpaths only applies to paths in the working directory.
* | path: git_path_isvalid -> git_path_validateEdward Thomson2021-04-141-2/+2
|/ | | | | | | If we want to validate more and different types of paths, the name `git_path_validate` makes that easier and more expressive. We can add, for example, `git_path_validate_foo` while the current name makes that less ergonomic.
* refdb_fs: Check git_sortedcache wlock/rlock errorspanda2021-02-161-2/+4
| | | | | To prevent a race condition, these wlock/rlock calls should probably be checked for errors.
* refdb_fs: use GIT_ASSERTEdward Thomson2020-11-271-31/+55
|
* refdb: extract function to check whether to append HEAD to the reflogPatrick Steinhardt2020-07-121-39/+13
| | | | | | | | | | | | The logic to determine whether a reflog entry should be for the HEAD reference is non-trivial. Currently, the only user of this is the filesystem-based refdb, but with the advent of the reftable refdb we're going to add a second user that's interested in having the same behaviour. Let's pull out a new function that checks whether a given reference should cause a entry to be written to the HEAD reflog as a preparatory step.
* refdb: extract function to check whether a reflog should be writtenPatrick Steinhardt2020-07-121-39/+4
| | | | | | | | | | The logic to determine whether a reflog should be written is non-trivial. Currently, the only user of this is the filesystem-based refdb, but with the advent of the reftable refdb we're going to add a second user that's interested in having the same behaviour. Let's pull out a new function that checks whether a given reference should cause a reflog to be written as a preparatory step.
* git_pool_init: handle failure casesethomson/poolinitEdward Thomson2020-06-011-1/+2
| | | | Propagate failures caused by pool initialization errors.
* refdb_fs: remove unused header filePatrick Steinhardt2020-03-251-2/+0
| | | | | | The "refdb_fs.h" header contains a single struct `git_refcache` that is not used anywhere. As a result, we can just delete the header altogether as it doesn't have any purpose and may confuse readers.
* refdb_fs: initialize backend versionPatrick Steinhardt2020-03-221-0/+3
| | | | | | While the `git_refdb_backend()` struct has a version, we do not initialize it correctly when calling `git_refdb_backend_fs()`. Fix this by adding the call to `git_refdb_init_backend()`.
* refs: rename git_reference__set_name to git_reference__reallocEtienne Samson2019-12-131-2/+2
| | | | | | | | | | | As git_reference__name will reallocate storage to account for longer names (it's actually allocator-dependent), it will cause all existing pointers to the old object to become dangling, as they now point to freed memory. Fix the issue by renaming to a more descriptive name, and pass a pointer to the actual reference that can safely be invalidated if the realloc succeeds.
* refdb_fs: properly parse corrupted reflogsPatrick Steinhardt2019-10-181-11/+12
| | | | | | | | | | | | | In previous versions, libgit2 could be coerced into writing reflog messages with embedded newlines into the reflog by using `git_stash_save` with a message containing newlines. While the root cause is fixed now, it was noticed that upstream git is in fact able to read such corrupted reflog messages just fine. Make the reflog parser more lenient in order to just skip over malformatted reflog lines to bring us in line with git. This requires us to change an existing test that verified that we do indeed _fail_ to parse such logs.
* refdb_fs: convert reflog parsing to use parserPatrick Steinhardt2019-10-181-44/+31
| | | | | The refdb_fs code to parse the reflog currently uses a hand-rolled parser. Convert it to use our `git_parse_ctx` structure instead.
* reflog: allow adding entries with newlines in their messagePatrick Steinhardt2019-10-181-0/+7
| | | | | | | | | | | | | | | | | | Currently, the reflog disallows any entries that have a message with newlines, as that would effectively break the reflog format, which may contain a single line per entry, only. Upstream git behaves a bit differently, though, especially when considering stashes: instead of rejecting any reflog entry with newlines, git will simply replace newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will create a reflog entry with "foo bar" as entry message. This commit adjusts our own logic to stop rejecting commit messages with newlines. Previously, this logic was part of `git_reflog_append`, only. There is a second place though where we add reflog entries, which is the serialization code in the filesystem refdb. As it didn't contain any sanity checks whatsoever, the refdb would have been perfectly happy to write malformatted reflog entries to the disk. This is being fixed with the same logic as for the reflog itself.
* refs: fix locks getting forcibly removedSebastian Henke2019-10-101-1/+1
| | | | | | | | | | | | | | | | | The flag GIT_FILEBUF_FORCE currently does two things: 1. It will cause the filebuf to create non-existing leading directories for the file that is about to be written. 2. It will forcibly remove any pre-existing locks. While most call sites actually do want (1), they do not want to remove pre-existing locks, as that renders the locking mechanisms effectively useless. Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to separate both behaviours cleanly from each other and convert callers to use it instead of `GIT_FILEBUF_FORCE` to have them honor locked files correctly. As this conversion removes all current users of `GIT_FILEBUF_FORCE`, this commit removes the flag altogether.
* refdb: make sure to remove packed refs firstEtienne Samson2019-09-051-10/+24
| | | | | This fixes part of the issue where, given a concurrent `git pack-refs`, a ref lookup could return an old, vestigial value from the packed file, as the valid loose one would have been deleted.
* refdb: repurpose filesystem prune functionEtienne Samson2019-09-051-6/+6
|
* refdb: reorder parameters for consistencyEtienne Samson2019-09-051-9/+10
|
* refdb: fix packed_delete clobbering some errorsEtienne Samson2019-09-051-5/+10
| | | | | In the case of a failed lookup, we'd paper over that by writing back the packed-refs successfully.
* refdb: make low-level deletion helpers explicitEtienne Samson2019-09-051-23/+47
|
* refdb: documentationEtienne Samson2019-09-051-1/+1
|
* fileops: rename to "futils.h" to match function signaturesPatrick Steinhardt2019-07-201-1/+1
| | | | | | | | | 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.
* configuration: cvar -> configmapPatrick Steinhardt2019-07-181-4/+4
| | | | | `cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
* global: convert trivial `fnmatch` users to use `wildcard`Patrick Steinhardt2019-06-151-4/+4
| | | | | | | | | | Upstream git.git has converted its codebase to use wildcard in favor of fnmatch in commit 70a8fc999d (stop using fnmatch (either native or compat), 2014-02-15). To keep our own regex-matching in line with what git does, convert all trivial instances of `fnmatch` usage to use `wildcard`, instead. Trivial usage is defined to be use of `fnmatch` with either no flags or flags that have a 1:1 equivalent in wildmatch (PATHNAME, IGNORECASE).
* posix: remove implicit include of "fnmatch.h"Patrick Steinhardt2019-06-151-0/+1
| | | | | | | | We're about to phase out our bundled fnmatch implementation as git.git has moved to wildmatch long ago in 2014. To make it easier to spot which files are stilll using fnmatch, remove the implicit "fnmatch.h" include in "posix.h" and instead include it explicitly.
* refdb_fs: make use of the `GIT_CONTAINER_OF` macroEtienne Samson2019-04-161-22/+22
|
* refdb_fs: fix race when migrating loose to packed refs in iterationPatrick Steinhardt2019-02-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, we first load the packed refs cache and only afterwards load the loose references. This is susceptible to a race when the loose ref is being migrated to a packed cache by e.g. git-pack-refs(1): libgit2 git-pack-refs 1. We load the packed ref, which does not yet have the migrated reference. 2. git-pack-refs updates the packed ref file to have the migrated ref. 3. git-pack-refs deletes the old loose ref. 4. We look up the loose ref. So we now do not find the reference at all and will never iterate over it. Fix the issue by reversing the order: instead of first loading the packed refs, we will now look up the loose reference first. If it has already been deleted, then it must already be present in the packed-refs by definition, as git.git will only delete the reference after updating the packed refs file.
* refdb_fs: remove ordering dependency on loose/packed refs loadingPatrick Steinhardt2019-02-151-8/+11
| | | | | | | | | | | | | | | | Right now, loading loose refs has the side-effect of setting the `PACKREF_SHADOWED` flag for references that exist both in the loose and the packed refs. Because of this, we are force do first look up packed refs and only afterwards loading the packed refs. This is susceptible to a race, though, when refs are being repacked: when first loading the packed cache, then it may not yet have the migrated loose ref. But when now trying to look up the loose reference afterwards, then it may already have been migrated. Thus, we would fail to find this reference in this scenario. Remove this ordering dependency to allow fixing the above race. Instead of setting the flag when loading loose refs, we will now instead set it lazily when iterating over the loose refs. This even has the added benefit of not requiring us to lock the packed refs cache, as we already have an owned copy of it.
* refdb_fs: do not lazily copy packed ref cachePatrick Steinhardt2019-02-151-13/+6
| | | | | | | | | | | | | | | When creating a new iterator, we eagerly load loose refs but only lazily create a copy of packed refs. The lazy load only happens as soon as we have iterated over all loose refs, opening up a potentially wide window for races. This may lead to an inconsistent view e.g. when the caller decides to reload packed references somewhen between iterating the loose refs, which is unexpected. Fix the issue by eagerly copying the sorted cache. Note that right now, we are heavily dependent on ordering here: we first need to reload packed refs, then we have to load loose refs and only as a last step are we allowed to copy the cache. This is because loading loose refs has the side-effect of setting the `PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid outputting packed refs that already exist as loose refs.
* refdb_fs: refactor error handling in iterator creationPatrick Steinhardt2019-02-151-15/+16
| | | | | Refactor the error handling in `refdb_fs_backend__iterator` to always return the correct error code returned by the failing function.
* refdb_fs: fix potential race with ref repacking in `exists` callbackPatrick Steinhardt2019-02-151-6/+18
| | | | | | | | | | | | | When repacking references, git.git will first update the packed refs and only afterwards delete any existing loose references that have now been moved to the new packed refs file. Due to this, there is a potential for racing if one first reads the packfile (which has not been updated yet) and only then trying to read the loose reference (which has just been deleted). In this case, one will incorrectly fail to lookup the reference and it will be reported as missing. Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`. Fix the race by reversing the lookup: we will now first check if the loose reference exists and only afterwards refresh the packed file.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-32/+32
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* references: use new names in internal usageethomson/git_refEdward Thomson2019-01-171-12/+12
| | | | Update internal usage to use the `git_reference` names for constants.
* refdb_fs: refactor error handling in `refdb_reflog_fs__delete`Patrick Steinhardt2018-12-191-12/+11
| | | | | | | | | | | | | | | The function `refdb_reflog_fs__delete` uses the `if (!error && foobar())` pattern of checking, where error conditions are being checked by following calls to different code. This does not match our current style, where the call-site of a function is usually directly responsible for checking the return value. Convert the function to use `if ((error = foobar()) < 0) goto out;` style. Note that this changes the code flow a bit: previously, we were always trying to delete empty reference hierarchies even if deleting the reflog entry has failed. This wasn't much of a problem -- if deletion failed, the hierarchy will still contain at least one file and thus the function call was an expensive no-op. Now, we will only perform this deletion if we have successfully removed the reflog.
* Merge pull request #4833 from csware/drop-empty-dirsPatrick Steinhardt2018-12-191-2/+42
|\ | | | | Remove empty (sub-)directories when deleting refs
| * Remove empty directories when deleting refsSven Strickroth2018-10-131-2/+42
| | | | | | | | Signed-off-by: Sven Strickroth <email@cs-ware.de>
* | object_type: use new enumeration namesethomson/index_fixesEdward Thomson2018-12-011-2/+2
| | | | | | | | Use the new object_type enumeration names within the codebase.
* | refs: add support for core.logAllRefUpdates=alwaysEtienne Samson2018-11-181-12/+20
|/ | | | | | | Since we were not expecting this config entry to contain a string, we would fail as soon as its (cached) value would be accessed. Hence, provide some constants for the 4 states we use, and account for "always" when we decide to reflog changes.
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-30/+30
|
View Lorry Controller Status