| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
This new class was added to base a while ago; I don't know what uses it,
but it's intended to be an async exception, so make sure we don't catch it.
|
| | |
|
| | |
|
| |
|
|
| |
local copy be locked for removal
|
| | |
|
| | |
|
| |
|
|
| |
Only ssh remotes lack locking now
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
By definition, a trusted repository is trusted to always have its location
tracking log accurate. Thus, it should never be in a position where content
is being dropped from it concurrently, as that would result in the location
tracking log not being accurate.
|
| |
|
|
|
|
|
|
|
| |
This avoids a failure where eg, we start with RecentlyVerifiedCopies
for all remotes, and so didn't do any active verification, which is
required.
Also, dedup the list of VerifiedCopies when checking if we have enough,
in case 2 copies of a UUID slip in.
|
| |
|
|
|
|
|
|
|
| |
See doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn for
discussion about why 1 locked copy is all we can require, and how this
fixes concurrent dropping bugs.
Note that, since nothing yet generates a VerifiedCopyLock yet, this commit
breaks dropping temporarily.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There should be no behavior changes in this commit, it just adds a more
expressive data type and adjusts code that had been passing around a [UUID]
or sometimes a Maybe Remote to instead use [VerifiedCopy].
Although, since some functions were taking two different [UUID] lists,
there's some potential for me to have gotten it horribly wrong.
|
| |
|
|
| |
copy of a file as one of the necessary copies to allow removing it from the import location.
|
| | |
|
| |
|
Joey Hess