display drop safety proofs in debug mode

fix lockKey to run callback in original Annex monad, not local remote's

content locking during drop working for local git remotes

Only ssh remotes lack locking now

finish and use lockContent interface

improve drop proof code

refactor

TrustedCopy is good enough to allow dropping

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.

try harder to verify until at least one VerifiedCopyLock is obtained

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.

require 1 locked copy while dropping from local or a remote

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.

support invalidating existing VerifiedCopys

add VerifiedCopy data type

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.

add removeKey action to Remote

Not implemented for any remotes yet; probably the git remote is the only
one that will ever implement it.

unused import

I think this comment is stale/confusing; remove

git-annex-shell: Added lockcontent command, to prevent dropping of key's content.

add lockContentShared

Also, rename lockContent to lockContentExclusive

inAnnexSafe should perhaps be eliminated, and instead use
`lockContentShared inAnnex`. However, I'm waiting on that, as there are
only 2 call sites for inAnnexSafe and it's fiddly.

export FileMode type

add tryLockShared

open lock file ReadOnly when taking shared lock

It's only necessary to open a file for write when taking an exclusive lock.

getting proof-y

Debian: Remove dependency on transformers library, as it is now included in ghc.

Backporters will need to revert this.

titles

indents

alternative solution

analysis of some topologies, and idea to generate moves

Debian: Add torrent library to build-depends as it's packaged now, and stop recommending bittornado | bittorrent.

be verbose to debug problem with aws

add test cases for copy --auto

(Only --from for now, should add --to sometime but I'm on low sleep so this
is the mininal test to catch the reversion just fixed, bad me for doing it
backwards and incompletely.)

copy --auto was checking the wrong repo's preferred content. (--from was checking what --to should, and vice-versa.) Fixed this bug, which was introduced in version 5.20150727.

oops, didn't mean to commit this debug

analysis

comment

force installing older warp; current fails to build

sed out the filename from sha1sum output

hopefuly fix sha1sum calling; also refactor and check downloaded program's sha before using it

confirmed

Merge branch 'master' of ssh://git-annex.branchable.com

response

Add some precision about the versions tested and why it is a bug in mind opinion

response

comment

show git-annex init w/o description for laptop, where default would suffice. And for init of usb drive, be clear that it's a description, not a name.

response

avoid using print action, which is reserved for debugging

comment

hairy problem

comment

Added a comment: account information was emailed

Added a comment

Added a comment

no www doesn't seem to resolve here or on google's public NSs

Added a comment: statfs64

Added a comment

Added a comment

Minor grammar fix in my comment

Added a comment: Yay, man!

devblog

Merge branch 'winprocfix'

response

response

comment

review

remove workaround

Merge branch 'master' of ssh://git-annex.branchable.com

force installing older warp; current fails to build

Added a comment

Added a comment

Added a comment: no statfs64 on OpenBSD

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment: Need advice on using gitlab with the assistant

Added a comment

Added a comment

Added a comment

Ported disk free space checking code to work on Solaris.

On Solaris, using f_bsize provided a value that is apparently much larger
than the real block size. The solaris docs for statvfs say
f_bsize is the "preferred" file system block size, and I guess the
filesystem prefers larger blocks, but uses smaller ones or something.
The docs also say that f_frsize is the "fundamental" block size.

Switched to using f_frsize on Linux and kFreeBSD too, since I guess
f_bsize could in theory vary the same way there too. Assuming that Solaris
is not violating the posix spec, I guess the linux man page for statvfs
is not as well written and I misunderstood it.

deal with more backward-compatible breaking renamings in conduit

This is the kind of annoying thing that makes me not want to use a library.
conduitManagerSettings was a perfectly fine name and could have been kept
forever.

other 80% of avoding verification when hard linking to objects in shared repo

In c6632ee5c8e66c26ef18317f56ae02bae1e7e280, it actually only handled
uploading objects to a shared repository. To avoid verification when
downloading objects from a shared repository, was a lot harder.

On the plus side, if the process of downloading a file from a remote
is able to verify its content on the side, the remote can indicate this
now, and avoid the extra post-download verification.

As of yet, I don't have any remotes (except Git) using this ability.
Some more work would be needed to support it in special remotes.

It would make sense for tahoe to implicitly verify things downloaded from it;
as long as you trust your tahoe server (which typically runs locally),
there's cryptographic integrity. OTOH, despite bup being based on shas,
a bup repo under an attacker's control could have the git ref used for an
object changed, and so a bup repo shouldn't implicitly verify. Indeed,
tahoe seems unique in being trustworthy enough to implicitly verify.

disabling verification also disables size verification

It's not expensive to do size verification, but let's be consistent and
turn it off too.

avoid verification when hard linking to objects in shared repository

Such a repository is implicitly trusted, so there's no point.

response

Allow building with S3 disabled again.

Added a comment: not easy to access history

Added a comment: iiuc assistant depends on s3

Added a comment