Added a comment

Added a comment

Added a comment

Added a comment: how to rename/remove the [here] ??

Added a comment: Explanation for a noGUI usage

Added a comment: import from special directory remote fails due to running out of memory

windows build fix from jwodder

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

comment

perf note

Following up to f44d4704c638e2fdb48dd0667809b16fac377b5b,
I tried making updateIncremental pure, avoiding the IORef overhead.
That did not improve speed though. It did complicate the interface since
thunks needed to be forced to avoid leaking memory. So am not going with
that change.

Looking at Crypto.Hash.hashUpdate, it copies a byte array on each call,
compared with hashlazy that only uses 1 copy for the whole bytestring.
That could well explain a lot of the overhead discussed in the
abovementioned commit. Don't see any way to improve that while hashing
incrementally, except using bigger chunks should reduce its overhead.
Since 10x larger chunks did not, I'm kind of puzzled if it's really
what's affecting performance.

Added a comment

comment

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

optimisation

IORef rather than MVar sped up benchmark mentioned in last commit to
13.0s.

This makes me wonder if changing the interface to not need the IORef
either would improve speed further.

incremental checksum for local remotes

This benchmarks only slightly faster than the old git-annex. Eg, for a 1
gb file, 14.56s vs 15.57s. (On a ram disk; there would certianly be
more of an effect if the file was written to disk and didn't stay in
cache.)

Commenting out the updateIncremental calls make the same run in 6.31s.
May be that overhead in the implementation, other than the actual
checksumming, is slowing it down. Eg, MVar access.

(I also tried using 10x larger chunks, which did not change the speed.)

stop using rsync in fileCopier

This is groundwork for calculating checksums while copying, rather than
in a separate pass, but that's not done yet. For now, avoid using rsync
(and cp on Windows), and instead read and write the file ourselves, with
resume handling.

Benchmarking vs old git-annex that used rsync, this is faster,
at least once the file size is larger than a couple of MB.

refactoring

Bugfix: fsck --from a ssh remote did not actually check that the content on the remote is not corrupted

Changing to the P2P protocol broke this, because preseedTmp copies
the local copy of the object to the temp file, and then the P2P transfer
sees the right length file and uses it as-is.

When git-annex-shell is too old and rsync is used, it did verify the
content, and when the local repo does not have the object it did verify the
content.

comment

fix missing call to check after hard linking

This could perhaps have caused a hard link to be made when the content
of the object was modified. I don't think that actually happened,
because the annexed file would have to be unlocked, with annex.thin, for
the object to get modified, and in that case, a hard link is not made.
However, to be sure, run the check.

Note that it seemed best to run the check only once, although the
current implementation is fast and safe to run repeatedly.

Merge branch 'incrementalhash'

incremental checksum on upload to ssh or p2p

deal with possibility of short read by S.hGet

It may read less than requested, and may yield an empty string if the
file was somehow shorter than expected.

Added a comment

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

comment

incremental checksum on download from ssh or p2p

Checksum as content is received from a remote git-annex repository, rather
than doing it in a second pass.

Not tested at all yet, but I imagine it will work!

Not implemented for any special remotes, and also not implemented for
copies from local remotes. It may be that, for local remotes, it will
suffice to use rsync, rely on its checksumming, and simply return Verified.
(It would still make a checksumming pass when cp is used for COW, I guess.)

add incremental hashing interface to Backend

As yet unused.

Backend.External could perhaps implement it too, although that would
involve sending chunks of data to it via a pipe or something, so likely
to be slow.

comment

Tahoe: Avoid verifying hash after download, since tahoe does sufficient verification itself

See my comment in the next commit for some details about why
Verified needs a hash with preimage resistance. As far as tahoe goes,
it's fully cryptographically secure.

I think that bup could also return Verified. However, the Retriever
interface does not currenly support that.

Added a comment

Added a comment

close

reorder

deal with cabal unpack not preserving execute bit

close as dup

2021

avoid making absolute git remote path relative

When a git remote is configured with an absolute path, use that path,
rather than making it relative. If it's configured with a relative path,
use that.

Git.Construct.fromPath changed to preserve the path as-is,
rather than making it absolute. And Annex.new changed to not
convert the path to relative. Instead, Git.CurrentRepo.get
generates a relative path.

A few things that used fromAbsPath unncessarily were changed in passing to
use fromPath instead. I'm seeing fromAbsPath as a security check,
while before it was being used in some cases when the path was
known absolute already. It may be that fromAbsPath is not really needed,
but only git-annex-shell uses it now, and I'm not 100% sure that there's
not some input that would cause a relative path to be used, opening a
security hole, without the security check. So left it as-is.

Test suite passes and strace shows the configured remote url is used
unchanged in the path into it. I can't be 100% sure there's not some code
somewhere that takes an absolute path to the repo and converts it to
relative and uses it, but it seems pretty unlikely that the code paths used
for a git remote would call such code. One place I know of is gitAnnexLink,
but I'm pretty sure that git remotes never deal with annex symlinks. If
that did get called, it generates a path relative to cwd, which would have
been wrong before this change as well, when operating on a remote.

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

Added a comment: why relative path?

removed

Added a comment

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

update

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

suggest when user may want annex.stalldetection

When annex.stalldetection is not enabled, and a likely stall is detected,
display a suggestion to enable it.

Note that the progress meter display is not taken down when displaying
the message, so it will display like this:

0%    8 B                 0 B/s
  Transfer seems to have stalled. To handle stalling transfers, configure annex.stalldetection
0%    10 B                0 B/s

Although of course if it's really stalled, it will never update
again after the message. Taking down the progress meter and starting
a new one doesn't seem too necessary given how unusual this is,
also this does help show the state it was at when it stalled.

Use of uninterruptibleCancel here is ok, the thread it's canceling
only does STM transactions and sleeps. The annex thread that gets
forked off is separate to avoid it being canceled, so that it
can be joined back at the end.

A module cycle required moving from dupState the precaching of the
remote list. Doing it at startConcurrency should cover all the cases
where the remote list is used in concurrent actions.

This commit was sponsored by Kevin Mueller on Patreon.

remove accidental duplicated code

The code in Annex.WorkerStage and Annex.Concurrent was 100% identical.

automatic stall detection

annex.stalldetection can now be set to "true" to make git-annex do
automatic stall detection when it detects a remote is updating its transfer
progress consistently enough.

This commit was sponsored by Luke Shumaker on Patreon.

Added a comment

Added a comment

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

support fuzzy matching of addon commands

Note this does find things in PATH that are not executable.
Like searchPath use, the executable bit is not checked. Thing is,
there does not seem to be a binding for access(), which would be the
right way to check that the right execute bit is set. Anyway, if it's in
PATH and it's a file, it's probably fine to treat it as something that
was intended to be executable.

This commit was sponsored by Brock Spratlen on Patreon.

add searchPathContents

And rename related functions for consistency.

addon commands

Seems only fair, that, like git runs git-annex, git-annex runs
git-annex-foo.

Implementation relies on O.forwardOptions, so that any options are passed
through to the addon program. Note that this includes options before the
subcommand, eg: git-annex -cx=y foo

Unfortunately, git-annex eats the --help/-h options.
This is because it uses O.hsubparser, which injects that option into each
subcommand. Seems like this should be possible to avoid somehow, to let
commands display their own --help, instead of the dummy one git-annex
displays.

The two step searching mirrors how git works, it makes finding
git-annex-foo fast when "git annex foo" is run, but will also support fuzzy
matching, once findAllAddonCommands gets implemented.

This commit was sponsored by Dr. Land Raider on Patreon.

move global options handling closer to Command definitions

refactor

Added a comment

close old todo

close

reject

remove no longer relevant part

meant to close this earlier

comment

fix syntax

close

remove priority tag (unused)

comment

update tutorial to work with 6 year old version of git-annex-shell

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

comment

comment

comment

comment

comment

response

remove spam

Include libkqueue.h file needed to build the assistant on BSDs

I suspect this is a bug in cabal sdist, because with
Includes: Utility/libkqueue.h
the file is not included, but putting it in extra-files does
get it into the tarball.

Fix build on openbsd. Thanks, James Cook for the patch.

fix build on openbsd

Added a comment: App Development

Added a comment: problems with init after clone

removed

Added a comment: problems with annex init in cloned repo

Added a comment