more RawFilePath

Remove dup definitions and just use the RawFilePath one. </> etc are
enough faster that it's probably faster than building a String directly,
although I have not benchmarked.

todo

keep filename ByteString

Minor optimisation, since it still has to be copied from lazy to strict,
but it will add up when doing a big merge.

wrap up

Merge branch 'master' into bs

and update changelog

added dep for custom-setup

stack build failed w/o this though cabal old-build succeeded.

more build fix

build fixes

get any old rpms

to prevent makerepo from falling over on broken symlinks

only delete old rpms for arches that have a new rpm

fixed

remove old rpms

Don't want a mass of old versions of git-annex in rpm form cluttering up
my server.

Also, makerepo falls over when confronted with a dangling symlink.

fix build

add news item for git-annex 7.20191218

inprogress: Support --key

add back changelog entry

comment

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

Merge branch 'master' into bs

use conversion functions from filepath-bytestring

Behavior should be the same, but I'd hope to eventually get rid of
most of Utility.FileSystemEncoding and this is a first step.

fix ByteString conversion on windows

the encode' and decode' functions on Windows should not apply the
filesystem encoding, which does not work there. Instead, convert to and
from UTF-8.

Also, avoid exporting encodeW8 and decodeW8. Both use the filesystem
encoding, so won't work as expected on windows.

update

fix fileJournal

My ByteString rewrite oversimplified it, resulting in any _ in a journal
file turning into a / in the git-annex branch, which was often the wrong
filename, or sometimes (//) an invalid filename that git
refused to add.

Added a comment: repodata is outdated

add todo

ask for --key on git-annex-inprogress

Added a comment: Would be useful

bug report

Added a comment

more info for debugging

add test case for bug

bug in this branch

match also / path separator on windows

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

devblog

use filepath-bytestring for annex object manipulations

git-annex find is now RawFilePath end to end, no string conversions.
So is git-annex get when it does not need to get anything.
So this is a major milestone on optimisation.

Benchmarks indicate around 30% speedup in both commands.

Probably many other performance improvements. All or nearly all places
where a file is statted use RawFilePath now.

Added a comment: annex-verify

Added a comment

Added a comment: Does android adb special remote support MTP?

removed

Added a comment: android special remote via mtp supported?

initial issue report on leaking error msgs

Added a comment: Key character set

convert TopFilePath to use RawFilePath

Adds a dependency on filepath-bytestring, an as yet unreleased fork of
filepath that operates on RawFilePath.

Git.Repo also changed to use RawFilePath for the path to the repo.

This does eliminate some RawFilePath -> FilePath -> RawFilePath
conversions. And filepath-bytestring's </> is probably faster.
But I don't expect a major performance improvement from this.
This is mostly groundwork for making Annex.Location use RawFilePath,
which will allow for a conversion-free pipleline.

avoid deprecation warning

use RawFilePath getSymbolicLinkStatus for speed

Merge branch 'master' into bs

update re state of bs branch

update re state of bs branch

use RawFilePath getFileStatus for speed

Only done on those calls to getFileStatus that had a RawFilePath, not a
FilePath. The others would probably be just as fast if converted to use
it with toRawFilePath, but I'm not 100% sure.

Note that genInodeCache' uses fromRawFilePath, but that value only gets
used on Windows, so on unix the thunk will never be evaluated.

use R.readSymbolicLink

This will be faster once gitAnnexLink is converted to a RawFilePath.

RawFilePath will need to support Windows too

Of course, readSymbolicLink always fails on Windows, but now it's ready
for other things that don't fail there.

fix git ls-tree parser

File mode is octal not decimal. This broke in the conversion to
attoparsec.

(I've submitted the content of Utility.Attoparsec to the attoparsec
developers.)

Test suite passes 100% now.

fix another quickcheck property broken by NUL in Arbitrary String

fix Arbitrary AssociatedFile

Empty filenames were already filtered out as not allowed. But before
the change to ByteString, a NUL could appear in an Arbitrary String,
and so Arbitrary AssociatedFile sometimes generated illegal filenames,
as NUL never appears in a filename. The change to ByteString meant the
String was run through toRawFilePath, which assumes a filename never
contains a NUL. That truncated the String at the NUL, which could
result in an AssociatedFile being generated with an empty filename.

The filtering of NUL added here is not really necessary, because
of the truncation, but it makes explicit that NUL is not allowed.
The real fix is that the suchThat now applies to the final
AssociatedFile, so will catch any empty ones however generated.

This raises the more general question of whether toRawFilePath might
truncate other strings that later get used as filenames. I think new
bugs probably won't be introduced by that. Before, a FilePath that got
read from somewhere (eg an attacker) and contained a NUL would perhaps
be printed out by git-annex, including the NUL, or written to disk
inside a file, or what have you. But as soon as that FilePath gets
passed to any IO action that treats it as a filename, it gets truncated
after the NUL. Eg, writeFile "foo\NULbar" "bar" writes to file "foo".
Now toRawFilePath will make the truncation happen earler, but at most
this will affect what gets printed out or is written to disk inside a
file; actually using the RawFilePath as a filename will not change from
using the FilePath as a filename.

add back lost filtering of multibyte chars in prop_encode_decode_roundtrip

I had thought using ByteString would avoid the problem, but the
quickcheck property is still taking Arbitrary String input, so the use
of ByteString internally doesn't matter.

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

devblog

everything is building again

However, the test suite fails some quickchecks, so this branch is not
yet in a mergeable state.

all commands building except for assistant

also, changed ConfigValue to a newtype, and moved it into Git.Config.

update

mention optimisations

Merge branch 'master' into bs

get many more commands building again

about half are building now

Added a comment: Great work! Thank you!

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

optimisation

This was already optimised before, but profiling found that delEntry was
around 1.5% of the total runtime of git-annex whereis. It was being
called once per environment variable per file processed.

Fixed by better caching. Since withIndexFile is almost always run with
the same .git/annex/index file, it can cache the modified environment,
rather than re-modifying it each time called.

(cherry picked from commit 6535aea49a402b9ca08fc1070358374e5e0eb618)

optimisation

This was already optimised before, but profiling found that delEntry was
around 1.5% of the total runtime of git-annex whereis. It was being
called once per environment variable per file processed.

Fixed by better caching. Since withIndexFile is almost always run with
the same .git/annex/index file, it can cache the modified environment,
rather than re-modifying it each time called.

get the most commonly used commands building again

A quick benchmark of whereis shows not much speed improvement, maybe a
few percent. Profiling it found a hotspot, adds to todo.

Added a comment

Added a comment: dropping contents of old keys after migration

include all remotes back in

include upgrade code back in

Remaining things that need to be fixed up to get this branch into a
basically mergeable state: remotes, commands, and the assistant

Added a comment

include git-annex-shell back in

Also pushed ConfigKey down into the Git modules, which is the bulk of
the changes.

revert unncessary changes

part of the hacking in 067aabdd4899997f10c78388273f28cccf777b66
but did not need to be committed

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

remove spam

fix hacked up AutoMerge module to work again

Added a comment: P.P.S. i dropped all local copies

Added a comment: P.S. they are all SHA256E

Added a comment: can't find unused objects

Added a comment: not able to find git-annex on openSUSE using zypper

Added a comment: migrating...

removed

Added a comment: hardlinking identical files in annex may break invariants

Added a comment

Added a comment: no collisions

added a hyperlink to key_format

Added a comment: same contents with different keys

Added a comment: duplicate objects?

Added a comment

refiled under dandi project - use case is https://gin.g-node.org

Added a comment: reference original bug report

Added a comment

Added a comment: related: shouldn't git annex try external remotes to download config?

initial report on inability to use remotes with authentication cached by git