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'

deal better with clock skew situations, using vector clocks

* Deal with clock skew, both forwards and backwards, when logging
  information to the git-annex branch.
* GIT_ANNEX_VECTOR_CLOCK can now be set to a fixed value (eg 1)
  rather than needing to be advanced each time a new change is made.
* Misuse of GIT_ANNEX_VECTOR_CLOCK will no longer confuse git-annex.

When changing a file in the git-annex branch, the vector clock to use is now
determined by first looking at the current time (or GIT_ANNEX_VECTOR_CLOCK
when set), and comparing it to the newest vector clock already in use in
that file. If a newer time stamp was already in use, advance it forward by
a second instead.

When the clock is set to a time in the past, this avoids logging with
an old timestamp, which would risk that log line later being ignored in favor
of "newer" line that is really not newer.

When a log entry has been made with a clock that was set far ahead in the
future, this avoids newer information being logged with an older timestamp
and so being ignored in favor of that future-timestamped information.
Once all clocks get fixed, this will result in the vector clocks being
incremented, until finally enough time has passed that time gets back ahead
of the vector clock value, and then it will return to usual operation.

(This latter situation is not ideal, but it seems the best that can be done.
The issue with it is, since all writers will be incrementing the last
vector clock they saw, there's no way to tell when one writer made a write
significantly later in time than another, so the earlier write might
arbitrarily be picked when merging. This problem is why git-annex uses
timestamps in the first place, rather than pure vector clocks.)

Advancing forward by 1 second is somewhat arbitrary. setDead
advances a timestamp by just 1 picosecond, and the vector clock could
too. But then it would interfere with setDead, which wants to be
overrulled by any change. So it could use 2 picoseconds or something,
but that seems weird. It could just as well advance it forward by a
minute or whatever, but then it would be harder for real time to catch
up with the vector clock when forward clock slew had happened.

A complication is that many log files contain several different peices of
information, and it may be best to only use vector clocks for the same peice
of information. For example, a key's location log file contains
InfoPresent/InfoMissing for each UUID, and it only looks at the vector
clocks for the UUID that is being changed, and not other UUIDs.

Although exactly where the dividing line is can be hard to determine.
Consider metadata logs, where a field "tag" can have multiple values set
at different times. Should it advance forward past the last tag?
Probably. What about when a different field is set, should it look at
the clocks of other fields? Perhaps not, but currently it does, and
this does not seems like it will cause any problems.

Another one I'm not entirely sure about is the export log, which is
keyed by (fromuuid, touuid). So if multiple repos are exporting to the
same remote, different vector clocks can be used for that remote.
It looks like that's probably ok, because it does not try to determine
what order things occurred when there was an export conflict.

Sponsored-by: Jochen Bartl on Patreon

Added a comment: downloading torrent files to annex

devblog

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

branch

Added a comment

update

new todo.. I seem to have cracked a longstanding problem

Sponsored-by: Jochen Bartl on Patreon

Added a comment

add: When adding a dotfile, avoid treating its name as an extension.

add news item for git-annex 8.20210803

releasing package git-annex version 8.20210803

whitespace

Added a comment

Added a comment: don't give up ;)

Added a comment

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

fix test suite

14683da9ebd629c3f77405b646d3f5661874f9d6 caused a test suite failure.
When the content of a key is not present, a LinkAnnexFailed is returned,
but replaceFile then tried to move the file into place, and since it was
not written, that crashed.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

fix missing new lines in processTranscript

initial observation of .dot filename to consider having .dot extension

Added a comment: Also seeing this behaviour

Added a comment

work around strange auto-init bug

git-annex get when run as the first git-annex command in a new repo did not
populate unlocked files. (Reversion in version 8.20210621)

I am not entirely happy with this, because I don't understand how
428c91606b434512d1986622e751c795edf4df44 caused the problem in the first
place, and I don't fully understand how skipping calling scanAnnexedFiles
during autoinit avoids the problem.

Kept the explicit call to scanAnnexedFiles during git-annex init,
so that when reconcileStaged is expensive, it can be made to run then,
rather than at some later point when the information is needed.

Sponsored-by: Brock Spratlen on Patreon

remove unused code

remove second pass in scanAnnexedFiles

The pass was needed to populate files when annex.thin was set,
but in commit 73e0cbbb19703f08daf783d8788370726f852162,
reconcileStaged started to do that. So, this second pass is not needed
any longer.