Added a comment: GitHub Actions

update

comment

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

comment

comment

Added a comment: Update

removed

Added a comment: Update

When retrival from a chunked remote fails, display the error that occurred when downloading the chunk

Rather than the error that occurred when trying to download the unchunked
content, which is less likely to actually be stored in the remote.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

followup

remove 3 comments that turned out to be about an unrelated problem which got its own bug report

avoid crashing tilde expansion on user who does not exist

git does not crash when there's a remote configured for a user who does
not exist, and this prevents git-annex from crashing too. Consider that
a user might exist on one system but not another, and the git repo be
moved between systems. So not crashing is desirable.

Note that git fetch seems to mishandle a remote path like ~foo/bar
when the user does not exist. While it does access ./~foo/bar,
and gets as far as running git-upload-pack on the path,
it then complains there is no such repo. So different parts of git seem
to be doing different things in that edge case. Anyway, git-annex does
not need to be bug-for-bug compatible with git.

Sponsored-by: Jack Hill on Patreon

close per comment

open todo

move gpg tmp home to system temp dir

test: Put gpg temp home directory in system temp directory, not filesystem
being tested.

Since I've found indications gpg can fail talking to the agent when the
socket ends up on eg, fat. And to hopefully fix this bug report I've
followed up on.

The main risk in using the system temp dir is that TMPDIR could be set to a
long directory path, which is too long to put a unix socket in. To
partially amelorate that risk, it uses either an absolute or a relative
path, whichever is shorter. (Hopefully gpg will not convert it to a longer
form of the path..)

If the user sets TMPDIR to something so long a path to it +
"S.gpg-agent" is too long, I suppose that's their issue to deal with.

Sponsored-by: Dartmouth College's Datalad project

remove support code for ancient git-annex-shell version

Wow, 5.20140405.. Yeah, definitely not supported any more, just landed
commits need 6.20180312.

negotiate P2P protocol version for tor remotes

This negotiation is not supported by versions of git-annex older
than 6.20180312. Well, maybe really 6.20180227 or so, but using that in
the changelog simplifies things since it was the version for the other
changes as well.

See commit c81768d425725f868ddf23333d49eed0f3fda011 for the back story.

As well as allowing for future protocol improvements, this will result
in negoatiating protocol version 1, which is an improvement over default
version 0.

In fact, it looks like no supported version of git-annex will use
protocol version 0, since version 1 was introduced in 6.20180227.
Still, removing the code for version 0 seems unncessary.
See commit 31e1adc005e8181c5190a9f39a3f148e10f4d364.

Sponsored-by: Brett Eisenberg on Patreon.

remove list of removed commands

the list was wrong and also users shouldn't need to know

Merge branch 'p2pflagday'

fix duplicated commands in git-annex-shell usage display

remove git-annex-shell compat code

* Removed support for accessing git remotes that use versions of
  git-annex older than 6.20180312.
* git-annex-shell: Removed several commands that were only needed to
  support git-annex versions older than 6.20180312.
  (lockcontent, recvkey, sendkey, transferinfo, commit)

The P2P protocol was added in that version, and used ever since, so
this code was only needed for interop with older versions.

"git-annex-shell commit" is used by newer git-annex versions, though
unnecessarily so, because the p2pstdio command makes a single commit at
shutdown. Luckily, it was run with stderr and stdout sent to /dev/null,
and non-zero exit status or other exceptions are caught and ignored. So,
that was able to be removed from git-annex-shell too.

git-annex-shell inannex, recvkey, sendkey, and dropkey are still used by
gcrypt special remotes accessed over ssh, so those had to be kept.
It would probably be possible to convert that to using the P2P protocol,
but it would be another multi-year transition.

Some git-annex-shell fields were able to be removed. I hoped to remove
all of them, and the very concept of them, but unfortunately autoinit
is used by git-annex sync, and gcrypt uses remoteuuid.

The main win here is really in Remote.Git, removing piles of hairy fallback
code.

Sponsored-by: Luke Shumaker

remove broken code

git-annex-shell fsck has never worked, back in
commit 1ffb3bb0ba3c87d14b896dac2a308de9376a44f1 I discussed maybe adding
it one day, but this code has always failed.

add news item for git-annex 8.20211011

releasing package git-annex version 8.20211011

document how to resume downloads

comment

update

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

Merge branch 'borgchunks'

todo

ImportableContentsChunkable

This improves the borg special remote memory usage, by
letting it only load one archive's worth of filenames into memory at a
time, and building up a larger tree out of the chunks.

When a borg repository has many archives, git-annex could easily OOM
before. Now, it will use only memory proportional to the number of
annexed keys in an archive.

Minor implementation wart: Each new chunk re-opens the content
identifier database, and also a new vector clock is used for each chunk.
This is a minor innefficiency only; the use of continuations makes
it hard to avoid, although putting the database handle into a Reader
monad would be one way to fix it.

It may later be possible to extend the ImportableContentsChunkable
interface to remotes that are not third-party populated. However, that
would perhaps need an interface that does not use continuations.

The ImportableContentsChunkable interface currently does not allow
populating the top of the tree with anything other than subtrees. It
would be easy to extend it to allow putting files in that tree, but borg
doesn't need that so I left it out for now.

Sponsored-by: Noam Kremen on Patreon

Added a comment: Re: Resuming an interrupted download

Added a comment

Added a comment

add footnote about the permissions required and Microsoft blog post

avoid cursor jitter when updating progress display

When the progress display gets longer, and then shorter again, it causes
the cursor to jitter back and forth. Somehow I never noticed this until
this morning, but then it became intolerable to watch.

To fix it, pad the progress display to the maximum length it's occupied.

Sponsored-by: Svenne Krap on Patreon

remove mention of mount option `case=dir` (turned out to be unnecessary)

Added a comment

Added a comment

Added a comment

Added a comment: the WSL1 use case

rename WSL1 section to highlight date, add wording about being experimental, reword some awkwardness, add further directions

Add steps for WSL1

Added a comment

branch

progress in my head

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

Added a comment

remove unused imports

minor optimisation

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

remove old and uncessary sanity check

All backends use genKeyName, which uses preSanitizeKeyName, which will
escape newlines.

I suspect this newline prevention was added back when git-annex was
reading the output of sha1sum..

Sponsored-by: Kevin Mueller on Patreon

convert Key to ShortByteString

This adds the overhead of a copy when serializing and deserializing keys.
I have not benchmarked much, but runtimes seem barely changed at all by that.

When a lot of keys are in memory, it improves memory use.

And, it prevents keys sometimes getting PINNED in memory and failing to GC,
which is a problem ByteString has sometimes. In particular, git-annex sync
from a borg special remote had that problem and this improved its memory
use by a large amount.

Sponsored-by: Shae Erisson on Patreon

comment and correct incorrect info in previous comment

Added a comment

Added a comment

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

comment

Added a comment: Thanks!

Added a comment

update

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

comment

use bytestring filepaths more

This should be more efficient, and allocate less.

Sponsored-by: Graham Spencer on Patreon

Added a comment

convert ExportLocation to ShortByteString to avoid PINNED memory fragmentation

This adds the overhead of a copy whenever converting to/from ExportLocation and
ImportLocation.

borg: Some improvements to memory use when importing a lot of archives.
(It's still pretty bad.)

Sponsored-by: Mark Reidenbach on Patreon

update

comment

response

promote comment to bug

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

update

comment

Added a comment: Memory issues

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

remove errant print debug

Added a comment

Added a comment

remove information about old version of debian

Added a comment: Resuming an interrupted download

removed

Added a comment: Resuming an interrupted download

reinject: Fix crash when reinjecting a file from outside the repository

Commit 4bf7940d6b912fbf692b268f621ebd41ed871125 introduced this
problem, but was otherwise doing a good thing. Problem being
that fileRef "/foo" used to return ":./foo", which was actually wrong,
but as long as there was no foo in the local repository, catKey
could operate on it without crashing. After that fix though, fileRef
would return eg "../../foo", resulting in fileRef returning
":./../../foo", which will make git cat-file crash since that's
not a valid path in the repo.

Fix is simply to make fileRef detect paths outside the repo and return
Nothing. Then catKey can be skipped. This needed several bugfixes to
dirContains as well, in previous commits.

In Command.Smudge, this led to needing to check for Nothing. That case
should actually never happen, because the fileoutsiderepo check will
detect it earlier.

Sponsored-by: Brock Spratlen on Patreon

fix bug in dirContains

dirContains "." ".." was incorrectly true
because normalize ("." </> "..") = ".."

Sponsored-by: Jochen Bartl on Patreon

fix bug in dirContains

dirContains ".." "../.." was incorrectly True.

This does not seem to be an exploitable security hole, at least
as dirContains is used in git-annex.

Sponsored-by: Jochen Bartl on Patreon

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

avoid uncessary call to inAnnex

sync --content: Avoid a redundant checksum of a file that was
incrementally verified, when used on NTFS and perhaps other filesystems.

When sync has just gotten the content, it does not need to check inAnnex a
second time. On NTFS, for some reason the write of the inode cache after
it gets the content is not immediately able to be read, and with an
empty/non-matching inode cache due to that stale data, inAnnex falls back
to hashing the whole object to determine if it's present.

Sponsored-by: Brock Spratlen on Patreon

analysis

add sign off

post bug

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

started analysis

Added a comment: Email resent from my personal domain jibun.eu

note about coreutils 9.0 supporting CoW by default

comment