Add a tip explaining how to enable-tor on NixOS

This is a little bare bones but hopefully useful, some things that could
be improved:

1. Follow steps in order and replicate (I reconstructed off of my
   success, so there may be inaccuracies or things I forgot)

2. Clarify correct ownership for directories & sockets
   - enable-tor's sudo child will obtain the hostname so no access is
     needed after that
   - does it also create the tor sockety directory?

3. Remove unnecessary boilerplate
   - can the hidden service dir be left with the NixOS default?

Added a comment: `git annex sync --no-commit --content` takes double the time of `git annex get .`

close

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

fix test suite failure when run with LANG=C

Added a comment: commit 492036622a6326852c29e23608f3959f63e55685 fixes this

Added a comment

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

fix OSX build

Added a comment: So where are the file stored?

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

incremental verification for gitlfs and httpalso

And that should be all the special remotes supporting it on linux now,
except for in the odd edge case here and there.

Sponsored-by: Dartmouth College's DANDI project

incremental verification for S3

Sponsored-by: Dartmouth College's DANDI project

incremental verification for web special remote

Except when configuration makes curl be used. It did not seem worth
trying to tail the file when curl is downloading.

But when an interrupted download is resumed, it does not read the whole
existing file to hash it. Same reason discussed in
commit 7eb3742e4b76d1d7a487c2c53bf25cda4ee5df43; that could take a long
time with no progress being displayed. And also there's an open http
request, which needs to be consumed; taking a long time to hash the file
might cause it to time out.

Also in passing implemented it for git and external special remotes when
downloading from the web. Several others like S3 are within striking
distance now as well.

Sponsored-by: Dartmouth College's DANDI project

distinguish between incremental verification failing and not being done

Sponsored-by: Dartmouth College's DANDI project

refactor

refactor

IncrementalVerifier moved to Utility.Hash, which will let Utility.Url
use it later.

It's perhaps not really specific to hashing, but making a separate
module just for the data type seemed unncessary.

Sponsored-by: Dartmouth College's DANDI project

remove comment

This comment used to be in Crypto, where it made sense, but it does not
really make any sense in Utility.Hash

status update

idea

Added a comment

commit f0754a61f doesn't compile on Windows without a small patch

plumb VerifyConfig into retrieveKeyFile

This fixes the recent reversion that annex.verify is not honored,
because retrieveChunks was passed RemoteVerify baser, but baser
did not have export/import set up.

Sponsored-by: Dartmouth College's DANDI project

comment

initial report about needing newer gpg to get tests pass

Added a comment: note on `sec=` on the mount

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

status update

incremental verify for webdav special remote

Sponsored-by: Dartmouth College's DANDI project

incremental verify for directory special remote

Added fileRetriever', which will let the remaining special remotes
eventually also support incremental verify.

Sponsored-by: Dartmouth College's DANDI project

refactor fileCopier

Sponsored-by: Dartmouth College's DANDI project

move comment

status update

I was wrong about S3 supporting tailVerify.

handle AlreadyInUseError

As happens when using the directory special remote, gitlfs, webdav, and
S3. But not external, adb, gcrypt, hook, or rsync.

Sponsored-by: Dartmouth College's DANDI project

better handling of finishing up incomplete incremental verify

Now it's run in VerifyStage.

I thought about keeping the file handle open, and resuming reading where
tailVerify left off. But that risks leaking open file handles, until the
GC closes them, if the deferred verification does not get resumed. Since
that could perhaps happen if there's an exception somewhere, I decided
that was too unsafe.

Instead, re-open the file, seek, and resume.

Sponsored-by: Dartmouth College's DANDI project

improve tailVerify

Wait for the file to get modified, not only opened. This way, if a
remote does not support resuming, and opens a new file over top of the
existing file, it will wait until that remote starts writing, and open
the file it's writing to, not the old file.

Sponsored-by: Dartmouth College's DANDI project

update description that it is isilon under

Added a comment: type=git special remote cannot be enabled, no uuid is generated

migrate script: Get full list of remotes that have a file; doc updates; progress output; corner case fixes

Added a comment: Another example

migrate script: Do whereis work before to speed up processing

Added a comment: annex-to-annex

migrate script: Fix accidentally commented-out fsck run

migrate script: Don't try on all remotes, look where it is and drop from there (faster)

Added a comment: annex-to-annex

Convert previously missing attachment

Tool to drop migrated files for good

fix windows build

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

status update

catch more exceptions

I saw this:

  .git/annex/tmp/SHA256E-s1234376--5ba8e06e0163b217663907482bbed57684d7188024155ddc81da0710dfd2687d: openBinaryFile: resource busy (file is locked)

 guess catching IO exceptions did not catch that one.

incremental hashing for fileRetriever

It uses tailVerify to hash the file while it's being written.

This is able to sometimes avoid a separate checksum step. Although
if the file gets written quickly enough, tailVerify may not see it
get created before the write finishes, and the checksum still happens.

Testing with the directory special remote, incremental checksumming did
not happen. But then I disabled the copy CoW probing, and it did work.
What's going on with that is the CoW probe creates an empty file on
failure, then deletes it, and then the file is created again. tailVerify
will open the first, empty file, and so fails to read the content that
gets written to the file that replaces it.

The directory special remote really ought to be able to avoid needing to
use tailVerify, and while other special remotes could do things that
cause similar problems, they probably don't. And if they do, it just
means the checksum doesn't get done incrementally.

Sponsored-by: Dartmouth College's DANDI project

INotify.removeWatch can crash

Unsure why, possibly if the file has been replaced by another file.

inotify reports paths relative to directory being watched

Sponsored-by: Dartmouth College's DANDI project

convert tailVerify to not finalize the verification

Added failIncremental so it can force failure to verify.

Sponsored-by: Dartmouth College's DANDI project

tailVerify: return deferred action when it gets behind

Sponsored-by: Dartmouth College's DANDI project

the fact that I needed a modification/patch to build mentioned

prop_view_roundtrips fails (occasionally)

windows build fails as of 7550ef9a2

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

comment

add tailVerify

Not yet used, but this will let all remotes verify incrementally if it's
acceptable to pay the performance price. See comment for details of when
it will perform badly. I anticipate using this for all special remotes
that use fileRetriever. Except perhaps for a few like GitLFS that could
feed the incremental verifier themselves despite using that.

Sponsored-by: Dartmouth College's DANDI project

a report on the flood of failing tests on discovery

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

Added a comment: I have this behavior consistently on the 2 repos I use

incremental verify for chunked remotes

Simply feed each chunk in turn to the incremental verifier.

When resuming an interrupted retrieve, it does not do incremental
verification. That would need to read the file, up to the resume point,
and feed it to the incremental verifier. That seems easy to get wrong.
Also it would mean extra work done before the transfer can start. Which
would complicate displaying progress, and would perhaps not appear to the
user as if it was resuming from where it left off. Instead, in that
situation, return UnVerified, and let the verification be done in a
separate pass.

Granted, Annex.CopyFile does manage all that, but it's not complicated
by dealing with chunks too.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

incremental verify for byteRetriever special remotes

Several special remotes verify content while it is being retrieved,
avoiding a separate checksum pass. They are: S3, bup, ddar, and
gcrypt (with a local repository).

Not done when using chunking, yet.

Complicated by Retriever needing to change to be polymorphic. Which in turn
meant RankNTypes is needed, and also needed some code changes. The
change in Remote.External does not change behavior at all but avoids
the type checking failing because of a "rigid, skolem type" which
"would escape its scope". So I refactored slightly to make the type
checker's job easier there.

Unfortunately, directory uses fileRetriever (except when chunked),
so it is not amoung the improved ones. Fixing that would need a way for
FileRetriever to return a Verification. But, since the file retrieved
may be encrypted or chunked, it would be extra work to always
incrementally checksum the file while retrieving it. Hm.

Some other special remotes use fileRetriever, and so don't get incremental
verification, but could be converted to byteRetriever later. One is
GitLFS, which uses downloadConduit, which writes to the file, so could
verify as it goes. Other special remotes like web could too, but don't
use Remote.Helper.Special and so will need to be addressed separately.

Sponsored-by: Dartmouth College's DANDI project

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

simplify and speed up Utility.FileSystemEncoding

This eliminates the distinction between decodeBS and decodeBS', encodeBS
and encodeBS', etc. The old implementation truncated at NUL, and the
primed versions had to do extra work to avoid that problem. The new
implementation does not truncate at NUL, and is also a lot faster.
(Benchmarked at 2x faster for decodeBS and 3x for encodeBS; more for the
primed versions.)

Note that filepath-bytestring 1.4.2.1.8 contains the same optimisation,
and upgrading to it will speed up to/fromRawFilePath.

AFAIK, nothing relied on the old behavior of truncating at NUL. Some
code used the faster versions in places where I was sure there would not
be a NUL. So this change is unlikely to break anything.

Also, moved s2w8 and w82s out of the module, as they do not involve
filesystem encoding really.

Sponsored-by: Shae Erisson on Patreon

remove unused function

Added a comment: sorry

comment

sheeeeeeeeesh

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

simplify

Added a comment

Added a comment

Added a comment: standalone build version vs standard release version

comment

response

typo

don't use changelog version in commit message

changelog may have a new unreleased version open already

close

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

rsync special remote: Stop displaying rsync progress, and use git-annex's own progress display

Reasons are same as in commit cee14f147ac229c99f001b3a0aaaefb4cb6f7785.
(It was already done when using -J.)

Sponsored-by: Mark Reidenbach on Patreon

Added a comment: Automatic watch for the heuristic

get failing to get if with --debug

reporting on odds in downloads.

Added a comment

Added a comment: creating directory special remote "in-place"

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

done!

Merge branch 'vectorclock'