changelog

Merge tag '10.20240129'

tagging package git-annex version 10.20240129

releasing package git-annex version 10.20240129

improve changelog

comment

webapp: Added --port option, and annex.port config

The getSocket comment that mentioned using ":port"
in the hostname seems to have been incorrect or be out of date.
After all, the bug report came when the user first tried doing that,
and it didn't work.

Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project

close

confirm this todo

close

update

nack

nack

nack

close

Added --expected-present file matching option

comment

comment

update comment

The segfault seems to be fixed with git 2.43, I'm not sure what the
affected range was.

fix example that combined encryption=shared with keyid=

close since bug submittor is happy with new option

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

add directional stalldetection and bwlimit configs

Sponsored-by: Dartmouth College's DANDI project

use watchFileSize in Remote.External.retrieveKeyFile

external: Monitor file size when getting content from external special
remotes and use that to update the progress meter, in case the external
special remote program does not report progress.

This relies on 703a70cafa79eb0cf9f3ae676763e1798cb77292 to prevent ever
running the meter backwards.

Sponsored-by: Dartmouth College's DANDI project

RawFilePath conversion

Sponsored-by: Dartmouth College's DANDI project

avoid watchFileSize running backward

This is groundwork for using watchFileSize for downloads from external
special remotes.

In Annex.Content.downloadUrl, this potentially avoids jitter in the
progress meter. When downloading with conduit, the meter gets updated based
on both the size of the file, and on the data flowing through conduit.
If that has not yet been flushed to the file, it seems possible for the
meter to run backwards when meter is updated with the file size.
It's probably only a few kb of jitter, so may not be visible.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

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

tweak stall detection scaling

Refactored to allow offline experimentation, and ended up changing the
allowedvariation (aka fudge factor) to 3. 10 seems too high, and 1.5 too low.

Scale earlier, so even if the first chunk takes less than the configured
time period, allowance is made that later chunks might transfer slower.
Decided to use the same allowedvariation to decide when to start
scaling.

Smoothed the scaling out.

Some examples:

ghci> upscale (BwRate 10 (Duration 60)) 25
BwRate 13 (Duration {durationSeconds = 75})
-- A small scaling upwards after 1/3rd the time. Not noticable.
ghci> upscale (BwRate 10 (Duration 60)) 60
BwRate 30 (Duration {durationSeconds = 180})
-- At the configured time, 3x scaling.
ghci> upscale (BwRate 10 (Duration 60)) 120
BwRate 60 (Duration {durationSeconds = 360})
-- A typical upscaling, here a 1 minute duration became 6 minutes
-- due to the first chunk taking 2 minutes to transfer.
ghci> upscale (BwRate 10 (Duration 60)) 600
BwRate 300 (Duration {durationSeconds = 1800})
-- Here the first chunk took 10 minutes to transfer, so it will
-- take 30 minutes to detect a stall.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

Added a comment

comment

comment

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

automatically adjust stall detection period

Improve annex.stalldetection to handle remotes that update progress less
frequently than the configured time period.

In particular, this makes remotes that don't report progress but are
chunked work when transferring a single chunk takes longer than the
specified time period.

Any remotes that just have very low update granulatity would also be
handled by this.

The change to Remote.Helper.Chunked avoids an extra progress update when
resuming an interrupted upload. In that case, the code saw first Nothing
and then Just the already transferred number of bytes, which defeated this
new heuristic. This change will mean that, when resuming an interrupted
upload to a chunked remote that does not do its own progress reporting, the
progress display does not start out displaying the amount sent so far,
until after the first chunk is sent. This behavior change does not seem
like a major problem.

About the scalefudgefactor, it seems reasonable to expect subsequent chunks
to take no more than 1.5 times as long as the first chunk to transfer.
Could set it to 1, but then any chunk taking a little longer would be
treated as a stall. 2 also seems a likely value. Even 10 might be fine?

Sponsored-by: Dartmouth College's DANDI project

Added a comment

improve annex.stalldetection documentation

comment

open todo

comment

document that --listen specifies an IP address

Avoid users getting confused and thinking this allows specifying the
port.

Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project

cleanup

import: --message/-m option

comment

not a bug

fixed

fix windows build

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

Mention annextimelog

Added a comment

Added a comment: I can confirm

close

disk free checking for unsized keys

Improve disk free space checking when transferring unsized keys to
local git remotes. Since the size of the object file is known, can
check that instead.

Getting unsized keys from local git remotes does not check the actual
object size. It would be harder to handle that direction because the size
check is run locally, before anything involving the remote is done. So it
doesn't know the size of the file on the remote.

Also, transferring unsized keys to other remotes, including ssh remotes and
p2p remotes don't do disk size checking for unsized keys. This would need a
change in protocol.

(It does seem like it would be possible to implement the same thing for
directory special remotes though.)

In some sense, it might be better to not ever do disk free checking for
unsized keys, than to do it only sometimes. A user might notice this
direction working and consider it a bug that the other direction does not.
On the other hand, disk reserve checking is not implemented for most
special remotes at all, and yet it is implemented for a few, which is also
inconsistent, but best effort. And so doing this best effort seems to make
some sense. Fundamentally, if the user wants the size to always be checked,
they should not use unsized keys.

Sponsored-by: Brock Spratlen on Patreon

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

optimise adjustTree when adding many TreeItems (take 2)

The old code traversed the list of addtreeitems once per subdirectory in
the tree, so could get quite slow. Converting to Map lookups sped it up
significantly.

In my test case, git-annex import used to take about 2 minutes, when
calling adjustTree to add back excluded files to the imported tree. This
dropped it down to 6 seconds. Of which 4 seconds are the actual
enumeration of the contents of the remote, so really only 2 seconds for
this.

The path prefix map is a bit suboptimal memory-wise, since items get
stored in the map once per subdirectory on the path to the item. It
would perhaps be better to use a tree data structure.

Also it's suboptimal memory-wise that it builds two maps, as well
as retaining a reference to addtreeitems. I could not see a way around
that though.

This is a fixed version of commit 2c86651180d5c8648b8244be894c26bc98a6c334.
It fixes a test suite reversion.

Sponsored-by: Jack Hill on Patreon

typo fix (renote -> remote)

windows build is broken

Added a comment

Added a comment

rename forum/Initial_macOS_setup_between_two_Macs.mdwn to forum/Initial_macOS_setup_between_two_local_Macs.mdwn

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

update

support annex.shared-sop-command for encryption=shared

This works well, and it interoperates with gpg in my testing (although some
SOP commands might choose to use a profile that does not so caveat emptor).

Note that for creating the Cipher, gpg --gen-random is still used. SOP
does not have an eqivilant, and as long as the user has gpg around,
which seems likely, it doesn't matter that it uses gpg here, it's not being
used for encryption. That seemed better than implementing a second way
to get high quality entropy, at least for now.

The need for the sop command to run in an empty directory has each call
to encrypt and decrypt creating a new temporary directory. That is some
unncessary overhead, though probably swamped by the overhead of running
the sop command. This could be improved in the future by passing an
already empty directory to them, or a sufficiently empty directory
(.git/annex/tmp would probably suffice).

Sponsored-by: Brett Eisenberg on Patreon

more groundwork for StatelessOpenPGP

no behavior changes

Added a comment: Try datalad

clarify that combined hook program is deprecated, not entire hook special remote

Added a comment

Added a comment

close send side of password pipe on exec

This avoids a hang approximately 1% of the time when running the test
suite on StatelessOpenPGP.

Since I've not seen git-annex hang when running git like that, I guess
git probably does something that avoids hanging similarly. Still, fixed
the same problem in Utility.Gpg too.

Sponsored-by: Kevin Mueller on Patreon

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

reverted problem commit

Revert "optimise adjustTree when adding many TreeItems"

This reverts commit 2c86651180d5c8648b8244be894c26bc98a6c334.

That commit caused a test failure and problably wrong trees to be
imported, so revert until that is fixed.

test annex.shared-sop-command

Test a specified Stateless OpenPGP command with eg:
git-annex test --test-git-config annex.shared-sop-command=sqop

Also documented that config and another one, but so far only the test suite
uses the configs, have not yet implemented using it for actual symmetric
encryption.

Sponsored-by: Joshua Antonishen on Patreon

Stateless OpenPGP interface

Implemented according to
https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-09.html#name-encrypt-encrypt-a-message

Not yet used by git-annex.

Sponsored-by: Leon Schuermann on Patreon

correct comment

update comment

Added a comment: Not a special remote

comments

update

sop

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

assistant: When generating a gpg secret key, avoid hardcoding the key algorithm and size

This aims to future-proof gpg key generation. OpenPGP is in flux with a
conflict over standards ongoing. It seems not unlikely that different
systems will have different gpg commands that support different algorithms.

This also simplifies the code by using the --quick-gen-key interface rather
than the experimental batch interface. It seems less likely that
--quick-gen-key will break than an experimental interface (whose
documentation I can no longer find).

--quick-gen-key is supported since gpg 2.1.0 (2014).

Sponsored-by: Graham Spencer on Patreon

Added a comment: Using fuse annexize - works like a charm

reporting about --listen

Added a comment

Added a comment

new issue about stalling transfers

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

optimise adjustTree when adding many TreeItems

The old code traversed the list of addtreeitems once per subdirectory in
the tree, so could get quite slow. Converting to Map lookups sped it up
significantly.

In my test case, git-annex import used to take about 2 minutes, when
calling adjustTree to add back excluded files to the imported tree. This
dropped it down to 6 seconds. Of which 4 seconds are the actual
enumeration of the contents of the remote, so really only 2 seconds for
this.

The path prefix map is a bit suboptimal memory-wise, since items get
stored in the map once per subdirectory on the path to the item. It
would perhaps be better to use a tree data structure.

Also it's suboptimal memory-wise that it builds two maps, as well
as retaining a reference to addtreeitems. I could not see a way around
that though.

Sponsored-by: Luke T. Shumaker on Patreon

Added a comment: confirmed fixed

todo

bump copyright year

after my first commit of 2024

comment