Added a comment

Added a comment

Added a comment

comment

comment

comment

Added a comment

Added a comment

Added a comment

comment

comment

comment

reopen

comment

comment

comment

comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment: still slow

Added a comment

comment

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

comment

Added a comment

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

comment

Added a comment

close

hard link git-annex to fix ./git-annex test

2fc46e1871e2f793689cc98523744040c9010bdc broke running ./git-annex test
when git-annex-shell is not in PATH from another install, and also
caused the wrong git-annex-shell to be tested.

Using a symlink made programPath return the .cabal/ directory where the
git-annex binary is, but git-annex-shell is not in that directory.
Changing to a hard link avoids that problem.

Sponsored-by: Dartmouth College's Datalad project

fix build warning with old aeson

close

document nix-on-droid as an alternative to termux

Sponsored-by: Graham Spencer on Patreon

comment

comment; close

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

Added a comment: Works fine

Added a comment

Added a comment

Added a comment

update

Added a comment

Added a comment: Thanks!

Added a comment

Added a comment

rename bugs/git-annex_is_slow_at_reading_files.mdwn to bugs/git-annex_is_slow_at_reading_file_content.mdwn

changelog

factor out Utility.Aeson.textKey

add back lost packString

The patch that removed it did not break anything, since the strings it's
used on are all ASCII not unicode. But I like making sure to use
packString everywhere just in case the code later changes in a way that
needs it.

allow building with aeson >= 2.0

In aeson 2.0, Text has been replaced by the Key type and HashMap by the
KeyMap interface. Accomodating this required adding some CPP in order to
still be able to compile with aeson < 2.0. The required changes were:

* Prevent Key from being re-exported by Utilities.Aeson, as it clashes
  with git-annex's own Key type.

* Fix up convertion from String/Text to Key (or Text in aeson 1.*) in a
  couple of places

* Import Data.Aeson.KeyMap instead of Data.HashMap.Strict, as they are
  mostly API-compatible. insertWith needs to be replaced by unionWith,
  however, as KeyMap lacks the former function.

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

add

Added a comment

git-annex test from standalone speedup

Avoid git-annex test being very slow when run from within the standalone
linux tarball or OSX app.

It may not really be necessary to add to PATH the directory where the
git-annex binary resides, but it can't hurt. Most places where the test
suite or git-annex run git-annex, they use programPath, so won't need
a modified PATH. But I'm not sure if that's always the case.

Sponsored-by: Dartmouth College's Datalad project

update comment

comment

remove broken test

After ce91f10132805d11448896304821b0aa9c6d9845, unannex on a non-annexed
file is expected to fail, unless annex.skipunknown were globally
overridden to true. So this test that used to succeed should probably
fail, but it seems better to just remove it than expect it to fail.

Added a comment: question about backend

initial report on a very slow git annex test  on discovery

commet

Added a comment

Added a comment

update

open related todo

remove 127/128 exit status mention

I cannot find any indication that git-annex uses these exit statuses,
and I see I didn't write this doc so I don't know where those numbers
came from. Odd.

mention --size-limit effect on exit status

Documented elsewhere already.

fix annex.skipunknown false error propagation

Propagate nonzero exit status from git ls-files when a specified file does
not exist, or a specified directory does not contain any files checked into
git.

The recent completion of the annex.skipunknown transition exposed this
bug, that has unfortunately been lurking all along.

It is also possible that git ls-files errors out for some other reason
-- perhaps a permission problem -- and this will also fix error propagation
in such situations.

Sponsored-by: Dartmouth College's Datalad project

comment

news

comment

initial report on changed (and non-conformant) behavior of  annex find

comment

turn of PackageImports in cabal file

This makes it easier to build eg benchmarks of individual modules.

May be that most of these PackageImports are not really necessary,
dunno.

avoid accidentally thawing git-annex symlink

It did nothing, since at this point the link is dangling. But when there
is a thaw hook, it would probably not be happy to be asked to run on a
symlink, or might do something unexpected.

Sponsored-by: Dartmouth College's Datalad project

Run annex.thawcontent-command before deleting an object file

In case annex.freezecontent-command did something that would prevent
deletion.

Sponsored-by: Dartmouth College's Datalad project

add debugging of freeze and thaw

ignore write bits being set when there is a freeze hook

When annex.freezecontent-command is set, and the filesystem does not
support removing write bits, avoid treating it as a crippled filesystem.

The hook may be enough to prevent writing on its own, and some filesystems
ignore attempts to remove write bits.

Sponsored-by: Dartmouth College's Datalad project

comment

comment

comment

Added a comment

Added a comment: for some reason `drop` freezes thawn key file before thawing key dir

Added a comment: approach which somewhat works

adjusted with edit 1 observation

initial experimentation/complain about freeze/thawing files

smudge: Warn when encountering a pointer file that has other content appended to it

It will then proceed to add the file the same as if it were any other
file containing possibly annexable content. Usually the file is one that
was annexed before, so the new, probably corrupt content will also be added
to the annex. If the file was not annexed before, the content will be added
to git.

It's not possible for the smudge filter to throw an error here, because
git then just adds the file to git anyway.

Sponsored-by: Dartmouth College's Datalad project

fully specify the pointer file format

This format is designed to detect accidental appends, while having some
room for future expansion.

Detect when an unlocked file whose content is not present has gotten some
other content appended to it, and avoid treating it as a pointer file, so
that appended content will not be checked into git, but will be annexed
like any other file.

Dropped the max size of a pointer file down to 32kb, it was around 80 kb,
but without any good reason and certianly there are no valid pointer files
anywhere that are larger than 8kb, because it's just been specified what it
means for a pointer file with additional data even looks like.

I assume 32kb will be good enough for anyone. ;-) Really though, it needs
to be some smallish number, because that much of a file in git gets read
into memory when eg, catting pointer files. And since we have no use cases
for the extra lines of a pointer file yet, except possibly to add
some human-visible explanation that it is a git-annex pointer file, 32k
seems as reasonable an arbitrary number as anything. Increasing it would be
possible, eg to 64k, as long as users of such jumbo pointer files didn't
mind upgrading all their git-annex installations to one that supports the
new larger size.

Sponsored-by: Dartmouth College's Datalad project

read up to and including maxPointerSz

For consistency with everything else.

Sponsored-by: Dartmouth College's Datalad project

read a consistent amount from pointer file

A few places were reading the max symlink size of a pointer file,
then passing tp parseLinkTargetOrPointer. Which is fine currently, but
to support pointer files with lines of data after the pointer, enough
has to be read that parseLinkTargetOrPointer can be assured of seeing
enough of that data to know if it's correctly formatted.

Sponsored-by: Dartmouth College's Datalad project

fold parseLinkTarget into parseLinkTargetOrPointer

Only one place remained that differentiated between them.

It is the case that a symlink target that happens to contain a newline
somehow will be treated as a link to a key truncated at the newline.
This is super unlikely to happen, and since a key cannot actually
contain a newline, it's as good a behavior as any. Anyway, this commit
does not change the behavior there, although arguably it should be
changed. Note that getAnnexLinkTarget does prevent a symlink target
containing a newline.

Sponsored-by: Dartmouth College's Datalad project

comment