avoid borg list of archives that have been listed before

This makes sync a lot faster in the common case where there's no new
backup.

There's still room for it to be faster. Currently the old imported tree
has to be traversed, to generate the ImportableContents. Which then
gets turned around to generate the new imported tree, which is
identical. So, it would be possible to just return a "no new imports",
or an ImportableContents that has a way to graft in a tree. The latter
is probably too far to go to optimise this, unless other things need it.
The former might be worth it, but it's already pretty fast, since git
ls-tree is pretty fast.

improve storage of redundant ContentIdentifiers

When a ContentIdentifier is already recorded, don't add it to the log
again, and avoid updating the log.

include borg archive name in tree, use empty ContentIdentifier

It's unusual to use a ContentIdentifier that is not semi-unique
for different contents. Note that in importKeys, it checks if a content
identifier is one that's known before, to avoid downloading the same
content twice. But that's done in a code path not used for borg repos,
because they are thirdpartypopulated.

notes on ImportableContents history not being used for retrieval

import from borg is basically working

Still some issues to deal with, see TODO and XXX.

Here's what gets logged, for each key:

cid log:
1608582045.832799227s 6720ebad-b20e-4460-a8f2-2477361aea75 !MjAyMC0xMi0yMVQxMTozMzoxNw==:!MjAyMC0xMi0yMVQxMzowNzoyNg==

The "!Mj" are base64 encoded borg archive names, since mine were
dates and contained some characters not allowed in cid logs unescaped.
There were archives that each contained the key. This list will grow as
more borg backups are done and learned about.

tree generated:
120000 blob 5ef6a4615c084819b44cd4e3a31657664ddf643b x/dotgit/annex/objects/06/mv/SHA256E-s30--a5d8532e64ec28f5491e25e7a6c1cb68f80507c1be6c1b35f8ec53d25413e5da/SHA256E-s30--a5d8532e64ec28f5491e25e7a6c1cb68f80507c1be6c1b35f8ec53d25413e5da
120000 blob 063a139d3021c8db60f5c576d29fada2b824d91c x/dotgit/annex/objects/72/PP/SHA256E-s30--e80b09a854b4e4d99a76caaa6983b34272480e0b4fdb95d04234a54b4849b893/SHA256E-s30--e80b09a854b4e4d99a76caaa6983b34272480e0b4fdb95d04234a54b4849b893
120000 blob b53b54916fd6abf21fedf796deca08d5ac7a75af x/dotgit/annex/objects/Ww/pk/SHA256E-s30--6aac072a8ebf02a5807c4f15e77ed585a6c87b3b333ba625a3c8d6b4dc50a9f2/SHA256E-s30--6aac072a8ebf02a5807c4f15e77ed585a6c87b3b333ba625a3c8d6b4dc50a9f2

This commit was sponsored by Denis Dzyubenko on Patreon.

improve thirdpartypopulated support

May actually work now.

Note that, importKey now has to add the size to the key if it's supposed
to have size. Remote.Directory relied on the importer adding the size,
which is no longer done, so it was changed; it was the only one.
This way, importKey does not need to behave differently between regular
and thirdpartypopulated imports.

support thirdPartyPopulated

These don't have importTree in their config, because they don't support
tree import, but they do still support import, and do not support export
or key/value modification.

fix logic error in thirdPartyPopulated handling

refactor

That code was not borg specific, and I can see making more remotes for
other backup software.

started borg special remote

Still need to implement 3 methods, but importKeyM looks like it will
work well to find annex object files.

Merge branch 'master' into borg

build fix

start borg special remote

Compiles, but unusable so far.

Merge branch 'master' into borg

add thirdPartyPopulated interface

This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.

So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that  the tree is recorded in the export log, and gets grafted
into the git-annex branch.

importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.

It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.

Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.

(Untested and unused as of yet.)

This commit was sponsored by Jochen Bartl on Patreon.

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

fix handling of importtree-only remotes

Don't want to try to use these remotes as key/value remotes, which will
surely fail. It only recently became possible for importtree to be set
w/o exporttree, so before this code was ok.

(cherry picked from commit 97599cb0f7f4115aa5a3e81a91ee3d1d6c52dc84)

update

change info from export=yes to exporttree=yes and same for import

for consistency

Added a comment: encryption=onlycreds

Merge branch 'master' into borg

avoid redundant set of a S3 verison ID that is already recorded

I think this could cause unnecessary changes to the git-annex branch,
and retrieveExportWithContentIdentifier is now also used for getting
content from importtree=yes remotes, so it would happen more frequently
so let's avoid.

Merge branch 'master' into borg

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

todo

update warnExportImportConflict for import-only remotes

fix call to warnExportImportConflict

That needs a Remote that has the right export/import set up, not the input
Remote, which does not yet.

add missing space

import remotes use ContentIdentifier for getting and checking content

This is better than using the equivilant actions for export remotes,
especially for getting content, since the ContentIdentifier checking
means we can be sure (enough) that the content is valid to not force
verification of content. Which allows getting keys of types that cannot
be verified.

Also, reorganized the internals of adjustExportImport which was becoming
very hard to follow. Now it's clear what each method does in each case.

force verification after getting file from export remote

This way, if annex.verify is disabled, it's still checked, since this is
not a key/value store, it has to be checked.

Added a comment

refactor common code

Added a comment

provide missing remote actions for importree only remote

Ah, it seemed too easy before when I was implementing importrree only,
and it was because all the key-based actions needed to be handled too.

Mostly copied from isexport, and this works. It does seem that
an import remote could use retrieveExportWithContentIdentifier
rather than retrieveExport, and checkPresentExportWithContentIdentifier
rather than checkPresentExport, which would both be more accurate.

importtree only remotes are untrusted, same as exporttree remotes

Importtree only remotes are new; importtree remotes used to always also be
exporttree, so were untrusted.

Since an import remote is one that can be edited by something other than
git-annex, it's clearly not trustworthy at all.

Added a comment

improve comment

docs for borg special remote

(which DNE yet)

typo

improve synopsis

response

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

improve docs

man page improvement

simplify

As the only blocking operation now is threadDelaySeconds, no need to
calculate actual time and actual expected minimum size.

Added a comment

Added a comment: How do I `man` annex config options?

Added a comment: Duplicate content creates frustrating cycles

Add post metadata

update

comment

check Remote.hasKeyCheap again

In cd1676d604, it stopped using that to avoid surprising behavior
when the location log and remote content were out of sync.
But, it seems that may have changed some behavior users relied on as
well, and also Remote.hasKeyCheap should be faster than checking then
location log.

So, try Remote.hasKeyCheap first, and only if it does not have the key,
fall back to checking the location log. If the location log still thinks
it's present, go ahead and try to get it, so the user will see a failure
rather than silently skipping a file what whereis says is on the remote.

This does make slightly slower the case where the remote does not have
the key, and location log and Remote.hasKeyCheap agree, since it now
checks both. But only 1 stat slower.

followup

comment

comment

response

OSXMkLibs: skip @loader_path

This may or may not make the OSX build work on a newer version of OSX
than the one that's currently being used for release builds. I have not
been able to find good docs about how exactly to get back from such a
value to the actual path to the library that the linker would use.

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

Windows: include= and exclude= containing '/' will also match filenames that are written using '\'

And vice-versa, but it's better to use '/' for portability.

Notably, standardPreferredContent contains "archive/*" and that might not
match if the filename ends up coming in with the slashes the other way
around.

Added a comment

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

reorg

clarify

initremote: Prevent enabling encryption with exporttree=yes/importtree=yes

I do think this was a reversion, but I have not tracked back to what
version. While involving the remote config, it's not the same class of
problems that I kept having to chase down for a while after the remote
config parser reworking.

propagate git-annex -c on to transferrer child process

git -c was already propagated via environment, but need this for
consistency.

Also, notice it does not use gitAnnexChildProcess to run the
transferrer. So nothing is done about avoid it taking the
pid lock. It's possible that the caller is already doing something that
took the pid lock, and if so, the transferrer will certianly fail,
since it needs to take the pid lock too. This may prevent combining
annex.stalldetection with annex.pidlock, but I have not verified it's
really a problem. If it was, it seems git-annex would have to take
the pid lock when starting a transferrer, and hold it until shutdown,
or would need to take pid lock when starting to use a transferrer,
and hold it until done with a transfer and then drop it. The latter
would require starting the transferrer with pid locking disabled for the
child process, so assumes that the transferrer does not do anyting that
needs locking when not running a transfer.

pass along -c options to child git-annex processes

populate new field

Editing files in tag / view branch

importfeed: Avoid using youtube-dl when a feed does not contain an enclosure, but only a link to an url which youtube-dl does not support

This is common in some feeds, which might mix some items with enclosures,
with others that link to posts or whatever. Before this, it would try to
use youtube-dl and fail, or if youtube-dl was not allowed, it would
incorrectly complain that an url was supported by youtube-dl.

Added a comment: yay, it's working now! :)

typo

avoid using MatchingKey where MatchingFile can be used now

This is actually matching worktree files, and now that a Key can be
provided along with the file when doing that, using MatchingFile
reflects that.

improve readability and fix a warning

comment

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

add key to FileInfo

MatchingKey is not the thing to use when matching on actual worktreee
files.

Fix reversion in 8.20201116 that made include= and exclude= in
preferred/required content expressions match a path relative to the current
directory, rather than the path from the top of the repository.

Added a comment

clarify comment

add USE_SYSTEM_LIBS=1 for osxapp build

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

improve some edge cases around partial initialization

* Guard against running in a repo where annex.uuid is set but
  annex.version is set, or vice-versa.
* Avoid autoinit when a repo does not have annex.version or annex.uuid
  set, but has a git-annex objects directory, suggesting it was used
  by git-annex before.

improve display

rename and refactor

Added a comment

add

Added a comment

Added a comment

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

fix stall detection to actually work when fully stalled

When fully stalled, the progress bar doesn't update, so waiting on a
MVar would block forever. There's no need to wait anyway, just wake up
after sleeping the configured period and check the current value.

Luckily Viasat makes it really easy for me to notice this kind of
mistake, by stalling long TCP connections frequently.

mention annex.stalldetection and don't recommend too infrequent progress updates

Added a comment

response and related todo

avoid transferrer committing the git-annex branch on shutdown

The parent is will do it when it shuts down, and having both of them
trying to do it at the same time seems like something good to avoid.

remove

I need to think about this some more, not clear if it's a todo
item specific to stalldetection at all. Remotes with this behavior
also show no progress when run with -J. And some other remotes don't
update any progress meters at all, eg adb is that way and so are hook
remotes and of course external remotes don't have to send progress info.

note

close

propagate signals to the transferrer process group

Done on unix, could not implement it on windows quite.

The signal library gets part of the way needed for windows.
But I had to open https://github.com/pmlodawski/signal/issues/1 because
it lacks raiseSignal.

Also, I don't know what the equivilant of getProcessGroupIDOf is on
windows. And System.Process does not provide a way to send any signal to
a process group except for SIGINT.

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.