diff --git a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn deleted file mode 100644 index fcd32f9dc9..0000000000 --- a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -Test output on OS X. Btw, the previous version works: - -``` -OK (4.87s) - map: OK (0.33s) - uninit: Deleted branch git-annex (was 9a28b38). -OK (0.38s) - uninit (in git-annex branch): Switched to branch 'git-annex' -OK (0.26s) - upgrade: OK (0.21s) - whereis: OK (0.61s) - hook remote: OK (0.91s) - directory remote: OK (0.85s) - rsync remote: OK (1.40s) - bup remote: Reinitialized existing Git repository in /private/var/folders/4j/br7bdhjx4b384_snb2087gt00000gn/T/nix-build-git-annex-5.20151116.drv-0/.bup/ -Initialized empty Git repository in /private/var/folders/4j/br7bdhjx4b384_snb2087gt00000gn/T/nix-build-git-annex-5.20151116.drv-0/git-annex-5.20151116/.t/tmprepo0/dir/ - content cannot be completely removed from bup remote -OK (2.62s) - crypto: OK (4.16s) - preferred content: OK (1.97s) - add subdirs: Merge made by the 'recursive' strategy. - conflictor.variant-cc12 | 1 + - conflictor/subfile | 1 + - 2 files changed, 2 insertions(+) - create mode 120000 conflictor.variant-cc12 - create mode 120000 conflictor/subfile -To /private/var/folders/4j/br7bdhjx4b384_snb2087gt00000gn/T/nix-build-git-annex-5.20151116.drv-0/git-annex-5.20151116/.t/repo - e4d3d14..60148c4 git-annex -> synced/git-annex - efda76d..f76baae master -> synced/master -OK (0.55s) - addurl: git-annex: .git/annex/objects/2Q/J8/SHA256E-s3--2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae/SHA256E-s3--2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae: createSymbolicLink: invalid argument (File name too long) -FAIL (0.29s) - addurl failed on file:///private/var/folders/4j/br7bdhjx4b384_snb2087gt00000gn/T/nix-build-git-annex-5.20151116.drv-0/git-annex-5.20151116/.t/tmprepo0/myurl - -2 out of 150 tests failed (126.13s) - (This could be due to a bug in git-annex, or an incompatibility - with utilities, such as git, installed on this system.) -``` - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/20151116_tests_fail_on_OS_X/comment_1_6c5cfe02b686d063e8f336620a81cca1._comment b/doc/bugs/20151116_tests_fail_on_OS_X/comment_1_6c5cfe02b686d063e8f336620a81cca1._comment deleted file mode 100644 index c3bc0f0686..0000000000 --- a/doc/bugs/20151116_tests_fail_on_OS_X/comment_1_6c5cfe02b686d063e8f336620a81cca1._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-30T19:22:43Z" - content=""" -You may have omitted 1 of the 2 failures in your paste. - -The only one I see has something to do with a filename being too long. -Since the filename in question is 77 bytes long, or 178 with the full path, -and industry standard for filename size is 1024 or longer, I am at a loss -why that would be considered too long. - -AFAIK there have been no changes in git-annex's filenames recently. What -was the previous version that worked? -"""]] diff --git a/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment b/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment deleted file mode 100644 index 01da6e8244..0000000000 --- a/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-12-06T20:02:49Z" - content=""" -Ok, this involves where the test suite is run. -The addurl test adds `file://`pwd`/somefile`, and that will create a file -with a name like `_home_you_sub_dir_path_here_somefile`. Which can easily -exceed filename length limits of 255 bytes. - -There was indeed a reversion in addurl's handling of that. -"""]] diff --git a/doc/bugs/7.20181105+git172-g76fc9af4_not_buildable.mdwn b/doc/bugs/7.20181105+git172-g76fc9af4_not_buildable.mdwn deleted file mode 100644 index 1902142b79..0000000000 --- a/doc/bugs/7.20181105+git172-g76fc9af4_not_buildable.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -first ran into on my laptop and just thought that my setup is outdated... this is now in clean uptodate debian sid - -[[!format sh """ -Annex/Ssh.hs:207:25: error: - * Couldn't match type `IO' with `Annex' - Expected type: Annex () - Actual type: IO () - * In the second argument of `($)', namely - `unlessM (tryssh ["-o", "BatchMode=true"]) - $ do liftIO $ print "ok then" - let p = ... in p `concurrently` p' - In the second argument of `($)', namely - `whenM (isNothing <$> fromLockCache socketlock) - $ unlessM (tryssh ["-o", "BatchMode=true"]) - $ do liftIO $ print "ok then" - let p = ... in p `concurrently` p' - In the expression: - debugLocks - $ whenM (isNothing <$> fromLockCache socketlock) - $ unlessM (tryssh ["-o", "BatchMode=true"]) - $ do liftIO $ print "ok then" - let p = ... in p `concurrently` p - | -207 | unlessM (tryssh ["-o", "BatchMode=true"]) $ do - | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... - -Annex/Ssh.hs:213:70: error: - * Couldn't match expected type `IO a0' with actual type `Annex ()' - * In the first argument of `concurrently', namely `p' - In the expression: p `concurrently` p - In a stmt of a 'do' block: - let p = void $ prompt $ tryssh [] in p `concurrently` p - | -213 | let p = void $ prompt $ tryssh [] in p `concurrently` p - | ^ - -Annex/Ssh.hs:213:70: error: - * Couldn't match type `(a0, b0)' with `()' - Expected type: IO () - Actual type: IO (a0, b0) - * In the expression: p `concurrently` p - In a stmt of a 'do' block: - let p = void $ prompt $ tryssh [] in p `concurrently` p - In the second argument of `($)', namely - `do liftIO $ print "ok then" - let p = ... in p `concurrently` p' - | -213 | let p = void $ prompt $ tryssh [] in p `concurrently` p - | ^^^^^^^^^^^^^^^^^^ - -Annex/Ssh.hs:213:87: error: - * Couldn't match expected type `IO b0' with actual type `Annex ()' - * In the second argument of `concurrently', namely `p' - In the expression: p `concurrently` p - In a stmt of a 'do' block: - let p = void $ prompt $ tryssh [] in p `concurrently` p - | -213 | let p = void $ prompt $ tryssh [] in p `concurrently` p - | ^ -"""]] - - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/8_unit_tests_fail.mdwn b/doc/bugs/8_unit_tests_fail.mdwn deleted file mode 100644 index 9bc53c9564..0000000000 --- a/doc/bugs/8_unit_tests_fail.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. - -8 out of 293 tests failed (200.39s) - (This could be due to a bug in git-annex, or an incompatibility - with utilities, such as git, installed on this system.) - -full log https://headcounter.org/hydra/build/1819294/nixlog/1 - -### What steps will reproduce the problem? - -./make test - - -### What version of git-annex are you using? On what operating system? - -6.20170510 - -nix-build and inside a nix shell with manual building. - - -### Please provide any additional information below. - - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yep, works apart from the few tests that fail. - -> Duplicate of [[git-annex_in_nixpkgs_fails_with_git-2.13.0]]; closing. [[done]] --[[Joey]] diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn deleted file mode 100644 index de6c26fbfe..0000000000 --- a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn +++ /dev/null @@ -1,86 +0,0 @@ -(Found the problem, so you might want to skip to the comments to see -what's wrong.) - -### Please describe the problem. - -Trying to drop the contents of 131 files in a subdirectory, but it dies -with an "sqlite worker thread crashed" error. The contents of one file -is deleted, and then it dies. The files in that directory are exactly 1G -(1000000000) bytes each. - -There's no data loss here, it creates files in `.git/annex/journal/` -which is added to the git-annex branch after a git annex sync. "git -annex fsck --fast --quiet" is happy and finds no errors. - -### What steps will reproduce the problem? - -"git annex drop" with and without --force. Tried to copy one of the -files to another server with Debian 8.7, and it's successfully dropped -there. Same git-annex version. - -### What version of git-annex are you using? On what operating system? - -OS: Ubuntu 14.04.5 LTS - -git-annex: 6.20161211-gc3ab3c668 (from -`git-annex-standalone-amd64.tar.gz` in the annex at -downloads.kitenet.net) - -I have compiled the newest sqlite3 3.16.2 and placed it in -/usr/local/bin/, just mentioning it because it's some kind of SQLite -error. but executing the command with a PATH without /usr/local/bin -makes no difference. - -### Please provide any additional information below. - -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - $ git annex drop -d --force - [2017-01-16 08:58:39.947856861] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","ls-files","--cached","-z","--"] - [2017-01-16 08:58:39.953150944] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"] - [2017-01-16 08:58:39.953742873] read: git ["--version"] - [2017-01-16 08:58:39.959438053] process done ExitSuccess - [2017-01-16 08:58:39.959919735] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","git-annex"] - [2017-01-16 08:58:39.963707897] process done ExitSuccess - [2017-01-16 08:58:39.963882344] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2017-01-16 08:58:39.967078602] process done ExitSuccess - [2017-01-16 08:58:39.969062554] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch"] - [2017-01-16 08:58:39.970168767] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] - drop MyStream_3/MyStream_3.mp4.split_ag [2017-01-16 08:58:39.984359273] Dropping from here proof: Nothing - sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform prepare "SELECT null from content limit 1": unable to open database file - ok - git-annex: thread blocked indefinitely in an MVar operation - $ git annex drop -d --force - [2017-01-16 08:58:58.890031175] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","ls-files","--cached","-z","--"] - [2017-01-16 08:58:58.895047131] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"] - [2017-01-16 08:58:58.895690334] read: git ["--version"] - [2017-01-16 08:58:58.901206493] process done ExitSuccess - [2017-01-16 08:58:58.901836453] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","git-annex"] - [2017-01-16 08:58:58.905632574] process done ExitSuccess - [2017-01-16 08:58:58.905793223] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2017-01-16 08:58:58.909227509] process done ExitSuccess - [2017-01-16 08:58:58.910902084] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch"] - [2017-01-16 08:58:58.912164764] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] - drop MyStream_3/MyStream_3.mp4.split_ah [2017-01-16 08:58:58.927477693] Dropping from here proof: Nothing - sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform prepare "SELECT null from content limit 1": unable to open database file - ok - git-annex: thread blocked indefinitely in an MVar operation - $ - -# End of transcript or log. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Indeed. All my stuff (around 3.5 terabytes) is stored in git-annex with -at least three copies of each file on different disks and locations, -spread over various hard disks, memory sticks, servers and you name it. -Unused disk space is a waste, so I fill everything up to the brim with -extra copies. - -In other words, Git-Annex and I are very happy together, and I'd like to -marry it. And because you are the father, I hereby respectfully ask for -your blessing. - -> [[fixed|done]] (and I suppose you have my blessing, but I'm not sure -> that's legal yet!) --[[Joey]] diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_1_cd09e4d4a73e003735e3297922b8faa8._comment b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_1_cd09e4d4a73e003735e3297922b8faa8._comment deleted file mode 100644 index 7c9caf052c..0000000000 --- a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_1_cd09e4d4a73e003735e3297922b8faa8._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="sunny256" - avatar="http://cdn.libravatar.org/avatar/8a221001f74d0e8f4dadee3c7d1996e4" - subject="Found the reason" - date="2017-01-16T11:03:45Z" - content=""" -I managed to find the reason why it failed. The files in .git/annex/keys/ had wrong permissions, so I wasn't able to write to them. This is a shared repository where everyone within the Unix group can read and write. All the directories including .git/annex/keys have chmod +s so any additions or edits are stored within the correct group. But the SQLite files were stored with permission 0644 instead of 0664, and my umask in the shell is 0002. Maybe SQLite is creating the database with wrong permissions? -"""]] diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_2_9a0fec331a858746e2fecc6b86ab8cbb._comment b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_2_9a0fec331a858746e2fecc6b86ab8cbb._comment deleted file mode 100644 index b3e5b8a02e..0000000000 --- a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_2_9a0fec331a858746e2fecc6b86ab8cbb._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="sunny256" - avatar="http://cdn.libravatar.org/avatar/8a221001f74d0e8f4dadee3c7d1996e4" - subject="Wrong permissions" - date="2017-01-16T11:17:31Z" - content=""" -Yes, confirmed. I tried to create a new test repository and chmod all directories with +s. I'm using umask 0002, so new files are created with perm 0664 and the correct shared group. But the SQLite files in .git/annex/keys/ are created with permission 0644, so other users in the group are not able to update the files there. -"""]] diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_3_88a09558f2da0a5733aa3dd042f9d59b._comment b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_3_88a09558f2da0a5733aa3dd042f9d59b._comment deleted file mode 100644 index 30e108b341..0000000000 --- a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_3_88a09558f2da0a5733aa3dd042f9d59b._comment +++ /dev/null @@ -1,53 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-02-13T20:21:09Z" - content=""" -Thanks for following up with the cause of this. - -In fact, assuming you're not using a v6 git-annex repository, it doesn't -really need to update that database at all. But since we'll be upgrading to -v6 eventually, I need to deal with problems like this. Also, -this same problem will also impact the database used for incremental fsck. - -I can reproduce this with a v5 repository; dropping a file happens to run a -code path that updates the database. And reproducing it w/o using git-annex too: - - joey@darkstar:~/tmp>mkdir empty - joey@darkstar:~/tmp>umask - 0002 - joey@darkstar:~/tmp>touch empty/file - joey@darkstar:~/tmp>sqlite3 empty/db - SQLite version 3.16.2 2017-01-06 16:32:41 - Enter ".help" for usage hints. - sqlite> create table foo; - Error: near ";": syntax error - sqlite> - joey@darkstar:~/tmp>ls -l empty/ - total 0 - -rw-r--r-- 1 joey joey 0 Feb 13 16:33 db - -rw-rw-r-- 1 joey joey 0 Feb 13 16:32 file - -Seems that sqlite uses `0644 & umask` for the db permissions, -which is *bad* because it doesn't allow the umask to enable the group -write bit. That 0644 is `SQLITE_DEFAULT_FILE_PERMISSIONS`, so it can -be changed to something saner at compile time. - -`http://www.sqlite.org/src/doc/trunk/src/os_unix.c` has a useful comment. -Seems that sqlite is careful to make -wal, -journal, and -shm files -have the exact same permissions as main database file. - -So, if `.git/annex/keys/*` is updated to have the desired permissions when -the database is created, every further write to the database will keep -using the desired permissions. - -Hmm, it turns out that git-annex does already set the database permissions when -creating it, but only if core.sharedRepository is set to group or all. So -there's a workaround; just `git config core.sharedRepository group` when -setting up a repository that's going to be accessed by multiple users. Almost -certianly a better idea than relying on umask anyway; people mess up umask -settings. - -I'll go ahead and make it always set sane permissions when creating databases. -I'm not going to try to fix up permissions in existing repositories though. -"""]] diff --git a/doc/bugs/Add_custom-setup_stanza_to_.cabal_file.mdwn b/doc/bugs/Add_custom-setup_stanza_to_.cabal_file.mdwn deleted file mode 100644 index fcf9b6b3ac..0000000000 --- a/doc/bugs/Add_custom-setup_stanza_to_.cabal_file.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -### Please describe the problem. - -git-annex uses a custom setup script but does not have a custom-setup stanza. This causes -git-annex to be unbuildable with `cabal new-build` and I'm told it's also unbuildable with -the old `cabal build` under certain circumstances. - -### What steps will reproduce the problem? - -Try building git-annex with `cabal new-build`. - -### What version of git-annex are you using? On what operating system? - -git-annex-6.20171214 on Debian GNU/Linux 9. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$ cabal new-build --constraint="any.git-annex -testsuite" -Resolving dependencies... -In order, the following will be built (use -v for more details): - - git-annex-6.20171214 (exe:git-annex) -testsuite -dbus -concurrentoutput (requires build) - - dummypkg-0 (lib) (first run) -Configuring git-annex-6.20171214 (all, legacy fallback)... -cabal: Failed to build git-annex-6.20171214 (which is required by dummypkg-0). -The failure occurred during the configure step. The exception was: -dieVerbatim: user error (cabal: '/usr/bin/ghc' exited with an error: - -/home/matthew/dummypkg/dist-newstyle/tmp/src-3285/git-annex-6.20171214/Utility/FileSize.hs:10:1: -error: -Failed to load interface for ‘System.PosixCompat.Files’ -It is a member of the hidden package ‘unix-compat-0.5.0.1’. -Perhaps you need to add ‘unix-compat’ to the build-depends in your .cabal -file. -Use -v to see a list of the files searched for. -) - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yeah, it's amazing! I've been using the version from the Debian repos and then -wanted to try building the new version for youtube-dl support. - -> Revisited it and seem to have managed to add custom-setup back. [[done]] -> --[[Joey]] diff --git a/doc/bugs/Add_custom-setup_stanza_to_.cabal_file/comment_1_88d5109a342e6a06d2f9f400cf850e3d._comment b/doc/bugs/Add_custom-setup_stanza_to_.cabal_file/comment_1_88d5109a342e6a06d2f9f400cf850e3d._comment deleted file mode 100644 index ccad24c3da..0000000000 --- a/doc/bugs/Add_custom-setup_stanza_to_.cabal_file/comment_1_88d5109a342e6a06d2f9f400cf850e3d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="mbekkema97@66b135681014f005a3a14c4011d148fcb6655f81" - nickname="mbekkema97" - avatar="http://cdn.libravatar.org/avatar/a5037b8a5914bd9f803af7b7e881d632" - subject="I just found out you're already aware of this" - date="2017-12-15T07:16:13Z" - content=""" -https://github.com/haskell/cabal/issues/4852 -"""]] diff --git a/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__.mdwn b/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__.mdwn deleted file mode 100644 index bb6ba69f51..0000000000 --- a/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. - -While download content from dropbox (via regular urls associated with the files, so "web" remote), some fail some time with error code returned 500 (internal server failure without explicit reason), which causes git-annex get also to fail if that was the only source for the file to try. - -### What steps will reproduce the problem? - -This is all happening with http://datasets.datalad.org/workshops/nih-2017/ds000114/derivatives/freesurfer/ repository (on eg https://dl.dropboxusercontent.com/s/sn4et1e3d2run9g/rh.aparc.dktatlas.annot?dl=0 url ), but for testing wget/curl I just created http://www.onerussian.com/tmp/errors/500 which would always return 500. - -### What version of git-annex are you using? On what operating system? - -6.20180316+gitg308f3ecf6 - -### Please provide any additional information below. - -here are options for wget and curl which could help us out here: - -[[!format sh """ - -# to make wget retry -> wget --retry-on-http-error=500 http://www.onerussian.com/tmp/errors/500 - -# to make curl retry, just needs --retry 10 which then considers 5xx errors intermittent -> curl --retry 10 http://www.onerussian.com/tmp/errors/500 - -"""]] - -Could git-annex add those options to curl/wget invocations for more robust access to the web remote? - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__/comment_1_9eafb42dce4c437a777cda0048756f42._comment b/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__/comment_1_9eafb42dce4c437a777cda0048756f42._comment deleted file mode 100644 index ee75dfb7d1..0000000000 --- a/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__/comment_1_9eafb42dce4c437a777cda0048756f42._comment +++ /dev/null @@ -1,33 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-03-24T13:54:31Z" - content=""" -Note that with --retry 10, curl will back off 10 times, with wait doubling, -so it could get stuck for 20+ minutes. That seems too long, but the right -number of retries seems to depend on how overloaded the http server is; you -may need a number that would otherwise be excessive in order to get a high -enough probability of success. - -Also worth noting that http *has* status codes such as 503 that are -intended to be used when the client should wait and retry; 500 is not such -a code. - -If this is done at the wget/curl level, it will also need to be done -when using the http-client library (which does not currently retry on any -code, AFAICs). - -And, it could just as easily be a S3 or webdav server that is throwing the -http retry codes, and the libraries for those will have their own retrying -behavior. (And it could even be a ssh server ot other non-http protocol -that connections to fail intermittently.) - -Putting all this together, I'm wondering if the http level is the right -place to put this retrying. It's not a matter of complying with the http -spec; it seems to need user configuration in order to handle their -particular use case. - -git-annex already does generic retrying as long as some data was -received, to recover from broken connections. That could be extended to -support a config option that enables a number of retries. -"""]] diff --git a/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__/comment_2_23fe5ddd3a77c20d66c6847bdb83c94b._comment b/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__/comment_2_23fe5ddd3a77c20d66c6847bdb83c94b._comment deleted file mode 100644 index 2072cc3ee4..0000000000 --- a/doc/bugs/Add_explicit_retries_for_curl__47__wget_on___34__transient__34___errors__63__/comment_2_23fe5ddd3a77c20d66c6847bdb83c94b._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-03-29T17:24:35Z" - content=""" -I've implemented `remote..annex-retry`, `annex.retry`, -`remote..annex-retry-delay`, `annex.retry-delay` configs, so you can -have full control over retry behavior for remotes. - -Since these are fully generic, not at the HTTP level, they'll -make any and all transfer failures be retried, no matter why it failed. -Which could be a good thing or a bad thing.. -"""]] diff --git a/doc/bugs/Adding_metadata.mdwn b/doc/bugs/Adding_metadata.mdwn deleted file mode 100644 index 2b4516a2f9..0000000000 --- a/doc/bugs/Adding_metadata.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -### Please describe the problem. -This is less of a bug and more of a feature(?) request. Currently, when assigning metadata to a datafile, git annex (v5.20150710-g8fd705) will produce no error or warning message if the file entered does not exist. This can be a tad confusing to users who might expect to see some output if they typed their path wrong. A successful `git annex metadata -s tags=best` will produce output acknowledging the change, but a failure produces no output at all. A quick check if the file exists, and a `File does not exist` error message if not, would be easy implement and helpful to new users. - -### What steps will reproduce the problem? - -git annex metadata -s tags+=atlas - -Where does not exist. - -### What version of git-annex are you using? On what operating system? - -v5.20150710-g8fd705 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -We use git-annex for our open-source !FreeSurfer software and find very helpful indeed. Thank you. https://surfer.nmr.mgh.harvard.edu/ - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Adding_torrent_via_addurl_fails.mdwn b/doc/bugs/Adding_torrent_via_addurl_fails.mdwn deleted file mode 100644 index 058abaefbe..0000000000 --- a/doc/bugs/Adding_torrent_via_addurl_fails.mdwn +++ /dev/null @@ -1,57 +0,0 @@ -[[!meta title="addurl failure with non-standard torrent file"]] - -### Please describe the problem. -Adding a magnet link via addurl fails after downloading the torrent metatdata if the "announce" field of the torrent is empty - -### What steps will reproduce the problem? - git annex addurl "magnet:?xt=urn:btih:88066b90278f2de655ee2dd44e784c340b54e45c" - - -### What version of git-annex are you using? On what operating system? -git-annex version: 6.20160126 -archlinux - -### Please provide any additional information below. -I have traced back the Problem to the parsing of the torrent metatdata. -Since you also seem to be the author of the haskel-torrent parser I felt it is apropriate to post here. - -The above magnet link (an Archlinux Iso) results in a .torrent file that has no "announce" entry. Instead it only has the entry "announce-list" with multiple urls. -This causes the parser to fail. -I dont know if having only "announce-list" horribly violates some standard, however a second magnet link that i tried showed the same behaviour so this might not be an unusual case. - -I was able to put in a workarround in btshowmetainfo.py to set "annonuce" to the first entry from "announce-list" if it wasn't defined. -My git-annex binary is compiled with the haskel parser enabled do this doesn't change annexs' behaviour. - -It's not a big dealbreaker for me, just playing arround with the torrent feaure for now. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -git annex addurl "magnet:?xt=urn:btih:88066b90278f2de655ee2dd44e784c340b54e45c" -(downloading torrent file...) - -02/07 16:42:13 [NOTICE] IPv4 DHT: listening on UDP port 6964 - -02/07 16:42:13 [NOTICE] IPv4 BitTorrent: listening on TCP port 6927 - -02/07 16:42:13 [NOTICE] IPv6 BitTorrent: listening on TCP port 6927 -[#96c5b2 27KiB/27KiB(100%) CN:11 SD:2] -02/07 16:42:32 [NOTICE] Download complete: [METADATA]88066b90278f2de655ee2dd44e784c340b54e45c - -02/07 16:42:32 [NOTICE] Saved metadata as ../../.git/annex/misctmp/URL--magnet&c,63xt,61urn&cbtih&c88066b90278f2de655ee2dd44e784c340b54e45c/meta/88066b90278f2de655ee2dd44e784c340b54e45c.torrent. - -Download Results: -gid |stat|avg speed |path/URI -======+====+===========+======================================================= -96c5b2|OK | 0B/s|[MEMORY][METADATA]88066b90278f2de655ee2dd44e784c340b54e45c - -Status Legend: -(OK):download completed. -git-annex: failed to parse torrent: Name not found in dictionary: announce -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - -> This was fixed in haskell-torrent version 10000.1.0. [[done]] diff --git a/doc/bugs/Adding_torrent_via_addurl_fails/comment_1_477913541446737692c2d3ae2cc197bb._comment b/doc/bugs/Adding_torrent_via_addurl_fails/comment_1_477913541446737692c2d3ae2cc197bb._comment deleted file mode 100644 index a85950bdde..0000000000 --- a/doc/bugs/Adding_torrent_via_addurl_fails/comment_1_477913541446737692c2d3ae2cc197bb._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-08T18:53:00Z" - content=""" -announce-list comes from BEP-0012. Reading that spec, the torrent file is -supposed to still have the announce field, although its contents are -supposed to be ignored by clients that support announce-list. - -When I download that torrent, it doesn't seem to have an -announce-list either. No announce and no announce-list? It's possible that -aria2c, which I used to download it like git-annex does, doesn't know about -announce-list and left it out when saving the torrent file. Maybe it left -out announce too? Do you have a non-magnet url for this torrent file? - -I'll make the haskell torrent library support parsing announce-list once - is fixed. -"""]] diff --git a/doc/bugs/Adding_torrent_via_addurl_fails/comment_2_e317aee1ff6e60aafcd106751af660c8._comment b/doc/bugs/Adding_torrent_via_addurl_fails/comment_2_e317aee1ff6e60aafcd106751af660c8._comment deleted file mode 100644 index 6b4a52478f..0000000000 --- a/doc/bugs/Adding_torrent_via_addurl_fails/comment_2_e317aee1ff6e60aafcd106751af660c8._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="annuges" - subject="comment 2" - date="2016-02-09T13:49:42Z" - content=""" -sorry looks like i hadd a litle mixup, the full magnet link that i used when checking btshowmetainfo was - - magnet:?xt=urn:btih:88066b90278f2de655ee2dd44e784c340b54e45c&dn=archlinux-2016.02.01-dual.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce - -Using this one with aria2c --bt-save-metadata results in a torrent file with the announce-list entry only. -Modifying the link to only contain one tracker url still results in an announce-list with a single entry. - -There also is a separate torrent file on the arch website that has the announce field set correctly. - - https://www.archlinux.org/releng/releases/2016.02.01/torrent/ - -They hide the actuall .torrent file though so addurl doesn't trigger the torrent parsing with led me to try the magnet link to begin with. - -Anyway, looks like aria2c is at fault because it doesn't generate standard compliant .torrent files from magnet links. - - - - -"""]] diff --git a/doc/bugs/Adding_torrent_via_addurl_fails/comment_3_7ff48f1b6426f7bbf6f3aaa4e1526d19._comment b/doc/bugs/Adding_torrent_via_addurl_fails/comment_3_7ff48f1b6426f7bbf6f3aaa4e1526d19._comment deleted file mode 100644 index 8b85097e2b..0000000000 --- a/doc/bugs/Adding_torrent_via_addurl_fails/comment_3_7ff48f1b6426f7bbf6f3aaa4e1526d19._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="mbekkema97@66b135681014f005a3a14c4011d148fcb6655f81" - nickname="mbekkema97" - avatar="http://cdn.libravatar.org/avatar/a5037b8a5914bd9f803af7b7e881d632" - subject="comment 3" - date="2018-01-12T12:01:30Z" - content=""" -This seems to be fixed now due to an update to Haskell's torrent library. -"""]] diff --git a/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn b/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn deleted file mode 100644 index 4b1c106843..0000000000 --- a/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn +++ /dev/null @@ -1,297 +0,0 @@ -### Please describe the problem. - -Installing git-annex on a new Nexus 5 with Android 4.4.4 using [Android 4.4 and 4.3 git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/4.3/git-annex.apk) does not give me a working git-annex environment. It seems permission is denied to install many of the app files. - - -### What steps will reproduce the problem? - -1. Install git-annex -2. From within `adb shell`, run: `/data/data/ga.androidterm/runshell` -3. Try one of the included programs, e.g., `git` - - -### What version of git-annex are you using? On what operating system? - -The current (as of 2014-08-30) git-annex for Android 4.3 and up on Android 4.4.4. - - -### Please provide any additional information below. - -Running `/data/data/ga.androidterm/runshell` from `adb shell` gives me: - -[[!format txt """ -shell@hammerhead:/ $ /data/data/ga.androidterm/runshell -Falling back to hardcoded app location; cannot find expected files in /data/app-lib -shell@hammerhead:/sdcard/git-annex.home $ ls -git-annex-install.log -shell@hammerhead:/sdcard/git-annex.home $ cat git-annex-install.log -Installation starting to /data/data/ga.androidterm -71c22504d777380dd59d2128b97715fde9ef6bec -mv: can't rename '/data/data/ga.androidterm/bin': Permission denied -installing busybox -ln: /data/data/ga.androidterm/bin/busybox: Permission denied -installing git-annex -ln: /data/data/ga.androidterm/bin/git-annex: Permission denied -installing git-shell -ln: /data/data/ga.androidterm/bin/git-shell: Permission denied -installing git-upload-pack -ln: /data/data/ga.androidterm/bin/git-upload-pack: Permission denied -installing git -ln: /data/data/ga.androidterm/bin/git: Permission denied -installing gpg -ln: /data/data/ga.androidterm/bin/gpg: Permission denied -installing rsync -ln: /data/data/ga.androidterm/bin/rsync: Permission denied -installing ssh -ln: /data/data/ga.androidterm/bin/ssh: Permission denied -installing ssh-keygen -ln: /data/data/ga.androidterm/bin/ssh-keygen: Permission denied -busybox: /data/data/ga.androidterm/bin/[: Permission denied -busybox: /data/data/ga.androidterm/bin/[[: Permission denied -busybox: /data/data/ga.androidterm/bin/ar: Permission denied -busybox: /data/data/ga.androidterm/bin/arp: Permission denied -busybox: /data/data/ga.androidterm/bin/ash: Permission denied -busybox: /data/data/ga.androidterm/bin/base64: Permission denied -busybox: /data/data/ga.androidterm/bin/basename: Permission denied -busybox: /data/data/ga.androidterm/bin/beep: Permission denied -busybox: /data/data/ga.androidterm/bin/blkid: Permission denied -busybox: /data/data/ga.androidterm/bin/blockdev: Permission denied -busybox: /data/data/ga.androidterm/bin/bunzip2: Permission denied -busybox: /data/data/ga.androidterm/bin/bzcat: Permission denied -busybox: /data/data/ga.androidterm/bin/bzip2: Permission denied -busybox: /data/data/ga.androidterm/bin/cal: Permission denied -busybox: /data/data/ga.androidterm/bin/cat: Permission denied -busybox: /data/data/ga.androidterm/bin/catv: Permission denied -busybox: /data/data/ga.androidterm/bin/chat: Permission denied -busybox: /data/data/ga.androidterm/bin/chattr: Permission denied -busybox: /data/data/ga.androidterm/bin/chgrp: Permission denied -busybox: /data/data/ga.androidterm/bin/chmod: Permission denied -busybox: /data/data/ga.androidterm/bin/chown: Permission denied -busybox: /data/data/ga.androidterm/bin/chpst: Permission denied -busybox: /data/data/ga.androidterm/bin/chroot: Permission denied -busybox: /data/data/ga.androidterm/bin/chrt: Permission denied -busybox: /data/data/ga.androidterm/bin/chvt: Permission denied -busybox: /data/data/ga.androidterm/bin/cksum: Permission denied -busybox: /data/data/ga.androidterm/bin/clear: Permission denied -busybox: /data/data/ga.androidterm/bin/cmp: Permission denied -busybox: /data/data/ga.androidterm/bin/comm: Permission denied -busybox: /data/data/ga.androidterm/bin/cp: Permission denied -busybox: /data/data/ga.androidterm/bin/cpio: Permission denied -busybox: /data/data/ga.androidterm/bin/cttyhack: Permission denied -busybox: /data/data/ga.androidterm/bin/cut: Permission denied -busybox: /data/data/ga.androidterm/bin/dc: Permission denied -busybox: /data/data/ga.androidterm/bin/dd: Permission denied -busybox: /data/data/ga.androidterm/bin/deallocvt: Permission denied -busybox: /data/data/ga.androidterm/bin/devmem: Permission denied -busybox: /data/data/ga.androidterm/bin/diff: Permission denied -busybox: /data/data/ga.androidterm/bin/dirname: Permission denied -busybox: /data/data/ga.androidterm/bin/dmesg: Permission denied -busybox: /data/data/ga.androidterm/bin/dnsd: Permission denied -busybox: /data/data/ga.androidterm/bin/dos2unix: Permission denied -busybox: /data/data/ga.androidterm/bin/dpkg: Permission denied -busybox: /data/data/ga.androidterm/bin/dpkg-deb: Permission denied -busybox: /data/data/ga.androidterm/bin/du: Permission denied -busybox: /data/data/ga.androidterm/bin/dumpkmap: Permission denied -busybox: /data/data/ga.androidterm/bin/echo: Permission denied -busybox: /data/data/ga.androidterm/bin/envdir: Permission denied -busybox: /data/data/ga.androidterm/bin/envuidgid: Permission denied -busybox: /data/data/ga.androidterm/bin/expand: Permission denied -busybox: /data/data/ga.androidterm/bin/fakeidentd: Permission denied -busybox: /data/data/ga.androidterm/bin/false: Permission denied -busybox: /data/data/ga.androidterm/bin/fbset: Permission denied -busybox: /data/data/ga.androidterm/bin/fbsplash: Permission denied -busybox: /data/data/ga.androidterm/bin/fdflush: Permission denied -busybox: /data/data/ga.androidterm/bin/fdformat: Permission denied -busybox: /data/data/ga.androidterm/bin/fdisk: Permission denied -busybox: /data/data/ga.androidterm/bin/fgconsole: Permission denied -busybox: /data/data/ga.androidterm/bin/find: Permission denied -busybox: /data/data/ga.androidterm/bin/findfs: Permission denied -busybox: /data/data/ga.androidterm/bin/flash_lock: Permission denied -busybox: /data/data/ga.androidterm/bin/flash_unlock: Permission denied -busybox: /data/data/ga.androidterm/bin/flashcp: Permission denied -busybox: /data/data/ga.androidterm/bin/flock: Permission denied -busybox: /data/data/ga.androidterm/bin/fold: Permission denied -busybox: /data/data/ga.androidterm/bin/freeramdisk: Permission denied -busybox: /data/data/ga.androidterm/bin/ftpd: Permission denied -busybox: /data/data/ga.androidterm/bin/ftpget: Permission denied -busybox: /data/data/ga.androidterm/bin/ftpput: Permission denied -busybox: /data/data/ga.androidterm/bin/fuser: Permission denied -busybox: /data/data/ga.androidterm/bin/getopt: Permission denied -busybox: /data/data/ga.androidterm/bin/grep: Permission denied -busybox: /data/data/ga.androidterm/bin/gunzip: Permission denied -busybox: /data/data/ga.androidterm/bin/gzip: Permission denied -busybox: /data/data/ga.androidterm/bin/hd: Permission denied -busybox: /data/data/ga.androidterm/bin/hdparm: Permission denied -busybox: /data/data/ga.androidterm/bin/head: Permission denied -busybox: /data/data/ga.androidterm/bin/hexdump: Permission denied -busybox: /data/data/ga.androidterm/bin/httpd: Permission denied -busybox: /data/data/ga.androidterm/bin/ifconfig: Permission denied -busybox: /data/data/ga.androidterm/bin/ifdown: Permission denied -busybox: /data/data/ga.androidterm/bin/ifup: Permission denied -busybox: /data/data/ga.androidterm/bin/inotifyd: Permission denied -busybox: /data/data/ga.androidterm/bin/install: Permission denied -busybox: /data/data/ga.androidterm/bin/iostat: Permission denied -busybox: /data/data/ga.androidterm/bin/ip: Permission denied -busybox: /data/data/ga.androidterm/bin/ipaddr: Permission denied -busybox: /data/data/ga.androidterm/bin/ipcalc: Permission denied -busybox: /data/data/ga.androidterm/bin/iplink: Permission denied -busybox: /data/data/ga.androidterm/bin/iproute: Permission denied -busybox: /data/data/ga.androidterm/bin/iprule: Permission denied -busybox: /data/data/ga.androidterm/bin/iptunnel: Permission denied -busybox: /data/data/ga.androidterm/bin/klogd: Permission denied -busybox: /data/data/ga.androidterm/bin/ln: Permission denied -busybox: /data/data/ga.androidterm/bin/loadkmap: Permission denied -busybox: /data/data/ga.androidterm/bin/losetup: Permission denied -busybox: /data/data/ga.androidterm/bin/lpd: Permission denied -busybox: /data/data/ga.androidterm/bin/lpq: Permission denied -busybox: /data/data/ga.androidterm/bin/lpr: Permission denied -busybox: /data/data/ga.androidterm/bin/ls: Permission denied -busybox: /data/data/ga.androidterm/bin/lsattr: Permission denied -busybox: /data/data/ga.androidterm/bin/lsof: Permission denied -busybox: /data/data/ga.androidterm/bin/lspci: Permission denied -busybox: /data/data/ga.androidterm/bin/lsusb: Permission denied -busybox: /data/data/ga.androidterm/bin/lzcat: Permission denied -busybox: /data/data/ga.androidterm/bin/lzma: Permission denied -busybox: /data/data/ga.androidterm/bin/lzop: Permission denied -busybox: /data/data/ga.androidterm/bin/lzopcat: Permission denied -busybox: /data/data/ga.androidterm/bin/makedevs: Permission denied -busybox: /data/data/ga.androidterm/bin/makemime: Permission denied -busybox: /data/data/ga.androidterm/bin/man: Permission denied -busybox: /data/data/ga.androidterm/bin/md5sum: Permission denied -busybox: /data/data/ga.androidterm/bin/mkdir: Permission denied -busybox: /data/data/ga.androidterm/bin/mkfifo: Permission denied -busybox: /data/data/ga.androidterm/bin/mknod: Permission denied -busybox: /data/data/ga.androidterm/bin/mkswap: Permission denied -busybox: /data/data/ga.androidterm/bin/mktemp: Permission denied -busybox: /data/data/ga.androidterm/bin/more: Permission denied -busybox: /data/data/ga.androidterm/bin/mpstat: Permission denied -busybox: /data/data/ga.androidterm/bin/mv: Permission denied -busybox: /data/data/ga.androidterm/bin/nbd-client: Permission denied -busybox: /data/data/ga.androidterm/bin/nc: Permission denied -busybox: /data/data/ga.androidterm/bin/netstat: Permission denied -busybox: /data/data/ga.androidterm/bin/nice: Permission denied -busybox: /data/data/ga.androidterm/bin/nmeter: Permission denied -busybox: /data/data/ga.androidterm/bin/nohup: Permission denied -busybox: /data/data/ga.androidterm/bin/od: Permission denied -busybox: /data/data/ga.androidterm/bin/openvt: Permission denied -busybox: /data/data/ga.androidterm/bin/patch: Permission denied -busybox: /data/data/ga.androidterm/bin/pidof: Permission denied -busybox: /data/data/ga.androidterm/bin/pipe_progress: Permission denied -busybox: /data/data/ga.androidterm/bin/pmap: Permission denied -busybox: /data/data/ga.androidterm/bin/popmaildir: Permission denied -busybox: /data/data/ga.androidterm/bin/printenv: Permission denied -busybox: /data/data/ga.androidterm/bin/printf: Permission denied -busybox: /data/data/ga.androidterm/bin/pscan: Permission denied -busybox: /data/data/ga.androidterm/bin/pstree: Permission denied -busybox: /data/data/ga.androidterm/bin/pwd: Permission denied -busybox: /data/data/ga.androidterm/bin/pwdx: Permission denied -busybox: /data/data/ga.androidterm/bin/raidautorun: Permission denied -busybox: /data/data/ga.androidterm/bin/rdev: Permission denied -busybox: /data/data/ga.androidterm/bin/readlink: Permission denied -busybox: /data/data/ga.androidterm/bin/readprofile: Permission denied -busybox: /data/data/ga.androidterm/bin/realpath: Permission denied -busybox: /data/data/ga.androidterm/bin/reformime: Permission denied -busybox: /data/data/ga.androidterm/bin/renice: Permission denied -busybox: /data/data/ga.androidterm/bin/reset: Permission denied -busybox: /data/data/ga.androidterm/bin/resize: Permission denied -busybox: /data/data/ga.androidterm/bin/rev: Permission denied -busybox: /data/data/ga.androidterm/bin/rm: Permission denied -busybox: /data/data/ga.androidterm/bin/rmdir: Permission denied -busybox: /data/data/ga.androidterm/bin/route: Permission denied -busybox: /data/data/ga.androidterm/bin/rpm: Permission denied -busybox: /data/data/ga.androidterm/bin/rpm2cpio: Permission denied -busybox: /data/data/ga.androidterm/bin/rtcwake: Permission denied -busybox: /data/data/ga.androidterm/bin/run-parts: Permission denied -busybox: /data/data/ga.androidterm/bin/runsv: Permission denied -busybox: /data/data/ga.androidterm/bin/runsvdir: Permission denied -busybox: /data/data/ga.androidterm/bin/rx: Permission denied -busybox: /data/data/ga.androidterm/bin/script: Permission denied -busybox: /data/data/ga.androidterm/bin/scriptreplay: Permission denied -busybox: /data/data/ga.androidterm/bin/sed: Permission denied -busybox: /data/data/ga.androidterm/bin/sendmail: Permission denied -busybox: /data/data/ga.androidterm/bin/seq: Permission denied -busybox: /data/data/ga.androidterm/bin/setconsole: Permission denied -busybox: /data/data/ga.androidterm/bin/setkeycodes: Permission denied -busybox: /data/data/ga.androidterm/bin/setlogcons: Permission denied -busybox: /data/data/ga.androidterm/bin/setserial: Permission denied -busybox: /data/data/ga.androidterm/bin/setsid: Permission denied -busybox: /data/data/ga.androidterm/bin/setuidgid: Permission denied -busybox: /data/data/ga.androidterm/bin/sh: Permission denied -busybox: /data/data/ga.androidterm/bin/sha1sum: Permission denied -busybox: /data/data/ga.androidterm/bin/sha256sum: Permission denied -busybox: /data/data/ga.androidterm/bin/sha512sum: Permission denied -busybox: /data/data/ga.androidterm/bin/showkey: Permission denied -busybox: /data/data/ga.androidterm/bin/sleep: Permission denied -busybox: /data/data/ga.androidterm/bin/smemcap: Permission denied -busybox: /data/data/ga.androidterm/bin/softlimit: Permission denied -busybox: /data/data/ga.androidterm/bin/sort: Permission denied -busybox: /data/data/ga.androidterm/bin/split: Permission denied -busybox: /data/data/ga.androidterm/bin/start-stop-daemon: Permission denied -busybox: /data/data/ga.androidterm/bin/strings: Permission denied -busybox: /data/data/ga.androidterm/bin/stty: Permission denied -busybox: /data/data/ga.androidterm/bin/sum: Permission denied -busybox: /data/data/ga.androidterm/bin/sv: Permission denied -busybox: /data/data/ga.androidterm/bin/svlogd: Permission denied -busybox: /data/data/ga.androidterm/bin/sync: Permission denied -busybox: /data/data/ga.androidterm/bin/sysctl: Permission denied -busybox: /data/data/ga.androidterm/bin/tac: Permission denied -busybox: /data/data/ga.androidterm/bin/tail: Permission denied -busybox: /data/data/ga.androidterm/bin/tar: Permission denied -busybox: /data/data/ga.androidterm/bin/tcpsvd: Permission denied -busybox: /data/data/ga.androidterm/bin/tee: Permission denied -busybox: /data/data/ga.androidterm/bin/test: Permission denied -busybox: /data/data/ga.androidterm/bin/time: Permission denied -busybox: /data/data/ga.androidterm/bin/timeout: Permission denied -busybox: /data/data/ga.androidterm/bin/top: Permission denied -busybox: /data/data/ga.androidterm/bin/touch: Permission denied -busybox: /data/data/ga.androidterm/bin/tr: Permission denied -busybox: /data/data/ga.androidterm/bin/true: Permission denied -busybox: /data/data/ga.androidterm/bin/ttysize: Permission denied -busybox: /data/data/ga.androidterm/bin/tunctl: Permission denied -busybox: /data/data/ga.androidterm/bin/tune2fs: Permission denied -busybox: /data/data/ga.androidterm/bin/udhcpc: Permission denied -busybox: /data/data/ga.androidterm/bin/uname: Permission denied -busybox: /data/data/ga.androidterm/bin/uncompress: Permission denied -busybox: /data/data/ga.androidterm/bin/unexpand: Permission denied -busybox: /data/data/ga.androidterm/bin/uniq: Permission denied -busybox: /data/data/ga.androidterm/bin/unix2dos: Permission denied -busybox: /data/data/ga.androidterm/bin/unlzma: Permission denied -busybox: /data/data/ga.androidterm/bin/unlzop: Permission denied -busybox: /data/data/ga.androidterm/bin/unxz: Permission denied -busybox: /data/data/ga.androidterm/bin/unzip: Permission denied -busybox: /data/data/ga.androidterm/bin/uudecode: Permission denied -busybox: /data/data/ga.androidterm/bin/uuencode: Permission denied -busybox: /data/data/ga.androidterm/bin/vi: Permission denied -busybox: /data/data/ga.androidterm/bin/volname: Permission denied -busybox: /data/data/ga.androidterm/bin/watch: Permission denied -busybox: /data/data/ga.androidterm/bin/wc: Permission denied -busybox: /data/data/ga.androidterm/bin/wget: Permission denied -busybox: /data/data/ga.androidterm/bin/which: Permission denied -busybox: /data/data/ga.androidterm/bin/whoami: Permission denied -busybox: /data/data/ga.androidterm/bin/whois: Permission denied -busybox: /data/data/ga.androidterm/bin/xargs: Permission denied -busybox: /data/data/ga.androidterm/bin/xz: Permission denied -busybox: /data/data/ga.androidterm/bin/xzcat: Permission denied -busybox: /data/data/ga.androidterm/bin/yes: Permission denied -busybox: /data/data/ga.androidterm/bin/zcat: Permission denied -tar: can't remove old file ./links/git-shell: Permission denied -cat: can't open '/data/data/ga.androidterm/links/git': Permission denied -rm: can't stat '/data/data/ga.androidterm/links/git': Permission denied -cat: can't open '/data/data/ga.androidterm/links/git-shell': Permission denied -rm: can't stat '/data/data/ga.androidterm/links/git-shell': Permission denied -cat: can't open '/data/data/ga.androidterm/links/git-upload-pack': Permission denied -rm: can't stat '/data/data/ga.androidterm/links/git-upload-pack': Permission denied -lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/runshell: Permission denied -lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/runshell: Permission denied -chmod: runshell: Operation not permitted -lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/bin/trustedkeys.gpg: Permission denied -lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/installed-version: Permission denied -Installation complete -tar: write: Broken pipe -shell@hammerhead:/sdcard/git-annex.home $ ^D -shell@hammerhead:/ $ -"""]] - -Android is new to me, so it's possible I'm doing something utterly wrong. - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors/comment_1_9b0ed646552e56b6b199761b3ff9eb85._comment b/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors/comment_1_9b0ed646552e56b6b199761b3ff9eb85._comment deleted file mode 100644 index 57136884e9..0000000000 --- a/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors/comment_1_9b0ed646552e56b6b199761b3ff9eb85._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:55:27Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. - -"""]] diff --git a/doc/bugs/Android_6.0_compatibility.mdwn b/doc/bugs/Android_6.0_compatibility.mdwn deleted file mode 100644 index c34822ca18..0000000000 --- a/doc/bugs/Android_6.0_compatibility.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. -Git-annex appears to be incompatible with Android 6. I downloaded the APK for Android 5 and tried installing it on a Nexus 5X running Android 6.0.1. The biggest issue is that pushing and pulling to SSH remotes fails with a "Permission denied" error from muxserver_listen() in OpenSSH. There are some other warnings and errors, listed below, would you like me to file separate bugs for each or track everything here? - -- The full error from ssh is "muxserver_listen: link mux listener /data/data/ga.androidterm/tmp/ssh/annex-user@192.168.0.3.Jg42jDbmIRBdbjDZ => /data/data/ga.androidterm/tmp/ssh/annex-user@192.168.0.3: Permission denied". Immediately after that there is an error message, presumably from git, that reads "fatal: Could not read from remote repository." I am able to SSH to the server from the app's command line, and get an interactive shell. I can successfully run 'git fetch `git remote`', but `git annex sync` runs into this issue. -- When switching between two repositories in the webapp, the page never loads after clicking on a repository. After trying the link a few times, I can see "git-annex: Daemon is already running." through the webapp's log viewer. However, if I stop the daemon through the webapp and start it again, then the webapp will indicate that I successfully switched to the other repository. -- There is a warning message in the console that reads, "WARNING: linker: git-annex has text relocations. This is wasting memory and prevents security hardening. Please fix." It appears that apps targeting SDK version 23 are not allowed to use text relocations, while apps targeting lower versions just get this warning. See http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-runtime -- There is a warning message at the top of every new terminal that says "Falling back to hardcoded app location; cannot find expected files in /data/app/ga.androidterm-1/lib". This issue doesn't appear to affect anything, but I thought I'd mention it for completeness. -- At various times during syncing, "\_\_bionic_open_tzdata_path: ANDROID_DATA not set!" and "\_\_bionic_open_tzdata_path: ANDROID_ROOT not set!" show up in the log. - -### What steps will reproduce the problem? -1. Install Android 5.0 APK on Android 6.0 phone -2. Create a repository -3. Add an SSH remote - -### What version of git-annex are you using? On what operating system? -5.20151217-g7b73f34 on Android 6.0.1 - -### Please provide any additional information below. -[[!format sh """ -muxserver_listen: link mux listener /data/data/ga.androidterm/tmp/ssh/annex-user@192.168.0.3.ZUzI2MBl8k0qt2pg => /data/data/ga.androidterm/tmp/ssh/annex-user@192.168.0.3: Permission denied -"""]] - -If I look in this temporary directory after the fact, I see the following. - -[[!format sh """ -> ls -l /data/data/ga.androidterm/tmp/ssh --rw------- 1 u0_a108 u0_a108 0 Dec 24 10:06 annex-user@192.168.0.3.lock -"""]] - -I suppose since the socket is a Unix domain socket, it gets destroyed when the process stops, so it shouldn't be surprising there's nothing else in that directory. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Not yet, but I'm excited to make it work! - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/Android_6.0_compatibility/comment_1_06dcb3d7c5de5a831403e8e6c4c98dfd._comment b/doc/bugs/Android_6.0_compatibility/comment_1_06dcb3d7c5de5a831403e8e6c4c98dfd._comment deleted file mode 100644 index 7fdff1937e..0000000000 --- a/doc/bugs/Android_6.0_compatibility/comment_1_06dcb3d7c5de5a831403e8e6c4c98dfd._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="comment 1" - date="2015-12-24T22:44:16Z" - content=""" -FWIW, it appears that SSH caching is already turned off in this repository. If I cd to the repository and run `git config annex.sshcaching` I get back \"false\". -"""]] diff --git a/doc/bugs/Android_6.0_compatibility/comment_2_c7cabab122174867d7350a1eaa76151c._comment b/doc/bugs/Android_6.0_compatibility/comment_2_c7cabab122174867d7350a1eaa76151c._comment deleted file mode 100644 index c7c559ca72..0000000000 --- a/doc/bugs/Android_6.0_compatibility/comment_2_c7cabab122174867d7350a1eaa76151c._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="Logcat output -- SELinux" - date="2015-12-30T03:01:56Z" - content=""" -I ran a sync again and captured output from logcat. It appears that an SELinux policy is preventing ssh from linking its socket file. (at [this line](https://github.com/openssh/openssh-portable/blob/master/mux.c#L1298)) There are several log messages similar to the one below, presumably one for each failed invocation of ssh. - -``` -12-29 20:49:07.308 29990 29990 W ssh : type=1400 audit(0.0:64711): avc: denied { link } for name=\"annex-user@192.168.0.3.cAGquyBx4Z10RTYL\" dev=\"dm-2\" ino=392849 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=sock_file permissive=0 -``` -"""]] diff --git a/doc/bugs/Android_6.0_compatibility/comment_3_47f9cbde0385a4816ccec1b512dea2fd._comment b/doc/bugs/Android_6.0_compatibility/comment_3_47f9cbde0385a4816ccec1b512dea2fd._comment deleted file mode 100644 index e54e394ca6..0000000000 --- a/doc/bugs/Android_6.0_compatibility/comment_3_47f9cbde0385a4816ccec1b512dea2fd._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="SELinux" - date="2015-12-30T03:40:02Z" - content=""" -According to [this issue on Google Code](https://code.google.com/p/android-developer-preview/issues/detail?id=3150), hard linking files is not allowed on Android 6.0. It looks like the only recourse will be to reconfigure or patch OpenSSH, such that it doesn't need to create a hardlink. -"""]] diff --git a/doc/bugs/Android_6.0_compatibility/comment_4_f1f3c98050247cbba4521311465513e2._comment b/doc/bugs/Android_6.0_compatibility/comment_4_f1f3c98050247cbba4521311465513e2._comment deleted file mode 100644 index abf7a78c1a..0000000000 --- a/doc/bugs/Android_6.0_compatibility/comment_4_f1f3c98050247cbba4521311465513e2._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-01-20T19:03:37Z" - content=""" -Unfortunately, I lack time, energy, or devices to do much work on the -Android port. Patches would be welcome for any or all of these issues. - -(Although the relocations warning seems completely ignorable.) - -(Wow, they broke hard links? What core unix feature is next to go? Sheesh.) -"""]] diff --git a/doc/bugs/Android_6.0_compatibility/comment_5_0bcee221dd22b424f08720604a486c79._comment b/doc/bugs/Android_6.0_compatibility/comment_5_0bcee221dd22b424f08720604a486c79._comment deleted file mode 100644 index 7ed65ea61d..0000000000 --- a/doc/bugs/Android_6.0_compatibility/comment_5_0bcee221dd22b424f08720604a486c79._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="Disabling SSH connection caching" - date="2016-02-01T06:52:55Z" - content=""" -I was looking into how SSH connection caching is handled, and it seems there's a bug in the sshCacheDir function in Annex/Ssh.hs. If I'm reading things right, `annex.sshcaching` is ignored when `annex.crippledfilesystem` is set. Thus, even though the configuration says SSH caching is disabled, this function still creates and passes out a temporary directory to be used for connection caching. Further up, this results in ControlPersist, ControlMaster, etc. being passed to OpenSSH, which runs into the SELinux rules. I think the `ifM` calls should be nested the other way around, (see below) which would allow me to turn off connection caching and hopefully get SSH working. I haven't tested this yet, though I plan to get a build environment set up within a month for further tinkering. - -Revised sshCacheDir: - -``` -sshCacheDir :: Annex (Maybe FilePath) -sshCacheDir - | SysConfig.sshconnectioncaching = ifM - ( fromMaybe True . annexSshCaching <$> Annex.getGitConfig ) - ( ifM crippledFileSystem - ( maybe (return Nothing) usetmpdir =<< gettmpdir - , Just <$> fromRepo gitAnnexSshDir ) - , return Nothing - ) - | otherwise = return Nothing - where - gettmpdir = liftIO $ getEnv \"GIT_ANNEX_TMP_DIR\" - usetmpdir tmpdir = liftIO $ catchMaybeIO $ do - let socktmp = tmpdir \"ssh\" - createDirectoryIfMissing True socktmp - return socktmp -``` -"""]] diff --git a/doc/bugs/Android_6.0_compatibility/comment_6_a4ef9eb27285aa68d6edc14e30627ebf._comment b/doc/bugs/Android_6.0_compatibility/comment_6_a4ef9eb27285aa68d6edc14e30627ebf._comment deleted file mode 100644 index fb980779b0..0000000000 --- a/doc/bugs/Android_6.0_compatibility/comment_6_a4ef9eb27285aa68d6edc14e30627ebf._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-04-20T18:40:57Z" - content=""" -Thanks, divergentdave for spotting that and also for writing a fix. -I've finally noticed your comment and put the fix in. It would probably be -good to open a todo if you have a patch in the future, to make sure it -doesn't get forgotten about. -"""]] diff --git a/doc/bugs/Android_6.0_compatibility/comment_7_a7110f92e8a90e95f494e3f917b610ea._comment b/doc/bugs/Android_6.0_compatibility/comment_7_a7110f92e8a90e95f494e3f917b610ea._comment deleted file mode 100644 index 30b7df2821..0000000000 --- a/doc/bugs/Android_6.0_compatibility/comment_7_a7110f92e8a90e95f494e3f917b610ea._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2018-05-08T18:51:44Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. - -"""]] diff --git a/doc/bugs/Android_CM_5.1_ANDROID__95__ROOT_not_set.mdwn b/doc/bugs/Android_CM_5.1_ANDROID__95__ROOT_not_set.mdwn deleted file mode 100644 index 10abf048db..0000000000 --- a/doc/bugs/Android_CM_5.1_ANDROID__95__ROOT_not_set.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. - -Downloaded git-annex (version for android 5.0) from the website. Upon opening the app for the first time and setting up a repository at /sdcard/annex, the terminal gave out the error. - -### What version of git-annex are you using? On what operating system? - -Nexus 4 running Cyanogenmod 12.1 (Android 5.1) build 20151007 and 20150901 - -### Please provide any additional information below. -Output to the terminal window: -[[!format sh """ -WARNING: linker: git-annex has text relocations. This is wating memory and prevents security hardening. Please fix. -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! - -Detected a filesystem without fifo support. - -Disabling ssh connection caching. - -Detected a crippled filesystem. - -Enabling direct mode. -fatal: ../../../../sdcard/annex: '../../../../sdcard/annex' is outside of repository -(recording state in git...) -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -"""]] -I can add remote repositories and they show up nicely in the webapp, but no files are ever downloaded. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I have a couple of repositories atm, one with my music, another that backs up our family pictures for the family and uses Amazon S3 as a backup. - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] - diff --git a/doc/bugs/Android_CM_5.1_ANDROID__95__ROOT_not_set/comment_1_5f480528fe855fcbdbf5b6950aa42a25._comment b/doc/bugs/Android_CM_5.1_ANDROID__95__ROOT_not_set/comment_1_5f480528fe855fcbdbf5b6950aa42a25._comment deleted file mode 100644 index c246116504..0000000000 --- a/doc/bugs/Android_CM_5.1_ANDROID__95__ROOT_not_set/comment_1_5f480528fe855fcbdbf5b6950aa42a25._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:52:02Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/Android__58___Cannot_create_repo_on_external_sd_card.mdwn b/doc/bugs/Android__58___Cannot_create_repo_on_external_sd_card.mdwn deleted file mode 100644 index ead5aa9d81..0000000000 --- a/doc/bugs/Android__58___Cannot_create_repo_on_external_sd_card.mdwn +++ /dev/null @@ -1,64 +0,0 @@ -I am using the latest daily build for Android 5.0 - -My version is Android 5.0.1 Lollipop. And I'm using a Samsung Galaxy S4 unrooted. - -Trying to create a repositpory in the folder /storage/extSdCard/Music gives me a webpage with a red error badge that says: - - "Internal Server Error" - - git init failed - - Output: - /storage/extSdCard/Music/.git: Permission denied - -I'm pretty sure this is because of Android's crappy permission system on sd cards. But when I install the app, it tells me it is asking for -read write access to the sd card. So this consideration must have happened. - - - -### Please describe the problem. - -I am using the latest daily build for Android 5.0 - -My version is Android 5.0.1 Lollipop. And I'm using a Samsung Galaxy S4 unrooted. - -Trying to create a repositpory in the folder /storage/extSdCard/Music gives me a webpage with a red error badge that says: - - "Internal Server Error" - - git init failed - - Output: - /storage/extSdCard/Music/.git: Permission denied - -I'm pretty sure this is because of Android's crappy permission system on sd cards. But when I install the app, it tells me it is asking for -read write access to the sd card. So this consideration must have happened. - -### What steps will reproduce the problem? - -1. Install the Android 5.0 daily build on an Android 5.0.1 phone. -2. Try to create a repo on an external sd card. - -### What version of git-annex are you using? On what operating system? - -Latest daily build of Android 5.0 git annex on Android 5.0.1 - -### Please provide any additional information below. - -When I run adb shell I see the following permissions on the file in question: - - drwxrwx--- root sdcard_r 2016-04-02 14:11 Music - -Additional info. The terminal emulator shows this output: - - Falling back to hardcoded app location: cannot find expected files in /data/app/ga.androidterm-2/lib - git annex webapp - WARNING: linker: git-annex has text relocations. This is wasting memory and prevents security hardening. Please fix. - -I have tried moving the app to the sd card, but it will not work if I do that. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! It's by far one of my favorite apps! it works very well on my laptop, on my home file server, and on my internal storage on my Android phone :) - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/Android__58___Cannot_create_repo_on_external_sd_card/comment_1_7ac9adea8bf562d590133e83cbb12570._comment b/doc/bugs/Android__58___Cannot_create_repo_on_external_sd_card/comment_1_7ac9adea8bf562d590133e83cbb12570._comment deleted file mode 100644 index 5d0e23956c..0000000000 --- a/doc/bugs/Android__58___Cannot_create_repo_on_external_sd_card/comment_1_7ac9adea8bf562d590133e83cbb12570._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:49:14Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__.mdwn b/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__.mdwn deleted file mode 100644 index c34ea43c3d..0000000000 --- a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -### Please describe the problem. -I’ve only just set up git-annex on my Android system, so I might be confused; but from what I could find on this site, the Android build only supports passwordless SSH key files, which must be deployed in /sdcard/git-annex.home/.ssh (I also found something about git-annex generating keys by itself, but the web app didn’t refer to something like that, so I take it this feature is gone now). What perplexed me about this is that /sdcard on Android is a VFAT file-system, and is set up so that any user or application may read it (with a permissions mask for the sdcard group), which isn’t ideal for a passwordless key. From what I could gather, there’s also a place in the virtual file-system under /data that is intended to house private, per-application data. Should git-annex use this location as its home instead? - -### What version of git-annex are you using? On what operating system? -git-annex 5.20150522-g260b59e -Android 4.4.4 - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_1_95481b150f43fd3db311fbcf6d1e48aa._comment b/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_1_95481b150f43fd3db311fbcf6d1e48aa._comment deleted file mode 100644 index cdfb498336..0000000000 --- a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_1_95481b150f43fd3db311fbcf6d1e48aa._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-07-06T18:23:57Z" - content=""" -I think that /data is locked down such that apps generally cannot write to -it, but please correct me if I'm wrong. -"""]] diff --git a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_2_041fe2a545b48acd2c9d15eb2ac2b34f._comment b/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_2_041fe2a545b48acd2c9d15eb2ac2b34f._comment deleted file mode 100644 index 486d1843ff..0000000000 --- a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_2_041fe2a545b48acd2c9d15eb2ac2b34f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="comment 2" - date="2016-03-21T04:13:15Z" - content=""" -Each app has one subfolder inside /data that is private to that app (and user) alone. Generally, you can't read or enumerate /data itself. There is a function in the Java API to get the current app's internal storage folder, see https://developer.android.com/reference/android/content/Context.html#getFilesDir%28%29. -"""]] diff --git a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_3_c46091ade13865addb83c6e77f97f195._comment b/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_3_c46091ade13865addb83c6e77f97f195._comment deleted file mode 100644 index 4682b3ae58..0000000000 --- a/doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_3_c46091ade13865addb83c6e77f97f195._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-05-08T18:50:00Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/Android_cannot_setup_gitlab_repo_due_to_ECDSA_key.mdwn b/doc/bugs/Android_cannot_setup_gitlab_repo_due_to_ECDSA_key.mdwn deleted file mode 100644 index 68a2d1a483..0000000000 --- a/doc/bugs/Android_cannot_setup_gitlab_repo_due_to_ECDSA_key.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -### Please describe the problem. -Cannot add gitlab repository on Android. - -### What steps will reproduce the problem? -After attempting to add a gitlab repository on git-annex assistant, I am presented with a ssh key and prompted to add it to my gitlab account. After doing so and continuing, git-annex assistant returns to the same page and presents the ssh key again. Attempting to continue repeats the cycle as the ssh key is presented over and over. - -### What version of git-annex are you using? On what operating system? -Stable version for Lollipop (I experienced this same error on Kit Kat ~6 months ago but could not resolve it at that point) -Android 5.0 git-annex.apk - -### Please provide any additional information below. -In the git-annex assistant log I see: - - No ECDSA host key is known for gitlab.com and you have requested strict checking. - Host key verification failed. - No ECDSA host key is known for gitlab.com and you have requested strict checking. - Host key verification failed. - fatal: Could not read from remote repository - - Please make sure you have the correct access rights and the repository exists. - Host key verification failed. - Host key verification failed. - fatal: Could not read from remote repository. - -I resolved the issue by opening a new terminal window, attempting to connect to gitlab (ssh git@gitlab.com), verifying the ECDSA key against the gitlab website (https://about.gitlab.com/gitlab-com/) and accepting the key. The file .ssh/known_hosts was created. The gitlab repository could then be added in git annex assistant. - -The lack of information about the error presented to the user in git annex assistant was part of the problem. - - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] - diff --git a/doc/bugs/Android_cannot_setup_gitlab_repo_due_to_ECDSA_key/comment_1_d46469579e96df51ad045340f974f268._comment b/doc/bugs/Android_cannot_setup_gitlab_repo_due_to_ECDSA_key/comment_1_d46469579e96df51ad045340f974f268._comment deleted file mode 100644 index d4d1fa1ff8..0000000000 --- a/doc/bugs/Android_cannot_setup_gitlab_repo_due_to_ECDSA_key/comment_1_d46469579e96df51ad045340f974f268._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:50:33Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH.mdwn b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH.mdwn deleted file mode 100644 index f4f5e661ee..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. - -The install script [[install/Android/git-annex-install]] only adds an entry to `$PATH` which lasts for as long as the shell used for the install. Subsequent launches of termux will not find `git-annex` on the `$PATH`. - -I'm puzzled why this hasn't been reported before. Is everyone on Android manually running `./git-annex.linux/git-annex ...` each time, or have they manually set up `$PATH` in their Termux shell profile without reporting back to the community, or am I missing something else? - -### What steps will reproduce the problem? - -- Install `git-annex` on Android as per [[Android]] -- Quit the shell used during install -- Relaunch termux -- Try to run `git-annex` - -### What version of git-annex are you using? On what operating system? - -6.20180927-gc5b6c55af on Android P - -I know this is probably old now but I can't see any evidence the installer fixed this issue since I last tried. Happy to be told I'm wrong. - -### Please provide any additional information below. - -[[!format sh """ -% git annex -git: 'annex' is not a git command. See 'git --help'. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, been using it for many years and couldn't live without it. - -[[!meta title="termux install adds git-annex only to bash path, not zsh etc"]] - -> made it detect when the login shell is not bash, and rather than add to -> .profile, print out a message letting the user know what they need to -> add to their shell's path [[done]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_1_7aad5d44591f456f2dfcbe5e2351b8bf._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_1_7aad5d44591f456f2dfcbe5e2351b8bf._comment deleted file mode 100644 index e7bd3a52b5..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_1_7aad5d44591f456f2dfcbe5e2351b8bf._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="anthony@ad39673d230d75cbfd19d2757d754030049c7673" - nickname="anthony" - avatar="http://cdn.libravatar.org/avatar/05b48b72766177b3b0a6ff4afdb70790" - subject="Should be in ~/.profile" - date="2019-05-14T19:15:07Z" - content=""" -At least here (on two Android devices I've used the installer on), the installer sets up ~/.profile to add git-annex to PATH. -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_2_ca7a2b0d05a925e530b637b209f1af34._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_2_ca7a2b0d05a925e530b637b209f1af34._comment deleted file mode 100644 index f9141d1278..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_2_ca7a2b0d05a925e530b637b209f1af34._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e" - nickname="branchable" - avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75" - subject="Are we talking about a different installer?" - date="2019-05-14T19:57:41Z" - content=""" -This is the one I used: - -The comment near the top even explicitly admits that it doesn't permanently set up `$PATH`: - -``` -# This script needs to be sourced into the current termux shell, rather -# than run with a new shell, so it can set the PATH to include git-annex. -``` -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_3_9949507f9222667645df6cb5b8aaaf44._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_3_9949507f9222667645df6cb5b8aaaf44._comment deleted file mode 100644 index 46e0ea7b13..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_3_9949507f9222667645df6cb5b8aaaf44._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="anthony@ad39673d230d75cbfd19d2757d754030049c7673" - nickname="anthony" - avatar="http://cdn.libravatar.org/avatar/05b48b72766177b3b0a6ff4afdb70790" - subject="comment 3" - date="2019-05-15T17:55:58Z" - content=""" -Yep, that's the same installer. After running it on my phone, I have a `~/.profile`: - -``` -$ cat .profile -PATH=$PATH:/data/data/com.termux/files/home/git-annex.linux -``` - -The code that adds it is in `~/git-annex.linux/runshell` (which is a shell script). That'd be a good place to start debugging if your `~/.profile` doesn't have the path line. -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_4_d8cec7fae740e82c5da1da47037e2da6._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_4_d8cec7fae740e82c5da1da47037e2da6._comment deleted file mode 100644 index 2c9ce281a0..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_4_d8cec7fae740e82c5da1da47037e2da6._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e" - nickname="branchable" - avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75" - subject=".profile doesn't take effect" - date="2019-05-18T19:46:09Z" - content=""" -Ah, interesting. Very odd that the install script doesn't do that directly. I do have the same contents in my `~/.profile`, but Termux happily ignores it, so `$PATH` is unaltered. Does it really work for you? What version of Termux do you have? -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_5_3eafb2258ac0c8c4e18a3f4591728b32._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_5_3eafb2258ac0c8c4e18a3f4591728b32._comment deleted file mode 100644 index f0a0dd8721..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_5_3eafb2258ac0c8c4e18a3f4591728b32._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="anthony@2b89f08c5c67f83d920fe464d7363db8f45cec20" - nickname="anthony" - avatar="http://cdn.libravatar.org/avatar/5d9fb1b0dd5ae1428c4c5b7df8d26bf2" - subject="comment 5" - date="2019-05-19T08:39:09Z" - content=""" -I have the latest from the Play store on one device and the latest from F-Droid on the other. Is it possible you have a bash_profile or bash_login? If so, then I believe bash won't read profile. -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_6_dd74b3b5a15b6b9f21f3835da134cd5a._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_6_dd74b3b5a15b6b9f21f3835da134cd5a._comment deleted file mode 100644 index a98c4ff2ee..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_6_dd74b3b5a15b6b9f21f3835da134cd5a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e" - nickname="branchable" - avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75" - subject="it's zsh" - date="2019-05-19T10:05:27Z" - content=""" -I figured it out - I changed my default shell to `zsh`, which doesn't read `.profile`. IMHO the installation should also set up `.zprofile` in the same way. -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_7_f9b09f1a720ab73f6a089e8c65f7c402._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_7_f9b09f1a720ab73f6a089e8c65f7c402._comment deleted file mode 100644 index abfb836e43..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_7_f9b09f1a720ab73f6a089e8c65f7c402._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2019-05-20T13:52:37Z" - content=""" -There are a lot of shells, and AFAIK no single place an environment -variable can be put that works with all of them. - -I'm inclined to say that working with termux's default shell is all this -needs to do, and if the user installs some other shell, it's up to them to -configure it. -"""]] diff --git a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_8_c15caba920b49cebf88ebd36caa053b7._comment b/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_8_c15caba920b49cebf88ebd36caa053b7._comment deleted file mode 100644 index 65b5546ed7..0000000000 --- a/doc/bugs/Android_install_doesn__39__t_permanently_add_to___36__PATH/comment_8_c15caba920b49cebf88ebd36caa053b7._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e" - nickname="branchable" - avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75" - subject="comment 8" - date="2019-05-20T15:23:45Z" - content=""" -I understand, and of course it's your prerogative to take that position. While there are many UNIX shells out there, I'm pretty sure that bash and zsh are the two which combined take the lion share of the market. - -If you're worried about the impact of adding `cp .profile .zprofile` to the install, a reasonable alternative would be to document that the install relies on setting up `$PATH` via `.profile` - this confusion only arose in the first place because that mechanism is somewhat hidden rather than taking place directly in the install script. -"""]] diff --git a/doc/bugs/Android_installation_is_missing___36__PATH_setup.mdwn b/doc/bugs/Android_installation_is_missing___36__PATH_setup.mdwn deleted file mode 100644 index a0c55ffad3..0000000000 --- a/doc/bugs/Android_installation_is_missing___36__PATH_setup.mdwn +++ /dev/null @@ -1,92 +0,0 @@ -### Please describe the problem. - -After following the (new) Android installation instructions, git-annex is not on `$PATH`, therefore literal `git annex` commands fail. -I'm sure this is trivially fixed by enhancing the install script so that it modifies `$PATH` in the termux profile, or similar. - -### What steps will reproduce the problem? - -1. Follow the instructions at https://git-annex.branchable.com/Android/ up to `sh git-annex-install` -2. Observe that the install succeeds -3. Try the next step: `git annex webapp` -4. Observe the error `git: 'annex' is not a git command. See 'git --help'.` -5. Observe that it works when using `./git-annex.linux/git-annex` instead - -### What version of git-annex are you using? On what operating system? - -6.20180927-gc5b6c55af on Android 8.1.0 (OxygenOS 5.1.5) on a OnePlus 5T (A5010). - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -% sh -x git-annex-install [20/4719] -+ set -e -+ uname -m -+ arch=arm64 -+ url=https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64.tar.gz -+ echo Installing dependencies with termux pkg manager... -Installing dependencies with termux pkg manager... -+ pkg install git wget tar coreutils proot -Hit:1 https://termux.net stable InRelease -Reading package lists... Done -Building dependency tree -Reading state information... Done -19 packages can be upgraded. Run 'apt list --upgradable' to see them. -Reading package lists... Done -Building dependency tree -Reading state information... Done -coreutils is already the newest version (8.30-1). -git is already the newest version (2.19.1). -proot is already the newest version (5.1.107-18). -tar is already the newest version (1.30-1). -wget is already the newest version (1.19.5-1). -0 upgraded, 0 newly installed, 0 to remove and 19 not upgraded. -+ echo Downloading git-annex... -Downloading git-annex... -+ cd -+ wget -O- https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64.tar.gz -+ tar zx ---2018-10-21 23:41:37-- https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64.tar.gz -Resolving downloads.kitenet.net... 66.228.36.95, 2600:3c03::f03c:91ff:fe73:b0d2 -Connecting to downloads.kitenet.net|66.228.36.95|:443... connected. -HTTP request sent, awaiting response... 200 OK -Length: 64590742 (62M) [application/x-gzip] -Saving to: ‘STDOUT’ - -- 100%[==================================================================>] 61.60M 2.51MB/s in 81s - -2018-10-21 23:42:59 (778 KB/s) - written to stdout [64590742/64590742] - -+ git-annex.linux/git-annex version -Running on Android.. Adding git-annex to PATH for you, and tuning for optimal behavior. -git-annex version: 6.20180927-gc5b6c55af -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser Mag$ -cMime Feeds Testsuite -dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12 persistent-sqlite-2.8.1.$ - torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_$ -84E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 -BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 $ -HA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux aarch64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -+ echo git-annex is successfully installed. -git-annex is successfully installed. -+ echo Now running termux-setup-storage, to let git-annex access system storage. -Now running termux-setup-storage, to let git-annex access system storage. -+ termux-setup-storage -+ echo Installation complete. -Installation complete. -% git annex webapp -git: 'annex' is not a git command. See 'git --help'. -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, lots of luck over the years :-) This is the final little tweak required to get it working for me on Android. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Android_installation_is_missing___36__PATH_setup/comment_1_cf0e167e2da279a20c5b71f9962d05a0._comment b/doc/bugs/Android_installation_is_missing___36__PATH_setup/comment_1_cf0e167e2da279a20c5b71f9962d05a0._comment deleted file mode 100644 index fa1771097b..0000000000 --- a/doc/bugs/Android_installation_is_missing___36__PATH_setup/comment_1_cf0e167e2da279a20c5b71f9962d05a0._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-10-22T17:04:18Z" - content=""" - Running on Android.. Adding git-annex to PATH for you, and tuning for optimal behavior. - -That means it should have updated ~/.profile to set PATH appropriate. - -The problem is the new git-annex-install script, when it exits, dumps the -user back into the shell they were in before, and that shell has not gotten -its path updated. And without sourcing the download script into the current -shell, it has no way to update the path. - -I suppose the best thing is to ask the user to source the script, and then -the script can set PATH. Which I've now done. -""]] diff --git a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable.mdwn b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable.mdwn deleted file mode 100644 index 9c55bff8a8..0000000000 --- a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable.mdwn +++ /dev/null @@ -1,53 +0,0 @@ -### Please describe the problem. -Git-annex is hanging for me on all operations if I have a customized OpenSSH host as a remote. -This is because git-annex uses a custom config file that uses directives introduced in OpenSSH 7.3p1 . I have OpenSSH 6.7p1 . - -### What steps will reproduce the problem? -On Debian Jessie, specify a custom host in ~/.ssh/config such as - - Host custom-host - HostName realhost.com - -Add it as a remote and try to use git-annex - - $ git remote add custom user@custom-host - $ git annex vicfg --debug - -It just hangs. - -### What version of git-annex are you using? On what operating system? - git-annex version: 6.20161211-gc3ab3c668 - PRETTY_NAME="Debian GNU/Linux 8 (jessie)" - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -annex@host:~/annex$ git annex vicfg --debug -[2017-01-16 12:01:58.104071891] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2017-01-16 12:01:58.110698965] process done ExitSuccess -[2017-01-16 12:01:58.11093666] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2017-01-16 12:01:58.116640973] process done ExitSuccess -[2017-01-16 12:01:58.123254411] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2017-01-16 12:01:58.125003224] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] -[2017-01-16 12:01:58.131239655] read: ssh ["-S",".git/annex/ssh/annex@annex-whonix-standalone","-o","ControlMaster=auto","-o","ControlPersist=yes","-F",".git/annex/ssh.config","-T","annex@annex-whonix-standalone","git-annex-shell 'configlist' '/~/annex' '--debug'"] -^C -annex@host:~/annex$ cat .git/annex/ssh.config -IgnoreUnknown Include -Include ~/.ssh/config -Include /etc/ssh/ssh_config -ServerAliveInterval 60 - -# End of transcript or log. -"""]] - -The problem is the use of the `Include` directive which is not understood by my release of OpenSSH. - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Git-annex rocks !!!! - -> [[done]]; this was already fixed --[[Joey]] diff --git a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_1_5a1f9a2014501072188fb235f1b03726._comment b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_1_5a1f9a2014501072188fb235f1b03726._comment deleted file mode 100644 index 700e234cab..0000000000 --- a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_1_5a1f9a2014501072188fb235f1b03726._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="xloem" - avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" - subject="comment 1" - date="2017-01-16T12:47:03Z" - content=""" -Fixed by upgrading to newer version ! Sorry for the re-bug. -"""]] diff --git a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_2_0bc9c0e6d72d6b0d9173e55eca8b107a._comment b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_2_0bc9c0e6d72d6b0d9173e55eca8b107a._comment deleted file mode 100644 index eb33165856..0000000000 --- a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_2_0bc9c0e6d72d6b0d9173e55eca8b107a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="xloem" - avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" - subject="comment 2" - date="2017-01-16T12:48:36Z" - content=""" -how do I move the bug to done? -"""]] diff --git a/doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn b/doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn deleted file mode 100644 index 48e5f12b9b..0000000000 --- a/doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -### Please describe the problem. - -When using tab-completion for git-annex subcommands, filenames with spaces (or other special characters) are not correctly handled. - -### What steps will reproduce the problem? - -[[!format sh """ -$ touch 'foo bar.baz' -$ git annex 'foo # completes to 'foo bar.baz', as expected -$ git annex add 'foo # presents the following (incorrect) options -bar.baz foo -"""]] - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -$ git annex version -git-annex version: 6.20180719 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput Feeds Testsuite -dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.4.3 http-client-0.5.13.1 persistent-sqlite-2.8.1.2 uuid-1.3.13 yesod-1.6.0 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 -SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 -BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -"""]] - -### Please provide any additional information below. - -This is a one-line patch that *somewhat* fixes the issue: - -[[!format sh """ ---- a/bash-completion.bash -+++ b/bash-completion.bash -@@ -20,6 +20,7 @@ complete -o bashdefault -o default -o filenames -F _git-annex git-annex - _git_annex() { - local cmdline - CMDLINE=(--bash-completion-index $(($COMP_CWORD - 1))) -+ local IFS=$'\n' - - local seen_g` -"""]] - -I've certainly not tested this thoroughly, but the problem demonstrated above is fixed, and a cursory check of other commands seems to behave as expected. - -However, it doesn't correctly handle escape characters. Typically, a filename completion escapes special characters as needed, taking into account quoting rules if necessary. This one line patch doesn't seem to do that and completes to names with raw spaces. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Many times over! I use git-annex to manage my hundreds of pdfs, images, video files etc! It essentially enables *exactly* the work flow I like, since I live in the command line and appreciate fine-grained control over my tools. So, yes, thank you very much for this excellent too! - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Bash_completion_of_filenames_with_spaces/comment_1_03146fdf32b16c9f3398c5a9c3ab32f6._comment b/doc/bugs/Bash_completion_of_filenames_with_spaces/comment_1_03146fdf32b16c9f3398c5a9c3ab32f6._comment deleted file mode 100644 index 7c2589d1c3..0000000000 --- a/doc/bugs/Bash_completion_of_filenames_with_spaces/comment_1_03146fdf32b16c9f3398c5a9c3ab32f6._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-11-12T16:13:26Z" - content=""" -I see this too. Note that it only affects tab -completing "git annex"; tab completing "git-annex" -works correctly for filenames with spaces and AFAICS -other problem characters. - -It used to be that git-annex's tab completion for "git annex" was only used -after the user tab completed "git-annex" which loaded the function. -That has changed; git now loads the git-annex completion. Which is good; -I asked the git devs a long time ago to add that. But the change means this -problem is more visible. I don't think the problem is new though. - -[[!commit 07c108e70e2df354d1478cbbec3630d2409d9d32]] -dealt with the same problem affecting "git-annex" tab completion. -The underlying problem is a bug in optparse-applicative, which -completes filenames without escaping them. -So that commit made the "git-annex" completion use "-o bashdefault -o default" -which bypasses the optparse-applicative completion for filenames and lets -bash handle them. It didn't seem to deal with "git annex" completion. - -I see that git uses `__gitcomp_file_direct` when using eg `git ls-files` -to list filenames. It seems that "compopt -o filenames" along with -IFS=newline fixes it. I'll put the same approach into the git-annex script. -"""]] diff --git a/doc/bugs/Build_failure__58___Utility__47__QuickCheck.hs__58__38__58__10__58___error__58___Duplicate_instance_declarations.mdwn b/doc/bugs/Build_failure__58___Utility__47__QuickCheck.hs__58__38__58__10__58___error__58___Duplicate_instance_declarations.mdwn deleted file mode 100644 index 400b7ae7bf..0000000000 --- a/doc/bugs/Build_failure__58___Utility__47__QuickCheck.hs__58__38__58__10__58___error__58___Duplicate_instance_declarations.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. -git-annex-6.20170520 no longer builds successfully. My last successful build of git-annex-6.20170520 was Jun 12, 2017, but something has probably changed in at least one of the dependencies on Hackage since then. - -The build fails on all three Homebrew CI nodes (macOS 10.10, 10.11, and 10.12). - -A full log is here: - -Duplicate since that will eventually be deleted: - -### What steps will reproduce the problem? -Attempt to build git-annex in a cabal sandbox using cabal install. - - -### What version of git-annex are you using? On what operating system? -git-annex-6.20170520 - -### Please provide any additional information below. - -The build error is - -[[!format sh """ -[ 8 of 559] Compiling Utility.QuickCheck ( Utility/QuickCheck.hs, dist/dist-sandbox-758c2984/build/git-annex/git-annex-tmp/Utility/QuickCheck.o ) - -Utility/QuickCheck.hs:38:10: error: - Duplicate instance declarations: - instance Arbitrary EpochTime - -- Defined at Utility/QuickCheck.hs:38:10 - instance [safe] Arbitrary Foreign.C.Types.CTime - -- Defined in ‘Test.QuickCheck.Arbitrary’ -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-6.20170520 failed during the building phase. The exception was: -ExitFailure 1 -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, thanks! - -> Fixed in [[!commit 75cecbbe3fdafdb6652e95ac17cd755c28e67f20]] [[done]] -> --[[Joey]] diff --git a/doc/bugs/Build_failure_with_feed___62____61___1.0.0.0.mdwn b/doc/bugs/Build_failure_with_feed___62____61___1.0.0.0.mdwn deleted file mode 100644 index 2b7bc53de2..0000000000 --- a/doc/bugs/Build_failure_with_feed___62____61___1.0.0.0.mdwn +++ /dev/null @@ -1,181 +0,0 @@ -### Please describe the problem. -git-annex cannot build with feed 1.0.0.0, which was uploaded to Hackage on Sat Aug 26 23:56:18 UTC 2017 by AdamBergmark. - -### What steps will reproduce the problem? -Try to build git-annex with cabal install in a cabal sandbox. - -### What version of git-annex are you using? On what operating system? -6.20170818 - -### Please provide any additional information below. - -[[!format sh """ -[416 of 562] Compiling Command.ImportFeed ( Command/ImportFeed.hs, dist/dist-sandbox-b4eb11e/build/git-annex/git-annex-tmp/Command/ImportFeed.o ) - -Command/ImportFeed.hs:139:61: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: URLString - Actual type: Text.Atom.Feed.URI - • In the first argument of ‘Enclosure’, namely ‘enclosureurl’ - In the second argument of ‘($)’, namely ‘Enclosure enclosureurl’ - In the second argument of ‘($)’, namely - ‘ToDownload f u i $ Enclosure enclosureurl’ - -Command/ImportFeed.hs:142:49: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: URLString - Actual type: Data.Text.Internal.Text - • In the first argument of ‘quviSupported’, namely ‘link’ - In the first argument of ‘ifM’, namely ‘(quviSupported link)’ - In the expression: - ifM - (quviSupported link) - (return $ Just $ ToDownload f u i $ QuviLink link, return Nothing) - -Command/ImportFeed.hs:143:71: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: URLString - Actual type: Data.Text.Internal.Text - • In the first argument of ‘QuviLink’, namely ‘link’ - In the second argument of ‘($)’, namely ‘QuviLink link’ - In the second argument of ‘($)’, namely - ‘ToDownload f u i $ QuviLink link’ - -Command/ImportFeed.hs:214:54: error: - • Couldn't match type ‘[Char]’ with ‘Data.Text.Internal.Text’ - Expected type: S.Set Data.Text.Internal.Text - Actual type: S.Set ItemId - • In the second argument of ‘S.member’, namely ‘(knownitems cache)’ - In the expression: S.member itemid (knownitems cache) - In a case alternative: - Just (_, itemid) -> S.member itemid (knownitems cache) - -Command/ImportFeed.hs:279:42: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe [Char] - Actual type: Maybe Text.RSS.Syntax.DateString - • In the second argument of ‘(<$>)’, namely - ‘getItemPublishDateString itm’ - In the expression: replace "/" "-" <$> getItemPublishDateString itm - In a case alternative: - _ -> replace "/" "-" <$> getItemPublishDateString itm - -Command/ImportFeed.hs:293:44: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: String - Actual type: Data.Text.Internal.Text - • In the first argument of ‘toMetaValue’, namely ‘itemid’ - In the second argument of ‘($)’, namely ‘toMetaValue itemid’ - In the second argument of ‘M.singleton’, namely - ‘(S.singleton $ toMetaValue itemid)’ - -Command/ImportFeed.hs:299:26: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: feedtitle - In the expression: [feedtitle] - In the expression: ("feedtitle", [feedtitle]) - -Command/ImportFeed.hs:300:26: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: itemtitle - In the expression: [itemtitle] - In the expression: ("itemtitle", [itemtitle]) - -Command/ImportFeed.hs:301:27: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: feedauthor - In the expression: [feedauthor] - In the expression: ("feedauthor", [feedauthor]) - -Command/ImportFeed.hs:302:27: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: itemauthor - In the expression: [itemauthor] - In the expression: ("itemauthor", [itemauthor]) - -Command/ImportFeed.hs:303:28: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: getItemSummary $ item i - In the expression: [getItemSummary $ item i] - In the expression: ("itemsummary", [getItemSummary $ item i]) - -Command/ImportFeed.hs:304:32: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: getItemDescription $ item i - In the expression: [getItemDescription $ item i] - In the expression: - ("itemdescription", [getItemDescription $ item i]) - -Command/ImportFeed.hs:305:27: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: getItemRights $ item i - In the expression: [getItemRights $ item i] - In the expression: ("itemrights", [getItemRights $ item i]) - -Command/ImportFeed.hs:306:23: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: snd <$> getItemId (item i) - In the expression: [snd <$> getItemId (item i)] - In the expression: ("itemid", [snd <$> getItemId (item i)]) - -Command/ImportFeed.hs:307:22: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: itemtitle - In the expression: [itemtitle, feedtitle] - In the expression: ("title", [itemtitle, feedtitle]) - -Command/ImportFeed.hs:307:33: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: feedtitle - In the expression: [itemtitle, feedtitle] - In the expression: ("title", [itemtitle, feedtitle]) - -Command/ImportFeed.hs:308:23: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: itemauthor - In the expression: [itemauthor, feedauthor] - In the expression: ("author", [itemauthor, feedauthor]) - -Command/ImportFeed.hs:308:35: error: - • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’ - Expected type: Maybe String - Actual type: Maybe Data.Text.Internal.Text - • In the expression: feedauthor - In the expression: [itemauthor, feedauthor] - In the expression: ("author", [itemauthor, feedauthor]) -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-6.20170818-ATXJn9dQzZj9avYQidLOBq failed during the building phase. -The exception was: -ExitFailure 1 -"""]] - -Full build log is here: -https://gist.githubusercontent.com/anonymous/dcc8d9823bd50b7fca10d5cf8961e75d/raw/c6500526bbad0a94e067816b1af2c9e8717a3419/08.cabal - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes! - -> I fixed this last week, in [[!commit ee2f096e3ba3aea24445ff2093b426b68e000cc2]]. [[done]] diff --git a/doc/bugs/CFBundleShortVersionString_is_not_incremented_with_git-annex.dmg_releases___40__downloads.kitenet.net__41__.mdwn b/doc/bugs/CFBundleShortVersionString_is_not_incremented_with_git-annex.dmg_releases___40__downloads.kitenet.net__41__.mdwn deleted file mode 100644 index e68647ec0e..0000000000 --- a/doc/bugs/CFBundleShortVersionString_is_not_incremented_with_git-annex.dmg_releases___40__downloads.kitenet.net__41__.mdwn +++ /dev/null @@ -1,61 +0,0 @@ -### Please describe the problem. - -*Current:* - -In the **git-annex.app** application bundle included on each [git-annex.dmg](https://downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg) the `CFBundleShortVersionString` and `CFBundleVersion` in the `/Content/PkgInfo.plist` are fixed at "0.0.1" over consecutive releases of `git-annex`. - - CFBundleShortVersionString - 0.0.1 - ... - CFBundleVersion - 0.0.1 - - -This is problematic for automated package deployment systems, such as [Munki](https://www.munki.org), which compare the `CFBundleShortVersionString` of an installed application on a given system with that of deployable packages in an administrator maintained repository to determine whether newer software will be deployed. As the `CFBundleShortVersionString` of `git-annex.app` is never incremented, the test always fails, and newer software is never deployed. - -This is also potentially confusing for end-users whose systems invariably report `/Application/git-annex.app` as being at version "0.0.1" in the Finder and elsewhere in the system. - -Compare to Firefox version 67.0.3: - - CFBundleShortVersionString - 67.0.3 - ... - CFBundleVersion - 6719.6.19 - -Cf: [Apple Technical Note TN2420 Version Numbers and Build Numbers](https://developer.apple.com/library/archive/technotes/tn2420/_index.html) - -*Expected:* - -The `CFBundleShortVersionString` in the `git-annex.app/Content/PkgInfo.plist` matches the `distributionVersion` in [git-annex.app.info](https://downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg.info) for each release. - -E.g.: The release of [version 7.20190507](http://git-annex.branchable.com/news/version_7.20190507/) where `git-annex.app/Contents/MacOS/git-annex version` reports -`git-annex version: 7.20190130-gfe9bfa815` and _downloads.kitenet.net_ hosts a `git-annex.dmg.info` containing`distributionVersion = 7.20190507`, the corresponding `git-annex.dmg`'s `/Content/PkgInfo.plist` would contain: - - ... - CFBundleShortVersionString - 7.20190507 - ... - -### What steps will reproduce the problem? - - -### What version of git-annex are you using? On what operating system? - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes, loving git-annex, it's a great tool! - -> [[fixed|done]] in the build scripts, when the OSX app will successfully -> build again I am not sure. Thanks for reporting this, I had no idea there -> was a significant version in there. --[[Joey]] diff --git a/doc/bugs/CFBundleShortVersionString_is_not_incremented_with_git-annex.dmg_releases___40__downloads.kitenet.net__41__/comment_1_a97699ec3b18b9601a891d399a0f36e4._comment b/doc/bugs/CFBundleShortVersionString_is_not_incremented_with_git-annex.dmg_releases___40__downloads.kitenet.net__41__/comment_1_a97699ec3b18b9601a891d399a0f36e4._comment deleted file mode 100644 index f8b999169b..0000000000 --- a/doc/bugs/CFBundleShortVersionString_is_not_incremented_with_git-annex.dmg_releases___40__downloads.kitenet.net__41__/comment_1_a97699ec3b18b9601a891d399a0f36e4._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="leej" - avatar="http://cdn.libravatar.org/avatar/eb1c6bd57680f694fb4658388e6de4ed" - subject="Thank you, CFBundleShortVersionString is present and matches the internal git-annex version" - date="2019-08-02T15:57:10Z" - content=""" -I can confirm that this works just fine with Munki tools version 3.6.2.3776. -Thank you again, Joey -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant.mdwn b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant.mdwn deleted file mode 100644 index f4605a3383..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant.mdwn +++ /dev/null @@ -1,111 +0,0 @@ -### Please describe the problem. -No matter what I do I can't - -### What steps will reproduce the problem? -Create a repository, try to add a remote. An external disk in this case. - -### What version of git-annex are you using? On what operating system? -Fedora 27 - - $ cat /etc/fedora-release - Fedora release 27 (Twenty Seven) - $ uname -a - Linux greger 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux - - $ git annex version - git-annex version: 6.20180130-g39d97867a - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser Feeds Testsuite - dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - - -### Please provide any additional information below. - -Debug log: - - [2018-01-31 14:46:15.670775214] main: starting assistant version 6.20180130-g39d97867a - [2018-01-31 14:46:15.776042349] Cronner: You should enable consistency checking to protect your data. - (scanning...) [2018-01-31 14:46:15.988042623] Watcher: Performing startup scan - (started...) - [2018-01-31 14:47:48.236476657] read: gpg ["--quiet","--trust-model","always","--with-colons","--list-secret-keys","--fixed-list-mode"] - [2018-01-31 14:47:48.262055169] process done ExitSuccess - [2018-01-31 14:47:51.695935824] read: git ["init","--quiet","--bare","/run/media/dxtr/archive/annex"] - [2018-01-31 14:47:51.700278024] process done ExitSuccess - [2018-01-31 14:47:51.700424216] read: git ["config","--null","--list"] - [2018-01-31 14:47:51.707427206] process done ExitSuccess - [2018-01-31 14:47:51.70868726] call: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","config","core.fsyncobjectfiles","true"] - [2018-01-31 14:47:51.725766269] process done ExitSuccess - [2018-01-31 14:47:51.728215647] read: git ["config","--null","--list"] - [2018-01-31 14:47:51.740757992] process done ExitSuccess - [2018-01-31 14:47:51.741434499] read: git ["config","--null","--list"] - [2018-01-31 14:47:51.753548799] process done ExitSuccess - [2018-01-31 14:47:51.755149461] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","show-ref","git-annex"] - [2018-01-31 14:47:51.771911199] process done ExitFailure 1 - [2018-01-31 14:47:51.772860937] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2018-01-31 14:47:51.789876829] process done ExitFailure 1 - [2018-01-31 14:47:51.790600261] call: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","show-ref","--verify","-q","origin/git-annex"] - [2018-01-31 14:47:51.79719711] process done ExitFailure 1 - [2018-01-31 14:47:51.799141741] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","write-tree"] - [2018-01-31 14:47:51.807820543] process done ExitSuccess - [2018-01-31 14:47:51.809126461] chat: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"] - [2018-01-31 14:47:51.836742843] process done ExitSuccess - [2018-01-31 14:47:51.837688371] call: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","update-ref","refs/heads/git-annex","c1bd62a595ce9cb811ad353ed0d9eaf8cfcb0b30"] - [2018-01-31 14:47:51.849598566] process done ExitSuccess - [2018-01-31 14:47:51.850762057] call: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","config","annex.uuid","da4c4bf3-5b3d-47f7-98d6-040cf8094360"] - [2018-01-31 14:47:51.855957091] process done ExitSuccess - [2018-01-31 14:47:51.85617243] read: git ["config","--null","--list"] - [2018-01-31 14:47:51.858450427] process done ExitSuccess - [2018-01-31 14:47:51.860771677] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","show-ref","git-annex"] - [2018-01-31 14:47:51.879636685] process done ExitSuccess - [2018-01-31 14:47:51.880463945] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2018-01-31 14:47:51.897305118] process done ExitSuccess - [2018-01-31 14:47:51.899214969] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","log","refs/heads/git-annex..c1bd62a595ce9cb811ad353ed0d9eaf8cfcb0b30","--pretty=%H","-n1"] - [2018-01-31 14:47:51.9105804] process done ExitSuccess - [2018-01-31 14:47:51.912107527] chat: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","cat-file","--batch"] - [2018-01-31 14:47:51.916244492] chat: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] - [2018-01-31 14:47:51.926062822] call: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","config","annex.version","5"] - [2018-01-31 14:47:51.943412825] process done ExitSuccess - [2018-01-31 14:47:51.943804264] read: git ["config","--null","--list"] - [2018-01-31 14:47:51.949022318] process done ExitSuccess - [2018-01-31 14:47:51.952482534] chat: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] - [2018-01-31 14:47:51.954175781] feed: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","update-index","-z","--index-info"] - [2018-01-31 14:47:51.968113275] process done ExitSuccess - [2018-01-31 14:47:51.969050491] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2018-01-31 14:47:51.979633335] process done ExitSuccess - (recording state in git...) - [2018-01-31 14:47:51.980277288] read: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","write-tree"] - [2018-01-31 14:47:51.989727059] process done ExitSuccess - [2018-01-31 14:47:51.98998106] chat: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","commit-tree","06548fa56acf18f9c1d74a29e248c4650df15e7e","--no-gpg-sign","-p","refs/heads/git-annex"] - [2018-01-31 14:47:52.011569157] process done ExitSuccess - [2018-01-31 14:47:52.012198525] call: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","update-ref","refs/heads/git-annex","26bcec3f33162a9c1c5b7a39c4828eedfdeae41b"] - [2018-01-31 14:47:52.030929599] process done ExitSuccess - [2018-01-31 14:47:52.037715315] process done ExitSuccess - [2018-01-31 14:47:52.038491764] process done ExitSuccess - [2018-01-31 14:47:52.039098682] process done ExitSuccess - [2018-01-31 14:47:52.039790346] read: uname ["-n"] - [2018-01-31 14:47:52.043271433] process done ExitSuccess - [2018-01-31 14:47:52.043523608] read: git ["config","--null","--list"] - [2018-01-31 14:47:52.057690629] process done ExitSuccess - [2018-01-31 14:47:52.058740927] call: git ["--git-dir=../../../../run/media/dxtr/archive/annex","--literal-pathspecs","remote","add","greger","../../../../../home/dxtr/temp/test"] - [2018-01-31 14:47:52.072184794] process done ExitSuccess - [2018-01-31 14:47:52.072509479] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","remote","add","archive","/run/media/dxtr/archive/annex"] - [2018-01-31 14:47:52.081339812] process done ExitSuccess - [2018-01-31 14:47:52.082154367] read: git ["config","--null","--list"] - [2018-01-31 14:47:52.093569488] process done ExitSuccess - 31/Jan/2018:14:47:52 +0100 [Error#yesod-core] there is no available git remote named "archive" @(yesod-core-1.4.37-GCI7RasEcSMIU2vku0fHJ1:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:693:5) - -The interesting part here is that if I try to run the failing git commands in the repository it works: - - $ git --git-dir=../../../../run/media/dxtr/archive/annex --literal-pathspecs show-ref git-annex - 26bcec3f33162a9c1c5b7a39c4828eedfdeae41b refs/heads/git-annex - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -I have been using it for years. Just not the webapp :) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_10_434c3a17d545b0d37aca55d129ddc66b._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_10_434c3a17d545b0d37aca55d129ddc66b._comment deleted file mode 100644 index 1a3fa282b1..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_10_434c3a17d545b0d37aca55d129ddc66b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 10""" - date="2018-11-05T18:29:07Z" - content=""" -@andrew, take a look at the [[contribute]] page, -bug triage section. -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_10_528d06a5299104cc17d0b1835fb74118._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_10_528d06a5299104cc17d0b1835fb74118._comment deleted file mode 100644 index fa0d3c69dd..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_10_528d06a5299104cc17d0b1835fb74118._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847" - nickname="marvin" - avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e" - subject="comment 10" - date="2018-11-05T18:22:49Z" - content=""" -thank you for fixing this bug. you do such a great job and we couldnt be more thankful for your code.... -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_1_a8a77df47eee0e15c25a89b68ec10e8f._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_1_a8a77df47eee0e15c25a89b68ec10e8f._comment deleted file mode 100644 index 05c2aeb8c7..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_1_a8a77df47eee0e15c25a89b68ec10e8f._comment +++ /dev/null @@ -1,35 +0,0 @@ -[[!comment format=mdwn - username="olaf" - avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572" - subject="I can reproduce" - date="2018-02-19T01:05:06Z" - content=""" -### Please describe the problem. - -Creating or adding remotes to an _existing_ repository via the webapp results in -> Internal Server Error -> -> there is no available git remote named \"XYZ\" - -**Creating a new repository** seems to create the repo and update the remotes (checked via `git` at command line) but does not update the repos in the webapp and results in the error: - - 19/Feb/2018:11:48:28 +1100 [Error#yesod-core] there is no available git remote named \"XYZ\" @(yesod-core-1.4.37.2-AqCgZCpSjdiDLzXFcWTxPQ:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:693:5) - - -**Adding an existing repo** to the current repo in the webapp results in the errors: (interesting as it first notes that the remote already exists and then complains that it's not available...) - - fatal: remote XYZ already exists. - 19/Feb/2018:11:52:24 +1100 [Error#yesod-core] there is no available git remote named \"XYZ\" @(yesod-core-1.4.37.2-AqCgZCpSjdiDLzXFcWTxPQ:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:693:5) - - -### Version - git-annex version: 6.20180112 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.18 bloomfilter-2.0.1.0 cryptonite-0.24 DAV-1.3.1 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.7.1 persistent-sqlite-2.6.4 torrent-10000.1.1 uuid-1.2.6 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: darwin x86_64 -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_2_81cdf91b7720cb0a36bdff2815210435._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_2_81cdf91b7720cb0a36bdff2815210435._comment deleted file mode 100644 index 5dd975c70c..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_2_81cdf91b7720cb0a36bdff2815210435._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="jhnichol@cce81d2a480707652a3340ea2f24b3dc4b1f808c" - nickname="jhnichol" - avatar="http://cdn.libravatar.org/avatar/2d05fd7e681bf4838bba8bab538ac65d" - subject="I also have this problem" - date="2018-04-05T15:25:22Z" - content=""" -I'm on OSX 10.11.6. I started with a homebrew install, and today I found the native .dmg app. Could there be a conflict between the homebrew install and the .app? -I'm a first time user trying to test this program and not getting very far. I have a minimal understanding of git, and therefore shy away from the CLI. -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_3_c928d9f0ed85f61270922471c8037643._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_3_c928d9f0ed85f61270922471c8037643._comment deleted file mode 100644 index 8e640e561b..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_3_c928d9f0ed85f61270922471c8037643._comment +++ /dev/null @@ -1,206 +0,0 @@ -[[!comment format=mdwn - username="andrew" - avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" - subject="comment 3" - date="2018-05-04T15:00:18Z" - content=""" -I am getting the same error messages as **olaf**. It does not seem to be related to brew vs dmg **jhnichol**. - -Using the web-gui I can create one local repo. When I try to create a second local repo, by clicking `Add another repository` | `Add another repository` | `Make Repository` | `Combine the repositories` the webapp then fails with this error message: - - Internal Server Error - there is no available git remote named \"a2\" - git-annex version 6.20180409-gfb0780266 - -Looking at the .git/config files for the repos, the names seem strange/incorrect. The second repo has the remote name listed as my hostname, “bumblebee.local”? Not sure if this is an issue. - -Also from a git remote perspective I am a bit confused what I just did? Did I create two completely separate git repos then try to combine them, what does that mean? Shouldn't I have cloned the first repo instead of creating a new one? - -When I created two repos on the commandline I didn't run into any issues, but, what I did was create a repo, then clone it into another directory, then added the new repo as a remote of the 1st repo. It seems the combine button in the webapp isn't doing that. Perhaps combine should only be enabled for special remotes, is that the problem? - - -—Andrew - - - - - -========== full log below, first steps to make the error with webapp, followed by success on the commandline ============= -
-git-annex webapp
-
-make repository:
-/Users/Shared/a1
-
-add a file:
-image1.png
-
-assistant detects and adds to git-annex
-
-click add another repository
-/Users/Shared/a2
-
-assistant creates the directory
-runs git init and git-annex init
-
-click:
-Combine repositories?
-The repository at /Users/Shared/a2 is set up. 
-Do you want to combine it with your existing repository at /Users/Shared/a1?
-
- The combined repositories will sync and share their files.
- 
-
-Internal Server Error
-there is no available git remote named \"a2\"
-git-annex version 6.20180409-gfb0780266
-
-At this point /Users/Shared/a2/.git/config has 
-[core]
-	repositoryformatversion = 0
-	filemode = true
-	bare = true
-	logallrefupdates = true
-	ignorecase = true
-	precomposeunicode = true
-[annex]
-	uuid = 8ee0b541-c429-45c5-aaa2-c4799843f809
-	version = 5
-	direct = true
-[gc]
-	auto = 0
-[remote \"bumblebee.local\"]
-	url = ../a1
-	fetch = +refs/heads/*:refs/remotes/bumblebee.local/*
-		
-And /Users/Shared/a1/.git/config has 
-[core]
-	repositoryformatversion = 0
-	filemode = true
-	bare = true
-	logallrefupdates = true
-	ignorecase = true
-	precomposeunicode = true
-[annex]
-	uuid = 46290480-c956-42ac-9ada-36b2281dbec2
-	version = 5
-	direct = true
-[gc]
-	auto = 0
-[remote \"a2\"]
-	url = /Users/Shared/a2
-	fetch = +refs/heads/*:refs/remotes/a2/*
-	
-
-Perhaps 
-
-
-
-
-
-
-
-OK.
-
-
-Now do this from the commandline:
-
-andrew@bumblebee /Users/Shared$ mkdir a1
-andrew@bumblebee /Users/Shared$ cd a1
-andrew@bumblebee /Users/Shared/a1$ git init
-Initialized empty Git repository in /Users/Shared/a1/.git/
-andrew@bumblebee /Users/Shared/a1$ git annex init
-init  ok
-(recording state in git...)
-
-andrew@bumblebee /Users/Shared/a1$ git annex describe here a1
-describe here ok
-(recording state in git...)
-
-andrew@bumblebee /Users/Shared/a1$ git annex direct
-commit 
-On branch master
-
-Initial commit
-
-nothing to commit
-ok
-direct ok
-andrew@bumblebee /Users/Shared/a1$ cp ~/Desktop/Screen\ Shot\ 2018-05-04\ at\ 10.10.55\ AM.png image1.png
-andrew@bumblebee /Users/Shared/a1$ git add image1.png 
-fatal: This operation must be run in a work tree
-andrew@bumblebee /Users/Shared/a1$ ls
-image1.png
-andrew@bumblebee /Users/Shared/a1$ git annex add image1.png 
-add image1.png ok
-(recording state in git...)
-andrew@bumblebee /Users/Shared/a1$ 
-
-add /Users/Shared/a1 to ~/.config/git-annex/autostart
-
-then:
-
-andrew@bumblebee /Users/Shared/a1$ git-annex assistant --autostart 
-git-annex autostart in /Users/Shared/a1
-ok
-andrew@bumblebee /Users/Shared/a1$ 
-
-launch webapp, see that a1 is listed, add a file, see that webapp detects it
-
-Clone repo1 to another directory
-andrew@bumblebee ~/.config/git-annex$ cd
-andrew@bumblebee ~$ cd /Users/Shared/
-andrew@bumblebee /Users/Shared$ git clone a1 a2
-Cloning into 'a2'...
-done.
-andrew@bumblebee /Users/Shared$ cd a2
-andrew@bumblebee /Users/Shared/a2$ git annex init \"a2\"
-init a2 (merging origin/git-annex into git-annex...)
-(recording state in git...)
-ok
-(recording state in git...)
-andrew@bumblebee /Users/Shared/a2$ 
-
-Add a2 as a remote from a1
-andrew@bumblebee /Users/Shared/a1$ git remote add a2 /Users/Shared/a2
-
-Add a2 to autostart file
-
-Now repos are syncing
-
-Both repos are listed in web-gui when I choose a2 as the repo, only one repo is listed in the web-gui when I choose a1 as the repo.
-
-andrew@bumblebee /Users/Shared/a1$ cat .git/config 
-[core]
-	repositoryformatversion = 0
-	filemode = true
-	bare = true
-	logallrefupdates = true
-	ignorecase = true
-	precomposeunicode = true
-[annex]
-	uuid = f65fd001-b6ea-4a86-9256-2387c830f933
-	version = 5
-	direct = true
-[remote \"a2\"]
-	url = /Users/Shared/a2
-	fetch = +refs/heads/*:refs/remotes/a2/*
-	annex-uuid = f9e9f00a-ae70-4c2d-bac3-fe8d6d05a4ea
-	
-andrew@bumblebee /Users/Shared/a2$ cat .git/config 
-	[core]
-		repositoryformatversion = 0
-		filemode = true
-		bare = false
-		logallrefupdates = true
-		ignorecase = true
-		precomposeunicode = true
-	[remote \"origin\"]
-		url = /Users/Shared/a1
-		fetch = +refs/heads/*:refs/remotes/origin/*
-		annex-uuid = f65fd001-b6ea-4a86-9256-2387c830f933
-	[annex]
-		uuid = f9e9f00a-ae70-4c2d-bac3-fe8d6d05a4ea
-		version = 5
-
-"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_4_52df3e78719c529987621b212588b785._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_4_52df3e78719c529987621b212588b785._comment deleted file mode 100644 index aa63dc834b..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_4_52df3e78719c529987621b212588b785._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="AlexP" - avatar="http://cdn.libravatar.org/avatar/a5756f1e491fa69cba8c2338ce459ed8" - subject="any update on this?" - date="2018-08-02T20:01:57Z" - content=""" -does anyone have a solution to this? I can't seem to add remotes through the webapp. I consistantly get the following error: - -Internal Server Error -there is no available git remote named \"blablabla\" - -thanks -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_5_0159868320e98ed614cefa4bb73f9ab0._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_5_0159868320e98ed614cefa4bb73f9ab0._comment deleted file mode 100644 index 283266843b..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_5_0159868320e98ed614cefa4bb73f9ab0._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="torpidus" - avatar="http://cdn.libravatar.org/avatar/997fb77747b008a26383426ae6561368" - subject="comment 5" - date="2018-09-16T18:40:43Z" - content=""" - This affects me also. git-annex in version of August 8th, 2018. -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_6_bb6c572eb9b9d5d435bdb6eeb78a11f9._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_6_bb6c572eb9b9d5d435bdb6eeb78a11f9._comment deleted file mode 100644 index 754e875a5f..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_6_bb6c572eb9b9d5d435bdb6eeb78a11f9._comment +++ /dev/null @@ -1,37 +0,0 @@ -[[!comment format=mdwn - username="stefankangas@2fc5a0baba35168e9f9b5b72d5204558fd964c32" - nickname="stefankangas" - avatar="http://cdn.libravatar.org/avatar/5bef54a6599375e6bfe9da041e04b588" - subject="Same issue on OSX / git-annex 6.20180807" - date="2018-10-01T12:49:27Z" - content=""" -I'm seeing the same issue on OSX when adding a \"Remote server\", using git-annex version 6.20180807. This is on a completely new repository that I've created in \"~/annex\", with no files in it. - -After clicking \"Combine repositories\", I get the following error: - - Internal Server Error - there is no available git remote named \"mydomain.example.com_annex\" - -Where mydomain.example.com is the address to my ssh server. - -The logs say: - - [2018-10-01 14:39:44.352157] main: starting assistant version 6.20180807 - [2018-10-01 14:39:44.416265] Cronner: You should enable consistency checking to protect your data. - (scanning...) [2018-10-01 14:39:44.670591] Watcher: Performing startup scan - (started...) - 01/Oct/2018:14:40:13 +0200 [Error#yesod-core] there is no available git remote named \"mydomain.example.com_annex\" @(yesod-core-1.4.37.3-2QxllzSqvdqJbUCjADwK0K:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:693:5) - -It does not matter if the remote repository has been created or not - I still see the same error. Also, my local \"~/annex\" git repository has a remote named \"mydomain.example.com_annex\": - - # git remote show mydomain.example.com_annex - mesg: ttyname failed: Inappropriate ioctl for device - * remote mydomain.example.com_annex - Fetch URL: ssh://skangas@mydomain.example.com/~/annex/ - Push URL: ssh://skangas@mydomain.example.com/~/annex/ - HEAD branch: (unknown) - Remote branch: - git-annex new (next fetch will store in remotes/mydomain.example.com_annex) - Local ref configured for 'git push': - git-annex pushes to git-annex (local out of date) -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_7_cc0b93a23da7fb9e1b3044f17e9fc3d2._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_7_cc0b93a23da7fb9e1b3044f17e9fc3d2._comment deleted file mode 100644 index 6f36b2b585..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_7_cc0b93a23da7fb9e1b3044f17e9fc3d2._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847" - nickname="marvin" - avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e" - subject="comment 7" - date="2018-10-25T10:23:49Z" - content=""" -i can reproduce this and struggle with it. i cant add any remote repo through the webapp. -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_8_4415e7897cca54e004f3cb06031753ae._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_8_4415e7897cca54e004f3cb06031753ae._comment deleted file mode 100644 index 794745a172..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_8_4415e7897cca54e004f3cb06031753ae._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 8""" - date="2018-10-29T19:36:51Z" - content=""" -Sorry for leaving such a bad bug unaddressed so long. (And in fact a -reversion since it used to work fine and I broke it about a month before -this bug was opened.) - -It's fixed now. - -Bear in mind that I have a backlog that is literally -over 400 items long and just can't get to everything promptly. -Unsure why I didn't notice one of the several followups in my -triage operations, other than the assistant being a ways down -my prority list and bug reports about it often being not detailed enough -and taking a lot of time to understand. If anyone would like to help -triage out important problems like this one that I may be missing, -that would be great. -"""]] diff --git a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_9_4081e8a2fa3899942f27a6fa356f9c63._comment b/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_9_4081e8a2fa3899942f27a6fa356f9c63._comment deleted file mode 100644 index 79ff0e2692..0000000000 --- a/doc/bugs/Can__39__t_add_remotes_through_the_web_assistant/comment_9_4081e8a2fa3899942f27a6fa356f9c63._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="andrew" - avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" - subject="comment 9" - date="2018-11-01T12:15:34Z" - content=""" -Thank you for fixing! - -|| If anyone would like to help triage out important problems like this one that I may be missing, that would be great. - -I can try. How would you like to receive this information? -"""]] diff --git a/doc/bugs/Can__39__t_compile_on_FreeBSD__58____Issues_with_System.Posix.Files.mdwn b/doc/bugs/Can__39__t_compile_on_FreeBSD__58____Issues_with_System.Posix.Files.mdwn deleted file mode 100644 index 79880b65e4..0000000000 --- a/doc/bugs/Can__39__t_compile_on_FreeBSD__58____Issues_with_System.Posix.Files.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -### Please describe the problem. - -git-annex can't compile on FreeBSD; specifically, the build fails due to issues with System.Posix.Files. - -### What steps will reproduce the problem? - -1. git clone git://git-annex.branchable.com/ git-annex -2. cd git-annex -3. stack setup -4. stack install - -### What version of git-annex are you using? On what operating system? - -git-annex HEAD. - -FreeBSD 11.1-RELEASE r321309 GENERIC amd64 - -### Please provide any additional information below. - -Let me know if you'd like me to set up a FreeBSD development environment for you to SSH into - happy to do that if it helps you in any way. - -Compilation failure is as follows: - - Configuring git-annex-6.20180807... - git-annex-6.20180807: build (exe) - Preprocessing executable 'git-annex' for git-annex-6.20180807... - [124 of 586] Compiling Utility.DirWatcher.Kqueue ( Utility/DirWatcher/Kqueue.hs, .stack-work/dist/x86_64-freebsd/Cabal-1.24.2.0/build/git-annex/git-annex-tmp/Utility/Di - rWatcher/Kqueue.o ) - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:112:49: error: - Not in scope: ‘Files.openFd’ - Module ‘System.Posix.Files’ does not export ‘openFd’. - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:112:66: error: - Not in scope: data constructor ‘Files.ReadOnly’ - Module ‘System.Posix.Files’ does not export ‘ReadOnly’. - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:112:89: error: - Not in scope: ‘Files.defaultFileFlags’ - Module ‘System.Posix.Files’ does not export ‘defaultFileFlags’. - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:132:15: error: - Not in scope: ‘Files.closeFd’ - Module ‘System.Posix.Files’ does not export ‘closeFd’. - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:170:14: error: - Not in scope: ‘Files.closeFd’ - Module ‘System.Posix.Files’ does not export ‘closeFd’. - - -- While building custom Setup.hs for package git-annex-6.20180807 using: - /usr/home/duncan/code/git-annex/.stack-work/dist/x86_64-freebsd/Cabal-1.24.2.0/setup/setup --builddir=.stack-work/dist/x86_64-freebsd/Cabal-1.24.2.0 build exe:git - -annex --ghc-options " -ddump-hi -ddump-to-file" - Process exited with code: ExitFailure 1 - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Can__39__t_compile_on_FreeBSD__58____Issues_with_System.Posix.Files/comment_1_c8d41357ea9d0ac4601e066982058545._comment b/doc/bugs/Can__39__t_compile_on_FreeBSD__58____Issues_with_System.Posix.Files/comment_1_c8d41357ea9d0ac4601e066982058545._comment deleted file mode 100644 index b10cc24762..0000000000 --- a/doc/bugs/Can__39__t_compile_on_FreeBSD__58____Issues_with_System.Posix.Files/comment_1_c8d41357ea9d0ac4601e066982058545._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-09-24T15:24:30Z" - content=""" -Seems it also needs to import System.Posix.IO, which I've now committed. -"""]] diff --git a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail.mdwn b/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail.mdwn deleted file mode 100644 index afcf23be64..0000000000 --- a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail.mdwn +++ /dev/null @@ -1,72 +0,0 @@ -### Please describe the problem. - -git-annex won't compile on FreeBSD 12.0. - -### What steps will reproduce the problem? - -[[!format txt """ -git clone git://git-annex.branchable.com/ /tmp/git-annex -cd /tmp/git-annex -stack setup -stack install -"""]] - -### What version of git-annex are you using? On what operating system? - -git-annex HEAD, on FreeBSD 12.0. stack Version 1.7.1 x86_64. The Glorious Glasgow Haskell Compilation System, version 8.4.3. - -### Please provide any additional information below. - -[[!format txt """ -clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] -clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] -stack will use a sandboxed GHC it installed -For more information on paths, see 'stack path' and 'stack exec env' -To use this GHC and packages outside of a project, consider using: -stack ghc, stack ghci, stack runghc, or stack exec -IfElse-0.85: configure -SafeSemaphore-0.10.1: configure -StateVar-1.1.1.1: configure -alex-3.2.4: configure - --- While building custom Setup.hs for package alex-3.2.4 using: - /root/.stack/setup-exe-cache/x86_64-freebsd/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4 --builddir=.stack-work/dist/x86_64-freebsd/Cabal-2.2.0.1 configure --with-ghc=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc --with-ghc-pkg=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/pkgdb --libdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/lib --bindir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/bin --datadir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/share --libexecdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/libexec --sysconfdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/etc --docdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/alex-3.2.4 --htmldir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/alex-3.2.4 --haddockdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/alex-3.2.4 --dependency=array=array-0.5.2.0 --dependency=base=base-4.11.1.0 --dependency=containers=containers-0.5.11.0 --dependency=directory=directory-1.3.1.5 - Process exited with code: ExitFailure 1 - Logs have been written to: /tmp/git-annex/.stack-work/logs/alex-3.2.4.log - - Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4: No cabal file found. - Please create a package description file .cabal - - --- While building custom Setup.hs for package StateVar-1.1.1.1 using: - /root/.stack/setup-exe-cache/x86_64-freebsd/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4 --builddir=.stack-work/dist/x86_64-freebsd/Cabal-2.2.0.1 configure --with-ghc=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc --with-ghc-pkg=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/pkgdb --libdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/lib --bindir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/bin --datadir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/share --libexecdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/libexec --sysconfdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/etc --docdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/StateVar-1.1.1.1 --htmldir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/StateVar-1.1.1.1 --haddockdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/StateVar-1.1.1.1 --dependency=base=base-4.11.1.0 --dependency=stm=stm-2.4.5.1 --dependency=transformers=transformers-0.5.5.0 - Process exited with code: ExitFailure 1 - Logs have been written to: /tmp/git-annex/.stack-work/logs/StateVar-1.1.1.1.log - - Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4: No cabal file found. - Please create a package description file .cabal - - --- While building custom Setup.hs for package SafeSemaphore-0.10.1 using: - /root/.stack/setup-exe-cache/x86_64-freebsd/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4 --builddir=.stack-work/dist/x86_64-freebsd/Cabal-2.2.0.1 configure --with-ghc=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc --with-ghc-pkg=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/pkgdb --libdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/lib --bindir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/bin --datadir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/share --libexecdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/libexec --sysconfdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/etc --docdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/SafeSemaphore-0.10.1 --htmldir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/SafeSemaphore-0.10.1 --haddockdir=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/doc/SafeSemaphore-0.10.1 --dependency=base=base-4.11.1.0 --dependency=containers=containers-0.5.11.0 --dependency=stm=stm-2.4.5.1 - Process exited with code: ExitFailure 1 - Logs have been written to: /tmp/git-annex/.stack-work/logs/SafeSemaphore-0.10.1.log - - Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4: No cabal file found. - Please create a package description file .cabal - - --- While building custom Setup.hs for package IfElse-0.85 using: - /root/.stack/setup-exe-cache/x86_64-freebsd/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4 --builddir=.stack-work/dist/x86_64-freebsd/Cabal-2.2.0.1 configure --with-ghc=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc --with-ghc-pkg=/root/.stack/programs/x86_64-freebsd/ghc-8.4.4/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/root/.stack/snapshots/x86_64-freebsd/lts-12.19/8.4.4/pkgdb --package-db=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/pkgdb --libdir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/lib --bindir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/bin --datadir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/share --libexecdir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/libexec --sysconfdir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/etc --docdir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/doc/IfElse-0.85 --htmldir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/doc/IfElse-0.85 --haddockdir=/tmp/git-annex/.stack-work/install/x86_64-freebsd/lts-12.19/8.4.4/doc/IfElse-0.85 --dependency=base=base-4.11.1.0 --dependency=mtl=mtl-2.2.2 - Process exited with code: ExitFailure 1 - Logs have been written to: /tmp/git-annex/.stack-work/logs/IfElse-0.85.log - - Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4: No cabal file found. - Please create a package description file .cabal -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! git-annex has been _very_ helpful for my personal website (see ), and was working like a charm on FreeBSD 11.2. - -> [[done]], not a bug in git-annex. --[[Joey]] diff --git a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_1_ec60a8b7fe91d62c60406315891c8811._comment b/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_1_ec60a8b7fe91d62c60406315891c8811._comment deleted file mode 100644 index 69fc119b27..0000000000 --- a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_1_ec60a8b7fe91d62c60406315891c8811._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-01-01T16:08:20Z" - content=""" -This is a failure installing depedencies of git-annex, and it looks kind of -like your cabal or haskell toolchain is broken. - -This is not a bug in git-annex. -"""]] diff --git a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_2_7159525b300cd606bf445d5204edd95b._comment b/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_2_7159525b300cd606bf445d5204edd95b._comment deleted file mode 100644 index 7f68a5d77b..0000000000 --- a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_2_7159525b300cd606bf445d5204edd95b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="duncan_bayne" - avatar="http://cdn.libravatar.org/avatar/2fc23e2009234ad965f9d5d796400417" - subject="Thanks" - date="2019-01-01T22:26:45Z" - content=""" -Thanks joey; I'll follow up w/ the FreeBSD folks. Sounds like a problem with the port. -"""]] diff --git a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_3_d752f3bae244af1bb06741cfb31d46c2._comment b/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_3_d752f3bae244af1bb06741cfb31d46c2._comment deleted file mode 100644 index fd24343664..0000000000 --- a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_3_d752f3bae244af1bb06741cfb31d46c2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="duncan_bayne" - avatar="http://cdn.libravatar.org/avatar/2fc23e2009234ad965f9d5d796400417" - subject="Bug raised" - date="2019-01-08T21:13:38Z" - content=""" -I've raised this with the maintainers of the Haskell toolchain on FreeBSD, and will post updates here. -"""]] diff --git a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_4_7030999ed483c680a80225a26a051b78._comment b/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_4_7030999ed483c680a80225a26a051b78._comment deleted file mode 100644 index 4faaebf393..0000000000 --- a/doc/bugs/Can__39__t_compile_on_FreeBSD__58___alex__44___StateVar__44___SafeSemaphore__44___IfElse_fail/comment_4_7030999ed483c680a80225a26a051b78._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="duncan_bayne" - avatar="http://cdn.libravatar.org/avatar/2fc23e2009234ad965f9d5d796400417" - subject="Known issue" - date="2019-01-09T09:17:20Z" - content=""" -This is a known issue, and is being fixed: https://github.com/commercialhaskell/stack/issues/3515 -"""]] diff --git a/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature.mdwn b/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature.mdwn deleted file mode 100644 index d5b8e27fad..0000000000 --- a/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature.mdwn +++ /dev/null @@ -1,57 +0,0 @@ -### Please describe the problem. -If a v6 submodule is using an adjusted branch, `git annex adjust --unlock` fails in its superproject. - -### What steps will reproduce the problem? -[[!format sh """ -#!/bin/bash - -set -ex -d=$(mktemp -d) -echo "directory: $d" -cd $d -git init -git annex init --version=6 -echo whatever > file -git annex add file -git commit -m "file added" -mkdir sub -cd sub -git init -git annex init --version=6 -echo something > subfile -git annex add subfile -git commit -m "subfile added." -cd .. -git submodule add ./sub sub -git commit -m "submodule added" -cd sub -git annex adjust --unlock -cd .. -git annex adjust --unlock - -"""]] -### What version of git-annex are you using? On what operating system? -[[!format sh """ -% git annex version -git-annex version: 6.20170209+gitg16be7b5cc-1~ndall+1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: unknown -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -"""]] - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature/comment_1_176faba802ecd62b04c06c6dab77f5f3._comment b/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature/comment_1_176faba802ecd62b04c06c6dab77f5f3._comment deleted file mode 100644 index 76e0c78143..0000000000 --- a/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature/comment_1_176faba802ecd62b04c06c6dab77f5f3._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-02-20T17:13:54Z" - content=""" -Error message is: - - git-annex: unexpected object type "comm" - -What it's actually choking on is the "commit" object for the submodule, -in git-ls-tree output. Doesn't matter if the submodule uses -adjusted branches or not. - -The parser for ls-tree output is buggy; -it's expecting only "blob" and "tree", so pulls out a fixed width 4 -characters: "comm" - -Also, the adjusted branch code needs to be made to skip over CommitObjects, -once the parser is fixed to generate them. -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1.mdwn b/doc/bugs/Cannot_build_with_GHC_8.2.1.mdwn deleted file mode 100644 index 4fa9e18ab9..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1.mdwn +++ /dev/null @@ -1,51 +0,0 @@ -### Please describe the problem. -git-annex cannot build with GHC 8.2.1 - -### What steps will reproduce the problem? -cabal install --jobs=8 --max-backjumps=100000 --only-dependencies --flags=s3\ webapp - -### What version of git-annex are you using? On what operating system? -Tested with 6.20170520 and HEAD at a983877279d5157d4e7a8c2397d9e541e3c41fa6 - -### Please provide any additional information below. -Discovered during https://github.com/Homebrew/homebrew-core/pull/15934 - -[[!format sh """ -==> cabal install --jobs=8 --max-backjumps=100000 --only-dependencies --flags=s3 webapp -clang: warning: -Wl,-headerpad_max_install_names: 'linker' input unused -clang: warning: argument unused during compilation: '-L/usr/local/opt/gettext/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/libffi/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/readline/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/sqlite/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/openssl/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/icu4c/lib' -clang: warning: argument unused during compilation: '-L/usr/local/lib' -clang: warning: argument unused during compilation: '-L/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries' -Resolving dependencies... -cabal: Could not resolve dependencies: -trying: git-annex-6.20170520 (user goal) -trying: base-4.10.0.0/installed-4.1... (dependency of git-annex-6.20170520) -next goal: sandi (dependency of git-annex-6.20170520) -rejecting: sandi-0.4.0 (conflict: base==4.10.0.0/installed-4.1..., sandi => -base>=4.7 && <4.10) -rejecting: sandi-0.3.6, sandi-0.3.5 (conflict: -base==4.10.0.0/installed-4.1..., sandi => base>=4.7 && <4.9) -rejecting: sandi-0.3.4 (conflict: base==4.10.0.0/installed-4.1..., sandi => -base==4.8.*) -rejecting: sandi-0.3.3, sandi-0.3.2, sandi-0.3.1 (conflict: -base==4.10.0.0/installed-4.1..., sandi => base==4.7.*) -rejecting: sandi-0.3.0.1 (conflict: base==4.10.0.0/installed-4.1..., sandi => -base==4.6.* || ==4.7.*) -rejecting: sandi-0.3.0 (conflict: base==4.10.0.0/installed-4.1..., sandi => -base==4.7.*) -rejecting: sandi-0.2.3, sandi-0.2.2.1, sandi-0.2.2, sandi-0.2.1 (conflict: -base==4.10.0.0/installed-4.1..., sandi => base>=4.5 && <4.7) -rejecting: sandi-0.2, sandi-0.1.1, sandi-0.1 (conflict: -base==4.10.0.0/installed-4.1..., sandi => base==4.6.*) -Dependency tree exhaustively searched. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes :) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_1_ffd824d79ec303d35b83255f0417d23a._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_1_ffd824d79ec303d35b83255f0417d23a._comment deleted file mode 100644 index a13fb0faab..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_1_ffd824d79ec303d35b83255f0417d23a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-07-28T13:05:38Z" - content=""" -I don't see any git-annex failure to build here. Cabal is failing to -install sandi, a dependency. That package needs to have its dependency on -base updated to allow building with the new ghc. Quite likely simply -adjusting the dependency version will work. -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_2_0796d1dfcf7116c38451febb9701c857._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_2_0796d1dfcf7116c38451febb9701c857._comment deleted file mode 100644 index cf83cd991d..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_2_0796d1dfcf7116c38451febb9701c857._comment +++ /dev/null @@ -1,67 +0,0 @@ -[[!comment format=mdwn - username="ilovezfs" - avatar="http://cdn.libravatar.org/avatar/f2b3954cf2ed0a551de9a49d3b6a64d0" - subject="pipe: resource exhausted (Too many open files)" - date="2017-07-30T16:05:10Z" - content=""" -Hi Joey, - -Yes, I can work around that particular failure by tweaking constraints. - -In particular, ---allow-newer=\"sandi:base\" --allow-newer=\"aws:time\" - -I also first need to \"cabal install Cabal<1.25\" because git-annex seems -to have a compatibility problem with Cabal-2.0.0.2. The error with -Cabal-2.0.0.2 is - -[[!format sh \"\"\" -Building executable 'git-annex' for git-annex-6.20170520.. - -Build/BuildVersion.hs:1:1: error: - File name does not match module name: - Saw: ‘Main’ - Expected: ‘Build.BuildVersion’ - | -1 | {- Outputs the version of git-annex that was built, for use by - | ^ -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-6.20170520-3mbb3kAWTlXI0EMervIo66 failed during the building phase. -The exception was: -ExitFailure 1 -\"\"\"]] - -But, once I've installed the lower version of Cabal, and tweaked the -constraints for sandi and for aws, git-annex does build successfully. - -However, at that point a more serious issue comes up when I run \"git -annex test\" and here is the full log: -https://gist.github.com/ilovezfs/d430f589d87d7f7237591cd51b2b94cb - -Here is a snippet: -[[!format sh \"\"\" -From ../../.t/tmprepo53 - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master - * [new branch] synced/master -> r2/synced/master -conflictor/subfile -conflictor.variant-cc12 -conflictor/subfile -conflictor.variant-cc12 -OK (3.27s) - conflict resolution symlink bit: OK - conflict resolution (uncommitted local file): FAIL (0.49s) - sync failed in r1 - conflict resolution (removed file): FAIL - Exception: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files) - conflict resolution (nonannexed file): FAIL - Exception: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files) - conflict resolution (nonannexed symlink): FAIL (0.03s) - git annex init failed - conflict resolution (mixed locked and unlocked file): FAIL - Exception: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files) - map: FAIL - Exception: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files) -\"\"\"]] -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_3_c43f26b71cd7335951fb71f68b84ed10._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_3_c43f26b71cd7335951fb71f68b84ed10._comment deleted file mode 100644 index 6aada30f91..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_3_c43f26b71cd7335951fb71f68b84ed10._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-08-01T16:18:18Z" - content=""" -The cabal bug is , -and it seems like it would require *extensive* changes to git-annex's -source code to work around this cabal behavior. -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_4_f508b6db0513edcdc8600df405ce1913._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_4_f508b6db0513edcdc8600df405ce1913._comment deleted file mode 100644 index 7e277efd69..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_4_f508b6db0513edcdc8600df405ce1913._comment +++ /dev/null @@ -1,41 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~felixonmars" - nickname="felixonmars" - avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38" - subject="comment 4" - date="2017-08-17T19:10:24Z" - content=""" -I managed to build git-annex with GHC 8.2.1 on Linux by removing a bunch of Win32/OSX modules from the cabal file and another small fix. However, there are two test failures when running git-annex test. Do you think it's related to the GHC version? - - Tests - QuickCheck - prop_isomorphic_deencode_git: FAIL - *** Failed! Falsifiable (after 6 tests and 1 shrink): - \"\1086483\" - Use --quickcheck-replay=615269 to reproduce. - prop_isomorphic_deencode: FAIL - *** Failed! Falsifiable (after 3 tests and 1 shrink): - \"\185545\" - Use --quickcheck-replay=915399 to reproduce. - ... - 2 out of 293 tests failed (486.80s) - (This could be due to a bug in git-annex, or an incompatibility - with utilities, such as git, installed on this system.) - - -All other tests are working, though. - -Versions: - - $ git --version - git version 2.14.1 - - $ git-annex version - git-annex version: 6.20170612-ge4100fd60 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.24 DAV-1.3.1 feed-0.3.12.0 ghc-8.2.1 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -The changes to build: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/git-annex&id=e75ed0bdf9748df000aa584e0ebff3b7d56b76d6 -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_5_a0663aeef21b09393600593409f1a7a9._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_5_a0663aeef21b09393600593409f1a7a9._comment deleted file mode 100644 index 93d4a11753..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_5_a0663aeef21b09393600593409f1a7a9._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2017-08-17T19:12:09Z" - content=""" -Thanks for working on this! - -It's entirely possible that the quickcheck tests happen to generate -better test data under the new ghc, and have found an actual bug. -I doubt that it's related to your changes. - -I do need git-annex to remain buildable on OSX and Windows. What basically -needs to be done is, instead of sed-ing those files out of the cabal file, -make the cabal file say "if os(windows)" to conditionally include the -modules that only work on one OS. -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_6_e948c8fcf34559808726aaa0d5f5f020._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_6_e948c8fcf34559808726aaa0d5f5f020._comment deleted file mode 100644 index ee4b88feb4..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_6_e948c8fcf34559808726aaa0d5f5f020._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2017-08-18T15:02:42Z" - content=""" -I've updated the cabal file, it should build now. Although unfortunately -the breaking changes to cabal are such that it might still fail to build -with some OS's and some combinations of build flags, where it used to build -before. I only tested on Linux with stack (modified for resolver: -nightly-2017-08-17) - -As to the quickcheck failures, I think that's the same problem I already -fixed in [[!commit da8e84efe997fcbfcf489bc4fa9cc835ed131d3a]]. -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_7_bd5b764715a9a7c35921803d534a9989._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_7_bd5b764715a9a7c35921803d534a9989._comment deleted file mode 100644 index ebc05ffecc..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_7_bd5b764715a9a7c35921803d534a9989._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="ilovezfs" - avatar="http://cdn.libravatar.org/avatar/f2b3954cf2ed0a551de9a49d3b6a64d0" - subject="Exception: getCurrentDirectory:getWorkingDirectory: resource exhausted (Too many open files)" - date="2017-08-18T18:28:01Z" - content=""" -Thanks! 6.20170818 does build with Cabal 2.0.0. However, I'm still seeing the too many open files error. -The log is here: https://gist.github.com/ilovezfs/5dabc76086ba4b028b1eae7f301a5219 -"""]] diff --git a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_8_329e8eb873ca684dc3221b462827ecd5._comment b/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_8_329e8eb873ca684dc3221b462827ecd5._comment deleted file mode 100644 index 183ec3bbc2..0000000000 --- a/doc/bugs/Cannot_build_with_GHC_8.2.1/comment_8_329e8eb873ca684dc3221b462827ecd5._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 8""" - date="2017-10-02T16:36:40Z" - content=""" -The git-annex test FD leak is now fixed. -"""]] diff --git a/doc/bugs/Cannot_build_with_aws_0.17.1.mdwn b/doc/bugs/Cannot_build_with_aws_0.17.1.mdwn deleted file mode 100644 index 3a3a528947..0000000000 --- a/doc/bugs/Cannot_build_with_aws_0.17.1.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -### Please describe the problem. -git-annex doesn't build if the aws dependency is version 0.17.1 - -This probably wasn't caught during your testing because the stack.yaml is currently set to use aws-0.16. - -### What steps will reproduce the problem? -cabal install with --flags=s3\ webapp - -### What version of git-annex are you using? On what operating system? -6.20171003 on macOS - -### Please provide any additional information below. - -The error is - -[[!format sh """ -[327 of 580] Compiling Remote.Helper.Http ( Remote/Helper/Http.hs, dist/dist-sandbox-69bd6735/build/git-annex/git-annex-tmp/Remote/Helper/Http.o ) -[328 of 580] Compiling Remote.WebDAV ( Remote/WebDAV.hs, dist/dist-sandbox-69bd6735/build/git-annex/git-annex-tmp/Remote/WebDAV.o ) -[329 of 580] Compiling Remote.S3 ( Remote/S3.hs, dist/dist-sandbox-69bd6735/build/git-annex/git-annex-tmp/Remote/S3.o ) - -Remote/S3.hs:501:57: error: - • Couldn't match expected type ‘AWS.Configuration’ - with actual type ‘Maybe - http-client-0.5.7.0:Network.HTTP.Client.Types.Proxy - -> AWS.Configuration’ - • Probable cause: ‘awscfg’ is applied to too few arguments - In the second argument of ‘S3Handle’, namely ‘awscfg’ - In the second argument of ‘($)’, namely ‘S3Handle mgr awscfg s3cfg’ - In the second argument of ‘($)’, namely - ‘Just $ S3Handle mgr awscfg s3cfg’ - | -501 | a $ Just $ S3Handle mgr awscfg s3cfg - | ^^^^^^ -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-6.20171003-5GFRliFOEl0KqDuhwYRTdH failed during the building phase. -The exception was: -ExitFailure 1 -"""]] - -Full build log is here: https://gist.github.com/ilovezfs/661a158dbe8aac33802f9b43eb150539 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! :) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Cannot_build_with_aws_0.17.1/comment_1_937238ba11540f1ee9ba8de621277b2f._comment b/doc/bugs/Cannot_build_with_aws_0.17.1/comment_1_937238ba11540f1ee9ba8de621277b2f._comment deleted file mode 100644 index d22c31e9c4..0000000000 --- a/doc/bugs/Cannot_build_with_aws_0.17.1/comment_1_937238ba11540f1ee9ba8de621277b2f._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~felixonmars" - nickname="felixonmars" - avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38" - subject="comment 1" - date="2017-10-05T14:02:03Z" - content=""" -My humble workaround: - - sed -i 's/let awscfg = AWS.Configuration AWS.Timestamp awscreds debugMapper$/let awscfg = AWS.Configuration AWS.Timestamp awscreds debugMapper Nothing/ ' Remote/S3.hs -"""]] diff --git a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn deleted file mode 100644 index 3dc28d4e6e..0000000000 --- a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -### Please describe the problem. -Issue uploading to S3 remote (Dreamhost) - -### What steps will reproduce the problem? -git-annex copy massart/f16_Web1/screencaptures/IMG_5159.MOV --to=cloud -on my repo - -### What version of git-annex are you using? On what operating system? -6.20161031-g0a58e94 -OS-X 10.11.6 - -### Please provide any additional information below. -I am using a different WIFI I haven't used before. Maybe it is blocking something… - -[[!format sh """ -git-annex copy massart/f16_Web1/screencaptures/IMG_5159.MOV --to=cloud -copy massart/f16_Web1/screencaptures/IMG_5159.MOV (checking cloud...) (to cloud...) -17% 0.0 B/s 0sgpg: error running `/Users/joey/homebrew/opt/gpg-agent/bin/gpg-agent': probably not installed -gpg: DBG: running `/Users/joey/homebrew/opt/gpg-agent/bin/gpg-agent' for testing failed: Configuration error -gpg: can't connect to the agent: IPC connect call failed -gpg: problem with the agent: No agent running -35% 1021.8KB/s 30s - user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","26","--symmetric","--force-mdc","--no-textmode"] exited 2) -failed -git-annex: copy: 1 failed -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes. - -[[done]] diff --git a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment deleted file mode 100644 index 02b62f46e8..0000000000 --- a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="andrew" - avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" - subject="RESOLVED" - date="2016-11-17T14:59:15Z" - content=""" -Ooops. I am on OS-X. I use brew for my gnupg installation. It appears I had removed gpg from the path when installing something. I just needed to run to fix: - - brew link gnupg2 - -Thanks, - -Andrew -"""]] diff --git a/doc/bugs/Default_startup_command.mdwn b/doc/bugs/Default_startup_command.mdwn deleted file mode 100644 index 2c16868c6b..0000000000 --- a/doc/bugs/Default_startup_command.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -[[!meta title="Android Default startup command"]] - -### Please describe the problem. -On a CM11 4.4.4 install, the startup will fail with the default startup command "git annex webapp". -The error message shown is: -``` -Falling back to hardcoded app location; cannot find expected files in /data/app-lib -git annex webapp -``` - -However, using "git-annex webapp", git-annex will run fine. - -### What steps will reproduce the problem? - -Launch the beta or nightly build for 4.3 and 4.4, wait for error message - -### What version of git-annex are you using? On what operating system? - -Version "current" as of 2014-11-15 and also version "nightly build" as of 2014-11-15 on Android 4.4.4 CM11, device: Oppo Find 7a - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/Default_startup_command/comment_1_2d63fb301586c9a97ceff1d1b9fafbee._comment b/doc/bugs/Default_startup_command/comment_1_2d63fb301586c9a97ceff1d1b9fafbee._comment deleted file mode 100644 index 47487f01a2..0000000000 --- a/doc/bugs/Default_startup_command/comment_1_2d63fb301586c9a97ceff1d1b9fafbee._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="git-annex@53a027ebda399714df9272a135f22ac774f3c9f1" - nickname="git-annex" - subject="i can second this" - date="2015-07-26T10:29:32Z" - content=""" -I have the same behaviour on CM11 4.4.4 on a Moto G as well. -When i installed git annex i would be greeted by the same message, but then could start the webapp from the menu successfully. -i then proceeded to setup my repo, which synced flawlessly, if i had started the webapp as stated above. -however my files were never automatically synced when just starting the app (terminal window). - -Therefore i resorted to \"cd\" to my repo and \"git annex add *\" and \"git annex sync --content\" every time i wanted to sync. - -i tried changing the startup command to \"git annex assistant --autostart\", \"git annex assistant --autostart --foreground\", \"cd ../DCIM;git annex sync --content\", \"echo test\" but nothing seems to start (not quite sure how to check for that). - -for my shell i had the default/data/data/ga.androidterm/lib/lib.start.so and /data/data/ga.androidterm/runshell if that makes any difference? - -not sure if that's related -when trying to manually invoke \"git annex --assistant [--foreground]\" i get: - - git annex autostart in /sdcard/DCIM - usage: ionice [none|rt|be|idle] [prio] - failed - -and back to prompt. Not sure if this is CM(11) only? - -my git annex version is: 5.20150527-gfc92f13 for android 4.3 and 4.4. if you need more information i'll be happy to provide it, to get this out of the way :D - -"""]] diff --git a/doc/bugs/Default_startup_command/comment_2_296de7f38161ebc21da954d46c924c98._comment b/doc/bugs/Default_startup_command/comment_2_296de7f38161ebc21da954d46c924c98._comment deleted file mode 100644 index af5cfc44db..0000000000 --- a/doc/bugs/Default_startup_command/comment_2_296de7f38161ebc21da954d46c924c98._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="git-annex@53a027ebda399714df9272a135f22ac774f3c9f1" - nickname="git-annex" - subject="small correction to the above" - date="2015-07-26T10:33:28Z" - content=""" -i can not start the webapp via the menu (firefox opens but cant connect to the webapp) but if i do git annex webapp manually in the terminal it works as expected -"""]] diff --git a/doc/bugs/Default_startup_command/comment_3_f388be6121f3449f28aa3d6ca53fa88d._comment b/doc/bugs/Default_startup_command/comment_3_f388be6121f3449f28aa3d6ca53fa88d._comment deleted file mode 100644 index eda3046276..0000000000 --- a/doc/bugs/Default_startup_command/comment_3_f388be6121f3449f28aa3d6ca53fa88d._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-05-08T18:54:32Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__.mdwn b/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__.mdwn deleted file mode 100644 index 7c48be0e39..0000000000 --- a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. -git-annex doesn't start. - -### What steps will reproduce the problem? -launch git-annex from terminal (if it is ran from GUI it doesn't open without notifying any error) - -### What version of git-annex are you using? On what operating system? -Version: 6.20171128-g58b04cd2e on OS X 10.13.1 (17B1003) - -### Please provide any additional information below. -I solved the issue by manually changing the file /Applications/git-annex.app/Contents/MacOS/bundle/B which is an alias pointing to the file /Applications/git-annex.app/Contents/MacOS/bundle/usr/lib/libz.1.dylib with a new alias having the same name 'B' which link to /usr/lib/libz.1.dylb. -I'm pretty sure this is not an optimal and general solution, but it is useful in order to prove what's the problem. Further, for it worked. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -dyld: Symbol not found: _inflateValidate - Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib - Expected in: /Applications/git-annex.app/Contents/MacOS/bundle/B - in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib -Abort trap: 6 - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -> OSX autobuild is updated and no longer contains the copy of libz. -> [[done]] diff --git a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_1_0f013027500f03b52e021716e493fbff._comment b/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_1_0f013027500f03b52e021716e493fbff._comment deleted file mode 100644 index c6784f79b4..0000000000 --- a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_1_0f013027500f03b52e021716e493fbff._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="rameshvenk" - avatar="http://cdn.libravatar.org/avatar/185911818a3eb3795072b1aa1256449c" - subject="dyld: Symbol not found: _inflateValidate" - date="2018-03-04T03:59:42Z" - content=""" -Can confirm that this fix did resolve the issue. My version of git annex is as follows - -git-annex version: 6.20180226-g15a11fedf - -running on 10.13.3 -"""]] diff --git a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_2_e15b265d67cad6fb914f626e646c2fe7._comment b/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_2_e15b265d67cad6fb914f626e646c2fe7._comment deleted file mode 100644 index ebf5867e25..0000000000 --- a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_2_e15b265d67cad6fb914f626e646c2fe7._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-03-05T14:40:08Z" - content=""" -This is a bit puzzling, since git-annex does not link to libpng. - -I think what must be going on os that Cocoa, which git-annex does link to, -links to libpng. - -The dmg contains its own copy of zlib, not for git-annex, -which does not directly link to it, but for the embedded copy of curl. -But the linker is told to prefer the bundled libraries, so it tries to use -the bundled zlib with Cocoa. - -Upgrading the OSX autobuilder to 10.13 would be the cleanest fix, but -installing a newer zlib on there with homebrew should also work. -Hmm, but I tried homebrew and their zlib does not contain the -`_inflateValidate` symbol. -"""]] diff --git a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_3_1346c5aa68b06d512aced0ef72cc92fc._comment b/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_3_1346c5aa68b06d512aced0ef72cc92fc._comment deleted file mode 100644 index cd256b8e4c..0000000000 --- a/doc/bugs/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/comment_3_1346c5aa68b06d512aced0ef72cc92fc._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-03-22T15:52:04Z" - content=""" -I've excluded libz.1.dylb from git-annex.apk, on the assumuption that OSX -always ships with libz, and so git-annex does not need to provide it. -"""]] diff --git a/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn b/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn deleted file mode 100644 index b7b3ec4900..0000000000 --- a/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -### Please describe the problem. - -Opening the Android app, the following message is shown: - - referenceTable GDEF length=778 - referenceTable GSUB length=6388 - referenceTable GPOS length=76868 - - [Terminal session finished] - -I am not able to use git-annex. Trying to open a new window in git-annex, I get similar errors: - - [Terminal session finished] - referenceTable GDEF length=778 1 - referenceTable GSUB length=6388 1 - referenceTable GPOS length=76868 1 - referenceTable head length=54 1 - referenceTable GDEF length=670 - referenceTable GSUB length=7168 - referenceTable GPOS length=24560 - referenceTable head length=54 1 - git annex webapp - - -### What steps will reproduce the problem? - -Download the most recent Android 5.0 app (I tried both [[http://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk]] and [[http://downloads.kitenet.net/git-annex/autobuild/android/5.0/git-annex.apk]]). -Install it and open it. - -### What version of git-annex are you using? On what operating system? - -OS: Android 5.1.1. -git-annex: I tried the currently available stable 5.0 package (6.20170101), as well as the nightly build one (it shows version 6.20170102). - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, I used it successfully until recently. I remember that I installed a new version of git-annex recently. I used it successfully after the update. However, I am not sure whether I closed and reopened the git-annex app after the update. - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868/comment_1_0014a7f4cf8d3c39b96bfb93c906c93f._comment b/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868/comment_1_0014a7f4cf8d3c39b96bfb93c906c93f._comment deleted file mode 100644 index a5da7d13dd..0000000000 --- a/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868/comment_1_0014a7f4cf8d3c39b96bfb93c906c93f._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:45:59Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows.mdwn b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows.mdwn deleted file mode 100644 index 4c6c85e514..0000000000 --- a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -### Please describe the problem. - -Getting a file with a long name on Windows fails due to doubling the size of the path in the "misctmp" directory. - -### What steps will reproduce the problem? - -``` -get [Connectivity and Thought - The Influence of Semantic Network Structure in a Neurodynamical Model of Thinking] marupaka_creativity_NN12.pdf (from origin...) -SHA256-s588307--41bf10d5c3a924808c6219395758354d7b6c4ff0a75e0d1a90e798fac015536c - 588,307 100% 670.38kB/s 0:00:00 (xfr#1, to-chk=0/1) -(checksum...) -git-annex: MoveFileEx "..\\..\\.git\\annex\\tmp\\SHA256-s588307--41bf10d5c3a924808c6219395758354d7b6c4ff0a75e0d1a90e798fac015536c" "..\\..\\.git\\annex\\misctmp\\[Connectivity and Thought - The Influence of Semantic Network Structure in a Neurodynamical Model of Thinking] marupaka_creativ.0\\[Connectivity and Thought - The Influence of Semantic Network Structure in a Neurodynamical Model of Thinking] marupaka_creativ": does not exist (The system cannot find the path specified.) -failed -git-annex: get: 1 failed -``` - -Note that the second argument to MoveFileEx is longer than 256 characters, because the name of the file gets doubled for the temp directory. - - -### What version of git-annex are you using? On what operating system? - -``` -git-annex version: 6.20160427-gd0036b9 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV ConcurrentOutput TorrentParser Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 5 6 -upgrade supported from repository versions: 2 3 4 5 -``` - -OS: Windows 10 - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, managing 30000 files, on operating systems other than Windows though... - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_1_fafaff54e55e0b82df52656d8afb1c3e._comment b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_1_fafaff54e55e0b82df52656d8afb1c3e._comment deleted file mode 100644 index b672dea8a7..0000000000 --- a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_1_fafaff54e55e0b82df52656d8afb1c3e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-06T16:46:22Z" - content=""" -Thanks for reporting this. I can't fix all the too long path problems -on windows currently, but I can fix this particular one at least. -"""]] diff --git a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment deleted file mode 100644 index 7ba0734027..0000000000 --- a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="kubaello@d561f15ff5c07a78b706b096375cd89d6d706066" - nickname="kubaello" - avatar="http://cdn.libravatar.org/avatar/df2d1d9871b92552b99c3bacf442d739" - subject="comment 2" - date="2017-03-16T01:22:44Z" - content=""" -I came across the same problem today and I think I've found a workaround: [long paths on windows 10 - workaround](https://git-annex.branchable.com/forum/long_paths_on_windows_10_-_workaround/). It turns out Windows 10 allows enabling support for long paths with a single registry modification - unfortunately it is a system level setting, so it can potentially break some other programs. -"""]] diff --git a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_3_a3ca2004c5a0cb594448d6e4f081c4fb._comment b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_3_a3ca2004c5a0cb594448d6e4f081c4fb._comment deleted file mode 100644 index e9a1469553..0000000000 --- a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_3_a3ca2004c5a0cb594448d6e4f081c4fb._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="cman122887@9badeb8bdb364090f0a22e00ba16426ad65c34c9" - nickname="cman122887" - avatar="http://cdn.libravatar.org/avatar/6b9d25d94633a5002be6fe34da1b97a0" - subject="similar?" - date="2019-02-27T02:47:56Z" - content=""" -Hello! - -I think I am getting something similar, but I can't quite tell: - -git-annex: MoveFileEx \".git\\annex\\tmp\\SHA256E-s555--205ac67c0c3fdc7cbe48007246dd0642dda416a57e8604b241cebfd6d83fb00a.txt\" Just \".git\\annex\\objects\\510\\441\\SHA256E-s555--205ac67c0c3fdc7cbe48007246dd0642dda416a57e8604b241cebfd6d83fb00a.txt\\SHA256E-s555--205ac67c0c3fdc7cbe48007246dd0642dda416a57e8604b241cebfd6d83fb00a.txt\": does not exist (The system cannot find the path specified.) - -This might just be the plain long path issue but I thought I saw similarities in what I am getting and this post. - -Windows 10 - -Git for Win: 2.20.1 - -git-annex version: 7.20190219-g728228d5d - -... - -operating system: mingw32 i386 - -local repository version: 7 - -TIA for any advice you can bestow! -"""]] diff --git a/doc/bugs/Export_fails_for_files_directly_in_git_repo.mdwn b/doc/bugs/Export_fails_for_files_directly_in_git_repo.mdwn deleted file mode 100644 index 3d9a402ae4..0000000000 --- a/doc/bugs/Export_fails_for_files_directly_in_git_repo.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -### Please describe the problem. -I'm playing around with the new export function and it's working really fine so far. But just now I ran into problems when `git add`ing a file, see below. - -### What steps will reproduce the problem? - -[[!format sh """ - -$ echo test > file.txt -$ git add file.txt -$ git annex sync -commit -[master a05faa1] git-annex in lykos@**:/tmp/testrepo2 - 1 file changed, 1 insertion(+) - create mode 100644 file.txt -ok -$ git annex export --tracking master --to exp -export exp file.txt -git-annex: Sorry, this file cannot be stored on an external special remote because its key's name contains a space. To avoid this problem, you can run: git-annex migrate --backend=SHA1 and pass it the name of the file -failed -(recording state in git...) -git-annex: export: 1 failed - -"""]] - - -### What version of git-annex are you using? On what operating system? -6.20171026-g43d011a52 on Arch Linux - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Of course ;) All the time - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_1_0077e5e36896116059070e26143f03d0._comment b/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_1_0077e5e36896116059070e26143f03d0._comment deleted file mode 100644 index 7105d42aaa..0000000000 --- a/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_1_0077e5e36896116059070e26143f03d0._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-10-30T16:11:42Z" - content=""" -The limitation on spaces in key names only impacts -exporting to external special remotes, so "exp" must be some kind -of external special remote. (I was not aware of any that -supported exports yet..) - -I was able to reproduce this using an external special remote, -but not otherwise. -"""]] diff --git a/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_2_d98990c87e18b0dd99d78e3d136c4094._comment b/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_2_d98990c87e18b0dd99d78e3d136c4094._comment deleted file mode 100644 index a6b45f1174..0000000000 --- a/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_2_d98990c87e18b0dd99d78e3d136c4094._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="Lykos153" - avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2" - subject="comment 2" - date="2017-10-30T18:18:56Z" - content=""" -Thanks for your reply. I'm currently working on a python version of [git-annex-remote-gdrive](https://github.com/Lykos153/git-annex-remote-gdrive/tree/v2) and I just completed support for export. That's how I came across this issue. - - -"""]] diff --git a/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_3_dce8cbd3a216da6b4d09c2445b04d060._comment b/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_3_dce8cbd3a216da6b4d09c2445b04d060._comment deleted file mode 100644 index d2fdb3fa93..0000000000 --- a/doc/bugs/Export_fails_for_files_directly_in_git_repo/comment_3_dce8cbd3a216da6b4d09c2445b04d060._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-10-30T18:23:04Z" - content=""" -The problem is fixed in git-annex's master now. Thanks for working on the -special remote and for the testing! -"""]] diff --git a/doc/bugs/Exporting_subdirs_fails.mdwn b/doc/bugs/Exporting_subdirs_fails.mdwn deleted file mode 100644 index 9d21e0a942..0000000000 --- a/doc/bugs/Exporting_subdirs_fails.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -### Please describe the problem. -git annex won't export subdirectories claiming they don't exist. `git rev-parse` however, returns hashes for said directories which then are accepted by `git annex export`. - - -### What steps will reproduce the problem? - -[[!format sh """ -$ git annex export master:folder --to exp -fatal: Path 'folder:' does not exist in 'master' -git-annex: unknown tree -$ git rev-parse master:folder -943218c141ab2a315b533fa9f92fe610916b5d1b -$ git annex export 943218c141ab2a315b533fa9f92fe610916b5d1b --to exp -export exp testfile2 -ok -(recording state in git...) -"""]] - - -### What version of git-annex are you using? On what operating system? -git-annex version: 6.20171026-g43d011a52 on Arch Linux - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Exporting_subdirs_fails/comment_1_2113ddd317cd5d11cf1d7a56b30bb452._comment b/doc/bugs/Exporting_subdirs_fails/comment_1_2113ddd317cd5d11cf1d7a56b30bb452._comment deleted file mode 100644 index c3bddf2ffa..0000000000 --- a/doc/bugs/Exporting_subdirs_fails/comment_1_2113ddd317cd5d11cf1d7a56b30bb452._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-11-07T21:08:48Z" - content=""" -This got fixed in [[!commit 24883e01cd487feb1be95146811d65e4f240465d]], -the next release of git-annex will have the fix. -"""]] diff --git a/doc/bugs/GHC_8.4.3_build_failure_in_Types__47__DesktopNotify.hs.mdwn b/doc/bugs/GHC_8.4.3_build_failure_in_Types__47__DesktopNotify.hs.mdwn deleted file mode 100644 index 61ac77f0ea..0000000000 --- a/doc/bugs/GHC_8.4.3_build_failure_in_Types__47__DesktopNotify.hs.mdwn +++ /dev/null @@ -1,139 +0,0 @@ -### Please describe the problem. -The build fails with GHC 8.4.3 - -### What steps will reproduce the problem? -Be sure to use esqueleto HEAD to avoid getting stuck on dependencies. - -### What version of git-annex are you using? On what operating system? -git-annex-6.20180529 on macOS - -### Please provide any additional information below. - -[[!format sh """ -==> cabal install --jobs=8 --max-backjumps=100000 --prefix=/usr/local/Cellar/git-annex/6.20180529 --flags=s3 webapp -clang: warning: -Wl,-headerpad_max_install_names: 'linker' input unused -clang: warning: argument unused during compilation: '-L/usr/local/opt/gettext/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/libffi/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/icu4c/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/openssl/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/readline/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/sqlite/lib' -clang: warning: argument unused during compilation: '-L/usr/local/lib' -clang: warning: argument unused during compilation: '-L/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries' -Resolving dependencies... -Notice: installing into a sandbox located at -/private/tmp/git-annex-20180529-26197-14ebtme/git-annex-6.20180529/.cabal-sandbox -Configuring git-annex-6.20180529... -Building git-annex-6.20180529... -Failed to install git-annex-6.20180529 -Build log ( /private/tmp/git-annex-20180529-26197-14ebtme/git-annex-6.20180529/.cabal-sandbox/logs/ghc-8.4.3/git-annex-6.20180529-9O50etRsVNH1q2HUlIF2Gu.log ): -cabal: Entering directory '.' -[ 1 of 34] Compiling Utility.Applicative ( Utility/Applicative.hs, dist/dist-sandbox-669b35af/setup/Utility/Applicative.o ) -[ 2 of 34] Compiling Utility.Data ( Utility/Data.hs, dist/dist-sandbox-669b35af/setup/Utility/Data.o ) -[ 3 of 34] Compiling Utility.Exception ( Utility/Exception.hs, dist/dist-sandbox-669b35af/setup/Utility/Exception.o ) -[ 4 of 34] Compiling Utility.Env.Basic ( Utility/Env/Basic.hs, dist/dist-sandbox-669b35af/setup/Utility/Env/Basic.o ) -[ 5 of 34] Compiling Build.Mans ( Build/Mans.hs, dist/dist-sandbox-669b35af/setup/Build/Mans.o ) -[ 6 of 34] Compiling Utility.FileSize ( Utility/FileSize.hs, dist/dist-sandbox-669b35af/setup/Utility/FileSize.o ) -[ 7 of 34] Compiling Utility.Misc ( Utility/Misc.hs, dist/dist-sandbox-669b35af/setup/Utility/Misc.o ) -[ 8 of 34] Compiling Utility.Monad ( Utility/Monad.hs, dist/dist-sandbox-669b35af/setup/Utility/Monad.o ) -[ 9 of 34] Compiling Utility.PartialPrelude ( Utility/PartialPrelude.hs, dist/dist-sandbox-669b35af/setup/Utility/PartialPrelude.o ) -[10 of 34] Compiling Utility.Process.Shim ( Utility/Process/Shim.hs, dist/dist-sandbox-669b35af/setup/Utility/Process/Shim.o ) -[11 of 34] Compiling Utility.Process ( Utility/Process.hs, dist/dist-sandbox-669b35af/setup/Utility/Process.o ) -[12 of 34] Compiling Utility.Network ( Utility/Network.hs, dist/dist-sandbox-669b35af/setup/Utility/Network.o ) -[13 of 34] Compiling Utility.Split ( Utility/Split.hs, dist/dist-sandbox-669b35af/setup/Utility/Split.o ) -[14 of 34] Compiling Utility.SafeCommand ( Utility/SafeCommand.hs, dist/dist-sandbox-669b35af/setup/Utility/SafeCommand.o ) -[15 of 34] Compiling Utility.ExternalSHA ( Utility/ExternalSHA.hs, dist/dist-sandbox-669b35af/setup/Utility/ExternalSHA.o ) -[16 of 34] Compiling Utility.FileSystemEncoding ( Utility/FileSystemEncoding.hs, dist/dist-sandbox-669b35af/setup/Utility/FileSystemEncoding.o ) -[17 of 34] Compiling Utility.SystemDirectory ( Utility/SystemDirectory.hs, dist/dist-sandbox-669b35af/setup/Utility/SystemDirectory.o ) -[18 of 34] Compiling Utility.Tmp ( Utility/Tmp.hs, dist/dist-sandbox-669b35af/setup/Utility/Tmp.o ) -[19 of 34] Compiling Utility.Directory ( Utility/Directory.hs, dist/dist-sandbox-669b35af/setup/Utility/Directory.o ) -[20 of 34] Compiling Build.Version ( Build/Version.hs, dist/dist-sandbox-669b35af/setup/Build/Version.o ) -[21 of 34] Compiling Utility.UserInfo ( Utility/UserInfo.hs, dist/dist-sandbox-669b35af/setup/Utility/UserInfo.o ) -[22 of 34] Compiling Utility.Path ( Utility/Path.hs, dist/dist-sandbox-669b35af/setup/Utility/Path.o ) -[23 of 34] Compiling Common ( Common.hs, dist/dist-sandbox-669b35af/setup/Common.o ) -[24 of 34] Compiling Utility.DottedVersion ( Utility/DottedVersion.hs, dist/dist-sandbox-669b35af/setup/Utility/DottedVersion.o ) -[25 of 34] Compiling Git.Version ( Git/Version.hs, dist/dist-sandbox-669b35af/setup/Git/Version.o ) -[26 of 34] Compiling Build.TestConfig ( Build/TestConfig.hs, dist/dist-sandbox-669b35af/setup/Build/TestConfig.o ) -[27 of 34] Compiling Build.Configure ( Build/Configure.hs, dist/dist-sandbox-669b35af/setup/Build/Configure.o ) -[28 of 34] Compiling Utility.OSX ( Utility/OSX.hs, dist/dist-sandbox-669b35af/setup/Utility/OSX.o ) -[29 of 34] Compiling Utility.FreeDesktop ( Utility/FreeDesktop.hs, dist/dist-sandbox-669b35af/setup/Utility/FreeDesktop.o ) -[30 of 34] Compiling Config.Files ( Config/Files.hs, dist/dist-sandbox-669b35af/setup/Config/Files.o ) -[31 of 34] Compiling Assistant.Install.Menu ( Assistant/Install/Menu.hs, dist/dist-sandbox-669b35af/setup/Assistant/Install/Menu.o ) -[32 of 34] Compiling Assistant.Install.AutoStart ( Assistant/Install/AutoStart.hs, dist/dist-sandbox-669b35af/setup/Assistant/Install/AutoStart.o ) -[33 of 34] Compiling Build.DesktopFile ( Build/DesktopFile.hs, dist/dist-sandbox-669b35af/setup/Build/DesktopFile.o ) -[34 of 34] Compiling Main ( dist/dist-sandbox-669b35af/setup/setup.hs, dist/dist-sandbox-669b35af/setup/Main.o ) -Linking ./dist/dist-sandbox-669b35af/setup/setup ... - checking version...fatal: Not a git repository (or any of the parent directories): .git - 6.20180529 - checking UPGRADE_LOCATION... not available - checking git... yes - checking git version... 2.10.1 (Apple Git-78) - checking cp -a... yes - checking cp -p... yes - checking cp --preserve=timestamps... no - checking cp --reflink=auto... no - checking xargs -0... yes - checking rsync... yes - checking curl... yes - checking bup... no - checking nice... yes - checking ionice... no - checking nocache... no - checking gpg... not available - checking lsof... lsof - checking git-remote-gcrypt... not available - checking ssh connection caching... yes - checking sha1... not available - checking sha256... not available - checking sha512... not available - checking sha224... not available - checking sha384... not available -Configuring git-annex-6.20180529... -clang: warning: -Wl,-headerpad_max_install_names: 'linker' input unused -clang: warning: argument unused during compilation: '-L/usr/local/opt/gettext/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/libffi/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/icu4c/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/openssl/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/readline/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/sqlite/lib' -clang: warning: argument unused during compilation: '-L/usr/local/lib' -clang: warning: argument unused during compilation: '-L/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries' -Preprocessing executable 'git-annex' for git-annex-6.20180529.. -Building executable 'git-annex' for git-annex-6.20180529.. -[ 1 of 593] Compiling Assistant.Types.BranchChange ( Assistant/Types/BranchChange.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Assistant/Types/BranchChange.o ) -[ 2 of 593] Compiling Assistant.Types.ThreadName ( Assistant/Types/ThreadName.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Assistant/Types/ThreadName.o ) -[ 3 of 593] Compiling Assistant.Types.TransferSlots ( Assistant/Types/TransferSlots.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Assistant/Types/TransferSlots.o ) -[ 4 of 593] Compiling BuildFlags ( BuildFlags.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/BuildFlags.o ) -[ 5 of 593] Compiling BuildInfo ( BuildInfo.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/BuildInfo.o ) -[ 6 of 593] Compiling Build.BundledPrograms ( Build/BundledPrograms.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Build/BundledPrograms.o ) -[ 7 of 593] Compiling Config.Cost ( Config/Cost.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Config/Cost.o ) -[ 8 of 593] Compiling Logs.Line ( Logs/Line.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Logs/Line.o ) -[ 9 of 593] Compiling Types.Availability ( Types/Availability.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Types/Availability.o ) -[ 10 of 593] Compiling Types.BranchState ( Types/BranchState.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Types/BranchState.o ) -[ 11 of 593] Compiling Types.Concurrency ( Types/Concurrency.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Types/Concurrency.o ) -[ 12 of 593] Compiling Types.Creds ( Types/Creds.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Types/Creds.o ) -[ 13 of 593] Compiling Assistant.Types.CredPairCache ( Assistant/Types/CredPairCache.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Assistant/Types/CredPairCache.o ) -[ 14 of 593] Compiling Types.DesktopNotify ( Types/DesktopNotify.hs, dist/dist-sandbox-669b35af/build/git-annex/git-annex-tmp/Types/DesktopNotify.o ) - -Types/DesktopNotify.hs:19:10: error: - • No instance for (Semigroup DesktopNotify) - arising from the superclasses of an instance declaration - • In the instance declaration for ‘Monoid DesktopNotify’ - | -19 | instance Monoid DesktopNotify where - | ^^^^^^^^^^^^^^^^^^^^ -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-6.20180529-9O50etRsVNH1q2HUlIF2Gu failed during the building phase. -The exception was: -ExitFailure 1 -"""]] - -Full log https://gist.github.com/ilovezfs/e3af135ed0362e0253a786c71f2a914f - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! Thanks :) - -> Consequence of the Semigroup Monoid change. Fixed. [[done]] --[[Joey]] - diff --git a/doc/bugs/GPG_subkeys.mdwn b/doc/bugs/GPG_subkeys.mdwn deleted file mode 100644 index 917ec90029..0000000000 --- a/doc/bugs/GPG_subkeys.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -### Please describe the problem. -Despite the very fast, much appreciated, and excellent response to my initial question [here](http://git-annex.branchable.com/encryption/#comment-cb9c20121e570f80fcd799c1619ced69), I still can't get encryption working with subkeys. - -I have a few different machines, each with its own subkey and each configured with the master key stripped out. I'm hoping to be able to encrypt and decrypt from the same special remotes with each of them. - -The issue is that git-annex consistently tries to encrypt with the master key, which is not available, and so encryption and the `initremote` fail. - -I'm submitting a bug report but I should say that I'm not sure this is the intended (or documented) way to use GPG subkeys and it may not be a git-annex concern. The [Debian Wiki](https://wiki.debian.org/Subkeys) does say that it won't work but the [password store](https://lists.zx2c4.com/pipermail/password-store/2014-September/001131.html) project has implemented it. - -Side note: this is not working in gcrypt either. - -### What steps will reproduce the problem? - -I've tried the following in a few different combinations, with both short and long KEYIDs, and with or without the appended '!' that's supposed to tell gpg which key to use for encryption: -`git annex initremote cloud type=S3 encryption=hybrid keyid=EFEFEFE host=storage.googleapis.com port=80` - -In each case I get the same error: -`gpg: decryption failed: No secret key` -`git-annex: user error (/usr/local/bin/gpg ["--quiet","--trust-model","always","--decrypt"] exited 2)` -`failed` - -### What version of git-annex are you using? On what operating system? -`git-annex version: 6.20171109` -OS X 10.10.5 - -### Please provide any additional information below. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -I love git annex. Thank you for your work on it. - -> Yeah, so I had that working before but then I tightened the -> code to determine what is a forced subkey and broke it. -> -> [Fixed now; use a "!" at the _end_ to force subkey use: - - joey@darkstar:~/tmp/a>git annex initremote testing type=directory directory=../d encryption=hybrid keyid='A4FEC0B5F031BA70!' - initremote testing (encryption setup) gpg: A4FEC0B5F031BA70!: skipped: Unusable public key - gpg: [stdin]: encryption failed: Unusable public key - -> It failed to use that subkey because it is a sign-only key, -> and git-annex needs to encrypt, but that certainly shows I got -> git-annex to use the subkey.. -> -> I made an encrypt-only subkey, and git-annex is able to use it, -> and it fully works as far as I can tell. -> -> [[done]] --[[Joey]] diff --git a/doc/bugs/GPG_subkeys/comment_1_9be3e177b0b02c3988d5af64dc6e67ed._comment b/doc/bugs/GPG_subkeys/comment_1_9be3e177b0b02c3988d5af64dc6e67ed._comment deleted file mode 100644 index 230ed65506..0000000000 --- a/doc/bugs/GPG_subkeys/comment_1_9be3e177b0b02c3988d5af64dc6e67ed._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="Yurt" - avatar="http://cdn.libravatar.org/avatar/28d2177f7678c6cc0b677c34927eba06" - subject="comment 1" - date="2017-12-20T22:33:03Z" - content=""" -Hi, - -I've tested this and can confirm it's working for me in 6.20171214. I can encrypt with a subkey when the master key is not present. -Thanks so much for your work on this and git-annex in general (and mr and etckeeper and everything else). -"""]] diff --git a/doc/bugs/Git-annex_not_properly_detecting_symlink_capability_in_CryFS.mdwn b/doc/bugs/Git-annex_not_properly_detecting_symlink_capability_in_CryFS.mdwn deleted file mode 100644 index bb62802283..0000000000 --- a/doc/bugs/Git-annex_not_properly_detecting_symlink_capability_in_CryFS.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -### Please describe the problem. - -When creating a new git-annex repository (or upgrading, or doing fsck) inside a CryFS container (FUSE-based encrypted local filesystem, similiar to EncFS), git-annex goes into direct(or adjusted, in v6) mode despite CryFS working just fine with symlinks. - -Indeed, a created-outside-cryfs git-annex repository works as expected when copied inside - -### What steps will reproduce the problem? -1. Install cryfs (https://www.cryfs.org/, packaged for ubuntu,debian, or build from source) -2. Create a CryFS container: $ cryfs container container-data -3. Create a git annex repository inside the container: - - $ cd container - $ git init . - $ git annex init --version 6 - -#### Cloning from v6 repository, you get - -git annex init --version 6 -init - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Disabling core.symlinks. -(merging origin/git-annex into git-annex...) -(recording state in git...) -(scanning for unlocked files...) - - Entering an adjusted branch where files are unlocked as this filesystem does not support locked files. - -Switched to branch 'adjusted/master(unlocked)' -ok -(recording state in git...) - -#### Cloning from v5 repository and upgrading, you get - -git annex upgrade -upgrade . - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Disabling core.symlinks. -(merging origin/git-annex into git-annex...) -(recording state in git...) - - Enabling direct mode. -(v5 to v6...) (scanning for unlocked files...) -ok -(recording state in git...) - -### What version of git-annex are you using? On what operating system? -git-annex-6.20170519-1.fc26.x86_64 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I love git-annex. - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Git-annex_not_properly_detecting_symlink_capability_in_CryFS/comment_1_78f6f047578974df0dd73740ab05ee8c._comment b/doc/bugs/Git-annex_not_properly_detecting_symlink_capability_in_CryFS/comment_1_78f6f047578974df0dd73740ab05ee8c._comment deleted file mode 100644 index dae2a9d099..0000000000 --- a/doc/bugs/Git-annex_not_properly_detecting_symlink_capability_in_CryFS/comment_1_78f6f047578974df0dd73740ab05ee8c._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-08-28T17:06:35Z" - content=""" -git-annex has detected problems with the filesystem, since symlinks -work I think it detected that the filesystem allows writing to a -file even when the file's write bit is not set. - -In that situation, a git-annex repository using symlinks will apprear to -work, but if you have an annexed file "foo" in there, and run "echo hi > -foo", it will follow the symlink, and overwrite the annexed file, ignoring -the lack of write bit. This can result in data loss in an unexpected way, -which is why git-annex avoids using the symlinks in this situation. - -I've added an additional message to make more clear what is happening. -"""]] diff --git a/doc/bugs/How_to_clone_git-annex__63__.mdwn b/doc/bugs/How_to_clone_git-annex__63__.mdwn deleted file mode 100644 index e71e6b18bb..0000000000 --- a/doc/bugs/How_to_clone_git-annex__63__.mdwn +++ /dev/null @@ -1,59 +0,0 @@ -### Please describe the problem. - -When I clone git-annex with: - -``` -git clone git://git-annex.branchable.com/ git-annex -``` - -I get errors about filenames being too long and the checkout fails after the clone: - - - $ git clone git://git-annex.branchable.com/ git-annex - Cloning into 'git-annex'... - remote: Counting objects: 183837, done. - remote: Compressing objects: 100% (51419/51419), done. - remote: Total 183837 (delta 131729), reused 183837 (delta 131729) - Receiving objects: 100% (183837/183837), 46.20 MiB | 4.90 MiB/s, done. - Resolving deltas: 100% (131729/131729), done. - error: unable to create file doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn: File name too long - error: unable to create file doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__.mdwn: File name too long - error: unable to create file doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_.mdwn: File name too long - fatal: cannot create directory at 'doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_': File name too long - warning: Clone succeeded, but checkout failed. - You can inspect what was checked out with 'git status' - and retry the checkout with 'git checkout -f HEAD' - -I would like to contribute, but I was a bit surprised by this problem right when I wanted to poke around in the code. - -After the clone attempt running `git status` in the checkout directory produces a **huge** amount of output about deleted files and changes to the repo: - - $ git status - On branch master - Your branch is up-to-date with 'origin/master'. - Changes to be committed: - (use "git reset HEAD ..." to unstage) - - deleted: .ghci - deleted: .gitattributes - deleted: .gitignore - deleted: .mailmap - deleted: Annex.hs - deleted: Annex/Action.hs - deleted: Annex/AdjustedBranch.hs - ... - - -Note that I have snipped off over 10K lines of output from above! - - -### What steps will reproduce the problem? - -Just try to clone it. - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -git-annex looks like a really promising project for my personal backups solution involving usb disks, and some external services such as Backblaze B2. I wanted to look into improving Backblaze B2 support (large file support, etc). - -> [[done]]; ecryptfs is not supported --[[Joey]] diff --git a/doc/bugs/How_to_clone_git-annex__63__/comment_1_a55d9717cffca2817254026cc9407b20._comment b/doc/bugs/How_to_clone_git-annex__63__/comment_1_a55d9717cffca2817254026cc9407b20._comment deleted file mode 100644 index 76da8fd96b..0000000000 --- a/doc/bugs/How_to_clone_git-annex__63__/comment_1_a55d9717cffca2817254026cc9407b20._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="aditya.mmy@be7b2fbd14a6ce2b6b8588f6719672725a11ed35" - nickname="aditya.mmy" - avatar="http://cdn.libravatar.org/avatar/ec711faaa06edd971f00a6d107fd3206" - subject="Nevermind - I got it working" - date="2017-08-27T10:18:03Z" - content=""" -The problem was that I am using ecryptfs - I was not aware of any file-length limitations in it until now, but here they are - https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs -"""]] diff --git a/doc/bugs/How_to_clone_git-annex__63__/comment_2_9b235c0a8f0e299f84e97857cb09c4cb._comment b/doc/bugs/How_to_clone_git-annex__63__/comment_2_9b235c0a8f0e299f84e97857cb09c4cb._comment deleted file mode 100644 index ad7845d71c..0000000000 --- a/doc/bugs/How_to_clone_git-annex__63__/comment_2_9b235c0a8f0e299f84e97857cb09c4cb._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-08-28T17:00:21Z" - content=""" -You didn't say what OS/filesystem you're using that has trouble with -filenames that are 144 characters long. Even Windows supports up to 255 -character long filenames IIRC. -"""]] diff --git a/doc/bugs/How_to_clone_git-annex__63__/comment_3_6ac90de5faa03726b760eda831fd5203._comment b/doc/bugs/How_to_clone_git-annex__63__/comment_3_6ac90de5faa03726b760eda831fd5203._comment deleted file mode 100644 index 3ffcbd1022..0000000000 --- a/doc/bugs/How_to_clone_git-annex__63__/comment_3_6ac90de5faa03726b760eda831fd5203._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-08-28T17:01:21Z" - content=""" -Ah yes, ecryptfs.. It has some problems. I am not going to try to limit -filenames to support it. -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default.mdwn b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default.mdwn deleted file mode 100644 index d81e005f36..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -### Please describe the problem. -the import and reinject commands are needlessly destructive by default. -this caused me some grief as it repeatedly "destroyed" data on my cammeras sdcard -as i tried to import new data nad/or reinject missing data correctly -without having to scan 40gb of pictures for hases repeatedly. - -### software versions -[[!format sh """ -$ git-annex version -git-annex version: 6.20180626-gdf91a5cff -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.1 persistent-sqlite-2.6.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -"""]]] - -### what i would like to see - -* better documentation for commands that sort out non-destructive importing - (@joeyh already pointed out `cp` followed by `git annex add` on irc, but that doesn't cover known files/keys) -* comprehensible options that disable deletion for `reinject`/`import`, i consider the semantics of "move" for commands with actionable names like "import" and "reinject" a bit deceptive even if they are documented that way - - -for me personally the ideal case would be a cp command for git annex that would copy in new data -in a cp style allowing to use options like `noclobber` and perhaps `reinject` - -it may be sensible to leave supporting this to the importtree feature - -> I think we've argued pretty well that the current behavior makes sense, -> so [[done]] --[[Joey]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_1_96fae5927db6badfe13466cd27cfc371._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_1_96fae5927db6badfe13466cd27cfc371._comment deleted file mode 100644 index 8eba862c35..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_1_96fae5927db6badfe13466cd27cfc371._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 1" - date="2018-07-05T13:53:46Z" - content=""" -This shouldn't be under bugs, it is the intended behaviour. - -Both the words `import` and `reinject` relate to the movement of something from one place to another (importing goods, injecting fluids). Descriptions for both these commands state that data will be *moved* into the annex in the first sentence. If you aren't reading docs before using these commands, better docs are hardly going to have helped.. - -What you are trying to do can be done with `import --skip-duplicates` then `cp` -> `reinject`, albeit a bit of a pain. Personally, I would use `calckey` to generate the hashes (and keep them in a file), add hashes for files not listed in that file, then use that file to find out what keys were unknown and `import --duplicate` just those files. - -..or [following a suggestion I made a while ago](http://git-annex.branchable.com/todo/Alternative_mode_control_for_import/) `git annex import --mode=Di,Nsi` would do what you want (injects duplicates without deleting, adds new without deleting) :P -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_2_432795dbe2308013b76488f273ce31e9._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_2_432795dbe2308013b76488f273ce31e9._comment deleted file mode 100644 index cebf3d3e1b..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_2_432795dbe2308013b76488f273ce31e9._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="git-annex.branchable.com@07c0f8919010cc703ae7eea746d9b494c153291f" - nickname="git-annex.branchable.com" - avatar="http://cdn.libravatar.org/avatar/c5379a3fe2188b7571858c49f9db63c6" - subject="comment 2" - date="2018-07-05T15:47:14Z" - content=""" -thanks for the outline - -i believe by refining the arguments of `import` my use-case could be sorted out -im happy to move this to a todo - -basically i'm looking for `--no-clobber` to easily skip existing known files `--reinject-missing` and `--remove-source==never` or something like that -i'd prefer to decompose the features into flags over the condensed examples you suggested -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_3_3aefeda27ae0d6a34d26fc4bce56c48b._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_3_3aefeda27ae0d6a34d26fc4bce56c48b._comment deleted file mode 100644 index 9b8fcb0844..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_3_3aefeda27ae0d6a34d26fc4bce56c48b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-07-06T16:43:15Z" - content=""" -When you say it «"destroyed" data on my cammeras sdcard» -do you mean you actually lost data, and if so, how? -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_4_bc6fa5cf986502ef36d949ff3c7daa2f._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_4_bc6fa5cf986502ef36d949ff3c7daa2f._comment deleted file mode 100644 index ba29827acf..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_4_bc6fa5cf986502ef36d949ff3c7daa2f._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="git-annex.branchable.com@07c0f8919010cc703ae7eea746d9b494c153291f" - nickname="git-annex.branchable.com" - avatar="http://cdn.libravatar.org/avatar/c5379a3fe2188b7571858c49f9db63c6" - subject="comment 4" - date="2018-07-06T20:13:32Z" - content=""" -the data was not lost as i had a copy, but i was quite surprised that the data was completely gone at first as i misunderstood the command -im under the impression it was pure luck on my side that this didn't end in me getting an actual data loss -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_5_b9de159a02d0ec8e6466154302c39bf3._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_5_b9de159a02d0ec8e6466154302c39bf3._comment deleted file mode 100644 index 5ff8ee4d5b..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_5_b9de159a02d0ec8e6466154302c39bf3._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="andrew" - avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" - subject="comment 5" - date="2018-07-08T16:37:04Z" - content=""" -I was also confused the first time I read the documentation of `git-annex-import`. By default it *moves* files, IE copies files into your annex and then deletes them from the source. Since `git-annex` commands seems to be eager to preserve multiple copies of files I did find it surprising that with this command it does not. I suppose one motivation for deleting the files at the source is so `git-annex` or the user can keep track of which files have been imported, IE they are using the import command to put unorganized files under the control of an annex. - -I would have expected `git-annex import` to *copy* files by default, then have an option like `--move` to *move* files instead. I'm not sure this is a compelling enough reason to change an existing command though… - -Personally I always do `git-annex import --duplicate` -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_6_61ca3d5bb350e52f31d8b75dd3ece1d9._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_6_61ca3d5bb350e52f31d8b75dd3ece1d9._comment deleted file mode 100644 index 3439a759fe..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_6_61ca3d5bb350e52f31d8b75dd3ece1d9._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 6" - date="2018-07-08T17:58:33Z" - content=""" - By default it moves files, IE copies files into your annex and then deletes them from the source. - -Only if you move from one filesystem to another (because it has to). -If it is on the same filesystem, *move* doesn't do any copy/delete of the data, only the references to the file. -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_7_c8a0a64aa4253ba2eea525ce9fc67d4f._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_7_c8a0a64aa4253ba2eea525ce9fc67d4f._comment deleted file mode 100644 index ed4f904d0b..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_7_c8a0a64aa4253ba2eea525ce9fc67d4f._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2018-07-11T19:41:15Z" - content=""" -Seems to me that the documentation of git-annex import, git-annex reinject, -and git-annex setkey is clear, that these commands all move content into the -annex. - -If you don't want it to move, you can always make a copy of the file first, -and run the command on the copy. But git-annex is about managing large -files, and making a second local copy of a large file would be surprising -behavior if the user didn't explicitly ask for it. - -When you set up a remote somewhere, and ask git-annex to ensure numcopies -is 2+, it is *then* eager to preserve multiple copies, because it's been -given a way to do so, and been told to. It's not eager by default though. - -Given that people get confused with the existing number of options to -git-annex import, I'm reluctant to add more to it, especially if the same -behavior as the suggested options can be obtained by running `cp` first. - -I still don't fully understand what your proposed options are supposed -to do.. -"""]] diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_8_f24b544018d84b0182621d07bb9c8c3d._comment b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_8_f24b544018d84b0182621d07bb9c8c3d._comment deleted file mode 100644 index f3e7a385fe..0000000000 --- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/comment_8_f24b544018d84b0182621d07bb9c8c3d._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="andrew" - avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" - subject="comment 8" - date="2018-07-13T15:04:13Z" - content=""" -That all makes sense Joey/CandyAngel. I do wonder how this command will change though if [import tree](https://git-annex.branchable.com/todo/import_tree/) is ever implemented. I presume the default behavior of `git annex import treeish` would preserve the source tree as if the option `--duplicate` had been given? Whereas `git annex import path` would continue to move files by default. But maybe this is another reason not to do `git annex import treeish`, maybe that command should be `git annex importtree treeish`? - -In terms of the anonymous poster's suggestions of changing the options to import, I would say all of your suggestions already exist in a usable form “skip existing known files” is already an option `--skip-duplicates`, “--remove-source==never” is already an option `--duplicate` and presumably “--reinject-missing” is similar to the existing option `--force`. -"""]] diff --git a/doc/bugs/Incorrect_escaping_of_file_names_for_smudging.mdwn b/doc/bugs/Incorrect_escaping_of_file_names_for_smudging.mdwn deleted file mode 100644 index cf41b2fb42..0000000000 --- a/doc/bugs/Incorrect_escaping_of_file_names_for_smudging.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -### Please describe the problem. - -I'm playing with git-annex on Android and I see the following error messages for file names starting with `-`: - - Usage: git-annex smudge (FILE [--clean] | --update) - error: external filter 'git-annex smudge %f' failed 1 - error: external filter 'git-annex smudge %f' failed - Invalid option `-123min/Home/9 - Home.mp3' - -### What steps will reproduce the problem? - -1. Add a file starting with `-` to the annex (on Debian/Linux in my case). -2. On another system (Android in my case) add `git remote` and run `git annex sync`. -3. Observe the error messages. - -### What version of git-annex are you using? On what operating system? - - git-annex version: 7.20181122-gbb94cc9f8 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - operating system: linux aarch64 - supported repository versions: 5 7 - upgrade supported from repository versions: 0 1 2 3 4 5 6 - local repository version: 7 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Sure :) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Incorrect_escaping_of_file_names_for_smudging/comment_1_62117387feca4f4b98350a838ed60043._comment b/doc/bugs/Incorrect_escaping_of_file_names_for_smudging/comment_1_62117387feca4f4b98350a838ed60043._comment deleted file mode 100644 index f685f6b15c..0000000000 --- a/doc/bugs/Incorrect_escaping_of_file_names_for_smudging/comment_1_62117387feca4f4b98350a838ed60043._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-03-18T18:03:41Z" - content=""" -No need to complicate this with Android, this is sufficient to reproduce -the problem: - - joey@darkstar:/tmp/a>touch ./-foo - joey@darkstar:/tmp/a>git add ./-foo - Invalid option `-foo' - - Usage: git-annex smudge (FILE [--clean] | --update) - error: external filter 'git-annex smudge --clean %f' failed 1 - -The fix is to edit .git/config to contain: - - [filter "annex"] - smudge = git-annex smudge -- %f - clean = git-annex smudge --clean -- %f - -The added -- before the filename prevents confusing it with an option. - -I've done this for new git-annex repositories, and `git annex init` will -also update existing repos. -"""]] diff --git a/doc/bugs/Incorrectly_linked_git_annex_shell_in_standalone_rpm.mdwn b/doc/bugs/Incorrectly_linked_git_annex_shell_in_standalone_rpm.mdwn deleted file mode 100644 index 3da9a2ac7c..0000000000 --- a/doc/bugs/Incorrectly_linked_git_annex_shell_in_standalone_rpm.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -### Please describe the problem. - -`/usr/bin/git-annex-shell` is linked to `/usr/lib/git-annex.linux/git-annex`, not `/usr/lib/git-annex.linux/git-annex-shell` after installing from git annex standalone rpm using yum. - -As a result, commands passed through `git-annex-shell` don't work, but other functions I tried work properly (e.g. initializing repos, adding files). I found the bug after running `git annex get myawesomefile` and getting a confusing error message about `git-annex` usage. - -Running `/usr/lib/git-annex.linux/git-annex-shell configlist ~/path/to/my/repo` would produce correct output, but `/usr/bin/git-annex-shell configlist ~/path/to/my/repo` would raise errors. Relinking `/usr/bin/git-annex-shell` seems to have fixed the problem. - - -### What steps will reproduce the problem? - -- Install git annex following these steps: https://git-annex.branchable.com/install/rpm_standalone/ -- Run any `git-annex-shell` command. In my case, `git-annex-shell configlist ~/path/to/my/repo`. - -### What version of git-annex are you using? On what operating system? - -git-annex version: 7.20190912-g05bc37910 -build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 -operating system: linux x86_64 (CentOS 7) - -### Please provide any additional information below. - -Here is output from one time I tried to run `git-annex-shell` over ssh. Note that the error message gives usage for `git-annex`, not `git-annex-shell`. - -[[!format sh """ -$ ssh username@my.remote.server 'git-annex-shell configlist ~/path/to/my/repo' -Invalid argument `configlist' - -Usage: git-annex COMMAND - git-annex - manage files with git, without checking their contents in - - Commonly used commands: - - add PATH ... add files to annex - addurl URL ... add urls to annex -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Git annex does exactly what I want, without the complicated setup or fees of git lfs. Thanks for your work maintaining this project! - -> [[fixed|done]] in git; the rpm itself will only get generated at the next -> release though. --[[Joey]] diff --git a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__.mdwn b/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__.mdwn deleted file mode 100644 index 85359ad175..0000000000 --- a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -The current Linux standalone for ARM, used on armv5tel with Debian stretch, does not work: - - $ cd git-annex.linux/ - $ ./runshell - $ git annex - error: git-annex died of signal 4 - $ git-annex - Illegal instruction - - -I downloaded the arm tarball, unpacked and did as above. Same if do as above as root or use the alternative way of modifying the PATH, as suggested in the installation instructions. The CPU is Feroceon 88FR131 rev 1 (v5l). - -Is there a way of getting a working pre-built git-annex on such a system? - -Thanks in advance! - -> I've updated the builder to use the fixed ghc and the haskell libraries -> built with it, so this is [[fixed|done]] in the git-annex armel -> autobuild. (Not yet in the release tarball but that will happen after the -> next git-annex release.) --[[Joey]] diff --git a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_1_1143917decff204a3965959d1cfaa8f4._comment b/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_1_1143917decff204a3965959d1cfaa8f4._comment deleted file mode 100644 index ed696deb7a..0000000000 --- a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_1_1143917decff204a3965959d1cfaa8f4._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce" - subject="git-annex not working on arm at all?" - date="2019-05-28T17:23:57Z" - content=""" -Further attempts to get a working git-annex on arm (kirkwood), all failed: - -1. I tried to compile git-annex from source, on Debian stretch on my ARM machine - armel, kirkwood subarchitecture, it's a [QNAP Turbo Station](https://www.debian.org/releases/stable/armel/ch02s01.html.en) - following the instruction in [fromsource](http://git-annex.branchable.com/install/fromsource/). Make failed with [this error](https://gist.github.com/emanuele/54d0fb1e8905cb48da0cdf9371679462). Additional comments: I used `sudo apt-get build-dep git-annex` to install dependencies but libghc-microlens was missing and I had to install it separately. Make required a large amount of RAM: >500Mb or resident memory and >1Gb of virtual memory, which is more than what's available on such hardware. So make failed but re-running it multiple times worked, until the bug above. -2. I installed git-annex from the official package of Debian testing (buster), via `apt`. The installation went well. Unfortunately, the executable does not work, issuing the same error mentioned before: - -``` - # which git-annex - /usr/bin/git-annex - # git annex - error: git-annex died of signal 4 - # git-annex - Illegal instruction -``` - -Thanks in advance for any help. - -"""]] diff --git a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_2_3dfc1d4c0fcd6b9af1205ad0f43bb1a7._comment b/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_2_3dfc1d4c0fcd6b9af1205ad0f43bb1a7._comment deleted file mode 100644 index da997df734..0000000000 --- a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_2_3dfc1d4c0fcd6b9af1205ad0f43bb1a7._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce" - subject="Misconfiguration in GHC" - date="2019-05-28T20:38:07Z" - content=""" -Apparently, the issue described above is due to a misconfiguration of `ghc`, as reported in this recent [Debian Bug Report (#928882)](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928882) which was triggered by [another bug report (#915333)](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915333) from users reporting `git-annex` not working in Debian on arm5te. - -In essence, this misconfiguration causes **all** Debian packages compiled with ghc not to work on ARM architectures below arm6. I hope that the proposed patch will be accepted soon. -"""]] diff --git a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_3_9117c76ad8f74c1f11eda2ecf7144402._comment b/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_3_9117c76ad8f74c1f11eda2ecf7144402._comment deleted file mode 100644 index a5dd38de99..0000000000 --- a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_3_9117c76ad8f74c1f11eda2ecf7144402._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2019-05-29T13:58:43Z" - content=""" -Thanks for tracking down the ghc bug. The git-annex standalone build is -built on Debian using its toolchain. So once that bug gets fixed, I will -just need to make sure the builder is up-to-date to close this. -"""]] diff --git a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_4_a5d5b908c4b9e91aff5eeb7cdb760ee7._comment b/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_4_a5d5b908c4b9e91aff5eeb7cdb760ee7._comment deleted file mode 100644 index 8cc8e8b87a..0000000000 --- a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_4_a5d5b908c4b9e91aff5eeb7cdb760ee7._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce" - subject="comment 4" - date="2019-05-29T17:36:06Z" - content=""" -Thank you for the great work done with `git-annex`! - -I am not much familiar with how the Debian maintainers decide to address - or not - a bug/patch like this one. But if dropping a line to support the [related Debian Bug Report](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928882) or subscribing to it could help, I invite everyone to do it. In my case, I have a 6TB RAID1 ARM Debian box meant to be used with `git-annex` but without it... -"""]] diff --git a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_5_b9d8b5776979213723249cdf4cf26dbc._comment b/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_5_b9d8b5776979213723249cdf4cf26dbc._comment deleted file mode 100644 index 84c1737a16..0000000000 --- a/doc/bugs/Linux_standalone_on_armv5tel__58___error__58_____34__git-annex_died_of_signal_4__34__/comment_5_b9d8b5776979213723249cdf4cf26dbc._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce" - subject="git-annex on armel now working on Debian unstable (sid)" - date="2019-06-25T10:07:56Z" - content=""" -I am very happy to announce that git-annex for the armel architecture, as provided by Debian unstable (sid), now works correctly! Details [here](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928882). Soon it should be available in Debian testing too. The misconfiguration of the Haskell compiler (ghc) for the armel architecture, that triggered the bug reported in this page, has been addressed and all Haskell packages have been re-built, git-annex included. Thanks to Ilias Tsitsimpis and Paul Gevers for all the work done! - -@Joey: if you'll use the updated compiler from Debian unstable (or, soon, from Debian testing too), then you'll be able to generate an arm standalone that works on armel architectures too. -"""]] diff --git a/doc/bugs/Make_Setup.hs_work_for_cabal_new-build.mdwn b/doc/bugs/Make_Setup.hs_work_for_cabal_new-build.mdwn deleted file mode 100644 index bfe612a61d..0000000000 --- a/doc/bugs/Make_Setup.hs_work_for_cabal_new-build.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -git-annex uses copyHook in Setup.hs to create/install man pages, .desktop file and etc. - -I'm using cabal new-build/new-install to install it, and these copyHooks don't get called. I reported it to Cabal, but they replied that this should be fixed on git-annex side: https://github.com/haskell/cabal/issues/5933 - -> [[done]], make install-home. Can't be done in Setup.hs for new-build so -> this is the best that can be done. --[[Joey]] diff --git a/doc/bugs/Make_Setup.hs_work_for_cabal_new-build/comment_1_ccc46b058bf27fd8d6474b130226f886._comment b/doc/bugs/Make_Setup.hs_work_for_cabal_new-build/comment_1_ccc46b058bf27fd8d6474b130226f886._comment deleted file mode 100644 index f939d7d622..0000000000 --- a/doc/bugs/Make_Setup.hs_work_for_cabal_new-build/comment_1_ccc46b058bf27fd8d6474b130226f886._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-03-18T15:22:46Z" - content=""" -stack install also bypasses the custom postCopy. It's not been much of a -problem. git-annex's Makefile can use either system to build, and does a -much better job of installing all needed files. - -I've updated the install/fromsource page to point the user toward -`make install` more. Also added a `make install-home` target. - -But I've kept support for using cabal install because users may be relying -on that installation method. If cabal switches to new-build by default -and it stops working, it can be removed then. -"""]] diff --git a/doc/bugs/Makefile_should_use___36____40__GHC__41___to_run_ghc_--make.mdwn b/doc/bugs/Makefile_should_use___36____40__GHC__41___to_run_ghc_--make.mdwn deleted file mode 100644 index 844ca57c4b..0000000000 --- a/doc/bugs/Makefile_should_use___36____40__GHC__41___to_run_ghc_--make.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -### Please describe the problem. -In line 32, Makefile runs "ghc --make Setup" which ignores the variable $(GHC). - -### What steps will reproduce the problem? -Arch Linux doesn't ship with static libraries of ghc boot libraries by default, so I am passing GHC="ghc -dynamic" to Makefile, which sadly doesn't work as intended. - -### What version of git-annex are you using? On what operating system? -7.20190730 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Sure！ - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn b/doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn deleted file mode 100644 index 1e7212dd6b..0000000000 --- a/doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn +++ /dev/null @@ -1,68 +0,0 @@ -### Please describe the problem. - -When adding plenty of files to my git annex repository, I encounter recurring sqlite errors. - -### What steps will reproduce the problem? -Create a git annex repo, add thousands of annexed binary files, and add thousands of small files tracked only with git. - - -### What version of git-annex are you using? On what operating system? - - >git annex version - git-annex version: 6.20171003 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - dependency versions: aws-0.13.0 bloomfilter-2.0.1.0 cryptonite-0.10 DAV-1.2 feed-0.3.10.4 ghc-7.10.3 http-client-0.4.26.2 persistent-sqlite-2.2 torrent-10000.0.0 uuid-1.3.11 yesod-1.4.2 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 6 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - - >lsb_release -d - Description: Ubuntu 16.04.3 LTS - - >uname -r - 4.4.0-43-Microsoft - #(I am using Bash on Windows.) - -### Please provide any additional information below. - - - # If you can, paste a complete transcript of the problem occurring here. - >git ls-files --others | grep txt | wc -l - 1953 - >git add $(git ls-files --others | grep txt) - sqlite worker thread crashed: SQLite3 returned ErrorIO while attempting to perform prepare "SELECT null from content limit 1": disk I/O error - git-annex: sqlite query crashed - error: external filter git-annex smudge --clean %f failed 1 - error: external filter git-annex smudge --clean %f failed - # [...] plenty of errors follow - >git ls-files --others | grep txt | wc -l - 1953 - # End of transcript or log. - - -Triying to solve this problem, I found a part of answer in the form of a similar problem encountered here : - -Deleting git annex databases and running git annex fsck didnt do the trick: - - rm -rf .git/annex/keys/db .git/annex/keys/db-wal - git annex fsck --incremental -J4 - git add $(git ls-files --others | grep txt) - # Again, plenty of sqlite errors :() - -It seems like a big overhead to add files tracked only by git in git annex repo. I know there are hooks/filters that catch and recover annexed files after modification but is it possible to disable these git annex hooks/filters when adding files that shouldn't be annexed ? - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Oh yeah, I am still discovering this powerfull git annex tool. - -In fact, collegues and I are forming a group during the process to exchange about different use cases, encountered problems and help each other. - -[[!meta title="v7: intermittent sqlite ErrorIO crash (especially in WSL)"]] - -> This bug still exists, and there's a more recent bug report -> documenting how it behaves in WSL now. -> -> So I don't think there's any point leaving this open, closing as a -> duplicate. [[done]] --[[Joey]] diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_1_6f4179fe22d85b4a51e4aad60c4ff00d._comment b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_1_6f4179fe22d85b4a51e4aad60c4ff00d._comment deleted file mode 100644 index e22ea1d93e..0000000000 --- a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_1_6f4179fe22d85b4a51e4aad60c4ff00d._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-11-07T17:48:28Z" - content=""" -There have been several bug reports with that same error message -and different causes (permissions problems; filesystems on which sqlite -doesn't work etc). So all that I know from the error is something went -wrong with the sqlite database, which causes queries of it to fail. - -Using the linux version of git-annex on Winows via the (misleadingly named) -"bash for windows" is pretty unusual. I have never seen it work; Microsoft -were still adding missing linux system calls to their emulation layer the -last time I tried it. It's quite possible that there remains a bug in that -emulation layer, that prevents sqlite from working, or makes it unreliable, -etc. I cannot reproduce the problem running git-annex on Linux. - -Note that since it's a v6 repository, running `git add` actually adds the -files to git-annex. `git add` unfortunately runs `git-annex smudge` once -per file. As you note, this is slow; this is one of the several reasons -documented in [[todo/smudge]] why v6 mode is still considered experimental; -and it will need changes in git to improve the speed). - -It would be useful to know if it's failing on the first file, -or if several files get processed ok before it begins to fail. -You could set `GIT_TRACE=1` in the environment to find out. -"""]] diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_2_74f3520d5eaecea35e52f3ffc2bbc559._comment b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_2_74f3520d5eaecea35e52f3ffc2bbc559._comment deleted file mode 100644 index 8b00153de4..0000000000 --- a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_2_74f3520d5eaecea35e52f3ffc2bbc559._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="webanck" - avatar="http://cdn.libravatar.org/avatar/cd273f76ef8c4218510b4f50ef7e1f3d" - subject="reply to comment 1" - date="2017-11-07T19:16:08Z" - content=""" -Hello joey, and thanks for the quick answer, I am honored ! -It's refreshing to enter an active community :) - -About the usage of \"bash on Windows\", well, git-annex had too many problems, especially with the symlinks, until the recent \"Windows 10 Fall Creators Update\". -Now it goes pretty well. - -My main concern for the moment is the symlinks created in the \"bash\" can't be used by windows whereas symlinks created in windows can be used in \"bash\". -Thus working in an annexed directory with Windows programs needs to unlock files. One note though, I didn't try with hardlinks. - -About the v6. I just figured that some minutes ago and, following , created a .gitattributes file. - - *.txt annex.largefiles=nothing - -It works better now. - -About the smudge/sqlite errors. I encountered those only after a big number of adds. -I even managed to add all my files eventually with a little loop ignoring the errors (for 1000 files): - - for i in {1..10} - do - git add $(git ls-files --others | grep txt | head -100) 2> /dev/null - done - - -"""]] diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_3_24eadf45e4d8690470ed34686569a323._comment b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_3_24eadf45e4d8690470ed34686569a323._comment deleted file mode 100644 index ee761a7cef..0000000000 --- a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_3_24eadf45e4d8690470ed34686569a323._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-11-07T19:45:51Z" - content=""" -The sqlite failure does not seem to be due to the database getting too -large or anything like that, because your loop does eventually manage to -add all the files. - -Perhaps sqlite is failing intermittently for whatever reason.. -"""]] diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_4_3f44cf6a9251f664cd0e00d168232696._comment b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_4_3f44cf6a9251f664cd0e00d168232696._comment deleted file mode 100644 index 7c5d61e968..0000000000 --- a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_4_3f44cf6a9251f664cd0e00d168232696._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="webanck" - avatar="http://cdn.libravatar.org/avatar/cd273f76ef8c4218510b4f50ef7e1f3d" - subject="Similar issue again" - date="2018-08-13T14:18:17Z" - content=""" -Hello, it has been a while since I posted here about this issue with sqlite but it keeps following me! I randomly get errors while trying to lock files: -```sqlite worker thread crashed: SQLite3 returned ErrorIO while attempting to perform prepare \"SELECT null from content limit 1\": disk I/O error``` - -Should I worry about the state of my hard drive? And I don't know if it is intended, but when this happens, the process doesn't stop with a failure code, it just freezes. -I checked with top, and git-annex seems to continue doing stuff as it is still using a full core. -"""]] diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_5_2031762304c505ca15656a36250fc739._comment b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_5_2031762304c505ca15656a36250fc739._comment deleted file mode 100644 index ef807d9836..0000000000 --- a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_5_2031762304c505ca15656a36250fc739._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2018-10-08T16:45:32Z" - content=""" -I saw these crashes the last couple of times I tried git-annex in WSL, just -running `git annex test` would immediately cause them. Before that it had -used to work ok, I even saw a full test suite pass under WSL before. But it -seems that something in the emulation layer has broken to the point that -sqlite is crashing. - -I think the problem only affects using v6 mode? -"""]] diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_6_86875c51c5ddad715a3691a95113a48a._comment b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_6_86875c51c5ddad715a3691a95113a48a._comment deleted file mode 100644 index 8b397d86f7..0000000000 --- a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_6_86875c51c5ddad715a3691a95113a48a._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2018-10-30T16:23:21Z" - content=""" -I saw a different "SQLite3 returned ErrorIO while attempting to perform step", -which seems likely to be closely related to this problem. -(The "step" action happens right after the "prepare" action.) - - failed to commit changes to sqlite database: Just SQLite3 returned ErrorIO while attempting to perform step. - CallStack (from HasCallStack): - error, called at ./Database/Handle.hs:116:26 in main:Database.Handle - -The test suite occasionally fails due to this, and it seems always in -`test_lock_v7_force`. Which notably deletes the sqlite database just before -the failure, and so causes it to be re-created. - -Dumping the keys database after such a failure, it is freshly created, -contains the tables but no data has been written to it. - -I've made git-annex catch ErrorIO and retry. Not sure if that fixes the bug, -but it may. - -Please try, if you can, the new git-annex version 7, and see if this bug -still happens. -"""]] diff --git a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely.mdwn b/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely.mdwn deleted file mode 100644 index cae951e5ba..0000000000 --- a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely.mdwn +++ /dev/null @@ -1,81 +0,0 @@ -### Please describe the problem. -In a v6 repository upgraded from direct mode on a FAT filesystem, the view `/=*` replaces locally available files with placeholders and embeds their directory in the name. For example, `x3gs/one.x3g` becomes `x3gs/one_%x3gs%.x3g`. - -### What steps will reproduce the problem? -Following http://git-annex.branchable.com/forum/How_to_hide_broken_symlinks/ on a v6 repository upgraded from direct mode. - -### What version of git-annex are you using? On what operating system? -6.20180427 on NixOS. Installed via `nix-env -iA nixos.gitAndTools.git-annex`. - -### Please provide any additional information below. - -[[!format sh """ -[leo60228@digitaleo:~]$ fallocate -l $((1024*1024*1024*2)) demo.img - -[leo60228@digitaleo:~]$ mkfs.vfat demo.img -mkfs.fat 4.1 (2017-01-24) - -[leo60228@digitaleo:~]$ mkdir demo - -[leo60228@digitaleo:~]$ sudo mount -o loop,uid=${UID},gid=$(id -g $UID) demo.img demo - -[leo60228@digitaleo:~]$ cd demo - -[leo60228@digitaleo:~/demo]$ git init -Initialized empty Git repository in /home/leo60228/demo/.git/ - -[leo60228@digitaleo:~/demo]$ git commit --allow-empty -m 'init' -[master (root-commit) 8dc8e0a] init - -[leo60228@digitaleo:~/demo]$ git annex init -init - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. -ok -(recording state in git...) - -[leo60228@digitaleo:~/demo]$ mkdir subdir - -[leo60228@digitaleo:~/demo]$ echo hi > subdir/file - -[leo60228@digitaleo:~/demo]$ git annex upgrade -upgrade (v5 to v6...) (scanning for unlocked files...) -ok -(recording state in git...) - -[leo60228@digitaleo:~/demo]$ git annex add subdir/ -add subdir/file ok -(recording state in git...) - -[leo60228@digitaleo:~/demo]$ git commit -m 'add file' -[adjusted/master(unlocked) 0e870b3] add file - 1 file changed, 1 insertion(+) - create mode 100644 subdir/file - -[leo60228@digitaleo:~/demo]$ ls subdir/ -file - -[leo60228@digitaleo:~/demo]$ cat subdir/file -hi - -[leo60228@digitaleo:~/demo]$ git-annex view /=* -view (searching...) -Switched to branch 'views/_=_' -ok - -[leo60228@digitaleo:~/demo]$ ls subdir/ -file_%subdir% - -[leo60228@digitaleo:~/demo]$ cat subdir/file_%subdir% -../.git/annex/objects/zQ/MQ/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4 -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yep! I already use it to move files between my laptop's HDD and SSD, and to copy files between my many SD cards. I was trying this to see if I could not have to scroll as far on my 3D printer's menu. - -> [[done]] see comments --[[Joey]] diff --git a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_1_9b274536dd5b2f29207fa2bebf3cad28._comment b/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_1_9b274536dd5b2f29207fa2bebf3cad28._comment deleted file mode 100644 index 648d7c84ff..0000000000 --- a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_1_9b274536dd5b2f29207fa2bebf3cad28._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://openid-provider.appspot.com/iakornfeld" - nickname="iakornfeld" - subject="Another weird bit" - date="2018-05-15T14:59:42Z" - content=""" -I forgot to put this in the example, but if the file has an extension the directory name is put *before* the extension. -"""]] diff --git a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_2_b129b1642f5d21a5b933c8c51807b33c._comment b/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_2_b129b1642f5d21a5b933c8c51807b33c._comment deleted file mode 100644 index e66d61afc6..0000000000 --- a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_2_b129b1642f5d21a5b933c8c51807b33c._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-05-15T15:37:57Z" - content=""" -This has nothing to do with direct mode or v6, or the filesystem. -It is behaving more or less as intended. - -Filenames in views are always mangled to make them guaranteed to be -unique, since two files with base name "foo" could be collected into the -same view directory. This is done by embedding the directory structure -inside the filename as you show. - -In the specific case of "/=*" that is not necessary since the view -is replicating the full directory structure. But most views do need -the mangling, and I feel it's better to always do the mangling than try to -work out when it's not needed. - -And "/=*" is a mostly not useful edge case in the actual useful functionality -of views. Note my comment in the http://git-annex.branchable.com/forum/How_to_hide_broken_symlinks/ -forum post; it's not really a good way to hide missing files. -"""]] diff --git a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_3_e9c819759cc930088c82e6ed7a038a26._comment b/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_3_e9c819759cc930088c82e6ed7a038a26._comment deleted file mode 100644 index 4a4440b755..0000000000 --- a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_3_e9c819759cc930088c82e6ed7a038a26._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://openid-provider.appspot.com/iakornfeld" - nickname="iakornfeld" - subject="Looking at code" - date="2018-05-15T19:01:10Z" - content=""" -I was going to try to program this, and https://git.kitenet.net/index.cgi/git-annex.git/tree/Annex/AdjustedBranch.hs appears to have (some?) code already. If the problem has to do with it not being immutable, I was thinking of adding a `filter.*.drop` option. This would, for all filters that have this property matching the file, be called like a normal git filter when the file gets dropped. On the v6 repository filter, there would be a drop filter that's a no-op outside an adjusted branch and would remove it from the adjusted branch when on one. Other uses could include backing up dropped files to a slow, local drive (like a portable NAS with a low-RPM drive?) when they're dropped in the background, so that they wouldn't have to be redownloaded when your main server is unavailable/remote. -"""]] diff --git a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_4_17838fe16ad66af62ac809829d8ede99._comment b/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_4_17838fe16ad66af62ac809829d8ede99._comment deleted file mode 100644 index b1e15fec6a..0000000000 --- a/doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_4_17838fe16ad66af62ac809829d8ede99._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2018-10-26T16:53:47Z" - content=""" -`git annex adjust --hide-missing` is now available to do what you want -re hiding missing files. - -`git annex view` doesn't currently unlock files in a v6 repo, so it's not -usable on a crippled filesystem. That's why the cat in the transcript above -shows the symlink content which git writes to a regular file when in a -crippled filesystem. - -I would like to eventually unify adjust with view, so `git annex adjust ---unlock` can be used with a view, which would support that. -See [[todo/unify_adjust_with_view]]. -"""]] diff --git a/doc/bugs/Missing_automounts_block_every_command.mdwn b/doc/bugs/Missing_automounts_block_every_command.mdwn deleted file mode 100644 index 53af6f15a4..0000000000 --- a/doc/bugs/Missing_automounts_block_every_command.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -### Please describe the problem. -When a remote is located on a device (network) that systemd is configured to automount but fails to do so, every git-annex command blocks/waits until the automount times out. - -Commands that have to access such a remote (e.g., `sync`, `move`) are are allowed to block, but commands that only operate on the local repository (e.g., `version`, `add`, `calckey`, `find`) or another one (`sync not-doesnotexist`, `move --to=not-doesnotexist`) should not. - -The Bash completion is also affected and blocks at every tab. - -Probably related: git-annex causes **not missing** idle hard drives (as remotes) to spin up for no reason – even for local commands and completions. - -### What steps will reproduce the problem? -Add a non-existing mount point to `/etc/fstab`: - - /dev/sdoesnotexist /mnt/doesnotexist ext4 defaults,noauto,x-systemd.automount,x-systemd.device-timeout=10 0 0 - -Add a remote pointing to a path on `/mnt/doesnotexist`: - - $ git remote add doesnotexist /mnt/doesnotexist/path/to/repository - -Use any git-annex command and wait for at least `x-systemd.device-timeout`: - - $ time git-annex version > /dev/null - real 0m10.433s - user 0m0.171s - sys 0m0.028s - -### What version of git-annex are you using? On what operating system? - - git-annex version: 6.20171214-g61b515d71d - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds - dependency versions: aws-0.18 bloomfilter-2.0.1.0 cryptonite-0.24 DAV-1.3.1 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.7.1 persistent-sqlite-2.6.4 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -### Please provide any additional information below. - -`strace` always includes a call to `stat("/mnt/doesnotexist/path/to/repository")`. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I’m very happy with git-annex (thanks) and use it frequently enough to notice this behavior. - -> [[fixed|done]] via the `remote..annex-checkuuid` config setting -> that can disable this behavior. --[[Joey]] diff --git a/doc/bugs/Missing_automounts_block_every_command/comment_1_3e9ac639a2f15cc3b0d277b5fbf17db7._comment b/doc/bugs/Missing_automounts_block_every_command/comment_1_3e9ac639a2f15cc3b0d277b5fbf17db7._comment deleted file mode 100644 index 620e061e82..0000000000 --- a/doc/bugs/Missing_automounts_block_every_command/comment_1_3e9ac639a2f15cc3b0d277b5fbf17db7._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-01-09T17:02:41Z" - content=""" -There are a couple of parts to this, so let's get this one out of the way -first: Tab completion etc should not be looking at remotes. - -It seems that even `git annex --help` does for some reason; so does -stuff like `git annex examinekey`. So it's happening in a core code-path. - -Ah, ok.. Git.Config.read uses Git.Construct.fromRemotes, -which uses Git.Construct.fromAbsPath, which stats -the remote directory to handle ".git" canonicalization. - -Fixed this part of it; now only when the remoteList is built does it -stat remotes. -"""]] diff --git a/doc/bugs/Missing_automounts_block_every_command/comment_2_94e118e60c74e6ac44aa6a396d41a939._comment b/doc/bugs/Missing_automounts_block_every_command/comment_2_94e118e60c74e6ac44aa6a396d41a939._comment deleted file mode 100644 index f60b4d7062..0000000000 --- a/doc/bugs/Missing_automounts_block_every_command/comment_2_94e118e60c74e6ac44aa6a396d41a939._comment +++ /dev/null @@ -1,39 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-01-09T19:56:42Z" - content=""" -With the above dealt with, the remaining problem is with commands -like `git annex whereis` or `git annex info`, which don't really -any on any remote, but still need to examine the remotes as part of -building the remoteList. - -git-annex supports remotes that point to a mount point that might have -different drives mounted at it at different times. So, it needs to -check the git config of the remote each time, to see what repository is -currently there. - -Even commands like "whereis" and "info" have output that depends on -what repository a remote is currently pointing to. In some cases, -"whereis" might not output anything that depends on a given remote, -so in theory it could avoid looking at the config of that remote. -And a command like "git annex copy --to origin" doesn't really -need to look at the configs of any other remotes. - -But to avoid unncessarily checking the git configs of remotes that a -command does not use would need each use of the current remoteList -to be replaced with something else that does the minimal needed work, -instead of building the whole remoteList. I think this would be quite -complicated. - -And, I don't know that it would address the bug report adequequately, even -if it were done. Running `git annex info` would -still block waiting for the automount; `git annex whereis` would -only *sometimes* block, depending on where content is. - -So instead of that approach, perhaps a config setting will do? -A per-remote config that tells git-annex that only one repository -should ever be mounted at its location. That would make git-annex -avoid checking the git config of that remote each time, except -when it's actually storing/dropping content on it. -"""]] diff --git a/doc/bugs/Missing_automounts_block_every_command/comment_3_c7d5015db5aea0dd4d2ed67803ee9c92._comment b/doc/bugs/Missing_automounts_block_every_command/comment_3_c7d5015db5aea0dd4d2ed67803ee9c92._comment deleted file mode 100644 index a2dae9620c..0000000000 --- a/doc/bugs/Missing_automounts_block_every_command/comment_3_c7d5015db5aea0dd4d2ed67803ee9c92._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-01-09T20:29:40Z" - content=""" -There would still be some cases where a git-annex command blocks somewhat -unexpectedly on the automount. - -For one, `git annex drop` can need to -check if content is in a remote, and so would block, despite not acting -directly on that remote. - -And, `git annex get` of a file that's located in -such an locally automounted remote and a network remote will -default to trying the local remote first, and so would block. - -The cost of the automounted remote could be adjusted to make these commands -prefer some other remote, but then you've configured git-annex to not -use the automounted remote much, which is probably not what you really want -to do if it's a fast drive. - -Of course, there are also ways to automount removable drives when they get -plugged in, rather than using automounts that block on access, and so -neatly avoid all blocking problems. -"""]] diff --git a/doc/bugs/Missing_automounts_block_every_command/comment_4_c3cfb1c27806c45dfa6ebf275c175d3e._comment b/doc/bugs/Missing_automounts_block_every_command/comment_4_c3cfb1c27806c45dfa6ebf275c175d3e._comment deleted file mode 100644 index 31f97beeba..0000000000 --- a/doc/bugs/Missing_automounts_block_every_command/comment_4_c3cfb1c27806c45dfa6ebf275c175d3e._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2018-01-10T17:37:42Z" - content=""" -Added remote..annex-checkuuid config, which can be set to false -to disable the default checking of the uuid. It will still check before -making any modification of the remote repository. - -There may still be situations where using this kind of automount is suboptimal -with git-annex, as outlined in comment 3, but I think this is as far as it makes -sense to change git-annex to deal with them. -"""]] diff --git a/doc/bugs/Missing_backend_extension_in_files_with_long_extensions.mdwn b/doc/bugs/Missing_backend_extension_in_files_with_long_extensions.mdwn deleted file mode 100644 index d554a390a7..0000000000 --- a/doc/bugs/Missing_backend_extension_in_files_with_long_extensions.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -### Please describe the problem. - -Adding a file with a long extension, like Apple Numbers file (for example budget.numbers) results in it being added to the backend without file extension at all. - -### What steps will reproduce the problem? -[[!format sh """ -$ touch budget.numbers -$ git-annex add budget.numbers -add budget.numbers ok -(recording state in git...) -$ git-annex lookupkey budget.numbers -SKEIN256E-s0--c8877087da56e072870daa843f176e9453115929094c3a40c463a196c29bf7ba -$ touch budget.num -$ git annex add budget.num -add budget.num ok -(recording state in git...) -$ git annex lookupkey budget.num -SKEIN256E-s0--c8877087da56e072870daa843f176e9453115929094c3a40c463a196c29bf7ba.num -"""]] -### What version of git-annex are you using? On what operating system? -[[!format sh """ -$ git-annex version -git-annex version: 6.20180807 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13.1 persistent-sqlite-2.6.4 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: darwin x86_64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -local repository version: 5 -"""]] - -macOS 10.13.6 - -### Please provide any additional information below. - -macOS isn't able to open a file without extension. In order to just view it, I have to `git annex unlock` it, so that there's a real file with an extension. Is there a way to tell macOS to use symlink extension instead? Or other workaround? - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yup, I've been using it for 5 years. It's awesome! Thank you. - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Missing_backend_extension_in_files_with_long_extensions/comment_1_69f8ce0c55af2667b2977d19b173fb83._comment b/doc/bugs/Missing_backend_extension_in_files_with_long_extensions/comment_1_69f8ce0c55af2667b2977d19b173fb83._comment deleted file mode 100644 index 7ce0d1687d..0000000000 --- a/doc/bugs/Missing_backend_extension_in_files_with_long_extensions/comment_1_69f8ce0c55af2667b2977d19b173fb83._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-10-04T19:30:23Z" - content=""" -The problem is that "foo.numbers" may appear to have an extension to you, -but "foo.doesnothaveanextension" appears to me to not have an extension. - -(And I doubt I'd consider ".numbers" to be an extension either because it's -much longer than any usual extension and looks like like an english word. -"I.like.numbers" does not have an extension IMHO.) - -So, git-annex has to somehow guess, and it does this by assuming that all -common filename extensions are less than 4 letters (not including the dot). - -The annex.maxextensionlength setting was recently added which lets you tune -this. -"""]] diff --git a/doc/bugs/Missing_backend_extension_in_files_with_long_extensions/comment_2_58c42e1f0dcb827f788ead011dd61981._comment b/doc/bugs/Missing_backend_extension_in_files_with_long_extensions/comment_2_58c42e1f0dcb827f788ead011dd61981._comment deleted file mode 100644 index 6f5a41e1b0..0000000000 --- a/doc/bugs/Missing_backend_extension_in_files_with_long_extensions/comment_2_58c42e1f0dcb827f788ead011dd61981._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="pz63@5ea0a27986d782e467e1ebef6eb31ba440cc58d5" - nickname="pz63" - avatar="http://cdn.libravatar.org/avatar/6268f09b18a71aafa3ad68ecd8a20d50" - subject="comment 2" - date="2018-10-12T15:49:00Z" - content=""" -Makes sense. Thank you very much! -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD.mdwn b/doc/bugs/More_build_oddities_under_OpenBSD.mdwn deleted file mode 100644 index f36604c575..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. -I have managed to get most things working under OpenBSD 5.4 now. - -One of the last hurdles is that if I enable XMPP the build fails on "Loading package gnuidn-0.2.1..." -See the error below. - -I suspect this is an error in git-annex because network-protocol-xmpp AND gnuidn compiles (and links) fine. - -I will gladly do anything I can to get this working, but I'm at a loss what to do right now. It's the last major piece of the puzzle before I get it properly functioning under OpenBSD. - -### What steps will reproduce the problem? -Building with XMPP support under OpenBSD 5.4 - -### What version of git-annex are you using? On what operating system? -5.20140129 under OpenBSD 5.4 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -Loading package gnuidn-0.2.1 ... - -GHCi runtime linker: fatal error: I found a duplicate definition for symbol - c_isascii -whilst processing object file - /usr/local/lib/libidn.a -This could be caused by: - * Loading two different object files which export the same symbol - * Specifying the same object file twice on the GHCi command line - * An incorrect `package.conf' entry, causing some object to be - loaded twice. -GHCi cannot safely continue in this situation. Exiting now. Sorry. - - -# End of transcript or log. -"""]] - -> Since this bug was filed, git-annex has dropped xmpp and the problimatic -> libraries. Since the bug comments say the build worked without xmpp, -> closing this bug [[done]] --[[Joey]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_10_09297f99f3c1c081738ca4ab32808fde._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_10_09297f99f3c1c081738ca4ab32808fde._comment deleted file mode 100644 index e3871ea612..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_10_09297f99f3c1c081738ca4ab32808fde._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.163" - subject="comment 10" - date="2014-02-08T18:31:23Z" - content=""" -But you said that setSocketOption failed when you were using XMPP, not when starting the webapp, so I think it's more likely to be one of the setSocketOption calls in the network library, or possibly somewhere else. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_11_1407efc78b92a3c6156154f54e4a14e2._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_11_1407efc78b92a3c6156154f54e4a14e2._comment deleted file mode 100644 index 78c430533d..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_11_1407efc78b92a3c6156154f54e4a14e2._comment +++ /dev/null @@ -1,97 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 11" - date="2014-02-08T19:18:17Z" - content=""" -I honestly have no idea why that move works because - - % ls -lh /usr/lib|grep -E '(gsasl|xml2|gnutls|idn)' - -returns nothing. But couldn't those symbols already be in the other libraries considering, from what I've read at least, haskell stuff are statically compiled by default? - -Anyway, you are completely right that this happened when I try to use XMPP. The reason I was looking in the wrong place to begin with was because the webapp spit out the error messsage. I have redirected my attention to the network library and the xmpp library. - -But I might have found something interesting in the network library. Keep in mind that I just learned a little today, so do correct me if I'm wrong. - -Looking at http://hackage.haskell.org/package/network-2.2.1.8/docs/src/Network-Socket.html I found: - - setSocketOption :: Socket - -> SocketOption -- Option Name - -> Int -- Option Value - -> IO () - setSocketOption (MkSocket s _ _ _ _) so v = do - with (fromIntegral v) $ \ptr_v -> do - throwErrnoIfMinus1_ \"setSocketOption\" $ - c_setsockopt s (socketOptLevel so) (packSocketOption so) ptr_v - (fromIntegral (sizeOf v)) - return () - -Everything here looks good. So I decided to take a look at SocketOption, socketOptLevel and packSocketOption. - - data SocketOption - = DummySocketOption__ - | Debug {- SO_DEBUG -} - | ReuseAddr {- SO_REUSEADDR -} - | Type {- SO_TYPE -} - | SoError {- SO_ERROR -} - | DontRoute {- SO_DONTROUTE -} - | Broadcast {- SO_BROADCAST -} - | SendBuffer {- SO_SNDBUF -} - | RecvBuffer {- SO_RCVBUF -} - | KeepAlive {- SO_KEEPALIVE -} - | OOBInline {- SO_OOBINLINE -} - | TimeToLive {- IP_TTL -} - | MaxSegment {- TCP_MAXSEG -} - | NoDelay {- TCP_NODELAY -} - | Linger {- SO_LINGER -} - | RecvLowWater {- SO_RCVLOWAT -} - | SendLowWater {- SO_SNDLOWAT -} - | RecvTimeOut {- SO_RCVTIMEO -} - | SendTimeOut {- SO_SNDTIMEO -} - - socketOptLevel :: SocketOption -> CInt - socketOptLevel so = - case so of - TimeToLive -> 0 - MaxSegment -> 6 - NoDelay -> 6 - _ -> 1 - - packSocketOption :: SocketOption -> CInt - packSocketOption so = - case so of - Debug -> 1 - ReuseAddr -> 2 - Type -> 3 - SoError -> 4 - DontRoute -> 5 - Broadcast -> 6 - SendBuffer -> 7 - RecvBuffer -> 8 - KeepAlive -> 9 - OOBInline -> 10 - TimeToLive -> 2 - MaxSegment -> 2 - NoDelay -> 1 - Linger -> 13 - RecvLowWater -> 18 - SendLowWater -> 19 - RecvTimeOut -> 20 - SendTimeOut -> 21 - -Everything looks good so I thought long and hard about this. Then, by chance, I just looked at the man page for setsockopt() and it mentioned SOL_SOCKET and I was like \"Hmm...\" - - % grep -R SOL_SOCKET /usr/include - /usr/include/openssl/e_os.h:#define ioctlsocket(a,b,c) setsockopt((a),SOL_SOCKET,(b),(c),sizeof(*(c))) - /usr/include/sys/socket.h:#define SOL_SOCKET 0xffff /* options for socket level */ - /usr/include/sys/socket.h:/* Read using getsockopt() with SOL_SOCKET, SO_PEERCRED */ - -Wat? - - #define SOL_SOCKET 0xffff - -Going back to the Haskell code above I realized that SetSocketOption will NEVER feed 0xffff as level to setsockopt() because socketOptLevel returns 1 unless optname is TimeToLive, MaxSegment or NoDelay. - -Am I way off? -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_12_fdec033e37652c51fbcd74438586d285._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_12_fdec033e37652c51fbcd74438586d285._comment deleted file mode 100644 index 77c8edc68a..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_12_fdec033e37652c51fbcd74438586d285._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.163" - subject="comment 12" - date="2014-02-08T20:03:30Z" - content=""" -WRT haskell static linking, AFAIK that only affects haskell libraries. If they in turn link with C libs, the linking is still dynamic. At least this is the case on both Linux and the limited BSDs I've used it on. Have no OpenBSD experience. - -`SOL_SOCKET` is 1 on linux, so you may have the culprit. - -However.. That's a really old version of network! 2.2.1.8 is from 2010. In a more current 2.4.x version, packSocketOption uses the `SOL_SOCKET` value and not 1, so should work AFAICS. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_13_ed3716baf787ca17d227ce2e327a1959._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_13_ed3716baf787ca17d227ce2e327a1959._comment deleted file mode 100644 index 3981d32bfd..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_13_ed3716baf787ca17d227ce2e327a1959._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.163" - subject="comment 13" - date="2014-02-08T20:12:12Z" - content=""" -Does your binary end up dynamically linked to libxml2 etc? If not, it certianly seems plausible that the haskell libs statically linked with the C libs, and then at binary link time it tried to redundantly link with the libs again and failed. If this is the case, it seems it would probably be a bug in ghc. You can use `cabal build --ghc-options=-v` to get a look at how the linker is run. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_14_cf5f92e5cdfc738e7f6178c1d7a73ceb._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_14_cf5f92e5cdfc738e7f6178c1d7a73ceb._comment deleted file mode 100644 index bb4d095a37..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_14_cf5f92e5cdfc738e7f6178c1d7a73ceb._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 14" - date="2014-02-08T20:29:46Z" - content=""" -Sigh.. Ofcourse it was an old version. It never occurred to me to check that. I was just Googling around and stumbled over that page. -Do you have any pointers on how I would debug this further? - -Regarding the linking; I haven't checked it any further actually. I'm planning on investigating that further once I can get this error sorted out. But my hypothesis is that it's all statically linked all the way through, like I said. That would also explain those error messages I got during linking before. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_15_ad4b7191c9b8f67def33b26a1d762a5d._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_15_ad4b7191c9b8f67def33b26a1d762a5d._comment deleted file mode 100644 index 4aeda69ebf..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_15_ad4b7191c9b8f67def33b26a1d762a5d._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.163" - subject="comment 15" - date="2014-02-08T20:56:10Z" - content=""" -I think you need to find which calls to setSocketOption are failing and/or what value is causing the crash. It's a bit of a pain to get a backtrace on error (would need to build everything with profiling enabled and run git-annex with +RTS -xc options). Probably simplest to modify the setSocketOption code: - -[[!format patch \"\"\" -diff --git a/Network/Socket.hsc b/Network/Socket.hsc -index 2fe62ee..0c66432 100644 ---- a/Network/Socket.hsc -+++ b/Network/Socket.hsc -@@ -963,7 +963,7 @@ setSocketOption :: Socket - setSocketOption (MkSocket s _ _ _ _) so v = do - (level, opt) <- packSocketOption' \"setSocketOption\" so - with (fromIntegral v) $ \ptr_v -> do -- throwSocketErrorIfMinus1_ \"setSocketOption\" $ -+ throwSocketErrorIfMinus1_ (\"setSocketOption \" ++ show so ++ \" \" ++ show v) $ - c_setsockopt s level opt ptr_v - (fromIntegral (sizeOf (undefined :: CInt))) - return () -\"\"\"]] - -Which should make it print out a quite nice symbolic name of the option being used on failure, which will make it easy to find any call sites and more importantly, determine what's wrong with that option. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_16_2e765b5286d816bea00880a17a20cbfb._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_16_2e765b5286d816bea00880a17a20cbfb._comment deleted file mode 100644 index def40653da..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_16_2e765b5286d816bea00880a17a20cbfb._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 16" - date="2014-02-08T21:08:38Z" - content=""" -Thanks for that code snippet! I'll try it out within the next few minutes. - -Also, how would I go about rebuilding everything with profiling support? I'm doing this testing in a virtual machine so I can always start over from scratch. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_17_ded9011dcdbe4de05189a0e8d040f045._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_17_ded9011dcdbe4de05189a0e8d040f045._comment deleted file mode 100644 index f361268419..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_17_ded9011dcdbe4de05189a0e8d040f045._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.163" - subject="comment 17" - date="2014-02-08T21:23:02Z" - content=""" -Blow away ~/.ghc and ~/.cabal; cabal update; put `library-profiling: True` in ~/.cabal/config; and reinstall everything. - -Note that you may need to first build ghc's own bundled libraries with profiling support, if your ghc installation does not already include them. I don't know how to do that since on debian I can just `apt-get install ghc-prof`. If that's needed, ghc will tell you and refuse to build stuff with profiling. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_18_f7a85b46bf7afaaf431d6771219c66b0._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_18_f7a85b46bf7afaaf431d6771219c66b0._comment deleted file mode 100644 index d8d73a0b77..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_18_f7a85b46bf7afaaf431d6771219c66b0._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 18" - date="2014-02-08T23:25:29Z" - content=""" -I applied your patch and rebuilt. I even tried doing it from scratch just to get it right. - -I have three news: - -1) I got it completely working in a virtual machine - -2) On my actual (physical) openbsd machine it still isn't working, even though they're almost identical. The only difference is that the physical one also has IPv6 connectivity, while the virtual machine doesn't. Could that be it? I don't know yet, although I'm about to try it. - -3) Your patch did not help. It still didn't print out anything more useful, suggesting that it in fact isn't that function that is throwing the error. [This](http://i.imgur.com/tmBiseE.png) is what the actual error looks like and shows up after I enter the jabber account details. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_19_217be2000e423e844241d405ba9f64c8._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_19_217be2000e423e844241d405ba9f64c8._comment deleted file mode 100644 index 7ea52c150a..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_19_217be2000e423e844241d405ba9f64c8._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.172" - subject="comment 19" - date="2014-02-09T02:13:20Z" - content=""" -I'll bet you didn't rebuild all the libraries that depend on network. (Which all that static linking makes necessary...) - -IPv6 was my first guess; see http://git-annex.branchable.com/bugs/More_build_oddities_under_OpenBSD/#comment-84ee81cd162d22283fcccc1a41c8f8b3 -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_1_4ffea64907656ff2ec65ff4450aadda7._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_1_4ffea64907656ff2ec65ff4450aadda7._comment deleted file mode 100644 index f2ac7af8f0..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_1_4ffea64907656ff2ec65ff4450aadda7._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="71.80.94.56" - subject="comment 1" - date="2014-02-07T18:49:38Z" - content=""" -This is definitely not an issue in git-annex's code. Two C libraries are exporting the same symbol (gnulib might be the other one, or it could be part of the OpenBSD libc as it's some deprecated POSIX symbol, I don't know) and this is simply not apparent until the linker tries to make a binary linking with both. - -I have dealt with a similar issue on Android by modifying C libraries to not export colliding symbols. See: - -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_20_df72e5698ba2bf2eb4fa39c5b2c5be83._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_20_df72e5698ba2bf2eb4fa39c5b2c5be83._comment deleted file mode 100644 index 29e58e1564..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_20_df72e5698ba2bf2eb4fa39c5b2c5be83._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.172" - subject="comment 20" - date="2014-02-20T20:26:03Z" - content=""" -Any further luck on this? - -It would be nice if a page on openbsd could be added to the install page documenting what is needed to get it to build. -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_21_8a7f5a87bbd4289362f8f4609c02322d._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_21_8a7f5a87bbd4289362f8f4609c02322d._comment deleted file mode 100644 index 5befc39dbe..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_21_8a7f5a87bbd4289362f8f4609c02322d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 21""" - date="2015-02-06T20:34:17Z" - content=""" -C-Keen on irc: -for the record git-annex works fine on openbsd-current (5.7) without xmpp -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_2_4fb96984757b3d37a1a5ebce664aa8fe._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_2_4fb96984757b3d37a1a5ebce664aa8fe._comment deleted file mode 100644 index 248f7fb335..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_2_4fb96984757b3d37a1a5ebce664aa8fe._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 2" - date="2014-02-07T19:38:14Z" - content=""" -I do realize that it's not a fault in git-annex' code. I'm sorry if it was a stupid idea to post it here, but I was thinking if there exists some kind of workaround one could implement in the build system. I mean.. This isn't the first time someone compiles a program with libidn, gettext and/or gnutls (According to 'grep -R c_isascii /usr') -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_3_c5fdf29499a02be83850d1238fc8ce23._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_3_c5fdf29499a02be83850d1238fc8ce23._comment deleted file mode 100644 index ee7c537d91..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_3_c5fdf29499a02be83850d1238fc8ce23._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 3" - date="2014-02-07T20:57:54Z" - content=""" -I have researched this a little more and I am not entirely convinced it is an actual conflict anywhere. I did, in fact, compile a patched version of libidn WITHOUT the c_isascii symbols and.. It suddenly started complaining about even MORE symbols (stringprep_utf8_to_unichar). -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_4_d42106128c3dac2dd7761a82cc03912f._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_4_d42106128c3dac2dd7761a82cc03912f._comment deleted file mode 100644 index 9677848d3d..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_4_d42106128c3dac2dd7761a82cc03912f._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 4" - date="2014-02-07T22:12:43Z" - content=""" -Couldn't it be possible that something is passed twice on the command line, like that message says could be the reason? Because I have inspected my systems and the only thing I can find that even contains such a string (stringprep_utf8_to_unichar) is libidn so there shouldn't be any conflicts. - -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_5_71166beb796f22dcee065a167cd5e0ed._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_5_71166beb796f22dcee065a167cd5e0ed._comment deleted file mode 100644 index a2772452d2..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_5_71166beb796f22dcee065a167cd5e0ed._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 5" - date="2014-02-08T14:46:10Z" - content=""" -Okay, so I did work around this with an ugly hack (I'm not even sure it will work properly) so I now have XMPP support, according to git-annex. - -But.. When I try to play around with XMPP I get: - - setSocketOption: invalid argument (Invalid argument) -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_6_65913a2de8bbe981beaa66c58d2429b5._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_6_65913a2de8bbe981beaa66c58d2429b5._comment deleted file mode 100644 index ff76fb3ded..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_6_65913a2de8bbe981beaa66c58d2429b5._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 6" - date="2014-02-08T17:23:54Z" - content=""" -Googling around I found [this](http://lpaste.net/77947) codesnippet that suggests setSocketOption is broken under OpenBSD -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_7_8dd46cec230125d1410d8e6824aeddf2._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_7_8dd46cec230125d1410d8e6824aeddf2._comment deleted file mode 100644 index 72b427357a..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_7_8dd46cec230125d1410d8e6824aeddf2._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.163" - subject="comment 7" - date="2014-02-08T17:42:52Z" - content=""" -What was the ugly hack that got it to link? - -I've seen setSocketOption fail on other OS's for various portability reasons. The haskell library that is responsible for this is , and you can find several setSocketOption calls in it. I've had good luck ifdefing those out when they don't work. - -Here's a patch where I disable the IPv6Only setting on Android (amoung other unrelated porting) -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_8_275d3e62cb5667a2d6ddd90db7a40bff._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_8_275d3e62cb5667a2d6ddd90db7a40bff._comment deleted file mode 100644 index f7f7e34291..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_8_275d3e62cb5667a2d6ddd90db7a40bff._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" - nickname="dxtrish" - subject="comment 8" - date="2014-02-08T18:13:33Z" - content=""" -What I did was to temporarily move away (or rename) the offending libs. What I essentially did was this: - - cabal configure - cabal build - sudo mv /usr/local/lib/lib{xml2,gnutls,gsasl,idn}.a /tmp - cabal install - sudo mv /tmp/lib{xml2,gnutls,gsasl,idn}.a /usr/local/lib - -but I've also had to patch network-info. I've contacted the maintainer of that package but I haven't received anything. I'm considering creating an actual fork with my changes but that would almost seem kind of silly as I don't know *ANY* haskell.. But I am looking at the Haskell wiki as I'm typing this so I can see what I'm looking at :). - -Won't break anything by not setting SO_REUSEADDR? I suspect you're setting it for a reason? -"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_9_ec6a1eb6c7b264c23ec4bbd45465d7d8._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_9_ec6a1eb6c7b264c23ec4bbd45465d7d8._comment deleted file mode 100644 index dee77a69f8..0000000000 --- a/doc/bugs/More_build_oddities_under_OpenBSD/comment_9_ec6a1eb6c7b264c23ec4bbd45465d7d8._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.163" - subject="comment 9" - date="2014-02-08T18:29:41Z" - content=""" -So you moved away libs in /usr/local to expose usable ones in /usr? - -I've had luck before sending the network-info mantainer pull requests: - -git-annex does set ReuseAddr in one place; in Utility/Webapp.hs. The only time that would have a benefit would be when using `git annex webapp --listen=address:port` and starting and restarting the webapp. Normally the webapp chooses a random free port so it shouldn't need that. -"""]] diff --git a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others.mdwn b/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others.mdwn deleted file mode 100644 index f67d73ba43..0000000000 --- a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others.mdwn +++ /dev/null @@ -1,251 +0,0 @@ -### Please describe the problem. - -For shared repositories git annex refuses to move file out of repository (git annex move --to) if user triggering the move is not the owner of the file. - -### What steps will reproduce the problem? - - * Init two shared repositories and create a file - * Modify that file in repo1 as user u1 - * Move the file to repo2 as "repository maintenance" user u2 - - this gives permission denied error - -Alternatively -- mabye better understandable usecase(repository maintainer moves unused files to backup): - - * Init two shared repositories and create a file - * Modify that file in repo1 as user u1 - * Modify that file in repo1 a second time (regardless which user) -- this makes the version edited by u1 unused - * Display unused files as repository maintenance user u2 - - this gives permission denied error - * Move unused files to repo2 as "repository maintenance" user u2 - - this gives permission denied error - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -stefan@atom-linux:/tmp/git-annex-test/a$ git --version -git version 2.6.2 -stefan@atom-linux:/tmp/git-annex-test/a$ git annex version -git-annex version: 5.20150610+gitg608172f-1~ndall+1 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 -stefan@atom-linux:/tmp/git-annex-test/a$ uname -a -Linux atom-linux 3.13.0-66-generic #108-Ubuntu SMP Wed Oct 7 15:21:40 UTC 2015 i686 i686 i686 GNU/Linux -"""]] - -### Please provide any additional information below. - -[[!format sh """ - -# init two shared repositories and create a file "file.txt" - -stefan@atom-linux:/tmp/git-annex-test$ mkdir a -stefan@atom-linux:/tmp/git-annex-test$ mkdir b -stefan@atom-linux:/tmp/git-annex-test$ sudo chown :fileadmin-data * -stefan@atom-linux:/tmp/git-annex-test$ sudo chmod g+s * -stefan@atom-linux:/tmp/git-annex-test$ cd a -stefan@atom-linux:/tmp/git-annex-test/a$ git init --shared . -Initialized empty shared Git repository in /tmp/git-annex-test/a/.git/ -stefan@atom-linux:/tmp/git-annex-test/a$ git config core.sharedrepository group -stefan@atom-linux:/tmp/git-annex-test/a$ echo "test" >> file.txt -stefan@atom-linux:/tmp/git-annex-test/a$ ls -al -total 16 -drwxrwsr-x 3 stefan fileadmin-data 4096 Nov 1 16:41 . -drwxrwxr-x 4 stefan stefan 4096 Nov 1 16:39 .. --rw-rw-r-- 1 stefan fileadmin-data 5 Nov 1 16:41 file.txt -drwxrwsr-x 7 stefan fileadmin-data 4096 Nov 1 16:40 .git -stefan@atom-linux:/tmp/git-annex-test/a$ git annex init -init ok -(recording state in git...) -stefan@atom-linux:/tmp/git-annex-test/a$ git annex add file.txt -add file.txt ok -(recording state in git...) -stefan@atom-linux:/tmp/git-annex-test/a$ git commit -m "new file" -[master (root-commit) 7aeaa5f] new file - 1 file changed, 1 insertion(+) - create mode 120000 file.txt -stefan@atom-linux:/tmp/git-annex-test/a$ cd .. -stefan@atom-linux:/tmp/git-annex-test$ cd b -stefan@atom-linux:/tmp/git-annex-test/b$ git clone -o a ssh://127.0.0.1/tmp/git-annex-test/a . -Cloning into '.'... -remote: Counting objects: 13, done. -remote: Compressing objects: 100% (9/9), done. -remote: Total 13 (delta 0), reused 0 (delta 0) -Receiving objects: 100% (13/13), done. -Checking connectivity... done. -stefan@atom-linux:/tmp/git-annex-test/b$ git config core.sharedrepository group -stefan@atom-linux:/tmp/git-annex-test/b$ git annex init "B" -init B (merging a/git-annex into git-annex...) -(recording state in git...) -ok -(recording state in git...) -stefan@atom-linux:/tmp/git-annex-test/b$ cd .. -stefan@atom-linux:/tmp/git-annex-test$ cd a -stefan@atom-linux:/tmp/git-annex-test/a$ git remote add b ssh://127.0.0.1/tmp/git-annex-test/b -stefan@atom-linux:/tmp/git-annex-test/a$ git annex sync -commit ok -pull b -remote: Counting objects: 6, done. -remote: Compressing objects: 100% (5/5), done. -remote: Total 6 (delta 0), reused 1 (delta 0) -Unpacking objects: 100% (6/6), done. -From ssh://127.0.0.1/tmp/git-annex-test/b - * [new branch] git-annex -> b/git-annex - * [new branch] master -> b/master -ok -(merging b/git-annex into git-annex...) -push b -Total 0 (delta 0), reused 0 (delta 0) -To ssh://127.0.0.1/tmp/git-annex-test/b - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master -ok -stefan@atom-linux:/tmp/git-annex-test/a$ git annex move file.txt --to b -move file.txt (checking b...) (to b...) -SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2.txt - 5 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1) -ok -(recording state in git...) - -## ok, everything fine so far - we have a file "file.txt" which was created in a and moved to b successfully. -## Now we go to a different user account and modify "file.txt" -## -------------------------------------- userswitch - -unison@atom-linux:/tmp/git-annex-test/a$ git annex get file.txt -get file.txt (from b...) -SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2.txt - 5 100% 4.88kB/s 0:00:00 (xfr#1, to-chk=0/1) -ok -(recording state in git...) -unison@atom-linux:/tmp/git-annex-test/a$ git annex unlock file.txt -unlock file.txt (copying...) ok -unison@atom-linux:/tmp/git-annex-test/a$ ls -al -total 16 -drwxrwsr-x 3 stefan fileadmin-data 4096 Nov 1 16:48 . -drwxrwxr-x 4 stefan stefan 4096 Nov 1 16:39 .. --rw-rw-r-- 1 unison fileadmin-data 5 Nov 1 16:47 file.txt -drwxrwsr-x 9 stefan fileadmin-data 4096 Nov 1 16:44 .git -unison@atom-linux:/tmp/git-annex-test/a$ echo "a change by unison user" >> file.txt -unison@atom-linux:/tmp/git-annex-test/a$ git annex add . -add file.txt ok -(recording state in git...) -unison@atom-linux:/tmp/git-annex-test/a$ git commit -m "unison change" -[master 37bd55d] unison change - 1 file changed, 1 insertion(+), 1 deletion(-) - -## now the original user / repository maintainer wants to move the file -## out to b which gives an permission denied error for setFileMode -## git annex does copy it to b, but not remove it from a -## -------------------------------------- userswitch - -stefan@atom-linux:/tmp/git-annex-test/a$ ls -al -total 16 -drwxrwsr-x 3 stefan fileadmin-data 4096 Nov 1 16:48 . -drwxrwxr-x 4 stefan stefan 4096 Nov 1 16:39 .. -lrwxrwxrwx 1 unison fileadmin-data 188 Nov 1 16:48 file.txt -> .git/annex/objects/8x/7w/SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.tx -t/SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt -drwxrwsr-x 9 stefan fileadmin-data 4096 Nov 1 16:48 .git -stefan@atom-linux:/tmp/git-annex-test/a$ git annex move file.txt --to b -move file.txt (checking b...) (to b...) -SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt - 29 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1) -git-annex: failed to lock content: .git/annex/objects/8x/7w/SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt/SHA256E-s29--6aec68aad4745c6 -eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt: setFileMode: permission denied (Operation not permitted) - -# which makes sense - the file is owned by other user: -stefan@atom-linux:/tmp/git-annex-test/a$ ls -al .git/annex/objects/8x/7w/SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt/SHA256E-s29--6 -aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt --r--r--r-- 1 unison fileadmin-data 29 Nov 1 16:48 .git/annex/objects/8x/7w/SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt/SHA256E-s29- --6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt - -## the last editor of the file can move it, though: -## -------------------------------------- userswitch -unison@atom-linux:/tmp/git-annex-test/a$ git annex move file.txt --to b -move file.txt (checking b...) ok -(recording state in git...) - -## continued - for second usecase... -## edit file two more times as unison user: - -unison@atom-linux:/tmp/git-annex-test/a$ git annex unlock file.txt -unlock file.txt (copying...) ok -unison@atom-linux:/tmp/git-annex-test/a$ echo "another unison modification" >> file.txt -unison@atom-linux:/tmp/git-annex-test/a$ ls -file.txt -unison@atom-linux:/tmp/git-annex-test/a$ git annex add -add file.txt ok -(recording state in git...) -unison@atom-linux:/tmp/git-annex-test/a$ git commit -m "another unison change" -[master df85491] another unison change - 1 file changed, 1 insertion(+), 1 deletion(-) -unison@atom-linux:/tmp/git-annex-test/a$ git annex unlock file.txt -unlock file.txt (copying...) ok -(recording state in git...) -unison@atom-linux:/tmp/git-annex-test/a$ echo "changes once more" >> file.txt -unison@atom-linux:/tmp/git-annex-test/a$ git annex add . -add file.txt ok -(recording state in git...) -unison@atom-linux:/tmp/git-annex-test/a$ git commit -m "1 more" -[master 099a2c7] 1 more - 1 file changed, 1 insertion(+), 1 deletion(-) - -unison@atom-linux:/tmp/git-annex-test/a$ git annex unused -unused . (checking for unused data...) (checking b/master...) (checking master...) - Some annexed data is no longer used by any files: - NUMBER KEY - 1 SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt - 2 SHA256E-s57--dc131ed3874c3b51a6801c43f5d5c0706a9aea58134459eeddf3436626adc89f.txt - (To see where data was previously used, try: git log --stat -S'KEY') - - To remove unwanted data: git-annex dropunused NUMBER - -ok - -## switch to repository maintenance user and list unused: -## -------------------------------------- userswitch - -stefan@atom-linux:/tmp/git-annex-test/a$ git annex unused --debug -unused . (checking for unused data...) [2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","--others","-z"," ---","."] -[2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"] -[2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"] -[2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref"] -(checking b/master...) [2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--head"] -[2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--head"] -[2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff-index","-z","--raw","--no-renames","-l0","refs/remotes/b/master","--"] -[2015-11-01 17:35:09 CET] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -(checking master...) [2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--head"] -[2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--head"] -[2015-11-01 17:35:09 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff-index","-z","--raw","--no-renames","-l0","refs/heads/master","--"] - - Some annexed data is no longer used by any files: - NUMBER KEY - 1 SHA256E-s29--6aec68aad4745c6eb7babaa5f66fb727e896ec47414edfd4fec8136a1db8484e.txt - 2 SHA256E-s57--dc131ed3874c3b51a6801c43f5d5c0706a9aea58134459eeddf3436626adc89f.txt - (To see where data was previously used, try: git log --stat -S'KEY') - - To remove unwanted data: git-annex dropunused NUMBER - - -git-annex: .git/annex/unused: openFile: permission denied (Permission denied) -failed -git-annex: unused: 1 failed - - -stefan@atom-linux:/tmp/git-annex-test/a$ git annex move --unused --to b -git-annex: .git/annex/unused: openFile: permission denied (Permission denied) -stefan@atom-linux:/tmp/git-annex-test/a$ git annex move --debug --unused --to b -[2015-11-01 17:38:48 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2015-11-01 17:38:48 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2015-11-01 17:38:48 CET] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4cdcc1b4550b2737e018d382022f3ce3e1dcb029","-n1"," ---pretty=%H"] -[2015-11-01 17:38:48 CET] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -git-annex: .git/annex/unused: openFile: permission denied (Permission denied) - -# End of transcript or log. -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment b/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment deleted file mode 100644 index 90491e5629..0000000000 --- a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-18T19:35:52Z" - content=""" -More simply stated, user A adds a file, which sets its perms to 444, and -user B can't change those perms to lock the file for removal. - -In sharedRepository mode, the object directory's perms are already -weakened, to eg 775 rather than the default 555, for the same reason; -another user with shared access can't chmod the object directory to allow -writing to it. That just needs to be extended from object directory to -object file to fix this. - -But, that means that the object file will be mode 664, rather than -444, and so git-annex can't prevent accidental direct modifications of the -content of objects when in sharedRepository mode, like it normally does. - -Since that's a belt and suspenders protection, and since the object -directory permissions weakening already lost a similar protection against -accidental deletion of object files, shrug, I guess we'll do that. - -I do feel that sharedRepository mode rarely ever makes sense to use. It's -very fiddly to get the permissions set up right and keep them right, and -there are much better ways to share a centralized repo between users, eg -use gitolite or a dedicated account that's locked down to only let -git/git-annex commands be run. -"""]] diff --git a/doc/bugs/No_MonadFail_instance.mdwn b/doc/bugs/No_MonadFail_instance.mdwn deleted file mode 100644 index b9ab6f8ee3..0000000000 --- a/doc/bugs/No_MonadFail_instance.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -### Please describe the problem. - - -### What steps will reproduce the problem? - -Build git-annex with GHC 8.6. - -### What version of git-annex are you using? On what operating system? - -7.20181211, master - -### Please provide any additional information below. - -Following the implementation plan for the [MonadFail Proposal](https://wiki.haskell.org/MonadFail_Proposal), GHC 8.6 has enabled `-XMonadFailDesugaring` by default. - -Some of the code in git-annex uses failable patterns in `do`-blocks, so it fails to compile starting from GHC 8.6, as there is no `MonadFail` instance for `Annex`. Here is an example of such an error: - - Remote/Glacier.hs:165:17: error: - • No instance for (Control.Monad.Fail.MonadFail Annex) - arising from a do statement - with the failable pattern ‘(_, Just h, _, pid)’ - • In a stmt of a 'do' block: - (_, Just h, _, pid) <- liftIO $ createProcess cmd - In the expression: - do let cmd = ... - (_, Just h, _, pid) <- liftIO $ createProcess cmd - ok <- ifM - (liftIO $ hIsEOF h) - (return False, sink =<< liftIO (L.hGetContents h)) - liftIO $ hClose h - .... - In an equation for ‘go’: - go (Just e) - = do let cmd = ... - (_, Just h, _, pid) <- liftIO $ createProcess cmd - ok <- ifM - (liftIO $ hIsEOF h) - (return False, sink =<< liftIO (L.hGetContents h)) - .... - | - 165 | (_, Just h, _, pid) <- liftIO $ createProcess cmd - | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Just trying to start using it. I have built it with `-XNoMonadFailDesugaring` for now. - -> [[fixed|done]] (release soonish) --[[Joey]] diff --git a/doc/bugs/No_MonadFail_instance/comment_1_444dd4bf522e93f1cbee562d748a781a._comment b/doc/bugs/No_MonadFail_instance/comment_1_444dd4bf522e93f1cbee562d748a781a._comment deleted file mode 100644 index d7ff9bad4e..0000000000 --- a/doc/bugs/No_MonadFail_instance/comment_1_444dd4bf522e93f1cbee562d748a781a._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="alogic0@d8fbd9f5b547237a650aa1d5605c2d3592496916" - nickname="alogic0" - avatar="http://cdn.libravatar.org/avatar/9498ef776e93104a14ea86b734a5f0cf" - subject="it's fixed" - date="2019-01-11T00:54:01Z" - content=""" -Try to build the latest version, obtained by - -```git clone git://git-annex.branchable.com/ git-annex``` -"""]] diff --git a/doc/bugs/No_MonadFail_instance/comment_2_b578bcc04c23407342830ef9bd27f755._comment b/doc/bugs/No_MonadFail_instance/comment_2_b578bcc04c23407342830ef9bd27f755._comment deleted file mode 100644 index 0cc557ac48..0000000000 --- a/doc/bugs/No_MonadFail_instance/comment_2_b578bcc04c23407342830ef9bd27f755._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="6yearold@36d59212c29d2959d6532d6db7928f01541bcf83" - nickname="6yearold" - avatar="http://cdn.libravatar.org/avatar/0227e5d5eaceb8ae2f751df38d421764" - subject="comment 2" - date="2019-01-11T06:28:31Z" - content=""" -Can we get a new release containing this fix? -"""]] diff --git a/doc/bugs/OSX_dmg_git-core_binaries_do_not_link.mdwn b/doc/bugs/OSX_dmg_git-core_binaries_do_not_link.mdwn deleted file mode 100644 index d976be1fd6..0000000000 --- a/doc/bugs/OSX_dmg_git-core_binaries_do_not_link.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -The OSX .dmg contains a few binaries in git-core like git-remote-http. -They have been adjusted by otool to link to libraries in the same directory -as the binary. However, the libraries are not located in the git-core -directory, but in its parent directory, and so the git-core binaries don't -link. - -I don't think this is a new regression, but not entirely sure. - -Seems that OSXMkLibs could symlink ../lib into git-core. ---[[Joey]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09.mdwn b/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09.mdwn deleted file mode 100644 index 0773f9976e..0000000000 --- a/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -### Please describe the problem. -In recent nixpkgs the S3 special remotes have been disabled because some of the dependencies are quite old or unmaintained. -More detail here: - -### What steps will reproduce the problem? -Installing git-annex from the 18.09 nixpkgs release. - -> [[done]]; the esqueleto dep was dropped and deps are fairly current now. -> --[[Joey]] diff --git a/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09/comment_1_6378778d1424c704b827dfb06650074a._comment b/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09/comment_1_6378778d1424c704b827dfb06650074a._comment deleted file mode 100644 index b4b4b1c249..0000000000 --- a/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09/comment_1_6378778d1424c704b827dfb06650074a._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-11-05T17:38:56Z" - content=""" -I'd kind of like to switch to using the Amazonka package for S3; -it may be better maintained and there are several modern S3 features -that the haskell aws library is lacking support for. -Patches in that direction would be great. - -But I see that this is actually a conflict between dependencies of aws and -equelito, so [[todo/Retire_Esqueleto_as_a_dependency]] would fix the -immediate problem. - -(I've been doing some work to keep aws current with new versions of its -dependencies, eg -https://github.com/aristidb/aws/commit/6fa37706d13133d0b5c406bca2f304d1e567d028 -since it's otherwise been lagging with such updates.) -"""]] diff --git a/doc/bugs/Operating_system_should_be_contained_in___96__git_annex_version__96___output_regardless_if_in_annex_repo_or_not.mdwn b/doc/bugs/Operating_system_should_be_contained_in___96__git_annex_version__96___output_regardless_if_in_annex_repo_or_not.mdwn deleted file mode 100644 index b4d84b6e52..0000000000 --- a/doc/bugs/Operating_system_should_be_contained_in___96__git_annex_version__96___output_regardless_if_in_annex_repo_or_not.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -### Please describe the problem. - -When looking over the [[bug reports|bugs]] here some of them are missing the "Operating system" info in the `git annex version` output. The reason for this is that the `git annex version` output depends on whether it was run inside an annex repo or not. - -### What steps will reproduce the problem? - -Run `git annex version` outside of an annex repo: - - git-annex version: 6.20180509 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - - -Run `git annex version` inside an annex repo: - - git-annex version: 6.20180509 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - - -### What version of git-annex are you using? On what operating system? - - git-annex version: 6.20180509 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - - -### Please provide any additional information below. - -It might make sense to also always output "supported repository versions" and "upgrade supported from repository versions" because they also do not depend on the current annex repo. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I am a long time happy user of git-annex. Thank you for your never ending effort! - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Operating_system_should_be_contained_in___96__git_annex_version__96___output_regardless_if_in_annex_repo_or_not/comment_1_17ab67ebfd21e0844973461bad1d40f9._comment b/doc/bugs/Operating_system_should_be_contained_in___96__git_annex_version__96___output_regardless_if_in_annex_repo_or_not/comment_1_17ab67ebfd21e0844973461bad1d40f9._comment deleted file mode 100644 index e618fbaf41..0000000000 --- a/doc/bugs/Operating_system_should_be_contained_in___96__git_annex_version__96___output_regardless_if_in_annex_repo_or_not/comment_1_17ab67ebfd21e0844973461bad1d40f9._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-06-04T16:16:39Z" - content=""" -Good catch. -"""]] diff --git a/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository.mdwn b/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository.mdwn deleted file mode 100644 index 568b2bf5f4..0000000000 --- a/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository.mdwn +++ /dev/null @@ -1,57 +0,0 @@ -### Please describe the problem. - -When trying to add a large file (compared to the amount of RAM on the machine) to a v6 repository using `git add large_file.iso`, I get `fatal: Out of memory, realloc failed`. Adding the file with `git annex add large_file.iso` works fine. - -### What steps will reproduce the problem? - -On a machine with 4 GiB of RAM, I'm trying to add a 2.8 GiB file called `large_file.iso` to a freshly created v6 repository: - -``` -$ mkdir annex -$ cd annex -$ git init -$ git annex init --version=6 -$ cp /tmp/large_file.iso . -$ git add large_file.iso -fatal: Out of memory, realloc failed -``` - - -### What version of git-annex are you using? On what operating system? - -- git-annex version: 6.20170101 -- git version 2.11.0 -- Debian GNU/Linux 9.0 (stretch) - -I also tried git-annex 6.20170321, with no success. - -### Please provide any additional information below. - -``` -$ GIT_TRACE=1 git add large_file.iso -06:48:23.048295 git.c:371 trace: built-in: git 'add' 'large_file.iso' -fatal: Out of memory, realloc failed -06:48:23.048725 run-command.c:350 trace: run_command: 'git-annex smudge --clean '\''large_file.iso'\''' -``` - -So the problem seems to be with Git trying to allocate memory the size of the file, rather that git-annex itself: - -``` -$ ltrace git add large_file.iso 2>&1 | grep realloc | tail -n3 -realloc(0, 2902458369) = 0 -realloc(0, 2902458369) = 0 -fputc('\n', 0x7ff2c98ce520Out of memory, realloc failed -``` - -``` -$ git-annex smudge --clean large_file.iso < large_file.iso -/annex/objects/SHA256E-s2902458368--f8ef73594445624eabc1ea4a567ebedb8841fd248347c1aa01538a8de705c5c1.iso -``` - -I have no idea why it needs to do that, though. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I've been using git-annex v5 repositories without any issues, and with smaller files, repository v6 works great! - -> dup; [[done]] --[[Joey]] diff --git a/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository/comment_1_b9154c38406fca40c4c0edb716707c3a._comment b/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository/comment_1_b9154c38406fca40c4c0edb716707c3a._comment deleted file mode 100644 index 9ef59ed710..0000000000 --- a/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository/comment_1_b9154c38406fca40c4c0edb716707c3a._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-06-09T17:34:40Z" - content=""" -Unfortunately, git add tries to load the whole file content -into memory (or at least allocates a buffer for it all), -even if it's only going to stream it through the clean filter -used in v6 mode, and even though the git-annex smudge -filter reads the file content from disk itself. - -I submitted a patch to git over a year ago, that IIRC fixes this kind of -problem, but it was not accepted. Getting an updated version of that patch -accepted into git is the main blocker for v6 repositories to not be -experimental. - -[[todo/smudge]] documents this problem. I'm going to close this bug -as it's a duplicate of stuff discussed there. -"""]] diff --git a/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository/comment_2_97d5a2571679d5f6dc90694e5be89eaa._comment b/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository/comment_2_97d5a2571679d5f6dc90694e5be89eaa._comment deleted file mode 100644 index 8eec02fa43..0000000000 --- a/doc/bugs/Out_of_memory_error_when_adding_large_files_to_v6_repository/comment_2_97d5a2571679d5f6dc90694e5be89eaa._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="yves.noirjean@3f9b06d19a920fbf5c82340c362e5971b00d4af2" - nickname="yves.noirjean" - avatar="http://cdn.libravatar.org/avatar/2f1ad9d443c037337d91f29781560344" - subject="comment 2" - date="2018-06-22T07:53:26Z" - content=""" -I stumbled over the same problem. With \"git annex add\" I can add the file. But in unlocked mode, I get the \"out of memory\" error when trying to commit. Is this also a known problem? Is there a workaround? -"""]] diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android.mdwn b/doc/bugs/Permission_problem_in_second_user_account_on_Android.mdwn deleted file mode 100644 index 57789e77d1..0000000000 --- a/doc/bugs/Permission_problem_in_second_user_account_on_Android.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -I get the following error message upon starting git-annex in a second user account on Android: - - Falling back to hardcoded app location: cannot find expected files in /data/app-lib - git annex webapp - lib/lib.runshell.so: line 133: git: Permission denied - - [Terminal session finished] - -The same version of git-annex works just fine for the primary user. -(The primary user has root access which unfortunately can't be enabled for other user accounts.) - -### What version of git-annex are you using? On what operating system? - - * git-annex: 5.20140710 - * OS: CyanogenMod 10.1.3-p3110 - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment deleted file mode 100644 index a4f56553c2..0000000000 --- a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 1" - date="2014-08-15T17:52:57Z" - content=""" -I'm afraid all I can do to help with this is to say that the git-annex Android app does not do anything I know of to prevent running the programs, such as git, that are included in it. If your user cannot access them, it must be your OS configuration preventing it. -"""]] diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_2_ef775b5fceb4caf00227978318f73470._comment b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_2_ef775b5fceb4caf00227978318f73470._comment deleted file mode 100644 index 761bca635e..0000000000 --- a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_2_ef775b5fceb4caf00227978318f73470._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://inkwell.za.net/" - nickname="kwill" - subject="Confirmation" - date="2014-11-11T08:01:48Z" - content=""" -I can confirm this occurs for me on Android 4.4 with exactly the same symptoms: primary user account can install and run Git Annex (triggers repo setup, webapp opens), secondary user account can install, but gets this error when starting Git Annex (webapp does not open). Is there any additional info I can provide to resolve this? -"""]] diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_3_2977076f0f4f26daa7d6a087d8af18b3._comment b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_3_2977076f0f4f26daa7d6a087d8af18b3._comment deleted file mode 100644 index 45700fda04..0000000000 --- a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_3_2977076f0f4f26daa7d6a087d8af18b3._comment +++ /dev/null @@ -1,43 +0,0 @@ -[[!comment format=mdwn - username="http://inkwell.za.net/" - nickname="kwill" - subject="Logfile with errors" - date="2015-01-06T11:43:12Z" - content=""" -Found the logfile for the attempted installation at `/storage/emulated/10/git-annex.home/git-annex-install.log` - -It looks like there's a problem quite early on. BTW this is on Android 4.4 running on a Nexus 7 (2012). Only modification is installation of F-Droid. Is it worth / possible to install the recent Android 5.0 build? - - Installation starting to /data/data/ga.androidterm - abcdef_SOME_LONG_HEX_STRING - mv: can't rename '/data/data/ga.androidterm/bin': Permission denied - installing busybox - ln: /data/data/ga.androidterm/bin/busybox: Permission denied - installing git-annex - ln: /data/data/ga.androidterm/bin/git-annex: Permission denied - - ... (more of the same) - - busybox: /data/data/ga.androidterm/bin/[: Permission denied - busybox: /data/data/ga.androidterm/bin/[[: Permission denied - busybox: /data/data/ga.androidterm/bin/ar: Permission denied - busybox: /data/data/ga.androidterm/bin/arp: Permission denied - - ... (more of the same) - - busybox: /data/data/ga.androidterm/bin/zcat: Permission denied - tar: can't remove old file ./links/git-shell: Permission denied - tar: write: Broken pipe - cat: can't open '/data/data/ga.androidterm/links/git': Permission denied - rm: can't stat '/data/data/ga.androidterm/links/git': Permission denied - cat: can't open '/data/data/ga.androidterm/links/git-shell': Permission denied - rm: can't stat '/data/data/ga.androidterm/links/git-shell': Permission denied - cat: can't open '/data/data/ga.androidterm/links/git-upload-pack': Permission denied - rm: can't stat '/data/data/ga.androidterm/links/git-upload-pack': Permission denied - lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/runshell: Permission denied - lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/runshell: Permission denied - chmod: runshell: Operation not permitted - lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/bin/trustedkeys.gpg: Permission denied - lib/lib.runshell.so: line 133: can't create /data/data/ga.androidterm/installed-version: Permission denied - Installation complete -"""]] diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_4_cccf1f3aca5edbd82661a9eb91c72de5._comment b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_4_cccf1f3aca5edbd82661a9eb91c72de5._comment deleted file mode 100644 index c392095404..0000000000 --- a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_4_cccf1f3aca5edbd82661a9eb91c72de5._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2018-05-08T18:56:00Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. - -"""]] diff --git a/doc/bugs/Recover_files_deleted_by_git-annex.mdwn b/doc/bugs/Recover_files_deleted_by_git-annex.mdwn deleted file mode 100644 index 4bc2672d0a..0000000000 --- a/doc/bugs/Recover_files_deleted_by_git-annex.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -### Please describe the problem. - -Git annex sometimes back-propagates the changes from a copy of the repo where files are missing to the one where I just added them and (I hope only seemingly!!!) very quietly deletes my files. -I don't care about solving whatever bug this is or isn't, this question is about getting my data back. -I can use `git log` to see the commits but I can't reset to or checkout any one of them. - - -### What steps will reproduce the problem? - -[repo0] git annex add XYZ -[repo0] git annex sync -[repo1] git annex sync -[repo0] git annex sync -[repo0] git reset --hard f67fae3166de7eca5ed8421ea4546aa32b84a964 -fatal: this operation must be run in a work tree - -### What version of git-annex are you using? On what operating system? -6.20170818 - - - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes, I did, it works great whenever I barely use, as soon as more data comes in it messes up and data goes missing. - - -[[done]] —resolved by poster diff --git a/doc/bugs/Recover_files_deleted_by_git-annex/comment_1_a9760b61bbd79015460365173440bbbe._comment b/doc/bugs/Recover_files_deleted_by_git-annex/comment_1_a9760b61bbd79015460365173440bbbe._comment deleted file mode 100644 index 72b130ed8a..0000000000 --- a/doc/bugs/Recover_files_deleted_by_git-annex/comment_1_a9760b61bbd79015460365173440bbbe._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Chymera" - avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309" - subject="comment 1" - date="2018-12-20T23:13:01Z" - content=""" -sorry, it turns out this is in the wrong forum, as stated in the question this is a request for help, and not an investigation of the underlying cause. -"""]] diff --git a/doc/bugs/Recover_files_deleted_by_git-annex/comment_2_47dd6d926698c1db9b0a5d25e70b02ab._comment b/doc/bugs/Recover_files_deleted_by_git-annex/comment_2_47dd6d926698c1db9b0a5d25e70b02ab._comment deleted file mode 100644 index 07ef617adb..0000000000 --- a/doc/bugs/Recover_files_deleted_by_git-annex/comment_2_47dd6d926698c1db9b0a5d25e70b02ab._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="Chymera" - avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309" - subject="comment 2" - date="2018-12-30T20:47:00Z" - content=""" -Luckily I had a backup, so I fixed this by re-adding my disappeared files with the cutting edge `cp` command. -Most probably this ended up cluttering my history, though. -"""]] diff --git a/doc/bugs/Recover_files_deleted_by_git-annex/comment_3_c88e1359327a3b6f8524d71e2063a7c3._comment b/doc/bugs/Recover_files_deleted_by_git-annex/comment_3_c88e1359327a3b6f8524d71e2063a7c3._comment deleted file mode 100644 index e874382112..0000000000 --- a/doc/bugs/Recover_files_deleted_by_git-annex/comment_3_c88e1359327a3b6f8524d71e2063a7c3._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="andrew" - avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" - subject="comment 3" - date="2018-12-30T22:12:08Z" - content=""" -OK. Glad to hear. I'll move this bug to done. - -There are some notes on how to run git commands on a direct mode repo here: . I would do this on a copy of your repo though. - -Also Joey did mention (5 years ago) that you can [switch to indirect mode to run git commands](http://git-annex.branchable.com/forum/Retrieve_previous_version_in_direct_mode/#comment-2d28e7d2f8442e2d815e7dff485a6b77). I am not sure if you would be able to switch back to direct mode with the latest git-annex though… I would do this on a copy of your repo if need be. -"""]] diff --git a/doc/bugs/Remote_does_not_work_with_UTF-8_filenames.mdwn b/doc/bugs/Remote_does_not_work_with_UTF-8_filenames.mdwn deleted file mode 100644 index db3d72b7ba..0000000000 --- a/doc/bugs/Remote_does_not_work_with_UTF-8_filenames.mdwn +++ /dev/null @@ -1,195 +0,0 @@ -### Please describe the problem. - -I'm using git-annex-remote-googledrive to sync a large music library. Some files contain special characters like: -chillgressive/\[Astropilot\ Music\]/Unusual\ Cosmic\ Process\ -\ Spacetime/Unusual\ Cosmic\ Process\ -\ Spacetime\ -\ 03\ Souvenirs\ Éphémère.flac - -When running: -"git annex sync google --content -v -d" - - -### What steps will reproduce the problem? - -The problem seems to be, that git annex sends non utf-8 data to the remote script which crashes due to decoding errors. This seems to be git annex bug as the remote should not have to guess which encoding is used but should be able to use utf-8 always. - -environment: -LANG=en_US.UTF-8 -LANGUAGE=en_US.UTF-8 - - -### What version of git-annex are you using? On what operating system? - -nixos - -git-annex version: 6.20180807 -build flags: Assistant Pairing WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.4.3 http-client-0.5.13.1 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -local repository version: 5 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -git annex sync google --content -v -d 1.8m  Tue 18 Sep 2018 12:29:32 PM CEST -[2018-09-18 12:29:41.854290811] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2018-09-18 12:29:41.856338835] process done ExitSuccess -[2018-09-18 12:29:41.85643436] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2018-09-18 12:29:41.858259966] process done ExitSuccess -[2018-09-18 12:29:41.859926397] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..97d762166d735b12c5393a21d5d2eeb27b33eb8d","--pretty=%H","-n1"] -[2018-09-18 12:29:41.861562154] process done ExitSuccess -[2018-09-18 12:29:41.864078093] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2018-09-18 12:29:41.864393271] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] -[2018-09-18 12:29:41.866339921] read: git ["config","--null","--list"] -[2018-09-18 12:29:41.867406295] process done ExitSuccess -[2018-09-18 12:29:41.867536122] read: git ["config","--null","--list"] -[2018-09-18 12:29:41.86768986] read: git ["config","--null","--list"] -[2018-09-18 12:29:41.86875252] chat: /home/poelzi/.nix-profile/bin/git-annex-remote-googledrive [] -[2018-09-18 12:29:42.10211189] git-annex-remote-googledrive[1] --> VERSION 1 -[2018-09-18 12:29:42.102224585] git-annex-remote-googledrive[1] <-- EXTENSIONS INFO -[2018-09-18 12:29:42.10234806] git-annex-remote-googledrive[1] --> EXTENSIONS -[2018-09-18 12:29:42.10240219] git-annex-remote-googledrive[1] <-- EXPORTSUPPORTED -[2018-09-18 12:29:42.102579476] git-annex-remote-googledrive[1] --> EXPORTSUPPORTED-SUCCESS -commit -[2018-09-18 12:29:42.106079317] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit","-a","-m","git-annex in poelzi@galaxy:/run/media/poelzi/backup-1/Music"] -On branch master -Your branch is ahead of 'origin/master' by 3 commits. - (use "git push" to publish your local commits) - -nothing to commit, working tree clean -[2018-09-18 12:29:42.325422783] process done ExitFailure 1 -ok -[2018-09-18 12:29:42.325517478] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"] -[2018-09-18 12:29:42.326719154] process done ExitSuccess -[2018-09-18 12:29:42.326780286] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"] -[2018-09-18 12:29:42.328496909] process done ExitSuccess -[2018-09-18 12:29:42.328549028] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/heads/synced/master"] -[2018-09-18 12:29:42.329769099] process done ExitSuccess -[2018-09-18 12:29:42.329841385] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"] -[2018-09-18 12:29:42.33163463] process done ExitSuccess -[2018-09-18 12:29:42.331711233] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2018-09-18 12:29:42.333577663] process done ExitSuccess -[2018-09-18 12:29:42.333638691] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2018-09-18 12:29:42.335399941] process done ExitSuccess -[2018-09-18 12:29:42.337137236] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..97d762166d735b12c5393a21d5d2eeb27b33eb8d","--pretty=%H","-n1"] -[2018-09-18 12:29:42.338812954] process done ExitSuccess -[2018-09-18 12:29:42.338954942] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"] -[2018-09-18 12:29:42.349381649] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"] -[2018-09-18 12:29:42.349788044] read: git ["--version"] -[2018-09-18 12:29:42.351035475] process done ExitSuccess -[2018-09-18 12:30:46.421010356] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","master:"] -[2018-09-18 12:30:46.423208056] process done ExitSuccess -[2018-09-18 12:30:46.426223794] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2018-09-18 12:30:46.428877128] process done ExitSuccess -[2018-09-18 12:30:46.428974324] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","-r","-t","--","97d762166d735b12c5393a21d5d2eeb27b33eb8d"] -[2018-09-18 12:30:50.326843882] process done ExitSuccess -[2018-09-18 12:30:50.326943526] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","mktree","--batch","-z"] -[2018-09-18 12:30:50.357438031] process done ExitSuccess -[2018-09-18 12:30:50.357526145] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","ee08aadd5604249699ce157df47426c70f62312b","--no-gpg-sign","-p","97d762166d735b12c5393a21d5d2eeb27b33eb8d"] -[2018-09-18 12:30:50.359994305] process done ExitSuccess -[2018-09-18 12:30:50.360058172] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","mktree","--batch","-z"] -[2018-09-18 12:30:50.383728957] process done ExitSuccess -[2018-09-18 12:30:50.383984605] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","acf111be942ccf1cfda391d7ecffc4a9c6a27d6f","--no-gpg-sign","-p","46bf4e6b14c01c587d5eb1be2db75c66479b6e15"] -[2018-09-18 12:30:50.388013862] process done ExitSuccess -[2018-09-18 12:30:50.388101083] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","125e9dfe8129591025117cc9dc0c752265be7e70"] -[2018-09-18 12:30:50.391058496] process done ExitSuccess -[2018-09-18 12:30:50.391473142] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff-tree","-z","--raw","--no-renames","-l0","-r","9557efae9721f725d73f2b2776a2070aad7b0a39","9557efae9721f725d73f2b2776a2070aad7b0a39","--"] -[2018-09-18 12:30:50.402405642] process done ExitSuccess -[2018-09-18 12:30:50.402521039] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff-tree","-z","--raw","--no-renames","-l0","-r","33bf55cdf1f58109ee31097308693f833c4cca97","9557efae9721f725d73f2b2776a2070aad7b0a39","--"] -[2018-09-18 12:30:50.415691771] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2018-09-18 12:30:50.41669191] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] -[2018-09-18 12:30:50.4222699] process done ExitSuccess -rename google chillgressive/[Astropilot Music]/Unusual Cosmic Process - Spacetime/Unusual Cosmic Process - Spacetime - 03 Souvenirs �ph�m�re.flac -> .git-annex-tmp-content-SHA256E-s97469487--14f5f5a819093a154f8d660ae1d986332108eb556a9c27dfd36d8f8dd90d30ae.flac [2018-09-18 12:30:50.422844753] git-annex-remote-googledrive[1] <-- PREPARE -[2018-09-18 12:30:50.423065052] git-annex-remote-googledrive[1] --> DEBUG Running .git-annex-remote-googledrive-wrapped version 0.11.1 -[2018-09-18 12:30:50.423111151] Running .git-annex-remote-googledrive-wrapped version 0.11.1 -[2018-09-18 12:30:50.423145446] git-annex-remote-googledrive[1] --> DEBUG Using AnnexRemote version 1.2.0 -[2018-09-18 12:30:50.423239295] Using AnnexRemote version 1.2.0 -[2018-09-18 12:30:50.423278034] git-annex-remote-googledrive[1] --> GETCONFIG prefix -[2018-09-18 12:30:50.423319342] git-annex-remote-googledrive[1] <-- VALUE Music -[2018-09-18 12:30:50.423424438] git-annex-remote-googledrive[1] --> GETCONFIG root_id -[2018-09-18 12:30:50.423486989] git-annex-remote-googledrive[1] <-- VALUE 1vnnTRDDMJWqTjm5hc0BGzxhCW4S7-j7b -[2018-09-18 12:30:50.42358159] git-annex-remote-googledrive[1] --> GETCREDS credentials -[2018-09-18 12:30:50.423727488] git-annex-remote-googledrive[1] <-- CREDS {"access_token":"ya...8Q","client_id":"...","client_secret":"...","refresh_token":"..."} -[2018-09-18 12:30:51.007447341] git-annex-remote-googledrive[1] --> SETCREDS credentials {"access_token":...} -[2018-09-18 12:30:51.348855667] git-annex-remote-googledrive[1] --> PREPARE-SUCCESS -[2018-09-18 12:30:51.348957671] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Unusual Cosmic Process - Spacetime/Unusual Cosmic Process - Spacetime - 03 Souvenirs �ph�m�re.flac -[2018-09-18 12:30:51.34902213] git-annex-remote-googledrive[1] <-- RENAMEEXPORT SHA256E-s97469487--14f5f5a819093a154f8d660ae1d986332108eb556a9c27dfd36d8f8dd90d30ae.flac .git-annex-tmp-content-SHA256E-s97469487--14f5f5a819093a154f8d660ae1d986332108eb556a9c27dfd36d8f8dd90d30ae.flac -Traceback (most recent call last): - File "/nix/store/478kqwy2yfrx61swlsnhjajna7sl8lhh-git-annex-remote-googledrive-0.11.1/bin/.git-annex-remote-googledrive-wrapped", line 584, in - main() - File "/nix/store/478kqwy2yfrx61swlsnhjajna7sl8lhh-git-annex-remote-googledrive-0.11.1/bin/.git-annex-remote-googledrive-wrapped", line 580, in main - master.Listen() - File "/nix/store/5wncs360nzq0fgqmv30p8qn0cga8zi0d-python3.6-annexremote-1.2.0/lib/python3.6/site-packages/annexremote/annexremote.py", line 394, in Listen - for line in self.input: - File "/nix/store/hy65mn4wjswqih75gfr6g4q3xgqdm325-python3-3.6.6/lib/python3.6/codecs.py", line 321, in decode - (result, consumed) = self._buffer_decode(data, self.errors, final) -UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc9 in position 125: invalid continuation byte -git-annex: external special remote protocol error, unexpectedly received "" (unable to parse command) - - rename failed; deleting instead -[2018-09-18 12:30:51.384823525] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Unusual Cosmic Process - Spacetime/Unusual Cosmic Process - Spacetime - 03 Souvenirs �ph�m�re.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed -rename google chillgressive/[Astropilot Music]/Unusual Cosmic Process - Elysium/Unusual Cosmic Process - Elysium - 04 Souvenirs �ph�m�re (Trance Version).flac -> .git-annex-tmp-content-SHA256E-s90158047--578d406e3db07835d3c4045096c7f8333c5adbbfe1003d37121d5b0656f45688.flac [2018-09-18 12:30:51.385017728] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Unusual Cosmic Process - Elysium/Unusual Cosmic Process - Elysium - 04 Souvenirs �ph�m�re (Trance Version).flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) - - rename failed; deleting instead -[2018-09-18 12:30:51.385128278] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Unusual Cosmic Process - Elysium/Unusual Cosmic Process - Elysium - 04 Souvenirs �ph�m�re (Trance Version).flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed -rename google chillgressive/[Astropilot Music]/Dream Twice - Enta/Dream Twice - Enta - 01 Artem�sia.flac -> .git-annex-tmp-content-SHA256E-s41053932--7bb9b80766e1d445bb39442e39e3e727ba7329d00186cccb5b2b1e2b28b493b1.flac [2018-09-18 12:30:51.38521185] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Dream Twice - Enta/Dream Twice - Enta - 01 Artem�sia.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) - - rename failed; deleting instead -[2018-09-18 12:30:51.385281886] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Dream Twice - Enta/Dream Twice - Enta - 01 Artem�sia.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed -rename google psychill/[Badger Records]/Badgers Records - VA - Inner Holographic Reality/Badgers Records - VA - Inner Holographic Reality - 01 Cord & Frankie L�t� - Lullaby.flac -> .git-annex-tmp-content-SHA256E-s43901186--9d51034d81247e3e0890d81c1e1c20c06149aac3bf4451d880523dcc89c3de82.flac [2018-09-18 12:30:51.385360183] git-annex-remote-googledrive[1] <-- EXPORT psychill/[Badger Records]/Badgers Records - VA - Inner Holographic Reality/Badgers Records - VA - Inner Holographic Reality - 01 Cord & Frankie L�t� - Lullaby.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) - - rename failed; deleting instead -[2018-09-18 12:30:51.385429424] git-annex-remote-googledrive[1] <-- EXPORT psychill/[Badger Records]/Badgers Records - VA - Inner Holographic Reality/Badgers Records - VA - Inner Holographic Reality - 01 Cord & Frankie L�t� - Lullaby.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed -rename google chillgressive/[Astropilot Music]/Skytechnic - Astral Insıgnias/Skytechnic - Astral Ins?gnias - 08 Vac�o.flac -> .git-annex-tmp-content-SHA256E-s89899720--afbc07b561f058db6da5849f728d665d14cc6ea42e2768fecf6396d0009e2861.flac [2018-09-18 12:30:51.385513597] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Skytechnic - Astral Insıgnias/Skytechnic - Astral Ins?gnias - 08 Vac�o.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) - - rename failed; deleting instead -[2018-09-18 12:30:51.385594622] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Skytechnic - Astral Insıgnias/Skytechnic - Astral Ins?gnias - 08 Vac�o.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed -rename google chillgressive/[Astropilot Music]/Unusual Cosmic Process - Elysium/Unusual Cosmic Process - Elysium - 03 Souvenirs �ph�m�re (Ambient Version).flac -> .git-annex-tmp-content-SHA256E-s81128227--c4222d79979c8562c44847869c20d172f51a8d4670192d860aa2dae1ba3d54c8.flac [2018-09-18 12:30:51.385768001] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Unusual Cosmic Process - Elysium/Unusual Cosmic Process - Elysium - 03 Souvenirs �ph�m�re (Ambient Version).flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) - - rename failed; deleting instead -[2018-09-18 12:30:51.385830411] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Unusual Cosmic Process - Elysium/Unusual Cosmic Process - Elysium - 03 Souvenirs �ph�m�re (Ambient Version).flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed -[2018-09-18 12:30:51.38631869] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","-r","--","9557efae9721f725d73f2b2776a2070aad7b0a39"] -export google .gitignore (not available) failed -export google bin/bandcamp-rip-album.variant-5bf5 (not available) failed -export google bin/flac2opus.variant-1201.py (not available) failed -export google chillgressive/[Astropilot Music]/Dream Twice - Enta/Dream Twice - Enta - 01 Artemísia.flac -[2018-09-18 12:30:59.661174242] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Dream Twice - Enta/Dream Twice - Enta - 01 Artemísia.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed -export google chillgressive/[Astropilot Music]/Dream Twice - Enta/Dream Twice - Enta - 02 Marwell.flac -[2018-09-18 12:30:59.663165427] git-annex-remote-googledrive[1] <-- EXPORT chillgressive/[Astropilot Music]/Dream Twice - Enta/Dream Twice - Enta - 02 Marwell.flac -git-annex: fd:16: hFlush: resource vanished (Broken pipe) -failed - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I love git annex, using it very day :) - -> closing since this is not a bug in git-annex but in the external remote. -> [[done]] --[[Joey]] diff --git a/doc/bugs/Remote_does_not_work_with_UTF-8_filenames/comment_1_08272c0ec6a35ec906ea8402e56bd3fa._comment b/doc/bugs/Remote_does_not_work_with_UTF-8_filenames/comment_1_08272c0ec6a35ec906ea8402e56bd3fa._comment deleted file mode 100644 index 538d8fd657..0000000000 --- a/doc/bugs/Remote_does_not_work_with_UTF-8_filenames/comment_1_08272c0ec6a35ec906ea8402e56bd3fa._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-10-04T19:19:29Z" - content=""" -Filenames, in Unix, do not have a defined encoding. They are a sequence of -arbitrary bytes, excluding NUL. - -So if a program assumes a filename is going to be utf-8 encoded and crashes -when it is not, that program is buggy. Especially if the program is a -git-annex external remote. You'll need to file a bug report on it, not -git-annex. - -Or alternatively, choose to re-encode all your filenames. -"""]] diff --git a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock.mdwn b/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock.mdwn deleted file mode 100644 index ef08680d4e..0000000000 --- a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock.mdwn +++ /dev/null @@ -1,249 +0,0 @@ -### Please describe the problem. - -I have a Synology DS216+ NAS, which can export shares via SMB2, AFP or NFS. Since I have a lot of "media" data in git-annex, I'd like to be able to put a useful copy of that data (ie, original file names) onto the NAS, and have git-annex track that content as another "local" copy of the content that is available (rather than having to track it by hand). - -Because the NFS shares have UID mapping issues (AFAICT NFS v4 id mapping is not supported without Kerberos authentication, due to changes since about Linux 3.4; the Synology is based on a Linux 3.10 kernel), I have been trying to use SMBv2 shares, with symlinks enabled ("Allow symbolic links within shared folders"). I'm aware that `git-annex` on a network file system is less supported, but this is still a use case that would be quite useful to manage larger pools of files. - -After updating to the latest release (to [fix git annex init timeouts](https://git-annex.branchable.com/forum/git_annex_init_timeout/)), I am able to complete the `git clone ...`, `git annex init`, and `git sync` steps. (The SMB mount supports symlinks, but not hard links; hence pidlocks being needed.) - -But `git annex get` or `git annex copy` to transfer any of the content files fails with: - - get README (transfer already in progress, or unable to take transfer lock) - Unable to access these remotes: ashram-data - -whether initiated from the SMB mounted `git-annex` or a `git-annex` with the data on a local file system. No content files get transferred. - -Of note, on this "SMB share with symlinks enabled" I can manually create symlinks, but `git annex` still detects symlinks as not possible and switches to direct mode. However it leaves the existing symlinks from `git clone ...` in place. It is unclear to me whether this is part of the cause of the "transfer lock" issue, or whether the transfer locks are, eg, not using pidlocks and thus failing because flock() does not work. - -### What steps will reproduce the problem? - -* Mount a remote file system via SMB v2, with symlinks enabled (eg mounting from a Samba share should be sufficient, as that's what is running on the Synology NAS) - -* `git clone` an existing `git-annex` onto a directory on that SMB mounted filesystem - -* `git remote ....` configure one or more remotes with the file data - -* `git annex init "SMB share"` - -* `git annex sync` - -* `git annex get ....` of an existing file - -or alternatively after the init/sync, go to a source `git-annex` and do: - -* `git remote add smb ....` - -* `git annex sync` - -* `git annex copy --to=smb ...` of an existing file with content in that `git-annex` - -### What version of git-annex are you using? On what operating system? - -`git-annex` 6.20170320 (downloaded 2017-04-23) on Mac OS X 10.11 (El Capitan): - - ewen@ashram:~$ uname -a - Darwin ashram 15.6.0 Darwin Kernel Version 15.6.0: Fri Feb 17 10:21:18 PST 2017; root:xnu-3248.60.11.4.1~1/RELEASE_X86_64 x86_64 - ewen@ashram:~$ git annex version - git-annex version: 6.20170320-g41c5d9d - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - ewen@ashram:~$ - -### Please provide any additional information below. - -[[!format sh """ -# Example session -ewen@ashram:/nas01/annex/purchased$ git clone /bkup/purchased/mediabytes -Cloning into 'mediabytes'... -done. -ewen@ashram:/nas01/annex/purchased$ cd mediabytes/ -ewen@ashram:/nas01/annex/purchased/mediabytes$ git remote add ashram-data /data/purchased/mediabytes -ewen@ashram:/nas01/annex/purchased/mediabytes$ git remote add ashram /bkup/purchased/mediabytes -ewen@ashram:/nas01/annex/purchased/mediabytes$ git remote remove origin -ewen@ashram:/nas01/annex/purchased/mediabytes$ git annex init 'nas01 file server' -init nas01 file server - Detected a filesystem without POSIX fcntl lock support. - - Enabling annex.pidlock. - - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Disabling core.symlinks. - - Enabling direct mode. -ok -(recording state in git...) -ewen@ashram:/nas01/annex/purchased/mediabytes$ git annex sync -commit ok -pull ashram -From /bkup/purchased/mediabytes - * [new branch] git-annex -> ashram/git-annex - * [new branch] master -> ashram/master - * [new branch] synced/git-annex -> ashram/synced/git-annex - * [new branch] synced/master -> ashram/synced/master -ok -pull ashram-data -From /data/purchased/mediabytes - * [new branch] git-annex -> ashram-data/git-annex - * [new branch] master -> ashram-data/master - * [new branch] synced/git-annex -> ashram-data/synced/git-annex - * [new branch] synced/master -> ashram-data/synced/master -ok -(merging ashram-data/git-annex into git-annex...) -(recording state in git...) -push ashram -Counting objects: 8, done. -Delta compression using up to 8 threads. -Compressing objects: 100% (6/6), done. -Writing objects: 100% (8/8), 806 bytes | 0 bytes/s, done. -Total 8 (delta 2), reused 1 (delta 0) -To /bkup/purchased/mediabytes - 02b7699..0edf575 git-annex -> synced/git-annex -ok -push ashram-data -Counting objects: 8, done. -Delta compression using up to 8 threads. -Compressing objects: 100% (6/6), done. -Writing objects: 100% (8/8), 806 bytes | 0 bytes/s, done. -Total 8 (delta 2), reused 1 (delta 0) -To /data/purchased/mediabytes - 02b7699..0edf575 git-annex -> synced/git-annex -ok -ewen@ashram:/nas01/annex/purchased/mediabytes$ git annex sync -commit ok -pull ashram -ok -pull ashram-data -ok -ewen@ashram:/nas01/annex/purchased/mediabytes$ git annex get . -get README (transfer already in progress, or unable to take transfer lock) - Unable to access these remotes: ashram-data - - Try making some of these repositories available: - 00420eb2-1c9a-47e8-abfa-675b9ffb0782 -- naos_wd_1 backup drive - 0ac1326e-9e03-4c1e-bd51-6cd664988caa -- Naos (colo) fileserver - 0e5fd428-ba5b-4817-8489-9780bc62e655 -- naos_wd_2 backup drive - 1144edcc-b18f-4cb1-a828-6c272d7788d6 -- naos_wd_3 backup drive - 6142cfd4-83ba-410f-bf54-fd4b79e49fdb -- ashram external data drive [ashram-data] - 77aeca6a-a4f8-4734-befc-2a0b50687c52 -- tv home fileserver - cc1c45f3-7c96-4103-b9c0-cce0f5f2cc36 -- bethel_data_drive - eb0ca2b6-e8c6-43b0-a805-de17a4d7eeae -- naos_wd_4 backup drive -failed -get alex-lindsay-1.m4a (transfer already in progress, or unable to take transfer lock) - Unable to access these remotes: ashram-data - - Try making some of these repositories available: - 00420eb2-1c9a-47e8-abfa-675b9ffb0782 -- naos_wd_1 backup drive - 0ac1326e-9e03-4c1e-bd51-6cd664988caa -- Naos (colo) fileserver - 0e5fd428-ba5b-4817-8489-9780bc62e655 -- naos_wd_2 backup drive - 1144edcc-b18f-4cb1-a828-6c272d7788d6 -- naos_wd_3 backup drive - 6142cfd4-83ba-410f-bf54-fd4b79e49fdb -- ashram external data drive [ashram-data] - 77aeca6a-a4f8-4734-befc-2a0b50687c52 -- tv home fileserver - cc1c45f3-7c96-4103-b9c0-cce0f5f2cc36 -- bethel_data_drive - eb0ca2b6-e8c6-43b0-a805-de17a4d7eeae -- naos_wd_4 backup drive -failed -[...] -[...] -failed -git-annex: get: 59 failed -ewen@ashram:/nas01/annex/purchased/mediabytes$ -ewen@ashram:/nas01/annex/purchased/mediabytes$ ls -l | head -total 118 -lrwx------ 1 ewen staff 182 23 Apr 18:53 README -> .git/annex/objects/3M/8w/SHA256E-s273--1eb5c07e12d99c99af8c163b5e005162820518020cc9922152852bd1422858ae/SHA256E-s273--1eb5c07e12d99c99af8c163b5e005162820518020cc9922152852bd1422858ae -lrwx------ 1 ewen staff 200 23 Apr 18:53 alex-lindsay-1.m4a -> .git/annex/objects/9M/xJ/SHA256E-s26905448--c8ecda8ca67c3ff8ab1061b34a2974be41eb4b44421e3c39d1dda63f4de6b910.m4a/SHA256E-s26905448--c8ecda8ca67c3ff8ab1061b34a2974be41eb4b44421e3c39d1dda63f4de6b910.m4a -lrwx------ 1 ewen staff 194 23 Apr 18:53 alexlindsay.txt -> .git/annex/objects/P7/7g/SHA256E-s17467--2e7ae57eff6db5a832681443eb3787d1d7f9e57a52e4fedb2b693136a3df19f0.txt/SHA256E-s17467--2e7ae57eff6db5a832681443eb3787d1d7f9e57a52e4fedb2b693136a3df19f0.txt -lrwx------ 1 ewen staff 198 23 Apr 18:53 bourne-1.mp3 -> .git/annex/objects/98/vg/SHA256E-s7560841--a24ce7acabcb0dd46b9a9df6df8aff50145d8b1d5253308a51573a7742652943.mp3/SHA256E-s7560841--a24ce7acabcb0dd46b9a9df6df8aff50145d8b1d5253308a51573a7742652943.mp3 -lrwx------ 1 ewen staff 192 23 Apr 18:53 bourne.txt -> .git/annex/objects/QK/2p/SHA256E-s1031--d45a0f0aba935126bf29d6265e9c252faae8b735abdc20edbec69eb3cc9edcd7.txt/SHA256E-s1031--d45a0f0aba935126bf29d6265e9c252faae8b735abdc20edbec69eb3cc9edcd7.txt -lrwx------ 1 ewen staff 200 23 Apr 18:53 chasejarvis-1.m4a -> .git/annex/objects/M1/8z/SHA256E-s80616681--d1b63892a9d68c51ddef9eb5c0a56ced795a449afe13d4884663ca6ecc76cade.m4a/SHA256E-s80616681--d1b63892a9d68c51ddef9eb5c0a56ced795a449afe13d4884663ca6ecc76cade.m4a -lrwx------ 1 ewen staff 194 23 Apr 18:53 chasejarvis.txt -> .git/annex/objects/35/jv/SHA256E-s50443--687b0cf63cc8f5724e3a694e1de6221ca4d1dd3449a6e6ad9b6f34501bfa30ce.txt/SHA256E-s50443--687b0cf63cc8f5724e3a694e1de6221ca4d1dd3449a6e6ad9b6f34501bfa30ce.txt -lrwx------ 1 ewen staff 184 23 Apr 18:53 checksums -> .git/annex/objects/3Q/vv/SHA256E-s1672--31b3cb7ccbcafc96d5061775dc31aa974bb4ce2f16984b2ab0104eb66674d81b/SHA256E-s1672--31b3cb7ccbcafc96d5061775dc31aa974bb4ce2f16984b2ab0104eb66674d81b -lrwx------ 1 ewen staff 200 23 Apr 18:53 chrismarquardt-1.m4a -> .git/annex/objects/k4/f3/SHA256E-s61861112--c14bacb5adfe3eca237547760183a986499808084dd1925a0202598981e4406b.m4a/SHA256E-s61861112--c14bacb5adfe3eca237547760183a986499808084dd1925a0202598981e4406b.m4a -ewen@ashram:/nas01/annex/purchased/mediabytes$ -ewen@ashram:/nas01/annex/purchased/mediabytes$ git annex info -repository mode: direct -trusted repositories: 0 -semitrusted repositories: 13 - 00000000-0000-0000-0000-000000000001 -- web - 00000000-0000-0000-0000-000000000002 -- bittorrent - 00420eb2-1c9a-47e8-abfa-675b9ffb0782 -- naos_wd_1 backup drive - 0ac1326e-9e03-4c1e-bd51-6cd664988caa -- Naos (colo) fileserver - 0ba93724-85a8-4ac7-855b-e656a6abaf09 -- ashram (laptop) internal drive [ashram] - 0e5fd428-ba5b-4817-8489-9780bc62e655 -- naos_wd_2 backup drive - 1144edcc-b18f-4cb1-a828-6c272d7788d6 -- naos_wd_3 backup drive - 4e5bfc02-1adc-44d2-a60a-885d9120ed5d -- nas01 file server [here] - 6142cfd4-83ba-410f-bf54-fd4b79e49fdb -- ashram external data drive [ashram-data] - 77aeca6a-a4f8-4734-befc-2a0b50687c52 -- tv home fileserver - bde87f8e-4740-411f-b068-3dbbd9db03d4 -- nas01 file server - cc1c45f3-7c96-4103-b9c0-cce0f5f2cc36 -- bethel_data_drive - eb0ca2b6-e8c6-43b0-a805-de17a4d7eeae -- naos_wd_4 backup drive -untrusted repositories: 0 -transfers in progress: none -available local disk space: 3.63 terabytes (+1 megabyte reserved) -local annex keys: 0 -local annex size: 0 bytes -annexed files in working tree: 59 -size of annexed files in working tree: 1.67 gigabytes -bloom filter size: 32 mebibytes (0% full) -backend usage: - SHA256E: 59 -ewen@ashram:/nas01/annex/purchased/mediabytes$ -"""]] - -For reference Synology DS216+ `/etc/samba/smb.conf`: - - ewen@nas01:/volume1$ cat /etc/samba/smb.conf - [global] - printcap name=cups - winbind enum groups=yes - include=/var/tmp/nginx/smb.netbios.aliases.conf - min protocol=SMB2 - security=user - local master=no - realm=* - passdb backend=smbpasswd - printing=cups - max protocol=SMB3 - winbind enum users=yes - load printers=yes - workgroup=WORKGROUP - ewen@nas01:/volume1$ - -and the relevant share: - - ewen@nas01:/volume1$ cat /etc/samba/smb.share.conf - [annex] - recycle bin admin only=no - ftp disable modify=no - ftp disable download=no - write list=nobody,nobody - browseable=yes - mediaindex=no - hide unreadable=no - win share=yes - enable recycle bin=no - invalid users=nobody,nobody - read list=nobody,nobody - ftp disable list=no - edit synoacl=yes - valid users=nobody,nobody - writeable=yes - guest ok=yes - path=/volume1/annex - skip smb perm=yes - comment="Git Annexes" - [music] - [...] - ewen@nas01:/volume1$ - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I'm an extremely regular user of git-annex on OS X and Linux, for several years, using it as a podcatcher and to manage most of my "large file" media. It's one of those "couldn't live without" tools. Thanks for writing it. - -(Touched, to ask for comments to be emailed to me) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_1_d165e4895e7043192888751218261282._comment b/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_1_d165e4895e7043192888751218261282._comment deleted file mode 100644 index 7b92837e35..0000000000 --- a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_1_d165e4895e7043192888751218261282._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="ewen" - avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e" - subject="git annex standalone on Synology NAS" - date="2017-04-23T07:52:19Z" - content=""" -After posting this bug, I found a [git annex tip on running a standalone build on the Synology NAS](http://git-annex.branchable.com/tips/Synology_NAS_and_git_annex/), so that may provide another workaround for me. Particularly since the Synology DS216+ is actually a x86-64 based system: - - ewen@nas01:/volume1$ uname -a - Linux nas01 3.10.102 #15047 SMP Thu Feb 23 02:23:28 CST 2017 x86_64 GNU/Linux synology_braswell_216+II - ewen@nas01:/volume1$ - -but it is probably still worth figuring out the cause of the transfer lock issue on SMB for other SMB use cases. - -Ewen -"""]] diff --git a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_2_8831965ea7abf5ac6fe860d93133fbb1._comment b/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_2_8831965ea7abf5ac6fe860d93133fbb1._comment deleted file mode 100644 index c422dc903e..0000000000 --- a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_2_8831965ea7abf5ac6fe860d93133fbb1._comment +++ /dev/null @@ -1,42 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-05-11T16:37:35Z" - content=""" -`git-annex init` is probably detecting a problem with the filesystem -allowing writes to files whose permissions don't allow them to be written -to. Since indirect mode relies on being able to prevent writing to files, -it enables direct mode. The disabling of symlinks is a side effect of that. -You can probably get away with using indirect mode, but there is the risk -of annexed files getting modified and so the old version of files being -lost. - -The pid lock is used for transfer locks when that's enabled. - -So, the pid lock creation is failing for some reason. The two likely causes -would be: - -* The pid locking code not working well on OSX. This would not be too - surprising. - - But, I gave pid locking on OSX a quick test, by making a repository - in my OSX home directory, `git config annex.pidlock true` and doing the - same in a clone. Transfers between the repositories worked ok so pid - locking seems to at least basically work on OSX. - -* Something to do with the SMB filesystem breaking the pid locking code. - Perhaps something to do with permissions since as noted `git annex init` - seems to have identified a problem with permissions handling. - -Could you possibly get a `dtruss` dump of git-annex when this error -happens? That would narrow down the problem a lot. - -I could try to set up SMB etc, but I don't have root access to an OSX -machine, so am not confident I could replicate the problem. - ----- - -Also, it might overall be better to run git-annex on the Synology NAS. -Then you don't have to mess with networked filesystems. People have done -this successfully before. -"""]] diff --git a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_3_24c6874757783e3c3838db35174870d1._comment b/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_3_24c6874757783e3c3838db35174870d1._comment deleted file mode 100644 index c549c19723..0000000000 --- a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_3_24c6874757783e3c3838db35174870d1._comment +++ /dev/null @@ -1,86 +0,0 @@ -[[!comment format=mdwn - username="ewen" - avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e" - subject="dtruss OS X 10.11 git annex on SMB mount" - date="2017-05-14T05:04:29Z" - content=""" -A tar file with: - - ewen@ashram:~/Desktop$ tar -tzf dtruss-git-annex-osx-smb-2017-05-14.tar.gz - dtruss-git-annex-osx-smb-2017-05-14/ - dtruss-git-annex-osx-smb-2017-05-14/00-ga-test-smb-osx-symlinks-2017-05-14.script - dtruss-git-annex-osx-smb-2017-05-14/01-ga-test-smb-osx-symlinks-dtruss-git-annex-init-2017-05-14.txt - dtruss-git-annex-osx-smb-2017-05-14/02-ga-test-smb-osx-symlinks-dtruss-git-annex-sync-2017-05-14.txt - dtruss-git-annex-osx-smb-2017-05-14/03-ga-test-smb-osx-symlinks-dtruss-git-annex-get-all-2017-05-14.txt - dtruss-git-annex-osx-smb-2017-05-14/04-ga-test-smb-osx-symlinks-dtruss-git-annex-sync-other-way-2017-05-14.txt - dtruss-git-annex-osx-smb-2017-05-14/05-ga-test-smb-osx-symlinks-dtruss-git-annex-copy-to-smb-2017-05-14.txt - dtruss-git-annex-osx-smb-2017-05-14/dtruss-ga - ewen@ashram:~/Desktop$ - -is available at [dtruss-git-annex-osx-smb-2017-05-14.tar.gz](http://ewen.mcneill.gen.nz/temp/dtruss-git-annex-osx-smb-2017-05-14.tar.gz) (at least until I next tidy up the `/temp/` directory :-) ). - -The script file is the output of \"`script ....`\" showing all the commands (including typos :-) ) run, except the `dtruss` ones themselves. The various `0n-ga-tst-smb-osx-symlinks-dtruss...` files contain the output of \"`sudo dtruss -af PID`\" where the `PID` was printed out by the script `dtruss-ga` that is included in the archive. `dtruss-ga` was used to enable running git-annex as non-root (to ensure that the SMB access wasn't altered by running as a different user), since `dtruss` itself can only run as root. The script is just: - - ewen@ashram:~/Desktop$ cat dtruss-git-annex-osx-smb-2017-05-14/dtruss-ga - #! /bin/sh - # Allow dtruss of non-root git annex - # - # Based on hints at: - # http://sec.cs.ucl.ac.uk/users/smurdoch/blog/2015/08/fixing-slow-start-mc-on-osx.html - #--------------------------------------------------------------------------- - - echo \"Run: sudo dtruss -af -p $$\" - echo \"Then press enter\" - read - exec git annex \"$@\" - ewen@ashram:~/Desktop$ - -so basically \"print PID, wait for go ahead, run git annex command\". - -From a quick glance through, it looks like: - - 7003/0x16c3126: 121576 14 11 write(0x12, \"PidLock {lockingPid = 7003, lockingHost = \\"ashram\\"}\0\", 0x33) = 51 0 - 7003/0x16c3126: 121775 3350 191 close(0x12) = 0 0 - 7003/0x16c3126: 121792 10 6 stat64(\"/Volumes/music/ga-test/.git/annex/locktmp16807282475249\0\", 0x200004940, 0x33) = 0 0 - 7003/0x16c3126: 122041 2341 235 link(\"/Volumes/music/ga-test/.git/annex/locktmp16807282475249\0\", \"/Volumes/music/ga-test/.git/annex/locktmp16807282475249.lnk\0\") = -1 Err#45 - 7003/0x16c3126: 122115 885 49 unlink(\"/Volumes/music/ga-test/.git/annex/locktmp16807282475249.lnk\0\", 0x200004D80, 0x33) = -1 Err#2 - -(in `03-...`, the first `get`) probably isn't helping -- that's trying to do a *hardlink* on a SMB file system, and appearing to give up when it fails... (`/Volumes/music` is the SMB mount I was using for testing). - -Also since I didn't realise until after the `script` file/`tar` file were made, there *is* an `annex/pidlock` file: - - ewen@ashram:~$ ls -l /Volumes/music/ga-test/.git/annex/pidlock - -rwx------ 1 ewen staff 51 14 May 16:25 /Volumes/music/ga-test/.git/annex/pidlock - ewen@ashram:~$ cat /Volumes/music/ga-test/.git/annex/pidlock - PidLock {lockingPid = 7143, lockingHost = \"ashram\"}ewen@ashram:~$ - ewen@ashram:~$ - -created within the SMB `git-annex`, which looks vaguely sensible. And FTR, there is *not* one in the HFS (local OS X) `git-annex`: - - ewen@ashram:~$ ls -l /var/tmp/ga-test/.git/annex/pidlock - ls: /var/tmp/ga-test/.git/annex/pidlock: No such file or directory - ewen@ashram:~$ - -so it definitely seems to *try* to do pidlocking on the SMB mount on transfers, but it looks like maybe it's also trying to do something *not* supported. - -Looking through the OS X `open(2)` manpage, it appears that: - - O_EXCL error if O_CREAT and the file exists - [...] - O_EXLOCK atomically obtain an exclusive lock - -might be plausible non-hardlink locking primitives that'd work better than nothing. The manpage also says: - - When opening a file, a lock with flock(2) semantics can be obtained by - setting O_SHLOCK for a shared lock, or O_EXLOCK for an exclusive lock. - If creating a file with O_CREAT, the request for the lock will never fail - (provided that the underlying filesystem supports locking). - -so maybe that's something to work with? (SMB as a protocol supports All Kinds Of Locking (tm), and hopefully the OS X SMB file system driver would also translate O_EXLOCK, etc, through to those...) - -Hope that's of some help. - -Ewen - -PS: Yes, I do plan to try to install the stand alone x86-64 git-annex on my Synology when I get a spare few hours to sort out all the details. It seems like it would be the most robust solution for my specific problem. But generalised SMB support could also be useful, even if it was \"user needs to be careful about running commands in parallel as there are races\". -"""]] diff --git a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_4_33087a19874447a1cb07aa794c0f030b._comment b/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_4_33087a19874447a1cb07aa794c0f030b._comment deleted file mode 100644 index 041fe926b4..0000000000 --- a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_4_33087a19874447a1cb07aa794c0f030b._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="ewen" - avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e" - subject="Standalone git-annex on Synology DS216+ NAS" - date="2017-05-28T01:24:43Z" - content=""" -For the benefit of future readers, I did manage to [get the stand alone `git-annex` running on my Synology DS216+](http://ewen.mcneill.gen.nz/blog/entry/2017-05-28-git-annex-on-synology-ds216+/). With a little bit of sorting out details, including adding some symlinks in `/usr/bin`, it runs like `git-annex` on any other Linux-based system. At this time that is definitely much easier than trying to use a SMB share if you are able to enable `ssh` access -- but note that `ssh` access to the Synology NAS requires an administrator account, so may not be available to everyone. (Plus of course this work around is useful mainly to relatively open Linux-based NAS solutions.) - -Ewen -"""]] diff --git a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_5_8b5d03f64127aa6b4073ff10796b9771._comment b/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_5_8b5d03f64127aa6b4073ff10796b9771._comment deleted file mode 100644 index 64b1feb8b2..0000000000 --- a/doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_5_8b5d03f64127aa6b4073ff10796b9771._comment +++ /dev/null @@ -1,59 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2017-06-06T17:54:42Z" - content=""" -Here's the relevant parts of the dtruss: - - 7003/0x16c3126: 121483 3371 127 open("/Volumes/music/ga-test/.git/annex/locktmp16807282475249\0", 0x20A06, 0x180) = 18 0 - ... - 7003/0x16c3126: 121792 10 6 stat64("/Volumes/music/ga-test/.git/annex/locktmp16807282475249\0", 0x200004940, 0x33) = 0 0 - 7003/0x16c3126: 122041 2341 235 link("/Volumes/music/ga-test/.git/annex/locktmp16807282475249\0", "/Volumes/music/ga-test/.git/annex/locktmp16807282475249.lnk\0") = -1 Err#45 - 7003/0x16c3126: 122115 885 49 unlink("/Volumes/music/ga-test/.git/annex/locktmp16807282475249.lnk\0", 0x200004D80, 0x33) = -1 Err#2 - 7003/0x16c3126: 122126 5 1 sigreturn(0x7FFF56C9E390, 0x1E, 0x33) = 0 Err#-2 - 7003/0x16c3126: 122247 1050 90 open("/Volumes/music/ga-test/.git/annex/pidlock\0", 0xA01, 0x124) = 18 0 - 7003/0x16c3126: 122256 4 1 fcntl(0x12, 0x3, 0x0) = 1 0 - 7003/0x16c3126: 122260 5 2 fstat64(0x12, 0x20001A120, 0x0) = 0 0 - 7003/0x16c3126: 122273 4 1 ioctl(0x12, 0x4004667A, 0x7FFF56C9E3FC) = -1 Err#25 - 7003/0x16c3126: 122274 2 0 ioctl(0x12, 0x40487413, 0x7FFF56C9E400) = -1 Err#25 - 7003/0x16c3126: 122314 677 32 open("/Volumes/music/ga-test/.git/annex/locktmp16807282475249\0", 0x20004, 0x1B6) = 19 0 - 7003/0x16c3126: 122319 5 2 fstat64(0x13, 0x20001A310, 0x1B6) = 0 0 - 7003/0x16c3126: 122326 2 0 ioctl(0x13, 0x4004667A, 0x7FFF56C9E3FC) = -1 Err#25 - 7003/0x16c3126: 122327 2 0 ioctl(0x13, 0x40487413, 0x7FFF56C9E400) = -1 Err#25 - 7003/0x16c3126: 122381 1455 46 read(0x13, "PidLock {lockingPid = 7003, lockingHost = \"ashram\"}\0", 0x1FA0) = 51 0 - 7003/0x16c3126: 122392 5 2 read(0x13, "\0", 0x1FA0) = 0 0 - 7003/0x16c3126: 122427 1339 27 close(0x13) = 0 0 - 7003/0x16c3126: 122441 10 4 select(0x13, 0x7FFF56C9E340, 0x7FFF56C9E3C0, 0x0, 0x7FFF56C9E330) = 1 0 - 7003/0x16c3126: 122469 661 23 write(0x12, "PidLock {lockingPid = 7003, lockingHost = \"ashram\"}\0", 0x33) = 51 0 - 7003/0x16c3126: 122577 6028 99 close(0x12) = 0 0 - -Avove shows hard linking failed, and it fell back to using open to create -the pidlock file. That seemed to finish successfully. - - 7003/0x16c3126: 122583 4 0 sigreturn(0x7FFF56C9E3B0, 0x1E, 0x33) = 0 Err#-2 - -Unsure what this is? - - 7003/0x16c3126: 122697 2126 101 unlink("/Volumes/music/ga-test/.git/annex/locktmp16807282475249\0", 0x1E, 0x33) = 0 0 - -Here linkToLock must has succeeded, because it deletes the tmp file that was passed to that function. -So, it looks like tryLock succeeded. - - 7003/0x16c3126: 122746 1423 28 stat64(".git/annex/pidlock\0", 0x20001A510, 0x33) = 0 0 - 7003/0x16c3126: 122775 10 5 select(0x2, 0x7FFF56C9E340, 0x7FFF56C9E3C0, 0x0, 0x7FFF56C9E330) = 1 0 - 7003/0x16c3126: 122786 10 8 write(0x1, "(transfer already in progress, or unable to take transfer lock) \0", 0x40) = 64 0 - -I think this is a call to checkSaneLock, which calls getFileStatus, -and since the pid lock was created earlier, that succeeds. -runTransfer does call checkSaneLock, and if it fails -we get the "transfer already in progress, or unable to take transfer lock" -message. - -So, why did checkSaneLock fail? - -Well, the device and inode of the lock file -are compared with the device and inode of the temp file -that was passed to linkToLock. However, since the hard link didn't -happen, the device and inode will be different! -And that's the bug. -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5.mdwn b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5.mdwn deleted file mode 100644 index f2ff387026..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -### Please describe the problem. - -standalone builds leap forward a bit too fast in terms of their demand on modern kernel. Up until a month ago, standalone build worked at least on CentOS 6.5 with 2.6.32-431.11.2.el6.x86_64 (although [already didn't on ancient but still in use RHEL5 with 2.6.18](https://github.com/datalad/datalad/issues/176#issuecomment-114612365)). Current build from 20150916 doesn't work on CentOS 6.5 any longer. No matter how much I like people to use more recent releases of their distributions, it is infeasible to demand people to do that. It would be great if standalone builds were carried out on some elder kernel/libc environment to make git-annex standalone builds usable there. - -> [[done]]; the ancient build provides this. It's now build with stack, so -> it gets most features enabled. (Except xmpp, notably.) This does mean -> it will only get library security fixes once git-annex's stack.yaml -> is updated to require a new version of the affected library. --[[Joey]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_1_625268287fe55e6f2254a6f31c637164._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_1_625268287fe55e6f2254a6f31c637164._comment deleted file mode 100644 index b59365274a..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_1_625268287fe55e6f2254a6f31c637164._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-23T16:00:38Z" - content=""" -This is entirely down to the libc used on the build system and included in -the tarball. - -Currently the builds use unstable or testing because this lets me get new -library-driven features like sha3 into the build (nearly) ASAP. - -It would be possible to switch to using Debian stable. But then I either -lose new library-driven features in the builds, or I have to start -installing haskell libraries from source on the build machines, which would -be a lot of additional work compared to letting Debian maintain hundreds of -haskell library packages for me. - -Then too, while I am pretty much committed to keeping git-annex building on -Debian stable (which is actually a lot of work, up to several thousand -lines of ifdefs, and prevents me from using newer ghc features which would -make my code happier), Debian stable does itself have a habit of updating to a -new libc release every couple of years. So no matter what, as long as libc -keeps requiring slightly less ancient kernels for whatever reasons it does, -everything isn't going to be supported forever. - -(OTOH, I'd expect that some enterprise level ancient distros might start to -include enterprise level ancient builds of git-annex themselves some time soon? -git-annex version 3, which is broadly compatible with current versions was -released a full 4 years ago already. Linux 2.6.32 is only, er, 3 years -older than that.) -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_3ed7589687fe251066677ad5a01bbbb0._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_3ed7589687fe251066677ad5a01bbbb0._comment deleted file mode 100644 index 01f83a095b..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_3ed7589687fe251066677ad5a01bbbb0._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-09-23T17:04:38Z" - content=""" -Actually, git-annex doesn't currently build on debian stable because it -needs a newer version of optparse-applicative. The new version builds just -fine on stable, so could easily be backported. I could probably get -git-annex building with the old version of optparse-applicative, with -sufficient ifdef pain, but a backport would be a nicer solution. -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_557d428d2aa6bf8e5d435e7f5350f5c6._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_557d428d2aa6bf8e5d435e7f5350f5c6._comment deleted file mode 100644 index 179c70f58d..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_557d428d2aa6bf8e5d435e7f5350f5c6._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-09-23T16:36:08Z" - content=""" -Shouldn't it be possible reasonably easily to create env which would just use stock haskell-platform? that one should provide all recent libraries you would need? and then just do that on e.g. debian stable -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment deleted file mode 100644 index 4dfe0f4608..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-09-23T17:14:14Z" - content=""" -It might be possible to use stackage to get a build of all libraries from -the base haskell platform that are not too far out of date and don't break -too often. There is currently no way to upgrade such a build to get newer -version of libraries except for throwing the whole build tree away and -building all libraries again. So, it would be a lot of CPU on an ongoing basis, -or a source of unfixed security bugs. - -And, I think it would not be entirely non-fragile. It's not exactly unheard -of for a new version of a haskell library to accidentally break -compatibility with the old version of ghc which is generally unused in the -haskell community outside of debian stable. Or, to need a newer version of -some C library headers than is in stable, or ... -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_5_8d5e7b7aa25a82e14611e0b852512adf._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_5_8d5e7b7aa25a82e14611e0b852512adf._comment deleted file mode 100644 index d3662569cd..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_5_8d5e7b7aa25a82e14611e0b852512adf._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2015-09-23T17:35:51Z" - content=""" -I've added an "ancient" autobuild, which is run on Debian stable plus -minimal backports (currently of optparse-applicative only). -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_6_391d0ba1cbe59de8e0cca2c29085d9fd._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_6_391d0ba1cbe59de8e0cca2c29085d9fd._comment deleted file mode 100644 index 70f53ea04c..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_6_391d0ba1cbe59de8e0cca2c29085d9fd._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 6" - date="2015-09-23T17:57:43Z" - content=""" -so far we are not bottlenecked in CPU power, so if needed could setup some CPU-intensive rebuilding of such environments (e.g. in a docker) so we could may be even have some \"collection\" of previous environments laying around -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_7_a72bed153e91e32ebd8944e5ee17c186._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_7_a72bed153e91e32ebd8944e5ee17c186._comment deleted file mode 100644 index 86043c49f3..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_7_a72bed153e91e32ebd8944e5ee17c186._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2015-09-30T17:09:49Z" - content=""" -I got stack working to build git-annex over the weekend, and it's now the -recommended way to build from source, since it avoids library churn issues -and automates everything. Upgrades can also be made to happen by increasing -the lts version in the stack.yaml file. - -So using that and the haskell platform would be a way to get an even more -ancient distribution autobuilding. (But, I had to leave out xmpp and dbus -support to make the stack recipe work everywhere, so I don't want to make -the regular autobuilds built using stack.) -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_8_be1d950835ee47774063e1335dd043e3._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_8_be1d950835ee47774063e1335dd043e3._comment deleted file mode 100644 index 218126f252..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_8_be1d950835ee47774063e1335dd043e3._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="standalone builds" - date="2015-10-08T16:35:10Z" - content=""" -Thanks Joey. So the standalone builds you currently have will still be full featured builds, but where could we get those ones with limited functionality? may be they could be automated and made available alongside with corresponding description (for older systems, without assistant functionalities such as X and Y)? -"""]] diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_9_805c0e3d4f3d0f3d4c1d4e6e9a5cf032._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_9_805c0e3d4f3d0f3d4c1d4e6e9a5cf032._comment deleted file mode 100644 index c1d9a876ec..0000000000 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_9_805c0e3d4f3d0f3d4c1d4e6e9a5cf032._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="ah -- the 32bit build I guess" - date="2015-10-08T17:50:50Z" - content=""" -ah -- now I saw the https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386-ancient.tar.gz which is I guess as ancient as it could get ;) unfortunately \"was built without its test suite; not testing\" so can't test but let's see how it performs ;) -"""]] diff --git a/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity.mdwn b/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity.mdwn deleted file mode 100644 index e7db9503e7..0000000000 --- a/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -This is a bug report about the "Starting at power on" section of the documentation in , which says: - ->If you install the Termux:Boot app, git-annex will automatically be automatically started when your Android device powers on. It will run in the background in whatever repositories you have set up in the webapp. ->(Or have listed in (or listed in ~/.config/git-annex/autostart) - -This gives rise to several questions: - -Will it really be automatically started without any additional configuration from the user? That's what the first sentence appears to claim, but it appears to contradict which suggests that manual configuration of `~/.termux/boot` is required. - -But if it's really true, exactly what `git-annex` command will be automatically started? Since running with no arguments simply outputs usage text. - -Or if manual configuration of `~/.termux/boot` *is* required, what exactly should that look like? Should it be `git annex assistant --autostart`, as per [[forum/Autostart_the_assistant]]? - -What's the format of the contents of `~/.config/git-annex/autostart`? - -Finally, the last sentence has unbalanced parentheses, and doesn't parse correctly. - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity/comment_1_345d53a4c8a3051a600dc4c45ce2e50e._comment b/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity/comment_1_345d53a4c8a3051a600dc4c45ce2e50e._comment deleted file mode 100644 index d1e489802c..0000000000 --- a/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity/comment_1_345d53a4c8a3051a600dc4c45ce2e50e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847" - nickname="marvin" - avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e" - subject="comment 1" - date="2018-10-25T21:00:32Z" - content=""" -i never ran the termux:boot on my android so far. but i can tell you what i discovered about the format of ~/.config/git-annex/autostart. use the full paths... no \"~\"s. that was my failure and i wondered why git-annex assistant --autostart didnt find anything. and then one repo per line. this worked for me. -"""]] diff --git a/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity/comment_2_a928028697a46c8dda04c91b85eb8733._comment b/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity/comment_2_a928028697a46c8dda04c91b85eb8733._comment deleted file mode 100644 index 940a96c405..0000000000 --- a/doc/bugs/Termux__58__Boot_instructions_need_a_bit_of_clarity/comment_2_a928028697a46c8dda04c91b85eb8733._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-10-26T17:47:12Z" - content=""" -Yes, it's really set up automatically. The first time the git-annex webapp -is run, it sets up the necessary Termux:Boot configuration to run the -assistant on boot. - -Fixed the paste errors. -"""]] diff --git a/doc/bugs/The_S3_special_remote_limits_HTTPS_support_to_port_443.mdwn b/doc/bugs/The_S3_special_remote_limits_HTTPS_support_to_port_443.mdwn deleted file mode 100644 index 49704cd94a..0000000000 --- a/doc/bugs/The_S3_special_remote_limits_HTTPS_support_to_port_443.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -### Please describe the problem. -The S3 special remote assumes that yout want to use HTTPS iff your service runs on port 443. This isn't true for most minio deployments. - -### What steps will reproduce the problem? -Attempt to add a S3 service using HTTPS and a port != 443 as special remote. - -### What version of git-annex are you using? On what operating system? -Version 7.20181121 on MacOS and 7.20190130-g024120065 on FreeBSD - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes. I only encountered the problem because git-annex works well enough for me that I want to put a lot more data into it. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/The_S3_special_remote_limits_HTTPS_support_to_port_443/comment_1_f6de7a30714d6281a81ae218bb92dfd6._comment b/doc/bugs/The_S3_special_remote_limits_HTTPS_support_to_port_443/comment_1_f6de7a30714d6281a81ae218bb92dfd6._comment deleted file mode 100644 index ba24ec5d67..0000000000 --- a/doc/bugs/The_S3_special_remote_limits_HTTPS_support_to_port_443/comment_1_f6de7a30714d6281a81ae218bb92dfd6._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-03-22T15:48:24Z" - content=""" -I've added a protocol= setting, so you can use port=N protocol=https -"""]] diff --git a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn deleted file mode 100644 index 11f4a9a3e1..0000000000 --- a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn +++ /dev/null @@ -1,111 +0,0 @@ -### Please describe the problem. - -I noticed three tests failed when running "git annex test", and it seems -it's because I have `annex.backends` set to `SHA256` in `~/.gitconfig`. -When I disable that option, all tests succeed. - -### What steps will reproduce the problem? - -Add - - [annex] - backends = SHA256 - -to `~/.gitconfig`. - -### What version of git-annex are you using? On what operating system? - -Newest git-annex (6.20160211 amd64) from downloads.kitenet.net. - -- Debian GNU/Linux 8.3 (64 bit). Installed yesterday, so it's pretty pristine. -- git version 2.7.1.287.g4943984 (Newest version from 'master' in - git.git) - -The first version with this problem is 6.20160114. 5.20151218 works. - -### Please provide any additional information below. - -[[!format text """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$ git annex test -Tests - -[Removed 188 lines] - - migrate (via gitattributes): /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -OK (3.11s) - unused: /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -FAIL (1.84s) - unused keys differ after origin branches are gone - expected: [Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}] - but got: [Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}] - describe: /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -OK (0.84s) - -[Removed 1108 lines] - - migrate (via gitattributes): /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -OK (3.34s) - unused: /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -/etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -/etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -FAIL (1.82s) - unused keys differ after origin branches are gone - expected: [Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}] - but got: [Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}] - describe: /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' -OK (0.78s) - -[Removed 1062 lines] - - migrate (via gitattributes): OK (2.64s) - unused: FAIL (1.53s) - unused keys differ after origin branches are gone - expected: [Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}] - but got: [Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}] - describe: OK (0.62s) - -[Removed 1667 lines] - -3 out of 269 tests failed (640.58s) - (This could be due to a bug in git-annex, or an incompatibility - with utilities, such as git, installed on this system.) -$ - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Roses are red
-Violets are blue
-git-annex is awesome
-and so are you - -`;-)` - -But bloody hell, it's hard to get this thing to build. As you've -mentioned earlier, building on Debian 7 isn't supported anymore, so I -installed Debian 8.3 yesterday for the sole purpose of compiling git-annex, -but still no luck: - - [32 of 32] Compiling Main ( dist/setup/setup.hs, dist/setup/Main.o ) - Linking ./dist/setup/setup ... - unrecognized option `--extra-prog-path=/home/sunny/.cabal/bin' - Makefile:19: recipe for target 'Build/SysConfig.hs' failed - make: *** [Build/SysConfig.hs] Error 1 - -I was hoping to get it to build so I could find the exact commit that -introduced this, and also provide some patches with some functionality -I've been thinking of. Is building on Debian 8.3 (jessie) supported? I -found a bug report from you on - that seems to -be related, but I don't know if that's the case. The newest version I'm -able to build is 5.20150219, somewhere after that various things start -to fail. - -> [[fixed|done]]; I found a way to isolate the test suite from global git -> configs, by setting `GIT_CONFIG_NOSYSTEM` and also setting -> `HOME` and `XDG_CONFIG_HOME` to an empty directory. --[[Joey]] diff --git a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined/comment_1_153ba2b98b65fcc6156b1f2f967839b2._comment b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined/comment_1_153ba2b98b65fcc6156b1f2f967839b2._comment deleted file mode 100644 index 194439668d..0000000000 --- a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined/comment_1_153ba2b98b65fcc6156b1f2f967839b2._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-17T16:16:53Z" - content=""" -The solution to your build failure is to edit ~/.cabal/config and remove -the extra-prog-path line. (It's unfortunate that Debian shipped 8.3 with -that bug. I told them about it before the release, but they didn't get it -fixed in time.) - -There are probably several other config settings that also break -the test suite if set in a global gitconfig. For example the -annex.addunlocked setting I added yesterday will. - -I think the best approach is to isolate the the test suite from global git -config settings. Making the test suite set `GIT_CONFIG` to the config of -each test repo it runs git-annex in seems like it would -work; this prevents git from reading the user and global configs. - -The test suite could set all config values to defaults -in the test git repos. But this would need some restructuring of the code to -be able to not just query, but also set those values. -"""]] diff --git a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined/comment_2_20bd7de1902f7e3e4afdb8a8ff0ca1b7._comment b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined/comment_2_20bd7de1902f7e3e4afdb8a8ff0ca1b7._comment deleted file mode 100644 index 917a88c1fc..0000000000 --- a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined/comment_2_20bd7de1902f7e3e4afdb8a8ff0ca1b7._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-02-17T19:19:18Z" - content=""" -Setting `GIT_CONFIG` won't work well, because sometimes git-annex in one -repo needs to look at the config of another repo, which would be prevented -by that setting. -"""]] diff --git a/doc/bugs/Unable_to_initialize_v5_Repository_on_a_Crippled_Filesystem.mdwn b/doc/bugs/Unable_to_initialize_v5_Repository_on_a_Crippled_Filesystem.mdwn deleted file mode 100644 index ab460671e8..0000000000 --- a/doc/bugs/Unable_to_initialize_v5_Repository_on_a_Crippled_Filesystem.mdwn +++ /dev/null @@ -1,48 +0,0 @@ - -### Fixed in Version 7.20190122 - -Hello, -When doing a "git annex init somename --version=5" on git-annex 7.20181211, it still creates an v7 repository. I want to be able to use the direct-mode because of space constraints (v7 unlocked files take up double the space). - -### What steps will reproduce the problem? -See the transcript below, on a vfat-Filesystem. - -### What version of git-annex are you using? On what operating system? -7.20181211 on debian buster - -### Please provide any additional information below. - -[[!format sh """ - -$ git init -Initialized empty Git repository in /media/xxx/xxx/.git/ -$ git annex init yellow-thumbdrive --version=5 -init yellow-thumbdrive - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Entering an adjusted branch where files are unlocked as this filesystem does not support locked files. - -Switched to branch 'adjusted/master(unlocked)' -ok -(recording state in git...) -$ git annex version -git-annex version: 7.20181211 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 5 7 -upgrade supported from repository versions: 0 1 2 3 4 5 6 -local repository version: 7 - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -> [[done]] diff --git a/doc/bugs/Unable_to_take_transfer_lock.mdwn b/doc/bugs/Unable_to_take_transfer_lock.mdwn deleted file mode 100644 index e1d4f0a117..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock.mdwn +++ /dev/null @@ -1,46 +0,0 @@ -### Please describe the problem. - -`git annex get --from=myremote' show "transfer already in progress, or unable to take transfer lock". - -**Likely Problem discovered!** I copied the whole remote repo (was residing on a Linux machine accessed via SMB) and pasted it into my Mac. The problem was resolved. It is likely something to do with the fact that Mac OS filesystem is **case-insensitive**. I discovered this issue when I tried to copy that remote repo with ``cp`` rather than ``tar``ing it first. - - -### What steps will reproduce the problem? - -Remote is on a Linux machine. -Do `git annex get' on a Mac OS. -Do the same on another Linux machine. - -The git annex client on the Linux machine works. -Mac OS doesn't. - -rsync version for all machines: 3.1.1 - -### What version of git-annex are you using? On what operating system? - -git-annex 5.20151019 - -Lubuntu 15.10. -Mac OS X 10.11.1 (El Capitan) - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes. - -It's wonderful. This should be a problem with Mac OS. - -> [[done]]; this appears to be the same bug as -> [[parallel_get_can_fail_some_downloads_and_require_re-getting_]], -> which was fixed in 6.20170520. -> --[[Joey]] diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_1_4eff7f261659202084d32e068b93f77b._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_1_4eff7f261659202084d32e068b93f77b._comment deleted file mode 100644 index 3db482bc19..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock/comment_1_4eff7f261659202084d32e068b93f77b._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-30T19:46:05Z" - content=""" -The most likely reason for that error message would be if a transfer -of the same file was already in progress by another git-annex process. - -It might also be the case that if you're trying to access a git-annex -repository via SMB, the POSIX fcntl locking that git-annex needs to do -don't work. This is often the case with various network filesystems. -Solution is to make the url for the git remote be a ssh:// url instead. - -I don't know what OSX's case-insensative complication could have to do with -this, although it certianly seems to be a good way to get completely -unexpected behavior. - -Is there an actual bug here? What are the steps to reproduce -it? -"""]] diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_2_88a6132696bd299fc40359ff56657596._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_2_88a6132696bd299fc40359ff56657596._comment deleted file mode 100644 index 3a7426cf07..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock/comment_2_88a6132696bd299fc40359ff56657596._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="jhannwong@c9c7a67b5632a4bbc0c959cfeb3d340e02f28565" - nickname="jhannwong" - subject="Am pretty sure this is a filesystem issue" - date="2015-12-01T12:45:50Z" - content=""" -Same git-annex repo. One resides on Linux; the other on Mac OS. - -The one on Mac OS can be accessed (`git annex get') by git clones on Linux and on Mac OS. - -The one on Linux can only be accessed by git clones on Linux. - -I even tracked it down to folders having the same name --- 'Fs' vs 'FS'. -"""]] diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_3_8ba3d4eb6ff857d6a33e5a84808fe4fa._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_3_8ba3d4eb6ff857d6a33e5a84808fe4fa._comment deleted file mode 100644 index 39b3f7a9e8..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock/comment_3_8ba3d4eb6ff857d6a33e5a84808fe4fa._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-12-02T17:01:36Z" - content=""" -What specific path names in the git repository did you track it down to? -"""]] diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_4_7468862a6d4ec47320071aa52ae4072a._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_4_7468862a6d4ec47320071aa52ae4072a._comment deleted file mode 100644 index a3ef3c0de0..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock/comment_4_7468862a6d4ec47320071aa52ae4072a._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="luca@b7e273474d087a5c7fc4428503f21d5624636d9f" - nickname="luca" - subject="comment 4" - date="2016-02-05T06:43:11Z" - content=""" -I get this error on OS X when setting the `-J` parameter to > 1, this works: - - git annex copy --to usb -J1 --auto - -This consistently throughs the error (but seems to copy everything): - - git annex copy --to usb -J2 --auto - -I'm running 6.20160126 on version 5 repositories. -"""]] diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment deleted file mode 100644 index 89ac13197d..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2016-02-05T17:01:24Z" - content=""" -@luca you might get that with -J2 if you have two work tree files that -point to the same key. The first thread will start copying the first file, -and then the second thread tries to copy the second file but sees the key -is already being copied. - -It shouldn't happen otherwise; the way -J works is it splits files between -threads. So, no two threads will be working on the same file, except in the -situation described above. - -I doubt that whatever you're seeing is the same problem originally -described in this bug report. I'm still waiting for a followup with missing -information about the originally described bug. -"""]] diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_6_4778b7004983ccea7a6ad87cfd61a0f1._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_6_4778b7004983ccea7a6ad87cfd61a0f1._comment deleted file mode 100644 index 0318092613..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock/comment_6_4778b7004983ccea7a6ad87cfd61a0f1._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="aer1PheiZa" - avatar="http://cdn.libravatar.org/avatar/1fb7b6779a544f27abf147fc614d6633" - subject="6.20170101 - still unable. " - date="2017-08-07T11:58:05Z" - content=""" -In 'git annex get . -J1' anything more than one given to -J causes annex to \"unable to transfer\", and the files are not copied. The higher the number, the more likely it is not to transfer any of the involved files. At the end it has to be run with -J1, because even running it multiple times does not really help. -And yes, all the files are different, as they are photos, and there are no copies. For me it looks like a race. -"""]] diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_7_051d76ff1ac98fc1e1f70872390dadbf._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_7_051d76ff1ac98fc1e1f70872390dadbf._comment deleted file mode 100644 index 98018439d8..0000000000 --- a/doc/bugs/Unable_to_take_transfer_lock/comment_7_051d76ff1ac98fc1e1f70872390dadbf._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2017-10-02T16:33:34Z" - content=""" -aer1PheiZa, I think this was fixed in 6.20170520. If you (or anyone else -still watching this) sees it with a newer version than that, let me know. -"""]] diff --git a/doc/bugs/Unchanged_files_are_detected_as_modified_in_unlocked_branch.mdwn b/doc/bugs/Unchanged_files_are_detected_as_modified_in_unlocked_branch.mdwn deleted file mode 100644 index 7580e0d213..0000000000 --- a/doc/bugs/Unchanged_files_are_detected_as_modified_in_unlocked_branch.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -### Please describe the problem. - -I have a git-annex repo with lots of images and keep a unlocked v6 branch around to access them. When new files are added (i.e. after running `git annex sync --content`), they are often detected as "modified": - - $ git annex status . - M image.jpg - -They are however identical to the checked-in files: - - $ cp image.jpg image-changed.jpg - $ git checkout -- image.jpg - $ cmp image.jpg image-changed.jpg && echo "No change" - No change - -This seems to happen to older files from time to time as well, but I cannot reproduce that. - -The only way to rectify this I can find is `git checkout` - but that means I have no way to know whether I am actually throwing away changes. It also has the unfortunate side effect of changing the mtime, leading to previews having to be regenerated. - -### What version of git-annex are you using? On what operating system? - -git-annex version: 6.20171026-gd451d333d (standalone binary) on Debian stretch. - -[[!meta title="v6 get/drop make git think files are changed"]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Unchanged_files_are_detected_as_modified_in_unlocked_branch/comment_1_d5e90cf5edf189bb023deb46b5ffe96c._comment b/doc/bugs/Unchanged_files_are_detected_as_modified_in_unlocked_branch/comment_1_d5e90cf5edf189bb023deb46b5ffe96c._comment deleted file mode 100644 index d635819d7d..0000000000 --- a/doc/bugs/Unchanged_files_are_detected_as_modified_in_unlocked_branch/comment_1_d5e90cf5edf189bb023deb46b5ffe96c._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-11-09T15:56:41Z" - content=""" -This is one of the primary known problems with v6 mode. On the page -[[todo/smudge]] that collects all such issues, it's the second item. -Basically, when git-annex gets/drops the content of the file, it -updates the work tree file, and so git thinks the file has changed. -Currently the best way to deal with it is to run `git add` on the file. -"""]] diff --git a/doc/bugs/Upload_to_box_very_slow.mdwn b/doc/bugs/Upload_to_box_very_slow.mdwn deleted file mode 100644 index 006fe1afa7..0000000000 --- a/doc/bugs/Upload_to_box_very_slow.mdwn +++ /dev/null @@ -1,122 +0,0 @@ -### Please describe the problem. - -In recent version of git-annex (including the most recent standalone version), uploading to box is slow. Typically, it will take 25 seconds or so for git-annex to begin the upload, whereas with previous versions it happened almost instantly. - -I used git bisect and rebuilds via stack to locate the commit that introduced this problem. This was the result: - - Bisecting: 0 revisions left to test after this (roughly 0 steps) - [cf51f40f0eaed2c5968f35b94bebab4a1c819491] webdav: Changed path used on webdav server for temporary files. - -Please note: this is distinct from the bug I reported here (https://git-annex.branchable.com/bugs/git-annex_can_no_longer_copy_files_to_box/), since it also affects the standalone version. - -### What steps will reproduce the problem? - -Use a version of git annex built after the commit above from Sept. 15 (e.g., a recent standalone): - -Use a repo with a box remote set up with encryption and chunking: - - WEBDAV_USERNAME=[username] WEBDAV_PASSWORD=[passwd] git annex initremote box type=webdav url=https://dav.box.com/dav/mystuff/annex chunk=100mb keyid=[keyid] - - echo "Hello, world!" > test.txt - git add test.txt - git annex --verbose --debug copy -t box test.txt - -### What version of git-annex are you using? On what operating system? - -Tested with the nightly standalone build on arch linux: - - git-annex version: 6.20171006-gbeca3ce2b - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -### Please provide any additional information below. - -Here is the output: - - % ~/git-annex.linux/git-annex --verbose --debug copy -t box test.txt - [2017-10-07 10:13:25.283802979] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] - [2017-10-07 10:13:25.294784901] process done ExitSuccess - [2017-10-07 10:13:25.295173712] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2017-10-07 10:13:25.305375915] process done ExitSuccess - [2017-10-07 10:13:25.306659057] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] - [2017-10-07 10:13:25.307617362] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] - [2017-10-07 10:13:25.338084356] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","test.txt"] - copy test.txt [2017-10-07 10:13:25.360741244] chat: gpg ["--quiet","--trust-model","always","--decrypt"] - [2017-10-07 10:13:25.454260122] process done ExitSuccess - (checking box...) (to box...) - [2017-10-07 10:13:26.215000484] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"] - 100% 2 B/s 7s[2017-10-07 10:13:58.059203157] process done ExitSuccess - ok - -Note the 32 second delay from 10:13:26 to 10:13:58 here - - [2017-10-07 10:13:58.066819166] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] - [2017-10-07 10:13:58.067584497] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"] - [2017-10-07 10:13:58.216568109] process done ExitSuccess - [2017-10-07 10:13:58.216839725] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2017-10-07 10:13:58.227738805] process done ExitSuccess - (recording state in git...) - [2017-10-07 10:13:58.227942884] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"] - [2017-10-07 10:13:58.386915393] process done ExitSuccess - [2017-10-07 10:13:58.387325088] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","bf90d33cdcf43119d2608e90fa6fdc23c497950d","--no-gpg-sign","-p","refs/heads/git-annex"] - [2017-10-07 10:13:58.400174021] process done ExitSuccess - [2017-10-07 10:13:58.400315661] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","b9583c0cf24933de01063281108f6d0c3a98053b"] - [2017-10-07 10:13:58.413220259] process done ExitSuccess - [2017-10-07 10:13:58.414476091] process done ExitSuccess - [2017-10-07 10:13:58.414890325] process done ExitSuccess - [2017-10-07 10:13:58.415545095] process done ExitSuccess - -Compare this with the results of git-annex built with stack that does not include the problematic commit: - - git-annex version: 6.20170915-g122396029 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Quvi - dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.21 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.6.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -Here is the output: - - % git annex --verbose --debug copy -t box test.txt - [2017-10-07 10:51:28.863004037] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] - [2017-10-07 10:51:28.866087687] process done ExitSuccess - [2017-10-07 10:51:28.866184907] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2017-10-07 10:51:28.868674623] process done ExitSuccess - [2017-10-07 10:51:28.869107711] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..5cc79198b2eb9e281d64b9eed7b1b6a2e869fb20","--pretty=%H","-n1"] - [2017-10-07 10:51:28.87271685] process done ExitSuccess - [2017-10-07 10:51:28.873655522] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] - [2017-10-07 10:51:28.874173468] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] - [2017-10-07 10:51:28.896038454] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","test.txt"] - copy test.txt [2017-10-07 10:51:28.909441282] chat: gpg ["--quiet","--trust-model","always","--decrypt"] - [2017-10-07 10:51:28.997627719] process done ExitSuccess - (checking box...) (to box...) - [2017-10-07 10:51:29.838627434] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"] - 100% 85 B/s 0s[2017-10-07 10:51:34.465610054] process done ExitSuccess - ok - -Notice the 5 second gap here: - - - [2017-10-07 10:51:34.469743494] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] - [2017-10-07 10:51:34.47009347] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"] - [2017-10-07 10:51:34.588535947] process done ExitSuccess - [2017-10-07 10:51:34.588699027] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2017-10-07 10:51:34.591436472] process done ExitSuccess - (recording state in git...) - [2017-10-07 10:51:34.59158293] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"] - [2017-10-07 10:51:34.767927859] process done ExitSuccess - [2017-10-07 10:51:34.768081231] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","b7c89dee187ca46d21ad05937d746acb149c323e","--no-gpg-sign","-p","refs/heads/git-annex"] - [2017-10-07 10:51:34.799274341] process done ExitSuccess - [2017-10-07 10:51:34.799458862] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","676897d54eeecff41c28432e903671400b3c0b84"] - [2017-10-07 10:51:34.802489572] process done ExitSuccess - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! Thank you! - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Upload_to_box_very_slow/comment_1_602697f6ea6cfd07764b1e9ed040736c._comment b/doc/bugs/Upload_to_box_very_slow/comment_1_602697f6ea6cfd07764b1e9ed040736c._comment deleted file mode 100644 index a5e9b69c3d..0000000000 --- a/doc/bugs/Upload_to_box_very_slow/comment_1_602697f6ea6cfd07764b1e9ed040736c._comment +++ /dev/null @@ -1,34 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-10-07T17:03:56Z" - content=""" -I suspect that the problem dealt with in -[[!commit 2ca1d3cc0134134314649c21822bf1352df52e93]] -is responsible for this behavior. If many redirects are -followed before git-annex gives up, it would explain why it's taking so long. - -In redirecting from a non-existant file to some index.php file that itself -doesn't exist, and so on forever, box.com is clearly a horrible, broken, -very bad webdav server. Given that it's so broken, it's not terribly -surprising that small changes might expose that or another brokenness in -different ways. Changing the location of a temp file from a tmp -subdirectory to the parent directory is not the kind of thing that causes -30 second delays with non-broken servers. - -I have not been able to reproduce the problem here though so that is just a -theory. - -I am not inclined to make random changes to try to work around random -breakage in box.com. That is a game you lose before you start playing. - -It may be that deleting line 132 from Remote/WebDAV.hs avoids -the problem. - - maybe noop (void . mkColRecursive) (locationParent tmp) - -Since the parent directory of the temp file is the top of the webdav -repository, and so already exists, that line is now unnecessary. -Since you can reproduce the problem and build from source, can you test -that change? -"""]] diff --git a/doc/bugs/Upload_to_box_very_slow/comment_2_380443c65e576959dddae499745bff09._comment b/doc/bugs/Upload_to_box_very_slow/comment_2_380443c65e576959dddae499745bff09._comment deleted file mode 100644 index 6dbd775ba3..0000000000 --- a/doc/bugs/Upload_to_box_very_slow/comment_2_380443c65e576959dddae499745bff09._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-10-07T18:05:44Z" - content=""" -Also, I've added logging of all webdav operations with --debug, which -should help with determining what operation is being slow. -"""]] diff --git a/doc/bugs/Upload_to_box_very_slow/comment_3_08d3bee435eb0950b3f6ac3b458dda18._comment b/doc/bugs/Upload_to_box_very_slow/comment_3_08d3bee435eb0950b3f6ac3b458dda18._comment deleted file mode 100644 index f4f9fc6669..0000000000 --- a/doc/bugs/Upload_to_box_very_slow/comment_3_08d3bee435eb0950b3f6ac3b458dda18._comment +++ /dev/null @@ -1,46 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="First test" - date="2017-10-09T14:22:22Z" - content=""" -I'm sorry to hear that Box has a buggy WebDav server. I would gladly shift away from Box except that I have unlimited storage through my university. So thanks for being willing to help debug this problem! - -Here is the first test *without* making the change above but with the new debug information. You can see the big gap after 9:04:54 and \"getProps .\". This test actually failed, so it could be that this bug is related to the earlier one I reported. I cannot reproduce this reliably with the latest build using stack. Sometimes git annex uploads the file after a long delay, sometimes it fails. - - % git annex --verbose --debug copy -t box test.txt - [2017-10-09 09:04:52.566913246] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"] - [2017-10-09 09:04:52.570241399] process done ExitSuccess - [2017-10-09 09:04:52.570335828] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] - [2017-10-09 09:04:52.573016175] process done ExitSuccess - [2017-10-09 09:04:52.57406831] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"] - [2017-10-09 09:04:52.57444107] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"] - [2017-10-09 09:04:52.595364899] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"test.txt\"] - copy test.txt [2017-10-09 09:04:52.609509008] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] - [2017-10-09 09:04:52.699246422] process done ExitSuccess - (checking box...) [2017-10-09 09:04:52.739720313] getProps 90a/d4d/GPGHMACSHA1--53636e5e7a50bc58eae478ddc260bb5abd899d03/GPGHMACSHA1--53636e5e7a50bc58eae478ddc260bb5abd899d03 - (to box...) - [2017-10-09 09:04:54.134452518] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"19\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"] - [2017-10-09 09:04:54.188323123] getProps . - [2017-10-09 09:05:24.214747951] mkCol . - [2017-10-09 09:05:24.900782145] process done ExitSuccess - - DAV failure: Status {statusCode = 405, statusMessage = \"Method Not Allowed\"} \"\n\n Sabre_DAV_Exception_MethodNotAllowed\n The resource you tried to create already exists\n\n\" HTTP request: \"MKCOL\" \"/dav/mystuff/annex/.\" - failed - [2017-10-09 09:05:24.903485338] process done ExitSuccess - [2017-10-09 09:05:24.904346521] process done ExitSuccess - git-annex: copy: 1 failed - -git-annex-version - - git-annex version: 6.20171007-g7613a5e81 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Quvi - dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.21 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.6.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -"""]] diff --git a/doc/bugs/Upload_to_box_very_slow/comment_4_9c503745b9c450f422ce47d9fd43e9b8._comment b/doc/bugs/Upload_to_box_very_slow/comment_4_9c503745b9c450f422ce47d9fd43e9b8._comment deleted file mode 100644 index 0b3f640c7a..0000000000 --- a/doc/bugs/Upload_to_box_very_slow/comment_4_9c503745b9c450f422ce47d9fd43e9b8._comment +++ /dev/null @@ -1,51 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="Second test (without line 134)" - date="2017-10-09T14:40:45Z" - content=""" -I removed line 134 and rebuilt using Stack: - - maybe noop (void . mkColRecursive) (locationParent tmp) - -The file uploaded right away: - - % git annex --verbose --debug copy -t box test.txt - [2017-10-09 09:36:32.711847016] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"] - [2017-10-09 09:36:32.809619031] process done ExitSuccess - [2017-10-09 09:36:32.809888889] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] - [2017-10-09 09:36:32.812814521] process done ExitSuccess - [2017-10-09 09:36:32.829791929] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"] - [2017-10-09 09:36:32.830463363] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"] - [2017-10-09 09:36:32.862446411] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"test.txt\"] - copy test.txt [2017-10-09 09:36:32.904592591] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] - [2017-10-09 09:36:33.015053401] process done ExitSuccess - (checking box...) [2017-10-09 09:36:33.127413417] getProps 90a/d4d/GPGHMACSHA1--53636e5e7a50bc58eae478ddc260bb5abd899d03/GPGHMACSHA1--53636e5e7a50bc58eae478ddc260bb5abd899d03 - (to box...) - [2017-10-09 09:36:35.646456289] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"19\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"] - [2017-10-09 09:36:35.700070757] putContent git-annex-webdav-tmp-GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624 - 100% 153 B/s 0s[2017-10-09 09:36:37.830031092] delContent 18f/335/GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624/GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624 - [2017-10-09 09:36:38.453637089] getProps 18f/335/GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624 - [2017-10-09 09:36:38.891805895] mkCol 18f/335/GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624 - [2017-10-09 09:36:39.47474337] moveContent git-annex-webdav-tmp-GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624 https://dav.box.com/dav/mystuff/annex/18f/335/GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624/GPGHMACSHA1--b7d5df88040626033a471159a0652c9e3777d624 - [2017-10-09 09:36:40.325543883] process done ExitSuccess - ok - [2017-10-09 09:36:40.343371234] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"] - [2017-10-09 09:36:40.346018836] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"] - [2017-10-09 09:36:40.574634504] process done ExitSuccess - [2017-10-09 09:36:40.574833127] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] - [2017-10-09 09:36:40.579083747] process done ExitSuccess - (recording state in git...) - [2017-10-09 09:36:40.579508229] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"] - [2017-10-09 09:36:40.908596805] process done ExitSuccess - [2017-10-09 09:36:40.908746261] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"890c8c30542bfb566cb0f6c18948661f9dba3477\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"] - [2017-10-09 09:36:40.911636345] process done ExitSuccess - [2017-10-09 09:36:40.911746341] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"8f02270fa945f2381b63ed2f8280f8f966628a70\"] - [2017-10-09 09:36:40.916033767] process done ExitSuccess - [2017-10-09 09:36:40.917348489] process done ExitSuccess - [2017-10-09 09:36:40.917759841] process done ExitSuccess - [2017-10-09 09:36:40.918326516] process done ExitSuccess - - - -"""]] diff --git a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition.mdwn b/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition.mdwn deleted file mode 100644 index 351851e246..0000000000 --- a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -### Please describe the problem. - -Originally shown/discussed in [local caching](http://git-annex.branchable.com/tips/local_caching_of_annexed_files/#comment-7f214f4eaa629b7731f82014a2e98964) tips page. Decided to give it a separate page for easier tracking etc. - -In my use case I have `/home` and `/mnt/btrfs/` as two subvolumes of the same drive - -[[!format sh """ -/dev/md10 on /mnt/btrfs type btrfs (rw,noatime,compress=lzo,space_cache,subvolid=5,subvol=/) -/dev/md10 on /home type btrfs (rw,noatime,compress=lzo,space_cache,subvolid=257,subvol=/home) -"""]] - -BTRFS's CoW is a great feature for annex, but whenever I try to `annex get` across those two (git annex version was 7.20190322+git133-g59922f1f4-1~ndall+1) - `rsync` is used instead of `cp`, disks got really busy, and I end up with >70GB of additional space utilization, which is "suboptimal". - -As in the original comments thread, I wonder on what is the advantage of using `rsync` over a regular `cp` across devices? (`Device` from `stat` seems to return different ids across volumes, so a bad indicator) - -If there is some generic benefit from `rsync`, could it may be at least be a configuration setting which I would set globally on machines with btrfs to use `cp` instead of `rsync` for local transfers? - - -[[!meta author="yoh"]] - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_1_a4b8273dca2e7d33c40166e34319263b._comment b/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_1_a4b8273dca2e7d33c40166e34319263b._comment deleted file mode 100644 index cc8cddae9d..0000000000 --- a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_1_a4b8273dca2e7d33c40166e34319263b._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-07-17T15:52:20Z" - content=""" -The reason git-annex uses rsync is it can resume interrupted transfers, -and cp cannot. - -As well as this btrfs subvolume problem, the current behavior has the -problem that when it uses cp on a non-CoW filesystem, it doesn't resume. - -It would really be nice to have a way to probe if CoW is supported for a -given combination of src, dest. - -One way would be to use `cp --reflink=always` and if it fails fall back to -rsync. But the overhead of running an extra cp command for each file, while -at first seemingly small, is actually fairly large. - -I benchmarked two shell loops over 1000 files. One did a `cp ---reflink=always`, which always failed. That took 2 seconds. One used rsync -to copy the (empty) file to 1000 different destination files. That took 3.7 -seconds. - -It seems that it would be worth the complication to try `cp --reflink=always` -just once per remote, and if it fails, fall back to rsync for the remainder -of the process's operations on that remote. -"""]] diff --git a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_2_319f0fd9159cb6022b8ede10c12586c1._comment b/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_2_319f0fd9159cb6022b8ede10c12586c1._comment deleted file mode 100644 index 4c577fb6bc..0000000000 --- a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_2_319f0fd9159cb6022b8ede10c12586c1._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2019-07-17T18:13:17Z" - content=""" -CoW probing implemented -"""]] diff --git a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_3_419a36dfd9c0dd7f31cacadd097860f8._comment b/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_3_419a36dfd9c0dd7f31cacadd097860f8._comment deleted file mode 100644 index d83c3b3f9a..0000000000 --- a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_3_419a36dfd9c0dd7f31cacadd097860f8._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="yarikoptic" - avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" - subject="comment 3" - date="2019-07-30T15:18:57Z" - content=""" -Thank you Joey! -"""]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail.mdwn b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail.mdwn deleted file mode 100644 index 6e5fd8433d..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail.mdwn +++ /dev/null @@ -1,134 +0,0 @@ -[[!tag moreinfo]] - -### Please describe the problem. -git annex get on a clone of a repository created on Windows fails. - -### What steps will reproduce the problem? -On Windows: -1. Create an annex using git annex init - -2. git add files - -3. git annex sync (because I forgot about commit) - -On Linux: - -1. Mount the Windows annex via SMB (mine was read only, but probably won't matter) - -2. git clone the folder (works fine) - -3. git annex get (fails, due to Windows drive letter) - -### What version of git-annex are you using? On what operating system? - -*Windows:* - -git-annex version: 4.20130802-g0a52f02 - -build flags: Pairing Testsuite S3 WebDAV DNS - -*Linux: (Debian wheezy on ARMel)* - -git-annex version: 3.20120629 - -local repository version: 3 - -default repository version: 3 - -supported repository versions: 3 - -upgrade supported from repository versions: 0 1 2 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -#output of git annex get on the Linux side. - -get Purchased/Caravan Palace/Panic/01 Queens.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/02 Maniac.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/03 The Dirty Side of the Street.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/04 12 juin 3049.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/05 Rock It for Me.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/06 Clash.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/07 Newbop.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/08 Glory of Nelly.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/09 Dramophone.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/10 Cotton Heads.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/11 Panic.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/12 Pirates.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/13 Beatophone.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/14 Sydney.mp3 (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music -failed -get Purchased/Caravan Palace/Panic/Thumbs.db (not available) - Try making some of these repositories available: - d6c78593-79d2-455a-8202-7be2133e2d48 -- ICARUS:E:\music - - -And the (broken) symlinks: - -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 01 Queens.mp3 -> .git/annex/objects/5P/vq/SHA256E-s9886015--dfb8f452d47f997a9141de3f152de375fad1d5ccb4a20d5c022064a630eaba88.mp3/SHA256E-s9886015--dfb8f452d47f997a9141de3f152de375fad1d5ccb4a20d5c022064a630eaba88.mp3 -lrwxrwxrwx 1 voltagex voltagex 200 Aug 11 23:05 02 Maniac.mp3 -> .git/annex/objects/J0/WV/SHA256E-s10116938--7ce35f4a54c4f74bd2e3813445cb3a07fae76b2854df06ab00876cd0067f34a5.mp3/SHA256E-s10116938--7ce35f4a54c4f74bd2e3813445cb3a07fae76b2854df06ab00876cd0067f34a5.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 03 The Dirty Side of the Street.mp3 -> .git/annex/objects/xz/4F/SHA256E-s8812949--9e15761ae8c6231d11d1f5a67de8a89142e2e4017b43b8ffac1088fd71842ca7.mp3/SHA256E-s8812949--9e15761ae8c6231d11d1f5a67de8a89142e2e4017b43b8ffac1088fd71842ca7.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 04 12 juin 3049.mp3 -> .git/annex/objects/Kp/k6/SHA256E-s8236133--3a6465bea3272ae7a22b77b67e96a91ae389390cc95642fb1456ce80e3313033.mp3/SHA256E-s8236133--3a6465bea3272ae7a22b77b67e96a91ae389390cc95642fb1456ce80e3313033.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 05 Rock It for Me.mp3 -> .git/annex/objects/Wk/Qv/SHA256E-s7701150--8197e499408e64601157df95927ac6b09bd37834a41eceecc5d12667bd7c66a4.mp3/SHA256E-s7701150--8197e499408e64601157df95927ac6b09bd37834a41eceecc5d12667bd7c66a4.mp3 -lrwxrwxrwx 1 voltagex voltagex 200 Aug 11 23:05 06 Clash.mp3 -> .git/annex/objects/ZQ/P4/SHA256E-s10201572--c2a1a8892fcaaab1ed59ca7f5ab9d45f0c3bb3c6d6450b95228039b9e8d7a0b4.mp3/SHA256E-s10201572--c2a1a8892fcaaab1ed59ca7f5ab9d45f0c3bb3c6d6450b95228039b9e8d7a0b4.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 07 Newbop.mp3 -> .git/annex/objects/Fk/wV/SHA256E-s6850587--b5ba0347f6a09a7ff8bec2dd1fbe8076fdff645d4bc1909ddeadfc035bf19fda.mp3/SHA256E-s6850587--b5ba0347f6a09a7ff8bec2dd1fbe8076fdff645d4bc1909ddeadfc035bf19fda.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 08 Glory of Nelly.mp3 -> .git/annex/objects/Pm/K3/SHA256E-s9002048--18149581cbfc3b4e3e72b784777fe34c53f1580e78e97f66058be0b1eb40e809.mp3/SHA256E-s9002048--18149581cbfc3b4e3e72b784777fe34c53f1580e78e97f66058be0b1eb40e809.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 09 Dramophone.mp3 -> .git/annex/objects/k3/Jf/SHA256E-s8199558--925117d9fc47a65e8e5324f3d0638a3c24bf51fd6c0b5d8ac2f63951c893cc48.mp3/SHA256E-s8199558--925117d9fc47a65e8e5324f3d0638a3c24bf51fd6c0b5d8ac2f63951c893cc48.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 10 Cotton Heads.mp3 -> .git/annex/objects/9f/32/SHA256E-s8801425--c6926238c0b1a3bbea1a5d17841ceac591e53e223e4c4c45a2077cabffc85d81.mp3/SHA256E-s8801425--c6926238c0b1a3bbea1a5d17841ceac591e53e223e4c4c45a2077cabffc85d81.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 11 Panic.mp3 -> .git/annex/objects/XF/WF/SHA256E-s9833770--5e837c7fa3ec096f7c0507efbcf398067029749f8a0fc77a2badf864b9ffbb7c.mp3/SHA256E-s9833770--5e837c7fa3ec096f7c0507efbcf398067029749f8a0fc77a2badf864b9ffbb7c.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 12 Pirates.mp3 -> .git/annex/objects/7Z/jz/SHA256E-s8017742--5fd49b2d89577266d2fb740e7e7def9338475af90c2ca99f9d6d513465b2bfac.mp3/SHA256E-s8017742--5fd49b2d89577266d2fb740e7e7def9338475af90c2ca99f9d6d513465b2bfac.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 13 Beatophone.mp3 -> .git/annex/objects/81/xv/SHA256E-s9339544--a1eb8404ecf0503b9f635378fec4e2c95ec08bb1428c2cd4c0cedf492811577d.mp3/SHA256E-s9339544--a1eb8404ecf0503b9f635378fec4e2c95ec08bb1428c2cd4c0cedf492811577d.mp3 -lrwxrwxrwx 1 voltagex voltagex 198 Aug 11 23:05 14 Sydney.mp3 -> .git/annex/objects/3K/99/SHA256E-s8459731--4ff44b25c912e914c79124ff9074c576c0024152442fc96c9bad65f5a50a40d9.mp3/SHA256E-s8459731--4ff44b25c912e914c79124ff9074c576c0024152442fc96c9bad65f5a50a40d9.mp3 -lrwxrwxrwx 1 voltagex voltagex 192 Aug 11 23:05 Thumbs.db -> .git/annex/objects/28/Zv/SHA256E-s85504--3604669cd3a55234516191eb4f19434829c1634d6dd69a9981185f095d2bbaba.db/SHA256E-s85504--3604669cd3a55234516191eb4f19434829c1634d6dd69a9981185f095d2bbaba.db - -# End of transcript or log. -"""]] - -> Closing since bug submitter did not follow up with requested information. -> [[done]] --[[Joey]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_1_c87bae87b7902db60a3fef41e1fca85d._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_1_c87bae87b7902db60a3fef41e1fca85d._comment deleted file mode 100644 index 0577531b7e..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_1_c87bae87b7902db60a3fef41e1fca85d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlzWwnBfgJrkhPQakBo6DbPXutJIVDHkj0" - nickname="Adam" - subject="comment 1" - date="2013-08-11T14:15:40Z" - content=""" -Confirming the same errors happen with git-annex version: 4.20130802 from sid. - -"""]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment deleted file mode 100644 index d98e7976e3..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.63" - subject="bad bug report title 101" - date="2013-08-24T19:17:29Z" - content=""" -I don't understand why you think the problem has something to do with Windows drive letters. There are no Windows drive letters in the symlinks you show. The only place I see any Windows drive letter is in the descripton of the remote that `git annex get` displays when it fails to get the file. That description is purely informative, it's not a path that git-annex is trying to use. - -I'd suggest that you run `git annex get --debug` to see if it is doing anything obviously wrong. The mostly likely culprit is your SMB setup, which I am not going to be able to replicate. -"""]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_3_3a0787912f4a3a8797b7786f5ce38590._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_3_3a0787912f4a3a8797b7786f5ce38590._comment deleted file mode 100644 index 16f240cf29..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_3_3a0787912f4a3a8797b7786f5ce38590._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlzWwnBfgJrkhPQakBo6DbPXutJIVDHkj0" - nickname="Adam" - subject="comment 3" - date="2013-08-26T06:56:33Z" - content=""" -You're correct. I can see in .git/config that the remote references z:\ which of course will break on the Linux side. Maybe this is a case of the error messages not quite telling me the right thing? -"""]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_4_c4249f32d65594d79ea01145b93ec948._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_4_c4249f32d65594d79ea01145b93ec948._comment deleted file mode 100644 index 31bc7c1a16..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_4_c4249f32d65594d79ea01145b93ec948._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.2.134" - subject="comment 4" - date="2013-09-13T19:29:25Z" - content=""" -I'd suggest that you run git annex get --debug to see if it is doing anything obviously wrong. The mostly likely culprit is your SMB setup, which I am not going to be able to replicate. - -"""]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_5_9308d5ef037afdaf48cc3378cfa10afb._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_5_9308d5ef037afdaf48cc3378cfa10afb._comment deleted file mode 100644 index 2964382d8e..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_5_9308d5ef037afdaf48cc3378cfa10afb._comment +++ /dev/null @@ -1,79 +0,0 @@ -[[!comment format=mdwn - username="https://openid.stackexchange.com/user/8a69a637-97cb-41e6-8f45-00f08ba54d6e" - nickname="Andreas Duering" - avatar="http://cdn.libravatar.org/avatar/915cf485815ded2f7f4b68736994c185ecda8c31dd293acd16f5e21ca7db23e1" - subject="comment 5" - date="2017-08-16T17:16:13Z" - content=""" -I think I have a similar problem - especially with the drive letters. I don't need any SMB shares, though. - -### What steps will reproduce the problem? - -1. git init / git annex init on a ext* drive under Linux -2. git sync it to a FAT32-formatted (USB) drive -3. git annex init on the USB drive -4. add each others as remote -5. git sync each other - works fine -6. Change into a Windows system -7. git annex add some files -8. Change back to a Linux system -9. git annex sync from the annex repository on USB -10. git annex sync from the linux-side - -now, if I do ls -l: - - $ ls -l - lrwxrwxrwx 1 me me 208 Aug 16 18:54 version2.win.txt -> G:/annex2/.git/annex/objects/j1/0J/SHA256E-s846--e46ff540d59e80b419798a53d6d97313a5e04b94f9708168a3d371be1ccd635c.win.txt/SHA256E-s846--e46ff540d59e80b419798a53d6d97313a5e04b94f9708168a3d371be1ccd635c.win.txt - -note the g:\, which was the Windows drive letter. - -git annex get worked fine for me: - - $ git annex get version2.win.txt - get version2.win.txt (from usb...) - version2.win.txt - 846 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1) - (checksum...) ok - (recording state in git...) - -However, the link is still broken (same ls -l output) - - $ stat version2.win.txt - File: 'version2.win.txt' -> 'G:/annex2/.git/annex/objects/j1/0J/SHA256E-s846--e46ff540d59e80b419798a53d6d97313a5e04b94f9708168a3d371be1ccd635c.win.txt/SHA256E-s846--e46ff540d59e80b419798a53d6d97313a5e04b94f9708168a3d371be1ccd635c.win.txt' - Size: 208 Blocks: 8 IO Block: 4096 symbolic link - Device: 81bh/2075d Inode: 1200146 Links: 1 - Access: (0777/lrwxrwxrwx) Uid: ( 1000/ me) Gid: ( 1000/ me) - Access: 2017-08-16 18:54:11.479490622 +0200 - Modify: 2017-08-16 18:54:11.479490622 +0200 - Change: 2017-08-16 18:54:11.479490622 +0200 - Birth: - - - $ cat version2.win.txt - cat: version2.win.txt: No such file or directory - -### What version of git-annex are you using? On what operating system? - -Gentoo: - - git-annex version: 6.20170611-gb493ac8d3 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -Windows 10: - - git-annex version: 6.20170611-gb493ac8 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParser Feeds Quvi - dependency versions: aws-0.14.0 bloomfilter-2.0.1.0 cryptonite-0.7 DAV-1.3.1 feed-0.3.11.1 ghc-7.10.2 http-client-0.4.31.1 persistent-sqlite-2.2 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 2 3 4 5 - operating system: mingw32 i386 -"""]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_6_616aebe7392c9f0e41fb33ed6a490d2a._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_6_616aebe7392c9f0e41fb33ed6a490d2a._comment deleted file mode 100644 index b751921812..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_6_616aebe7392c9f0e41fb33ed6a490d2a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://openid.stackexchange.com/user/8a69a637-97cb-41e6-8f45-00f08ba54d6e" - nickname="Andreas Duering" - avatar="http://cdn.libravatar.org/avatar/915cf485815ded2f7f4b68736994c185ecda8c31dd293acd16f5e21ca7db23e1" - subject="comment 6" - date="2017-08-16T18:18:27Z" - content=""" -Adding to the previous comment - a git annex fsck fixes the link -"""]] diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_7_6cdc019321e75ee269a4884f303d966d._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_7_6cdc019321e75ee269a4884f303d966d._comment deleted file mode 100644 index ec701c2f1b..0000000000 --- a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_7_6cdc019321e75ee269a4884f303d966d._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2017-10-30T17:07:18Z" - content=""" -@Andreas Duering, your problem was indeed a bug in git-annex; -I think it got introduced somewhere around April 2017, and I just fixed it -last week. - -However, it does not seem related to the original bug report from 2013, which, -despite the title, did not seem to have anything to do with drive letters. - -Since this bug report has languished since 2013 without the submitter -providing any information, I suppose I'll close this bug report. -"""]] diff --git a/doc/bugs/__34__Adding_4923_files__34___is_really_slow.mdwn b/doc/bugs/__34__Adding_4923_files__34___is_really_slow.mdwn deleted file mode 100644 index efdf1114b7..0000000000 --- a/doc/bugs/__34__Adding_4923_files__34___is_really_slow.mdwn +++ /dev/null @@ -1,107 +0,0 @@ -Wow, what a great archiving system. Thank you for all your work on git annex! - -### Please describe the problem. - -I was using 'git annex assistant' on a brand-new annex that I created today. I had previously added about 20GB of data and a couple thousand files, mostly MP4 videos and MP3 music. - -I then used regular 'mv' to add a folder containing about 20GB of music. This went well for a while—git annex assistant added two groups of files, containing roughly 700 and 1000 MP3s each. But the third group contained 4,923 files, and it's taking a really long time to import. - -CPU usage is pretty consistently near 100%. According to the log, the files are being processed slowly. - -### What steps will reproduce the problem? - -I don't want to try to reproduce this problem until the MP3s finish being imported. I can try again later with thousands of digital photos if that would help. - -### What version of git-annex are you using? On what operating system? - -Version: 4.20130709.1 -Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP - -Ubuntu 12.04.2 LTS - -### Please provide any additional information below. - -Here's the 'top' output and a snippet of the log. Let me know if you need anything else. - -[[!format sh """ -# CPU usage - - PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND - 584 ...me... 20 0 776m 147m 16m S 100 0.9 181:16.87 git-annex - - -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -[201ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._3-06 Words.mp3 3-0(checksum...) 7-22 14:52:14 EDT] TransferScanner: queued Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-08 Walk This Way.mp3 Nothing : expensive scan found missing object -[2013-07-22 14:52:34 EDT] Transferrer: Transferring: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-08 Walk This Way.mp3 Nothing -[2013-07-22 14:52:34 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._4-05 Our House.mp3 2013-0(checksum...) 7-22 14:52:34 EDT] TransferWatcher: transfer starting: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-08 Walk This Way.mp3 Nothing -[2013-07-22 14:52:54 EDT] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06", transferKey = Key {keyName = "a8ddf79be61cf4a5ab3c7c8e95d8c259ceb102410dff50eb1260e7d818f8c5a8.mp3", keyBackendName = "SHA256E", keySize = Just 70, keyMtime = Nothing}} -[2013-07-22 14:52:54 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/7-15 Never Gonna Give You Up.mp3 (checksum...) [2013-07-22 14:52:54 EDT] read: sha256sum ["/mnt/storage/private/annex/.git/annex/tmp/7-15 Never Gonna Give You Up584.mp3"] -[2013-07-22 14:52:55 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/3-09 Down Under.mp3 2013-07-(checksum...) 22 14:52:55 EDT] TransferScanner: queued Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-09 Dude (Looks Like A Lady).mp3 Nothing : expensive scan found missing object -[2013-07-22 14:52:55 EDT] read: sha256sum ["/mnt/storage/private/annex/.git/annex/tmp/3-09 Down Under584.mp3"] -[2013-07-22 14:52:55 EDT] Transferrer: Transferring: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-09 Dude (Looks Like A Lady).mp3 Nothing -[2013-07-22 14:52:55 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/7-19 Right Here Waiting.mp3 2013(checksum...) -07-22 14:52:55 EDT] TransferWatcher: transfer starting: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-09 Dude (Looks Like A Lady).mp3 Nothing -[2013-07-22 14:52:55 EDT] read: sha256sum ["/mnt/storage/private/annex/.git/annex/tmp/7-19 Right Here Waiting584.mp3"] -[2013-07-22 14:52:55 EDT] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06", transferKey = Key {keyName = "a8ddf79be61cf4a5ab3c7c8e95d8c259ceb102410dff50eb1260e7d818f8c5a8.mp3", keyBackendName = "SHA256E", keySize = Just 70, keyMtime = Nothing}} -[2013-07-22 14:52:55 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._1-04 Another One Bites The Dust.mp3 (checksum...) [2013-07-22 14:53:15 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[2013ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/2-08 Hold On Loosely.mp3 -07(checksum...) -22 14:53:15 EDT] TransferScanner: queued Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-10 What It Takes.mp3 Nothing : expensive scan found missing object -[2013-07-22 14:53:15 EDT] read: sha256sum ["/mnt/storage/private/annex/.git/annex/tmp/2-08 Hold On Loosely584.mp3"] -[2013-07-22 14:53:15 EDT] Transferrer: Transferring: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-10 What It Takes.mp3 Nothing -[2013-07-22 14:53:15 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._6-11 Kyrie.mp3 201(checksum...) 3-07-22 14:53:15 EDT] TransferWatcher: transfer starting: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-10 What It Takes.mp3 Nothing -[2013-07-22 14:53:36 EDT] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06", transferKey = Key {keyName = "a8ddf79be61cf4a5ab3c7c8e95d8c259ceb102410dff50eb1260e7d818f8c5a8.mp3", keyBackendName = "SHA256E", keySize = Just 70, keyMtime = Nothing}} -[2013-07-22 14:53:36 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._5-03 I'm So Excited.mp3 (checksum...) [2013-07-22 14:53:56 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[2013ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/7-20 Roam.mp3 -07-(checksum...) 22 14:53:56 EDT] TransferScanner: queued Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-11 Sweet Emotion.mp3 Nothing : expensive scan found missing object -[2013-07-22 14:53:56 EDT] read: sha256sum ["/mnt/storage/private/annex/.git/annex/tmp/7-20 Roam584.mp3"] -[2013-07-22 14:53:57 EDT] Transferrer: Transferring: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/._2-11 Sweet Emotion.mp3 Nothing -[2013-07-22 14:53:57 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[2ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._3-20 Goodbye To You.mp3 013-07(checksum...) -22 14:53:57 EDT] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06", transferKey = Key {keyName = "a8ddf79be61cf4a5ab3c7c8e95d8c259ceb102410dff50eb1260e7d818f8c5a8.mp3", keyBackendName = "SHA256E", keySize = Just 70, keyMtime = Nothing}} -[2013-07-22 14:54:17 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._7-18 Don't Worry Be Happy.mp3 (checksum...) [2013-07-22 14:54:37 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._3-04 Rock This Town.mp3 2013-(checksum...) 07-22 14:54:37 EDT] TransferScanner: queued Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/1-01 Eat The Rich.mp3 Nothing : expensive scan found missing object -[2013-07-22 14:54:57 EDT] Transferrer: Transferring: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/1-01 Eat The Rich.mp3 Nothing -[2013-07-22 14:54:57 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._7-13 Since You've Been Gone.mp3 [2013-(checksum...) 07-22 14:54:57 EDT] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06", transferKey = Key {keyName = "2cb6e7b6ee77f9f98e01e942185265dfe18868503e93d78201485672e6939ab7.mp3", keyBackendName = "SHA256E", keySize = Just 6354105, keyMtime = Nothing}} -[2013-07-22 14:55:18 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._2-09 Believe It Or Not (Theme From _Greatest American Hero_).mp3 (checksum...) [2013-07-22 14:55:38 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/7-14 Only In My Dreams.mp3 2013(checksum...) -07-22 14:55:38 EDT] TransferScanner: queued Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/1-02 Love In An Elevator.mp3 Nothing : expensive scan found missing object -[2013-07-22 14:55:38 EDT] read: sha256sum ["/mnt/storage/private/annex/.git/annex/tmp/7-14 Only In My Dreams584.mp3"] -[2013-07-22 14:55:38 EDT] Transferrer: Transferring: Upload UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06" music/Rock/Aerosmith/A Little South of Sanity/1-02 Love In An Elevator.mp3 Nothing -[2013-07-22 14:55:38 EDT] chat: git ["--git-dir=/mnt/storage/private/annex/.git","--work-tree=/mnt/storage/private/annex","hash-object","-t","blob","-w","--stdin","--no-filters"] -[2013-ok -add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._4-08 Talking In Your Sleep.mp3 07-2(checksum...) 2 14:55:38 EDT] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "8dbe75a4-b065-46fd-99f7-22599b2eaf06", transferKey = Key {keyName = "7cd4b9aefb99f044c5f3b24e9890f45673a63ada3b71e7399e17eb1d710ea0f6.mp3", keyBackendName = "SHA256E", keySize = Just 7181660, keyMtime = Nothing}} - -# End of transcript or log. -"""]] - -[[!meta title="direct mode mappings scale badly with thousands of identical files"]] - -[[!tag confirmed]] -[[!meta tag=deprecateddirectmode]] - -> direct mode has been removed from git-annex, and its replacement, v7 -> unlocked files, uses sqlite and should not suffer from a slowdown when -> many work tree files have the same content. So [[done]] --[[Joey]] diff --git a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_2_5f3b9f00bc31ce71d695c008971ed7fd._comment b/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_2_5f3b9f00bc31ce71d695c008971ed7fd._comment deleted file mode 100644 index 9030d73f7b..0000000000 --- a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_2_5f3b9f00bc31ce71d695c008971ed7fd._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://emk.myopenid.com/" - ip="24.2.150.84" - subject="Interesting speedup" - date="2013-07-22T19:45:58Z" - content=""" -I noticed that there were a lot of junk files with names of the form \"._*\" in the \"music\" directory I had added. These are created by older MacOS X systems storing Mac-related files on Unix file systems. (I think they're supposed to contain the old resource fork or something weird like that.) - -So while the endless import was running, I decided to live dangerous and delete the offending files: - - find music/ -name ._\* -print0 | xargs -0 rm - -A few seconds later, the 4,923 file import finished. - -If I discover anything else interesting, I'll mention it. Once again, many thanks! -"""]] diff --git a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_2_708b02dd06a1eed6b5ded9eb7aa9e7a8._comment b/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_2_708b02dd06a1eed6b5ded9eb7aa9e7a8._comment deleted file mode 100644 index 8ad833ca9a..0000000000 --- a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_2_708b02dd06a1eed6b5ded9eb7aa9e7a8._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.1.10" - subject="comment 2" - date="2013-07-22T20:15:03Z" - content=""" -I doubt that removing the junk files did anything, unless perhaps it deleted all the files that it had not yet gotten around to adding, and so short-circuited the slow part of the process. - -Adding a lot of files in a repository in direct mode can be slowed down some because it has to run `git hash-object` once per file to stage the symlink. It may be possible to speed this up by changing the code to write the symlink to disk in a temporary location, which would then allow it to use the single `git hash-object --batch` it keeps running, and just tell it to hash that file. - -It seems likely to me though that the sha256sum it has to run on every file before adding it is responsible for more of the slowdown. After all, that has to read every file from disk (here apparently from `/mnt` which, if it's a USB device etc could be pretty slow.) You can benchmark this at home: First look at the debug log to find the start and finish times of it adding all those files. Then clear all disk caches. Then run sha256sum on every file and time that. Compare & post here. ;) - -Adding to the overhead, the assistant is uploading every file it adds to the remote with uuid 8dbe75a4-b065-46fd-99f7-22599b2eaf06. Which means yet another read of the file, and more work depending on what kind of remote that is and how expensive it is to transfer to it. - -So, in summary, hashing, recording in git, and backing up a lot of files is really slow. It would be good to work out which parts are the slow parts, so we can think about whether that speed is acceptable for that part. -"""]] diff --git a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_3_6a735b7875d2a0c92df6786dd649985d._comment b/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_3_6a735b7875d2a0c92df6786dd649985d._comment deleted file mode 100644 index f95c368d63..0000000000 --- a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_3_6a735b7875d2a0c92df6786dd649985d._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="http://emk.myopenid.com/" - ip="24.2.150.84" - subject="That particular "Adding 4923 files" was unusually slow" - date="2013-07-23T11:46:03Z" - content=""" -That particular add took most of an afternoon, and didn't complete until I deleted all the junk files. - -I later did \"adding ~10,000 files\" and \"adding ~15,000 files\", all of which ran in an hour or so at most, even though I had added a second remote. So this isn't solely a disk I/O bottleneck. - -One peculiar thing about the garbage files: There were 1,626 of them, and they were all tiny: - -``` -00000000 00 05 16 07 00 02 00 00 00 00 00 00 00 00 00 00 |................| -00000010 00 00 00 00 00 00 00 00 00 01 00 00 00 09 00 00 |................| -00000020 00 26 00 00 00 20 4d 50 47 33 68 6f 6f 6b 00 00 |.&... MPG3hook..| -00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| -* -00000046 -``` - -1,581 of these files had the SHA1 hash code 5460c190ef495baf43e2cd001687be272cd6a9d2, and all but one of the rest had the hash code d4b1d36c67149c981ea4b3d8392050188673817c. So if there's anything weird about this repository, it was thousands of tiny identical files in the same 'git annex assistant' adding pass. Once I scrubbed those files on later imports, things were considerably faster even when the file count increased dramatically. - -You can go ahead and close this bug report if that seems reasonable—I just thought the weird behavior was worth reporting, in case somebody else runs it into again. - -And thank you for an awesome program! - -"""]] diff --git a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_4_7e768908ba6983ea13af27635c4a947f._comment b/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_4_7e768908ba6983ea13af27635c4a947f._comment deleted file mode 100644 index 0971f1c342..0000000000 --- a/doc/bugs/__34__Adding_4923_files__34___is_really_slow/comment_4_7e768908ba6983ea13af27635c4a947f._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.246.110" - subject="comment 4" - date="2013-07-26T22:28:37Z" - content=""" -Did some playing around, and I am seeing a progressive slowdown when adding lots of identical files in direct mode. -This does not happen when the files have different content, and thinking about it, it's pretty clear what's going on: - -When there are a ton of files with the same content, the map file that has to list all the files using this content -get larger and larger. Each file added has to read and re-write the map file, which is obviously not going to scale well to thousands of duplicate files. -"""]] diff --git a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48.mdwn b/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48.mdwn deleted file mode 100644 index 3381f7d684..0000000000 --- a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48.mdwn +++ /dev/null @@ -1,43 +0,0 @@ -### Please describe the problem. - -Tried to drop files that exist on s3: - git annex drop -J36 --in=ilya-s3 - -A few get dropped, and then it errors out with -git-annex: content is locked - -(Apart from the issue here, maybe add an option to keep working in case of error with one file?) - -### What version of git-annex are you using? On what operating system? -git-annex version: 6.20180926-gc906aaf -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feed\ -s Testsuite -dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-s\ -qlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\ -24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\ -2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256\ - BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -local repository version: 5 - - -(master_env_py27_v28) [01:05 PM /data/ilya-work]$ uname -a -Linux ip-172-31-87-156 4.14.72-68.55.amzn1.x86_64 #1 SMP Fri Sep 28 21:14:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux - -### Please provide any additional information below. - -> Made drop not operate on the same key multiple times concurrently. -> -> Also yeah, that kind of exception should not interrupt processing other -> files; the distinction git-annex has drawn between IO errors and other -> exceptions is not super useful unless a command for some reason wants to -> completely stop everything for some reason. I can't think of any cases -> where a command would want to do that; if it does turn out to be needed, -> a special type of exception could be thrown to force termination. -> So I changed it to catch all (non-async) errors. -> -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_1_48cef34f35af6f0150f216465f20ef5b._comment b/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_1_48cef34f35af6f0150f216465f20ef5b._comment deleted file mode 100644 index 4748d3386a..0000000000 --- a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_1_48cef34f35af6f0150f216465f20ef5b._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-10-29T19:12:30Z" - content=""" -Is annex.pidlock set? - -Do you have multiple files in the repository that point to the same key? -"""]] diff --git a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_2_b0ab844bd2714ae19d8cb45550e50249._comment b/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_2_b0ab844bd2714ae19d8cb45550e50249._comment deleted file mode 100644 index 0b711395e8..0000000000 --- a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_2_b0ab844bd2714ae19d8cb45550e50249._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="Ilya_Shlyakhter" - avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" - subject="comment 2" - date="2018-10-29T19:48:36Z" - content=""" -annex.pidlock is not set in the config file. \"Do you see git-annex displaying multiple concurrent actions at the same time?\" -- displaying where? I was just looking at 'top'. -There are some keys to which multiple git-annex symlink point. -"""]] diff --git a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_3_52c701312e6096f9d2ee057974a5d0f2._comment b/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_3_52c701312e6096f9d2ee057974a5d0f2._comment deleted file mode 100644 index 017a8eb787..0000000000 --- a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_3_52c701312e6096f9d2ee057974a5d0f2._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-10-29T20:37:12Z" - content=""" -I did not ask "Do you see git-annex displaying -multiple concurrent actions at the same time" in this bug report. I asked -it in an apparently unrelated bug report, - -Please follow up on that question where I asked it, not here. - -And you didn't answer the other question that I did ask in this bug report: -Do you have multiple files in the repository that point to the same key? -"""]] diff --git a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_4_d52bec110fa2508fb0439bdbe44d9ada._comment b/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_4_d52bec110fa2508fb0439bdbe44d9ada._comment deleted file mode 100644 index 2c48c14138..0000000000 --- a/doc/bugs/__34__content_is_locked__34___with_git-annex-drop_-J48/comment_4_d52bec110fa2508fb0439bdbe44d9ada._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Ilya_Shlyakhter" - avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" - subject="comment 4" - date="2018-10-29T21:08:55Z" - content=""" -\"Do you have multiple files in the repository that point to the same key?\" -- I wrote \"There are some keys to which multiple git-annex symlinks point.\" Does this not answer your question? -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows.mdwn b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows.mdwn deleted file mode 100644 index 4c740c5ed9..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows.mdwn +++ /dev/null @@ -1,111 +0,0 @@ -### Please describe the problem. - -When attempting to clone and use a git repository in a subdirectory several levels deep on Windows, I observe symptoms very similar to those described at http://git-annex.branchable.com/direct_mode/#comment-8feee726df4e287dd3751bc77fd1441f. By contrast, when I attempt the same operation in a subdirectory higher up, the operation is successful. Logs of both sessions are given below. - -My suspicion is that this has to do with exceeding the maximum path length limitation (MAX_PATH) of 260 characters on Windows, as described here: http://msdn.microsoft.com/en-us/library/aa365247.aspx. - - -### What steps will reproduce the problem? - -See above. - - -### What version of git-annex are you using? On what operating system? - ->git annex version -git-annex version: 5.20140517-gee56d21 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 2 3 4 - ->git version -git version 1.9.0.msysgit.0 - -Operating system: Windows 7 Professional (64-bit), Service Pack 1 - - -### Please provide any additional information below. - - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -C:\Users\areeves\Documents\Work\MyDirectoryHere\git>git clone ssh://areeves@myserver:/home/work/git/sbv -Cloning into 'sbv'... -remote: Counting objects: 65, done. -remote: Compressing objects: 100% (57/57), done. -remote: Total 65 (delta 26), reused 0 (delta 0) -Receiving objects: 100% (65/65), 9.25 KiB | 0 bytes/s, done. -Resolving deltas: 100% (26/26), done. -Checking connectivity... done. - - -C:\Users\areeves\Documents\Work\MyDirectoryHere\git>cd sbv -C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv>git annex get - - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. -git-annex: C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv\.git\annex\objects\3de\5f4\SHA256-s765223180--c9e2eebd915b4ade9429b00a7a893df928389b3fb4ab759ea9f00b0e05e18de6\: openTempFile: does not exist (No such file or directory) - - -C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv>git annex direct -commit -On branch master -Your branch is up-to-date with 'origin/master'. - -nothing to commit, working directory clean -ok - -git-annex: C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv\.git\annex\objects\3de\5f4\SHA256-s765223180--c9e2eebd915b4ade9429b00a7a893df928389b3fb4ab759ea9f00b0e05e18de6\: openTempFile: does not exist (No such file or directory) -failed -git-annex: direct: 1 failed - - -C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv>cd c:\temp -c:\temp>git clone ssh://areeves@myserver:/home/work/git/sbv -Cloning into 'sbv'... -remote: Counting objects: 65, done. -remote: Compressing objects: 100% (57/57), done. -remote: Total 65 (delta 26), reused 0 (delta 0) -Receiving objects: 100% (65/65), 9.25 KiB | 0 bytes/s, done. -Resolving deltas: 100% (26/26), done. -Checking connectivity... done. - -c:\temp>cd sbv -c:\temp\sbv>git annex direct - - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. -(Recording state in git...) - - -c:\temp\sbv>git annex get -get BigBinaryFile_Data_Package_2012-03-31.tar.bz2.gpg (merging origin/git-annex into git-annex...) -(Recording state in git...) -sent 30 bytes received 765316741 bytes 11011752.10 bytes/sec -total size is 765223180 speedup is 1.00 -ok -(Recording state in git...) - - -c:\temp\sbv> - -# End of transcript or log. -"""]] - -[[!meta title="window's tiny mind is confused by some long paths used by git-annex"]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_10_5638e0090598425d67c073b2f04e56d5._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_10_5638e0090598425d67c073b2f04e56d5._comment deleted file mode 100644 index f9b689974e..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_10_5638e0090598425d67c073b2f04e56d5._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="davclark" - avatar="http://cdn.libravatar.org/avatar/375c43ce3d79c0955a645e522cdab7af" - subject="Still getting this error" - date="2018-02-02T16:45:50Z" - content=""" -I enabled long filename support (running Windows 10 1709 build 16299.192), did a reboot and I'm still getting this error: - - git-annex: ..\..\.git\annex\objects\ada\ebe\SHA256E-s418503869--4ea1d3209d3199fed9b0e75e97cf299f59f37de2f204da2c3192ce04f69677ae.csv\SHA256E-s418503869--4ea1d3209d3199fed9b0e75e97cf299f59f37de2f204da2c3192ce04f69677ae.csv.cache: openFile: does not exist (No such file or directory) - failed - git-annex: add: 1 failed - -That filename is only 216 characters too... is there any way to diagnose *why* the file creation failed? -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_11_0740e1605708ef29d49d4c853c4e6e8a._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_11_0740e1605708ef29d49d4c853c4e6e8a._comment deleted file mode 100644 index ce76ad73d1..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_11_0740e1605708ef29d49d4c853c4e6e8a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 11""" - date="2019-09-18T17:23:46Z" - content=""" -This should be fixed since git-annex 7.20190730. The ghc compiler started -using more modern windows features for filenames, which avoid the length -limits. -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_1_ce2355485f2610b6a7a79914dcd365be._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_1_ce2355485f2610b6a7a79914dcd365be._comment deleted file mode 100644 index 127d0603f9..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_1_ce2355485f2610b6a7a79914dcd365be._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="edward" - subject="another example" - date="2014-12-06T21:01:03Z" - content=""" -I'm having the same problem: - -> git-annex: c:\Users\TV\annex\.git\annex\objects\566\a33\URL--quvi&chttps&c%%www.youtube.com%watch,63v,61XS-kKX9wQk0,38index,615,38list,61PLQ-uHSnFig5NCQkhJfkn8ogXFwzrP4SIf\: openTempFile: does not exist (No such file or directory) -> failed -> git-annex: init: 1 failed - -In my case the filename is slightly shorter, 154 characters, for Aaron the offending filename was 162 characters. - -I think the full filename that git annex is trying to write is 270 characters: - -> c:\Users\TV\annex\.git\annex\objects\566\a33\URL--quvi&chttps&c%%www.youtube.com%watch,63v,61XS-kKX9wQk0,38index,615,38list,61PLQ-uHSnFig5NCQkhJfkn8ogXFwzrP4SIf/URL--quvi&chttps&c%%www.youtube.com%watch,63v,61XS-kKX9wQk0,38index,615,38list,61PLQ-uHSnFig5NCQkhJfkn8ogXFwzrP4SIf -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment deleted file mode 100644 index 558a1ce23a..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - subject="comment 2" - date="2015-01-06T19:18:26Z" - content=""" -On Linux and OSX, there is a maximum filename size, typically 255 bytes. git-annex always ensures that keys it generates are a maximum of 255 bytes long, no matter the platform. But, in dir/subdir/file, each of the 3 segments of the path is allowed to be that long. The limit on the total path size on Linux is a more reasonable 4096 bytes; OSX has only 1024 bytes. - -I don't know what to do about Windows having such an absurdly small `MAX_PATH` compared to more modern systems. - -The length of just a SHA512 checksum is 128 bytes; that means SHA512 backend cannot be used on windows, at all, since the paths git-annex generates will be at least twice that long, and will easily overflow `PATH_MAX`. I've confirmed this; just adding a file with --backend=SHA512 fails with a \"No such file or directory\" error when it tries to use the path. - -A SHA256 is a more manageable 64 bytes long. So a typical path to such an object will end with eg \".git\annex\objects\566\a33\SHA256E--d728a4c4727febe1c28509482ae1b7b2215798218e544eed7cb7b4dc988f838b\SHA256E--d728a4c4727febe1c28509482ae1b7b2215798218e544eed7cb7b4dc988f838b\" -- 174 bytes long (or a bit longer when there are also extension and size in the key) and leaving only 86 bytes or so for `c:\path\to\repo`. - -Perhaps git-annex should reduce its maximum key size from 255 to 64 bytes, the same as SHA256. Then url keys would work on Windows, except for in deep paths, where git-annex cannot work at all. This would be an easy change. - -git-annex could also avoid using absolute paths, which it currently uses extensively for simplicity (and possiibly robustness against renames of repositories and changes of working directory?), and use relative paths instead. This would probably solve the two examples given in the bug report, and it would make git-annex work better when in a deep path in Windows. It would not make SHA512 work though; with keys that long, the relative path is still too long. (And, it's still possible to get a relative path that has so many '../../' and subdirectories etc that it overflows `PATH_MAX`. It would probably take a really crazy repository directory structure though.) - -The MSDN article has one very interesting bit: - -> The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the \"\\?\\" prefix. For example, \"\\?\D:\very long path\". - -(It seems that, when using that prefix, `/` is not converted to `\` .. I think git-annex is quite good about getting the slashes the right way round these days.) - -So it might be possible for git-annex to use that prefix and avoid this issue entirely. Haskell's FilePath library does understand that prefix (treats it as part of the drive). Since git-annex always uses the path to the top of the Repo when constructing the problematic FilePaths, I might be able to just change the Repo constructor to add that prefix, and everything follow from that. I tried doing that, unfortunately this makes *git* fail, with \"fatal: relative path syntax cannot be used outside working tree\" when operating on such a repo. Cause git doesn't understand that prefix. -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_3_1d23e9760782a8d6d2ea2dd5a4c6253a._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_3_1d23e9760782a8d6d2ea2dd5a4c6253a._comment deleted file mode 100644 index 153c48db23..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_3_1d23e9760782a8d6d2ea2dd5a4c6253a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - subject="comment 3" - date="2015-01-06T20:51:20Z" - content=""" -I've started a `relativepaths` branch that uses all relative paths to the git repo. After working on it for several hours, there are still 16 test suite failures (update: 10) (update: 1). The potential for uncaught breakage is much higher than I am happy with. (Amoung other problems, git-annex does call setCurrentDirectory in several places, and this utterly breaks the relative paths). - -Using that branch on windows, I am still unable to add files with --backend=SHA512; even relative paths don't make it short enough for such keys. -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_4_108f3e4449fc9591bcdeb490b486357f._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_4_108f3e4449fc9591bcdeb490b486357f._comment deleted file mode 100644 index 3aa56f0048..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_4_108f3e4449fc9591bcdeb490b486357f._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - subject="comment 4" - date="2015-01-06T21:59:15Z" - content=""" -Even with relative paths, Edward's example would use a path of 253 characters, and so a slightly longer url would still break it, even with relative paths. - -So, I think reducing url key length needs to be done anyway, and I've done that. Which hardly closes this bug. -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_5_a1c8ac1d7884d676f05db588b2894603._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_5_a1c8ac1d7884d676f05db588b2894603._comment deleted file mode 100644 index 54c29af3b5..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_5_a1c8ac1d7884d676f05db588b2894603._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - subject="comment 5" - date="2015-01-07T02:35:46Z" - content=""" -I've beat on the relativepaths branch some more and am probably as confident about it as I'm going to get. Will have to merge it and see what else it breaks. - -Also, I've documented that SHA512 and other large hashes are not recommended if one wants to interop with Windows. - -None of which completely fixes this bug, but short of teaching git about the magic filename prefix to make windows not be so broken, I don't see anything more I can do. -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_6_739b4fd2156de7570ec71417f41eb188._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_6_739b4fd2156de7570ec71417f41eb188._comment deleted file mode 100644 index b20fe2ab98..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_6_739b4fd2156de7570ec71417f41eb188._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=sh - username="https://www.google.com/accounts/o8/id?id=AItOawkDqgw0JLrxLH3GIpg36Mp79F_1pxZxWxU" - nickname="Benjamin" - subject="comment 6" - date="2015-02-04T14:56:36Z" - content=""" -Hi, - -I experienced the same problem. In my case the path to the local clone is \"C:\Users\user\Documents\dev\testplay\studyforrest\". Trying to get a file within that repo (\"c:\Users\user\Documents\dev\testplay\studyforrest\stimulus\task001\annotations>git annex get german_audio_description.csv\") results in \"couldn't find path\". -More precise git annex says: \"git-annex: MoveFileEx \"..\\..\\..\\.git\\annex\\tmp\\SHA256E-s49358--49140697bfd54e0d384b30efb7256c246b99f8c2cd63a48d54078e7d03e26286.csv\" \"..\\..\\..\\.git\\annex\\objects\\885\\a97\\SHA256E-s49358-- -49140697bfd54e0d384b30efb7256c246b99f8c2cd63a48d54078e7d03e26286.csv\\SHA256E-s49358--49140697bfd54e0d384b30efb7256c246b99f8c2cd63a48d54078e7d03e26286.csv\": does not exist (Das System kann den angegeb -enen Pfad nicht finden.) -failed -git-annex: get: 1 failed\" - - -Cloning to c:\studyforrest works. - -Now, I wonder why, since none of the mentioned paths exceeds the limit of 260. But as git annex mentioned it seems to use that relative path \"..\\..\\..\\.git\\annex\ [...]\". May be it internally composes it to something like -\"c:\Users\user\Documents\dev\testplay\studyforrest\stimulus\task001\annotations\..\\..\\..\\.git\\annex\ [...]\" where the part \"stimulus\task001\annotations\..\..\..\\" is actually not needed to adress the desired file. So, if that is the case may be you could give some more room by eliminating this? - - -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_7_c561d2eb75a2579db620bf7877c98502._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_7_c561d2eb75a2579db620bf7877c98502._comment deleted file mode 100644 index 6243b9129b..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_7_c561d2eb75a2579db620bf7877c98502._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="comment 7" - date="2015-02-04T15:53:48Z" - content=""" -It seems that is where where having no read-only key/ directory would also be of help to shorten filename paths. (as discussed in https://github.com/datalad/datalad/issues/32) -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_8_169423dd4f3292e503b285f088f6701f._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_8_169423dd4f3292e503b285f088f6701f._comment deleted file mode 100644 index c88e3b1b5f..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_8_169423dd4f3292e503b285f088f6701f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkDqgw0JLrxLH3GIpg36Mp79F_1pxZxWxU" - nickname="Benjamin" - subject="comment 8" - date="2015-02-05T13:05:31Z" - content=""" -Despite all things, that may or may not be possible to do to shorten the path lengths used by git-annex, it would be very helpful to properly detect that this problem is occuring and give a reasonable error message. Since windows' \"couldn't find path\"-message doesn't tell you what's going on. -"""]] diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_9_c85eff61e8f48f4d58e0e9a11e72e20d._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_9_c85eff61e8f48f4d58e0e9a11e72e20d._comment deleted file mode 100644 index 38657121c4..0000000000 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_9_c85eff61e8f48f4d58e0e9a11e72e20d._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 9""" - date="2017-06-06T19:52:31Z" - content=""" -Workaround: Enable long paths in the windows registry. See - - -It would be good to make git-annex enable that automatically, perhaps by -using the manifest file that is described on that page. I don't know -how to make windows use such a manifest file. It seems to have to be -embedded into the exe file. GHC has a open ticket to get it to do that: - -"""]] diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn deleted file mode 100644 index ed7d5c06a2..0000000000 --- a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn +++ /dev/null @@ -1,68 +0,0 @@ -### Please describe the problem. - -`git update-index --refresh bigfile` fails with `fatal: Out of memory, realloc failed` - -### What steps will reproduce the problem? - -Have sizeOf bigfile > sizeOf memory? - - -### What version of git-annex are you using? On what operating system? - -git-annex version: 7.20181205 -Debian sid - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$ GIT_TRACE=1 git update-index --refresh SERIES/bigfile.avi -19:08:14.507885 git.c:418 trace: built-in: git update-index --refresh 'SERIES/bigfile.avi' -19:08:14.536105 run-command.c:643 trace: run_command: 'git-annex smudge --clean '\''CLIPS/otherfile.txt'\''' -19:08:14.560898 git.c:418 trace: built-in: git config --null --list -19:08:14.568523 git.c:418 trace: built-in: git cat-file --batch -19:08:14.575319 git.c:418 trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)' -19:08:14.585333 git.c:418 trace: built-in: git check-attr -z --stdin annex.backend annex.numcopies annex.largefiles -- -19:08:14.588845 git.c:418 trace: built-in: git version -SERIES/bigfile.avi: needs update -fatal: Out of memory, realloc failed - -$ GIT_TRACE=1 strace git update-index --refresh SERIES/bigfile.avi -lstat("SERIES", {st_mode=S_IFDIR|0755, st_size=754, ...}) = 0 -lstat("SERIES/bigfile.avi", {st_mode=S_IFREG|0644, st_size=7130113113, ...}) = 0 -write(1, "SERIES/bigfile.avi"..., 105SERIES/bigfile.avi: needs update -) = 105 -lstat("SERIES/bigfile.avi", {st_mode=S_IFREG|0644, st_size=7130113113, ...}) = 0 -openat(AT_FDCWD, "SERIES/bigfile.avi", O_RDONLY) = 4 -openat(AT_FDCWD, "SERIES/.gitattributes", O_RDONLY) = -1 ENOENT (No such file or directory) -mmap(NULL, 7130113113, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f338b031000 -pipe([5, 6]) = 0 -fcntl(6, F_GETFD) = 0 -fcntl(6, F_SETFD, FD_CLOEXEC) = 0 -clone(child_stack=0x7f35477fdfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f35477fe9d0, tls=0x7f35477fe700, child_tidptr=0x7f35477fe9d0) = 7442 -mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) -brk(0x556c98800000) = 0x556aef81c000 -mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) -mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) -mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) -mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) -brk(0x556c98800000) = 0x556aef81c000 -mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) -write(2, "fatal: Out of memory, realloc fa"..., 37fatal: Out of memory, realloc failed -) = 37 -getpid() = 7130 -close(3) = 0 -unlink("/mnt/video/video/.git/index.lock") = 0 -exit_group(128) = ? -+++ exited with 128 +++ - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Sure, I love it :) - -> This bug was fixed in git 2.23. [[done]] --[[Joey]] diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_990498b543812acb1adf206d8d7d24eb._comment b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_990498b543812acb1adf206d8d7d24eb._comment deleted file mode 100644 index 423d85a0f3..0000000000 --- a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_990498b543812acb1adf206d8d7d24eb._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-12-11T20:40:36Z" - content=""" -It's strange that git runs the clean filter on CLIPS/otherfile.txt and not -on the file it was asked to. But that is probably a red herring. Git gets -past that extraneouss file and on to bigfile.avi before it crashes. - -The strace has a clone() and doesn't follow what happens in the child -process. I'm not clear what that child process is doing, although it seems -to involve the bigfile.avi that git is trying to mmap all into memory. -It would be good to strace -f and check what gets exec()ed. -"""]] diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_2_13bd85f768c192afe2d7d5339a5250ac._comment b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_2_13bd85f768c192afe2d7d5339a5250ac._comment deleted file mode 100644 index 428a16d688..0000000000 --- a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_2_13bd85f768c192afe2d7d5339a5250ac._comment +++ /dev/null @@ -1,83 +0,0 @@ -[[!comment format=mdwn - username="gueux" - avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34" - subject="comment 2" - date="2018-12-11T21:23:38Z" - content=""" -[[!format sh \"\"\" -$ GIT_TRACE=1 strace -ff -e execve git update-index --refresh SERIES/bigfile.avi -execve(\"/usr/bin/git\", [\"git\", \"update-index\", \"--refresh\", \"SERIES/bigfile.avi\"...], 0x7ffea5449570 /* 131 vars */) = 0 -22:19:30.019621 git.c:418 trace: built-in: git update-index --refresh 'SERIES/bigfile.avi' -strace: Process 21256 attached -strace: Process 21258 attached -strace: Process 21260 attached -strace: Process 21252 attached -strace: Process 21253 attached -strace: Process 21255 attached -strace: Process 21257 attached -strace: Process 21254 attached -strace: Process 21259 attached -[pid 21255] +++ exited with 0 +++ -[pid 21256] +++ exited with 0 +++ -[pid 21259] +++ exited with 0 +++ -[pid 21260] +++ exited with 0 +++ -[pid 21254] +++ exited with 0 +++ -[pid 21257] +++ exited with 0 +++ -[pid 21252] +++ exited with 0 +++ -[pid 21253] +++ exited with 0 +++ -[pid 21258] +++ exited with 0 +++ -strace: Process 21279 attached -22:19:32.576855 run-command.c:643 trace: run_command: 'git-annex smudge --clean '\''CLIPS/otherfile.txt'\''' -strace: Process 21280 attached -[pid 21280] execve(\"/bin/sh\", [\"/bin/sh\", \"-c\", \"git-annex smudge --clean 'CLIPS/\"..., \"git-annex smudge --clean 'CLIPS/\"...], 0x7f47b4001f90 /* 133 vars */) = 0 -strace: Process 21281 attached -[pid 21281] execve(\"/usr/bin/git-annex\", [\"git-annex\", \"smudge\", \"--clean\", \"CLIPS/otherfile.txt\"...], 0x5557f2cfdef8 /* 133 vars */) = 0 -strace: Process 21282 attached -strace: Process 21283 attached -strace: Process 21284 attached -strace: Process 21285 attached -[pid 21285] execve(\"/usr/lib/git-core/git\", [\"git\", \"config\", \"--null\", \"--list\"], 0x7ffc19e1be20 /* 133 vars */) = 0 -strace: Process 21286 attached -22:19:32.761868 git.c:418 trace: built-in: git config --null --list -[pid 21285] +++ exited with 0 +++ -[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21285, si_uid=1000, si_status=0, si_utime=0, si_stime=0} --- -strace: Process 21287 attached -[pid 21287] execve(\"/usr/lib/git-core/git\", [\"git\", \"--git-dir=.git\", \"--work-tree=.\", \"--literal-pathspecs\", \"cat-file\", \"--batch\"], 0x7ffc19e1be20 /* 132 vars */) = 0 -22:19:32.842280 git.c:418 trace: built-in: git cat-file --batch -strace: Process 21288 attached -[pid 21288] execve(\"/usr/lib/git-core/git\", [\"git\", \"--git-dir=.git\", \"--work-tree=.\", \"--literal-pathspecs\", \"cat-file\", \"--batch-check=%(objectname) %(ob\"...], 0x7ffc19e1be20 /* 132 vars */) = 0 -22:19:32.854004 git.c:418 trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)' -strace: Process 21289 attached -[pid 21289] execve(\"/usr/lib/git-core/git\", [\"git\", \"--git-dir=.git\", \"--work-tree=.\", \"--literal-pathspecs\", \"check-attr\", \"-z\", \"--stdin\", \"annex.backend\", \"annex.numcopies\", \"annex.largefiles\", \"--\"], 0x7ffc19e1be20 /* 132 vars */) = 0 -strace: Process 21290 attached -[pid 21290] execve(\"/usr/lib/git-core/git\", [\"git\", \"--version\"], 0x7ffc19e1be20 /* 132 vars */) = 0 -22:19:32.934952 git.c:418 trace: built-in: git version -22:19:32.935300 git.c:418 trace: built-in: git check-attr -z --stdin annex.backend annex.numcopies annex.largefiles -- -[pid 21290] +++ exited with 0 +++ -[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21290, si_uid=1000, si_status=0, si_utime=0, si_stime=0} --- -strace: Process 21291 attached -[pid 21287] +++ exited with 0 +++ -[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21287, si_uid=1000, si_status=0, si_utime=0, si_stime=0} --- -[pid 21288] +++ exited with 0 +++ -[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21288, si_uid=1000, si_status=0, si_utime=0, si_stime=0} --- -[pid 21289] +++ exited with 0 +++ -[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21289, si_uid=1000, si_status=0, si_utime=0, si_stime=0} --- -[pid 21283] +++ exited with 0 +++ -[pid 21284] +++ exited with 0 +++ -[pid 21286] +++ exited with 0 +++ -[pid 21291] +++ exited with 0 +++ -[pid 21282] +++ exited with 0 +++ -[pid 21281] +++ exited with 0 +++ -[pid 21280] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21281, si_uid=1000, si_status=0, si_utime=2, si_stime=1} --- -[pid 21280] +++ exited with 0 +++ -[pid 21251] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21280, si_uid=1000, si_status=0, si_utime=0, si_stime=0} --- -[pid 21279] +++ exited with 0 +++ -fatal: Out of memory, realloc failed -strace: Process 21292 attached -[pid 21292] +++ exited with 128 +++ -+++ exited with 128 +++ - - - -\"\"\"]] -"""]] diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_3_9deb76907a5b1182e201b0c6bc708caf._comment b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_3_9deb76907a5b1182e201b0c6bc708caf._comment deleted file mode 100644 index 007cea3559..0000000000 --- a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_3_9deb76907a5b1182e201b0c6bc708caf._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-02-05T18:04:51Z" - content=""" -This appears to be the same bug in git as - -and I suppose that the simple patch to git to make it avoid an excessive -malloc of memory it never actually needs to use would also fix this case. -"""]] diff --git a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client.mdwn b/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client.mdwn deleted file mode 100644 index 87e91d9a3a..0000000000 --- a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client.mdwn +++ /dev/null @@ -1,57 +0,0 @@ -### Please describe the problem. -git annex fsck and git annex get are showing (false?) sha256sum failed messages on Android with the 2016-07-19 android 5.0 build. I haven't seen this before but have been using git-annex on Android, with the same repository for a year, so I'd guess regression. - -I ran fsck on the files on another machine (Watt: Debian testing, 6.20160511-1) and no errors occur. Note that isn't the machine that the Android tablet transfers from (Einstein: Debian stable + backports, 5.20151208-1~bpo8+1). The Android shell didn't have a sha256sum command, but it had an md5 command—and I tried one of the files (Management Report.pdf) and the md5 matches on both Watt and the Android tablet. - -I also ran git annex fsck on Einstein (the entire repository, since it's a bare repo) and the only problem it found was a single (different) key with an insufficient number of trusted copies. - -So I think the file is actually fine. - -### What steps will reproduce the problem? -Unsure. Dropping and re-getting those files didn't help; it showed a sha256 error with get too. - -The only difference I can think of between the files that fail and work is the size: - -[[!format text """ -u0_a180@manta:/sdcard/Westerley-Board/Board Packets & Reports/2016-08-25 (Regular) $ ls -l --rw-rw---- root sdcard_r 116225 2016-08-24 05:40 Agenda 16-08-25.pdf --rw-rw---- root sdcard_r 10128521 2016-08-24 06:02 Management Report scan 2 (annotated; Anthony).pdf --rw-rw---- root sdcard_r 10128521 2016-08-24 06:02 Management Report scan 2.pdf --rw-rw---- root sdcard_r 53313352 2016-08-24 06:02 Management Report.pdf --rw-rw---- root sdcard_r 27154 2016-08-24 06:02 WHOA Chart of Accounts Spreadsheet.xlsx -"""]] - -### What version of git-annex are you using? On what operating system? - - -### Please provide any additional information below. - -[[!format text """ -u0_a180@manta:/sdcard/Westerley-Board/Board Packets & Reports/2016-08-25 (Regular) $ git annex fsck * -WARNING: linker: git-annex has text relocations. This is wasting memory and prevents security hardening. Please fix. -fsck Agenda 16-08-25.pdf (checksum...) ok -fsck Management Report scan 2 (annotated; Anthony).pdf (checksum...) -sha256sum failed -ok -fsck Management Report scan 2.pdf (checksum...) -sha256sum failed -ok -fsck Management Report.pdf (checksum...) -sha256sum failed -ok -fsck WHOA Chart of Accounts Spreadsheet.xlsx (checksum...) ok -(recording state in git...) -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -__bionic_open_tzdata_path: ANDROID_ROOT not set! -u0_a180@manta:/sdcard/Westerley-Board/Board Packets & Reports/2016-08-25 (Regular) $ -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, I've been using git annex for I think a year and a half now, on several repositories. It works pretty well. I have a total of around 315GB and 23K annexed keys across them (counting each annex only once, even though they're cloned on a bunch of machines). - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_1_f5643bafe724c98a6dc810adb2ea931a._comment b/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_1_f5643bafe724c98a6dc810adb2ea931a._comment deleted file mode 100644 index 7fe44973f5..0000000000 --- a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_1_f5643bafe724c98a6dc810adb2ea931a._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-05T17:19:43Z" - content=""" -That warning message indicates that the `sha256sum` command is exiting nonzero. -git-annex handles that failure by using its internal SHA, which apparently -succeeds, because the `fsck` output ends with "ok". Indeed, I don't see any -indication that this is causing any problems, other than a warning -message. - -The size variation is due to git-annex only using `sha256sum` for -larger files, where it can be faster than the internal SHA. - -Android is supposed to have `sha256sum` and `sha1sum` available -(but not some of the other sizes). They are included in the git-annex -bundle, in eg /data/data/ga.androidterm/bin/ along with lots of other -busybox utilities. - -So, the problem seems to be that either those commands are not in your -android device somehow, or indeed a reversion in the git-annex Android -build has lost them, or perhaps they're included but are always failing to -work. -"""]] diff --git a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_2_9a8c76e6043d30e77c7aa2513d5af45a._comment b/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_2_9a8c76e6043d30e77c7aa2513d5af45a._comment deleted file mode 100644 index 4ea42c1509..0000000000 --- a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_2_9a8c76e6043d30e77c7aa2513d5af45a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd" - nickname="Anthony DeRobertis" - subject="comment 2" - date="2016-09-09T06:51:45Z" - content=""" -`sha256sum` isn't available on the tablet—at least not in the git-annex shell's PATH. - -I tried checking if it's present in the apk, and I don't see it in there—but I'm also not sure exactly where in the jar file I should find it. Unfortunately, I couldn't find an older Android git-annex build to check—seems the download site only keeps the most recent. -"""]] diff --git a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_3_82369bb5a705dbf24b6511b864c98a73._comment b/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_3_82369bb5a705dbf24b6511b864c98a73._comment deleted file mode 100644 index b078e5aa29..0000000000 --- a/doc/bugs/__34__sha256sum_failed__34___for_some_files_with_newest_Android_client/comment_3_82369bb5a705dbf24b6511b864c98a73._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-05-08T18:47:38Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/__39__annex_add__39___locks_unmodified_file_in_V5_but_not_V6.mdwn b/doc/bugs/__39__annex_add__39___locks_unmodified_file_in_V5_but_not_V6.mdwn deleted file mode 100644 index 22f9270a57..0000000000 --- a/doc/bugs/__39__annex_add__39___locks_unmodified_file_in_V5_but_not_V6.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -### Please describe the problem. - -In a V6 repo, if I unlock a file, modify it, and `git annex add` it, -it ends up in a locked state: - - echo foo >foo && git annex add foo && git commit -mfoo - git annex unlock foo && echo more >>foo && git annex add foo - git cat-file -p :foo - # .git/annex/objects/60/QW/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d - -However, if I do the same, minus the modification, the file stays -unlocked: - - git reset --hard - git annex unlock foo && git annex add foo - git cat-file -p :foo - # /annex/objects/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c - -I'd expect the second action to end up with a locked file because (1) -it does with a modified file and (2) it does in V5. - -From a user's perspective, I suppose this is a minor inconsistency, -and it's easy enough to call `git annex lock` here instead `git annex -add`. But in the case of DataLad, it makes the handling of our -internal `git annex add` calls trickier because we assume the V5 -"annex add unconditionally locks" behavior and we'd have to add -special handling for the V6 behavior. - -### What version of git-annex are you using? On what operating system? - - git-annex version: 6.20180808-gdad627fa9 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Testsuite - dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - operating system: linux x86_64 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - -on Debian Stretch, built from source with `stack build` - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/__39__annex_add__39___locks_unmodified_file_in_V5_but_not_V6/comment_1_a54ff1147b025b58e65ce0be6e795029._comment b/doc/bugs/__39__annex_add__39___locks_unmodified_file_in_V5_but_not_V6/comment_1_a54ff1147b025b58e65ce0be6e795029._comment deleted file mode 100644 index d702e6226b..0000000000 --- a/doc/bugs/__39__annex_add__39___locks_unmodified_file_in_V5_but_not_V6/comment_1_a54ff1147b025b58e65ce0be6e795029._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-09-12T16:29:55Z" - content=""" -In fact, `git annex add` does not process the v6 unlocked file at all -since it only looks for unstaged changes to files and the unlocked file's -type change has been staged already. - -In v5 mode there is a separate pass to add unlocked files, which is -necessary since they have to be converted back to locked files before they -can be committed. - -It would need a separate pass in v6 too, since the main pass looks only -at unstaged modifications and git can't be queried for staged modifications -at the same time as unstaged. - -Hmm, this would though mean that `git annex add` would now be changing -what's staged. It has never done that before; it's only staged new changes. -Not convinced by that argument, but something to keep in mind. - -I'm feeling this is ok to change, and the patch is not difficult. -"""]] diff --git a/doc/bugs/__39__web__39___remote_does_not_work_on_Android.mdwn b/doc/bugs/__39__web__39___remote_does_not_work_on_Android.mdwn deleted file mode 100644 index c88b63341e..0000000000 --- a/doc/bugs/__39__web__39___remote_does_not_work_on_Android.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -### Please describe the problem. -On Android, any attempt by git-annex to use the 'web' special remote won't work, instead wget will complain about the user-agent parameter. This is very annoying when I have web URLs registered for numerous files. - -### What steps will reproduce the problem? -Try to grab a file via git-annex that has an attached web URL on Android. - -### What version of git-annex are you using? On what operating system? -Latest version of git-annex app on an Android 5 tablet. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/__39__web__39___remote_does_not_work_on_Android/comment_1_11d3af70288da83aee72a48cb46d22e9._comment b/doc/bugs/__39__web__39___remote_does_not_work_on_Android/comment_1_11d3af70288da83aee72a48cb46d22e9._comment deleted file mode 100644 index d5b18226ab..0000000000 --- a/doc/bugs/__39__web__39___remote_does_not_work_on_Android/comment_1_11d3af70288da83aee72a48cb46d22e9._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:45:14Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/__91__Android__93_____34__Make_Camera_Repository__34___button_goes_to_blank_page.mdwn b/doc/bugs/__91__Android__93_____34__Make_Camera_Repository__34___button_goes_to_blank_page.mdwn deleted file mode 100644 index 2261624387..0000000000 --- a/doc/bugs/__91__Android__93_____34__Make_Camera_Repository__34___button_goes_to_blank_page.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -### Please describe the problem. - -When first installing the Android app, it opens the browser to the "Welcome to git-annex!" page. There is a big button to "Make Camera Repository". I click it, and am brought to a completely blank page. If I re-open the web app, it does appear to have created the DCIM repository (it shows in the repository list), but should probably show something (a confirmation, at least?) on that page. - -### What steps will reproduce the problem? - -1. Install the android app -2. Run it -3. Click the "Make Camera Repository" button - -### What version of git-annex are you using? On what operating system? - -Current (2014-11-14) Android 4.3/4.4 build on a non-rooted Moto X. I don't see a way to find version info about the Android app itself, but the terminal output for "version" says it's running git-annex version 5.20141104-gcaafd06 - -### Please provide any additional information below. - - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/__91__Android__93_____34__Make_Camera_Repository__34___button_goes_to_blank_page/comment_1_0543bcdd46565275790069c572331dab._comment b/doc/bugs/__91__Android__93_____34__Make_Camera_Repository__34___button_goes_to_blank_page/comment_1_0543bcdd46565275790069c572331dab._comment deleted file mode 100644 index 8a7a553700..0000000000 --- a/doc/bugs/__91__Android__93_____34__Make_Camera_Repository__34___button_goes_to_blank_page/comment_1_0543bcdd46565275790069c572331dab._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:54:47Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. - -"""]] diff --git a/doc/bugs/__91__PATCH__93___Build_Build__47__InstallDesktopFile_at___34__make_all__34___time.mdwn b/doc/bugs/__91__PATCH__93___Build_Build__47__InstallDesktopFile_at___34__make_all__34___time.mdwn deleted file mode 100644 index ef4e63ffae..0000000000 --- a/doc/bugs/__91__PATCH__93___Build_Build__47__InstallDesktopFile_at___34__make_all__34___time.mdwn +++ /dev/null @@ -1,29 +0,0 @@ - commit 69138285fd4671855184a2de68e1b99aa0a4f3a8 - Author: Eric Siegerman - Date: Tue Oct 31 02:17:27 2017 -0400 - - Build Build/InstallDesktopFile at "make all" time - - If you run stack as root (e.g. for "make install"), any files it - creates under ./ will, of course, be owned by root. That's a - problem for subsequent runs as non-root. - - Reduce the likelihood of that happening by building - Build/InstallDesktopFile during "make all", so that it needn't be - built by "make install". - - diff --git a/Makefile b/Makefile - index aceb65cae..6ac241f67 100644 - --- a/Makefile - +++ b/Makefile - @@ -1,4 +1,4 @@ - -all=git-annex git-annex-shell mans docs - +all=git-annex git-annex-shell mans docs Build/InstallDesktopFile - - # set to "./Setup" if you lack a cabal program. Or can be set to "stack" - BUILDER?=cabal - -> Applied [[done]]. Note that I had to do a considerable amount of editing to -> get that in to a form that `git am` would accept. In the future, -> providing a patch in a form that `git am` can use would be better. -> --[[Joey]] diff --git a/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message.mdwn b/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message.mdwn deleted file mode 100644 index f62e75d9ee..0000000000 --- a/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message.mdwn +++ /dev/null @@ -1,24 +0,0 @@ - commit 3ee8dc86cd831e975c80844924ef062b79e763b6 - Author: Eric Siegerman - Date: Tue Oct 31 21:12:38 2017 -0400 - - Make a Makefile warning ... more obviously only a warning - - diff --git a/Makefile b/Makefile - index aceb65cae..0381e7383 100644 - --- a/Makefile - +++ b/Makefile - @@ -34,7 +34,10 @@ git-annex: tmp/configure-stamp - # Work around https://github.com/haskell/cabal/issues/3524 - # when not linked dynamically to haskell libs - @if ! ldd git-annex | grep -q libHS; then \ - - chrpath -d git-annex || echo "** unable to chrpath git-annex; it will be a little bit slower than necessary"; \ - + chrpath -d git-annex || { \ - + echo "** warning: unable to chrpath git-annex; it will run OK..."; \ - + echo "** ... but maybe a little bit slower than necessary"; \ - + } \ - fi - - git-annex-shell: git-annex - -> Added "warning:" [[done]] --[[Joey]] diff --git a/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message/comment_1_2ec5e2dfe502b3357f7cb224bb28219a._comment b/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message/comment_1_2ec5e2dfe502b3357f7cb224bb28219a._comment deleted file mode 100644 index fba3a63f75..0000000000 --- a/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message/comment_1_2ec5e2dfe502b3357f7cb224bb28219a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-11-07T20:39:22Z" - content=""" -Perhaps I'm blind as the one who wrote it, but I don't see anything -unclear about the message. -"""]] diff --git a/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message/comment_2_16c12a55f7d4b862e021e9bc1f8c9788._comment b/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message/comment_2_16c12a55f7d4b862e021e9bc1f8c9788._comment deleted file mode 100644 index f100492b37..0000000000 --- a/doc/bugs/__91__PATCH__93___Cosmetic__58___clarify_a_warning_message/comment_2_16c12a55f7d4b862e021e9bc1f8c9788._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="erics" - avatar="http://cdn.libravatar.org/avatar/6e5f74c742128e5d98fd672ed6ea4865" - subject="comment 2" - date="2017-12-08T21:11:40Z" - content=""" -It wasn't clear to me that this was just a warning, i.e. that functionality wasn't compromised. The part after the semicolon kind of implies that, but it seems clearer to say so explicitly. - -On second thought, though, the rephrasing probably isn't necessary. Just adding the \"Warning:\" prefix would suffice... -"""]] diff --git a/doc/bugs/__91__PATCH__93___Cosmetic__58___only_print_ikiwiki_command_if_it__39__s_run.mdwn b/doc/bugs/__91__PATCH__93___Cosmetic__58___only_print_ikiwiki_command_if_it__39__s_run.mdwn deleted file mode 100644 index f2cea95f50..0000000000 --- a/doc/bugs/__91__PATCH__93___Cosmetic__58___only_print_ikiwiki_command_if_it__39__s_run.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -No intended functional change; only what *make* prints should be different. - - commit bb43afb0d70311dc9fd7633133c3c4fec32511e6 - Author: Eric Siegerman - Date: Tue Oct 31 02:33:13 2017 -0400 - - Refactor "make docs" to eliminate confusing output - - The the many lines of arguments to the ikiwiki command would - always be printed -- even if ikiwiki was unavailable. Now - you'll only see them if they're accomplishing something. - - diff --git a/Makefile b/Makefile - index aceb65cae..121b19a99 100644 - --- a/Makefile - +++ b/Makefile - @@ -88,16 +88,21 @@ tags: - # If ikiwiki is available, build static html docs suitable for being - # shipped in the software package. - ifeq ($(shell which ikiwiki),) - -IKIWIKI=echo "** ikiwiki not found, skipping building docs" >&2; true - +BUILD_DOCS=_skip_building_docs - else - -IKIWIKI=ikiwiki - +BUILD_DOCS = _build_docs - endif - - mans: Build/MakeMans - ./Build/MakeMans - - -docs: mans - - LC_ALL=C TZ=UTC $(IKIWIKI) doc html -v --wikiname git-annex \ - +docs: mans $(BUILD_DOCS) - + - +_skip_building_docs: - + @echo "** ikiwiki not found, skipping building docs" >&2 - + - +_build_docs: - + LC_ALL=C TZ=UTC ikiwiki doc html -v --wikiname git-annex \ - --plugin=goodstuff \ - --no-usedirs --disable-plugin=openid --plugin=sidebar \ - --plugin theme --set theme=actiontabs --set deterministic=1 \ - -> [[done]] --[[Joey]] diff --git a/doc/bugs/__91__PATCH__93___Cosmetic__58___only_print_ikiwiki_command_if_it__39__s_run/comment_1_b8304ff302805f7bec977002d733436a._comment b/doc/bugs/__91__PATCH__93___Cosmetic__58___only_print_ikiwiki_command_if_it__39__s_run/comment_1_b8304ff302805f7bec977002d733436a._comment deleted file mode 100644 index 31a6700866..0000000000 --- a/doc/bugs/__91__PATCH__93___Cosmetic__58___only_print_ikiwiki_command_if_it__39__s_run/comment_1_b8304ff302805f7bec977002d733436a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-11-07T20:31:00Z" - content=""" -I don't like this amount of complication for a build system cosmetic -improvement. Instead, I have added a "@" to the objectionably long -command line in the Makefile. -"""]] diff --git a/doc/bugs/__91__macos__93___Watcher_crashed_-_probably_because_of_.gitignore.mdwn b/doc/bugs/__91__macos__93___Watcher_crashed_-_probably_because_of_.gitignore.mdwn deleted file mode 100644 index 36108d1124..0000000000 --- a/doc/bugs/__91__macos__93___Watcher_crashed_-_probably_because_of_.gitignore.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -### Please describe the problem. -The watcher in `git annex webapp` crashes (see error below). - -It seems to be a result of having the file `Icon^M^M` in `.gitignore` - - -### What steps will reproduce the problem? -1. Add `Icon^M^M` into `.gitignore` -2. Start the webapp -3. See the error in the top right hand side of the screen - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -git-annex version: 7.20190912 -build flags: Assistant Webapp Pairing S3 WebDAV FsEvents TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.3 feed-1.2.0.0 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.10.5 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external -operating system: darwin x86_64 -supported repository versions: 7 -upgrade supported from repository versions: 0 1 2 3 4 5 6 -local repository version: 7 -"""]] - -Running on MacOS 10.13.6 -### Please provide any additional information below. - -[[!format sh """ -Watcher crashed: unknown response from git cat-file ("HEAD:./Library/Icon missing",Ref "HEAD:./Library/Icon\r") -CallStack (from HasCallStack): -error, called at ./Git/CatFile.hs:119:28 in main:Git.CatFile -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! Been using it since the start. Donated. Will donate again if you run a funding run. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/__91__macos__93___Watcher_crashed_-_probably_because_of_.gitignore/comment_1_d7b2865af30732292d895f370380d8a5._comment b/doc/bugs/__91__macos__93___Watcher_crashed_-_probably_because_of_.gitignore/comment_1_d7b2865af30732292d895f370380d8a5._comment deleted file mode 100644 index a06e16221d..0000000000 --- a/doc/bugs/__91__macos__93___Watcher_crashed_-_probably_because_of_.gitignore/comment_1_d7b2865af30732292d895f370380d8a5._comment +++ /dev/null @@ -1,46 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-10-08T18:53:09Z" - content=""" -The error message shows that the problem is that git cat-file -output something ending with a carriage return. - -I don't think that the carriage return in your .gitignore is directly -related. git-annex uses `git check-ignore -z` which uses NUL for a -delimited and not newline characters. - -It's interesting that carriage returns would cause a problem with git -cat-file. Its interface is obviously problimatic for filenames containing -newlines, and git-annex has worked around that for a while. - -Here's git cat-file --batch falling over on a carriage return, indeed: - - joey@darkstar:/tmp/bad>git ls-tree HEAD - 100644 blob 79e1eee83674b65519a4a9d632bb38dda357512b .gitignore - 100644 blob d8a7f641c2ded93c164528b87fa17a12e7e6a5b1 foo - 100644 blob f8e47b9532ea17ac825c39bddc35dbd68f120a46 "foo\\r" - 100644 blob 4ed2fceb3af4c9dc27097d9a3f7d88973ffa2884 x - 100644 blob 4c2dbb3e16f26cdccc6da3aea3c5e69fe46098f5 y - joey@darkstar:/tmp/bad>printf 'HEAD:foo\r' | git cat-file --batch | hexdump -C - 00000000 48 45 41 44 3a 66 6f 6f 0d 20 6d 69 73 73 69 6e |HEAD:foo. missin| - 00000010 67 0a |g.| - 00000012 - -Here's the code from git that seems responsible: - - int strbuf_getline(struct strbuf *sb, FILE *fp) - { - if (strbuf_getwholeline(sb, fp, '\n')) - return EOF; - if (sb->buf[sb->len - 1] == '\n') { - strbuf_setlen(sb, sb->len - 1); - if (sb->len && sb->buf[sb->len - 1] == '\r') - strbuf_setlen(sb, sb->len - 1); - } - return 0; - } - -I've griped on the git mailing list, but also gonna fix git-annex to use -the slow fallback for filenames with carriage returns. -"""]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp.mdwn b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp.mdwn deleted file mode 100644 index 21bcb6f6c6..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -### Please describe the problem. -I didn't spot this bugs page before so here is my report I have commented on android page - -In addition to two existing repositories (1 local /sdcard/annex, which is also avail at/storage/sdcard0/annex + 1 remote) I have added one more local (and said to keep it in sync with original local). But it didn't work -- it "Synced with onerussian.com_annex but not with Annex" and claimed that the /external/extSdCard/Annex doesn't exist, although it is there (and with .git generated etc). When I restarted the deamon I got into a "new" Repository: /storage/extSdCard/Annex which also listed the 1st local but with "Failed to sync with localhost" message -- no remote one listed. Whenever I try to "Switch repository" to /sdcard/annex (the original local) -- it starts loading a new page but gets stuck right there. The only way to revive webui is to go back to Dashboard. Log there says (retyping from the screen so typos might be there): - -error: cannot run git-receive-pack '/storage/sdcard0/annex': No such file or directory fatal: unable to fork -### What steps will reproduce the problem? - - -### What version of git-annex are you using? On what operating system? -android - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_1_d488d71a72eb54d7711d2a867db6172f._comment b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_1_d488d71a72eb54d7711d2a867db6172f._comment deleted file mode 100644 index aedeaabf3e..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_1_d488d71a72eb54d7711d2a867db6172f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0" - nickname="Matthew" - subject="comment 1" - date="2013-07-28T11:21:42Z" - content=""" -I can confirm it's virtually impossible to change repository on Android (Stock Galaxy Nexus GSM). you click on the files link (which is hard to see on phone as it is in the notification blocks) and then click click \"Switch repository\", on the next page, select a different one. I think it does actually change, occasionally, you have to kill and restart the daemon at least and I think you also have to restart the phone. -"""]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_2_85b31db6d0fb2d20018db3d8c8258bf4._comment b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_2_85b31db6d0fb2d20018db3d8c8258bf4._comment deleted file mode 100644 index 0ee4e81669..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_2_85b31db6d0fb2d20018db3d8c8258bf4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0" - nickname="Matthew" - subject="comment 2" - date="2013-07-28T11:46:30Z" - content=""" -For notification -"""]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_3_9ffafbeb572e110b3e072029d1ce177c._comment b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_3_9ffafbeb572e110b3e072029d1ce177c._comment deleted file mode 100644 index b181a4fa13..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_3_9ffafbeb572e110b3e072029d1ce177c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="yasin.zaehringer" - ip="90.218.200.128" - subject="comment 3" - date="2014-04-02T11:43:52Z" - content=""" -The bug still exists. It is not possible to change the repository in the WebApp. -"""]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_4_69c0068218586ee22d3bd29dd30d0ae0._comment b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_4_69c0068218586ee22d3bd29dd30d0ae0._comment deleted file mode 100644 index 4374c0793e..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_4_69c0068218586ee22d3bd29dd30d0ae0._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnbPKLjBONawBd74MKJZo05juCqdsP1jAU" - nickname="Ramon" - subject="bug still there" - date="2015-02-22T14:58:41Z" - content=""" -As of today (with v 5.20150219-gd24cfd3, on two different Android tablets, one with Android 4.1.1 and the other 4.4.1) it is still impossible to switch repos in Android webapp. So configuration, etc, of different repos becomes somewhat of a pain. -"""]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_5_4522150470f42aee27233bfd35664b9e._comment b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_5_4522150470f42aee27233bfd35664b9e._comment deleted file mode 100644 index e74e137548..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_5_4522150470f42aee27233bfd35664b9e._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="ano.nymous@12ebd53e5933cd1730c84027a7cb905e7c3fdd9c" - nickname="ano.nymous" - avatar="http://cdn.libravatar.org/avatar/f75c9e80591de02a07a1156d45cacdda" - subject="Workaround for switching repos from WebApp" - date="2017-06-07T19:18:51Z" - content=""" -With version 6.20170104 the following workaround seems to work: - - - Start the webapp - - - Click on the menu and select \"Switch Repository\" (as ususal) - - - Click on the link of the repo you wish to switch to (as usual); at this point, the WebApp freezes and the repo is not changed. - - - Keep cool :-) Select the Git Annex terminal session from the slide-down menu. - - - In the Git Annex terminal create a new window by clicking the (+) icon. This will open a new WebApp Dashboard with the newly selected repository. - - - Enjoy :-) -"""]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_6_ee75ed3c65e0c3a0aaf22ea2ad7e9832._comment b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_6_ee75ed3c65e0c3a0aaf22ea2ad7e9832._comment deleted file mode 100644 index 1ada17de47..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_6_ee75ed3c65e0c3a0aaf22ea2ad7e9832._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="Crystalvonwerder@a141a1e27afcd463daccce74ba4df918a01dfd9e" - nickname="Crystalvonwerder" - avatar="http://cdn.libravatar.org/avatar/508da5fc6a8669b0c7dc674259f78075" - subject="Android" - date="2017-07-18T14:43:43Z" - content=""" -Not working -"""]] diff --git a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_7_828dd78475a11c38b58162485fc1a243._comment b/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_7_828dd78475a11c38b58162485fc1a243._comment deleted file mode 100644 index 8aee671c72..0000000000 --- a/doc/bugs/_impossible_to_switch_repositories_on_android__in_webapp/comment_7_828dd78475a11c38b58162485fc1a243._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2018-05-08T18:44:11Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/add_-J_fails_with_not_found.mdwn b/doc/bugs/add_-J_fails_with_not_found.mdwn deleted file mode 100644 index 05e42c48fc..0000000000 --- a/doc/bugs/add_-J_fails_with_not_found.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -here, caught one for you for add (git annex version is tiny bit dated: 6.20170815+gitg22da64d0f-1~ndall+1 ) - -(Pdb) print e.msg -Failed to run ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'add', '--json', '-J6', '082-sn/000001.dcm', '078-sn/000001.dcm', '080-sn/000002.dcm', '076-sn/000002.dcm', '080-sn/000004.dcm', '080-sn/000001.dcm', '079-sn/000003.dcm', '082-sn/000003.dcm', '073-sn/000002.dcm', '079-sn/000002.dcm', '079-sn/000001.dcm', '077-sn/000002.dcm', '074-sn/000001.dcm', '080-sn/000003.dcm', '077-sn/000001.dcm', '076-sn/000001.dcm', '081-sn/000002.dcm', '078-sn/000002.dcm', '081-sn/000001.dcm', '081-sn/000003.dcm', '073-sn/000001.dcm', '075-sn/000001.dcm', '079-sn/000004.dcm', '082-sn/000002.dcm', '075-sn/000002.dcm', '074-sn/000002.dcm'] under '/mnt/DICOM/test2/inbox/2016/12/12/unknown'. Exit code=1. out={"command":"add","success":true,"key":"MD5E-s193740--3da2e91e0888c05e01daf8ef9ae79570.dcm","file":"076-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s205064--851ce819ea44cabd66923d902e55cd2c.dcm","file":"082-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s226874--8acaba7ff0f57a3e69a5c1afb8bc0ba3.dcm","file":"080-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s193746--faf49ea7b403c8f6191fa5b7521ebbd5.dcm","file":"078-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s205066--c5af824ecd895a342cba7ffefe019fde.dcm","file":"082-sn/000003.dcm"} -{"command":"add","success":true,"key":"MD5E-s226872--abdaf5312c4c11da68cc9aaead6bc93a.dcm","file":"080-sn/000004.dcm"} -{"command":"add","success":true,"key":"MD5E-s226768--352d7bf9be4b45316cb75c2fc5bfbdd2.dcm","file":"079-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s226872--755e5e693b07fd7cab07fa55e0f17fd2.dcm","file":"080-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s193636--47816f992ddf6167549b0d20bf430036.dcm","file":"073-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s193750--465de1ebab376633842ac9e36f6fcc35.dcm","file":"074-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s226766--04006df494da6adbe7b3eea90e4dba1b.dcm","file":"079-sn/000003.dcm"} -{"command":"add","success":true,"key":"MD5E-s226768--3624982179994bbaa781ee8c72c5d6b9.dcm","file":"079-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s193636--98a6efe8bea17485297e5d600c4c01e6.dcm","file":"077-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s193642--15770ed37bedb6bd90a7a4b39761a1fa.dcm","file":"077-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s226870--621a7d3a2be10b99d45a39ef2526ab1c.dcm","file":"080-sn/000003.dcm"} -{"command":"add","success":true,"key":"MD5E-s204960--e28aac5eb5e52fe47c2671e8b87edc8c.dcm","file":"081-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s193750--25cadf2f0fc7a4ca324687a742a2d55e.dcm","file":"076-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s193740--0424fce22306f7590f6d94561eb74e93.dcm","file":"078-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s204956--039309e288379d98480390043ea84ecb.dcm","file":"081-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s204960--7b32e2620301909a74adea3d29c00ed5.dcm","file":"081-sn/000003.dcm"} -{"command":"add","success":true,"key":"MD5E-s193646--ff7337b5330f852063652f1e75099b27.dcm","file":"073-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s226768--40821b65d32878f5859ed1b19c5633d0.dcm","file":"079-sn/000004.dcm"} -{"command":"add","success":true,"key":"MD5E-s193646--02704fbd9d37349c4ee96c1509f1a20d.dcm","file":"075-sn/000001.dcm"} -{"command":"add","success":true,"key":"MD5E-s193636--7c727d28c56da2476b744e8aca421b5c.dcm","file":"075-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s193740--c0b3731d6a46df9000df32eeb78ae894.dcm","file":"074-sn/000002.dcm"} -{"command":"add","success":true,"key":"MD5E-s205066--11b6f6e4cb2f5879a530f83d288bb7fa.dcm","file":"082-sn/000002.dcm"} - err=git-annex: 075-sn/000001.dcm not found -git-annex: add: 1 failed - -(Pdb) -[1]+ Stopped ../test/addall.sh -(dev) [yoh@rolando test2]$ ls -l '/mnt/DICOM/test2/inbox/2016/12/12/unknown/075-sn/000001.dcm' -lrwxrwxrwx 1 yoh users 129 Dec 12 2016 /mnt/DICOM/test2/inbox/2016/12/12/unknown/075-sn/000001.dcm -> ../.git/annex/objects/ZQ/3G/MD5E-s193646--02704fbd9d37349c4ee96c1509f1a20d.dcm/MD5E-s193646--02704fbd9d37349c4ee96c1509f1a20d.dcm - -so it does report success in json, but complains in stderr that file is not found... I guess some race condition between workers so it manages to catch the moment when file is moved into a key or smth like that? - -> [[done]] --[[Joey]] diff --git a/doc/bugs/add_-J_fails_with_not_found/comment_1_daf1f53ac77f664ca0ce572c1bdc45ee._comment b/doc/bugs/add_-J_fails_with_not_found/comment_1_daf1f53ac77f664ca0ce572c1bdc45ee._comment deleted file mode 100644 index 078d14b6a8..0000000000 --- a/doc/bugs/add_-J_fails_with_not_found/comment_1_daf1f53ac77f664ca0ce572c1bdc45ee._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-10-16T16:08:18Z" - content=""" -The " not found" error message comes from -CmdLine.Seek.checkFileOrDirectoryExists, which is intended to catch -git-annex being run with a parameter that does not exist on disk and let -the user know about their mistake. - -Seems like that that's being called from withFilesOldUnlocked, -or withFilesMaybeModified. Both of which Command.Add -calls after withFilesNotInGit. - -With -J, I suppose there could be worker threads still running -to ingest withFilesNotInGit when it moves on to -withFilesOldUnlocked. - -There is a window during file ingestion where the file has been -removed from the working tree and the annex symlink has not been -created yet. Probably that is triggering checkFileOrDirectoryExists. -Although I'd expect that window to be small, so it's somewhat surprising -that yoh could reproduce this problem multiple times. - -The problem could be fixed in several different ways. Could wait for -worker threads to finish before moving on to the next `with*` seek. -Could make checkFileOrDirectoryExists only be run once, rather than 3 -times in `git annex add` (which is surely unncessary work..). Or could -try to eliminate the window where the file is not present in the working -tree. It may be worth doing several of those. -"""]] diff --git a/doc/bugs/add_-J_fails_with_not_found/comment_2_441ded7e239f26ab3a27a2c43a6d0856._comment b/doc/bugs/add_-J_fails_with_not_found/comment_2_441ded7e239f26ab3a27a2c43a6d0856._comment deleted file mode 100644 index 5a1f106182..0000000000 --- a/doc/bugs/add_-J_fails_with_not_found/comment_2_441ded7e239f26ab3a27a2c43a6d0856._comment +++ /dev/null @@ -1,44 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-10-16T16:47:57Z" - content=""" -Here's a way to reproduce it reliably: - - joey@darkstar:~/tmp/tt>for x in $(seq 1 25); do echo $x > $x.f;done - joey@darkstar:~/tmp/tt>git annex add --json -J6 *.f - {"command":"add","success":true,"key":"SHA256E-s2--4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865.f","file":"1.f"} - {"command":"add","success":true,"key":"SHA256E-s3--917df3320d778ddbaa5c5c7742bc4046bf803c36ed2b050f30844ed206783469.f","file":"10.f"} - {"command":"add","success":true,"key":"SHA256E-s3--a1fb50e6c86fae1679ef3351296fd6713411a08cf8dd1790a4fd05fae8688164.f","file":"12.f"} - {"command":"add","success":true,"key":"SHA256E-s3--1a252402972f6057fa53cc172b52b9ffca698e18311facd0f3b06ecaaef79e17.f","file":"13.f"} - {"command":"add","success":true,"key":"SHA256E-s3--9a92adbc0cee38ef658c71ce1b1bf8c65668f166bfb213644c895ccb1ad07a25.f","file":"14.f"} - {"command":"add","success":true,"key":"SHA256E-s3--25d4f2a86deb5e2574bb3210b67bb24fcc4afb19f93a7b65a057daa874a9d18e.f","file":"11.f"} - {"command":"add","success":true,"key":"SHA256E-s3--238903180cc104ec2c5d8b3f20c5bc61b389ec0a967df8cc208cdc7cd454174f.f","file":"15.f"} - {"command":"add","success":true,"key":"SHA256E-s3--e6c21e8d260fe71882debdb339d2402a2ca7648529bc2303f48649bce0380017.f","file":"16.f"} - {"command":"add","success":true,"key":"SHA256E-s3--54183f4323f377b737433a1e98229ead0fdc686f93bab057ecb612daa94002b5.f","file":"17.f"} - {"command":"add","success":true,"key":"SHA256E-s3--7ee29791fc17e986b97128845622b077fb45e349fdb80523fac9dba879b4ad60.f","file":"18.f"} - {"command":"add","success":true,"key":"SHA256E-s3--a9742eb8ee320e006666aef25ae9aeed948247f3125c9cafa7cf97b7e7467dd5.f","file":"19.f"} - {"command":"add","success":true,"key":"SHA256E-s2--53c234e5e8472b6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c3.f","file":"2.f"} - {"command":"add","success":true,"key":"SHA256E-s3--5378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe32238c0fa973f7aa3.f","file":"20.f"} - {"command":"add","success":true,"key":"SHA256E-s3--6e2ae11dad0616f66bbb2b6e6556f580bb987fd911d7132aa6bee2bfc7cc7b52.f","file":"21.f"} - {"command":"add","success":true,"key":"SHA256E-s3--f14b4987904bcb5814e4459a057ed4d20f58a633152288a761214dcd28780b56.f","file":"22.f"} - {"command":"add","success":true,"key":"SHA256E-s3--076320a2a08267b4c026d06573bba408ea68841e73cdc20e62cce59de165ece3.f","file":"23.f"} - {"command":"add","success":true,"key":"SHA256E-s3--68ca3fba3b7e864770cb61aeb306d4bd4354b68ab4dd38450860c5d823e42a53.f","file":"24.f"} - {"command":"add","success":true,"key":"SHA256E-s3--64aeb9975f234becd55bb4635e6e2f2da7a6b7bf0a896f0c07763bdfbfb31420.f","file":"25.f"} - {"command":"add","success":true,"key":"SHA256E-s2--06e9d52c1720fca412803e3b07c4b228ff113e303f4c7ab94665319d832bbfb7.f","file":"6.f"} - {"command":"add","success":true,"key":"SHA256E-s2--aa67a169b0bba217aa0aa88a65346920c84c42447c36ba5f7ea65f422c1fe5d8.f","file":"8.f"} - {"command":"add","success":true,"key":"SHA256E-s2--f0b5c2c2211c8d67ed15e75e656c7862d086e9245420892a7de62cd9ec582a06.f","file":"5.f"} - git-annex: 9.f not found - {"command":"add","success":true,"key":"SHA256E-s2--10159baf262b43a92d95db59dae1f72c645127301661e0a3ce4e38b295a97c58.f","file":"7.f"} - {"command":"add","success":true,"key":"SHA256E-s2--7de1555df0c2700329e815b93b32c571c3ea54dc967b89e81ab73b9972b72d1d.f","file":"4.f"} - {"command":"add","success":true,"key":"SHA256E-s2--1121cfccd5913f0a63fec40a6ffd44ea64f9dc135c66634ba001d10bcf4302a2.f","file":"3.f"} - {"command":"add","success":true,"key":"SHA256E-s2--2e6d31a5983a91251bfae5aefa1c0a19d8ba3cf601d0e8a706b4cfa9661a6b8a.f","file":"9.f"} - git-annex: add: 1 failed - -Which file it fails on varies, but it fails on one of the files -every time I've tried this. - -And, there's always a "success" line printed for the same file after -it failed on it. That confirms my hypothesis that the worker thread is -still running at the same time checkFileOrDirectoryExists gets run. -"""]] diff --git a/doc/bugs/add_-J_fails_with_not_found/comment_3_9749c2722b5520e13448128b68fcfaed._comment b/doc/bugs/add_-J_fails_with_not_found/comment_3_9749c2722b5520e13448128b68fcfaed._comment deleted file mode 100644 index b2ecb4c812..0000000000 --- a/doc/bugs/add_-J_fails_with_not_found/comment_3_9749c2722b5520e13448128b68fcfaed._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-10-16T16:25:39Z" - content=""" -It would be good to avoid the window where the file is not present in the -working tree during ingestion, because interupting `git annex add` during -that window causes the file to go missing, with no record of it yet in git. - -I tried making the window longer by adding a 10 second sleep, and indeed -interrupting `git annex add` during the window is *bad*. - -Looking at the code, `makeLink` uses `replaceFile` to atomicallty -replace the file with the symlink. But `ingestAdd` for some reason -calls `nukeFile` before `makeLink`. I could not find any good reason -for it to do that. So, I've removed the `nukeFile`, closing the window. - -That change also fixed the "file not found" error. But I'm not sure -if it's entirely dealt with the problems raised by this bug report.. -"""]] diff --git a/doc/bugs/add_-J_fails_with_not_found/comment_4_983aa78a20672e4d2b1b74a922eeba0a._comment b/doc/bugs/add_-J_fails_with_not_found/comment_4_983aa78a20672e4d2b1b74a922eeba0a._comment deleted file mode 100644 index f997b7193a..0000000000 --- a/doc/bugs/add_-J_fails_with_not_found/comment_4_983aa78a20672e4d2b1b74a922eeba0a._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2017-10-16T16:58:46Z" - content=""" -I was worried there could be further races in the seeking -done by withFilesOldUnlocked and withFilesMaybeModified if those -run while files are still being ingested by actions run earlier -in the `git annex add`. Seems this is not a problem though -- - -withFilesOldUnlocked looks for typeChanged files, but the files -that were just/are currently being added were not in git before, -so are not typeChanged. - -withFilesMaybeModified looks for modified files, and again these -files were/are just being added for the first time, so it won't stumble -over them. - -So, I don't think a synchronization point is needed. In fact, -all three seeks could actually be run more concurrently than they are not -without stepping on one-another's toes. -"""]] diff --git a/doc/bugs/add_-J_fails_with_not_found/comment_5_c18b38456d58900f5710a311eced9f34._comment b/doc/bugs/add_-J_fails_with_not_found/comment_5_c18b38456d58900f5710a311eced9f34._comment deleted file mode 100644 index 352cc7a26f..0000000000 --- a/doc/bugs/add_-J_fails_with_not_found/comment_5_c18b38456d58900f5710a311eced9f34._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2017-10-16T17:06:43Z" - content=""" -That leaves only the innefficiency of checkFileOrDirectoryExists being -run three times per parameter passed to `git annex add`. - -There are some other commands that also run checkFileOrDirectoryExists -multiple times. `git annex lock` being one. - -So, I factored that out into a separate pass, that's only done once. -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep.mdwn b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep.mdwn deleted file mode 100644 index 34798dc2d1..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep.mdwn +++ /dev/null @@ -1,138 +0,0 @@ -### Please describe the problem. -I've noticed that adding a modified file to a version 6 repo will throw a number of errors if 'git annex add' is executed four or more directories deep from the git directory. -Though it throws a number of errors, it seems the file is still added normally. -I have also experienced a problem whereby adding a file will replace it with its key (as if I had run 'git annex drop'). -I'm not sure if that problem is related. - -### What steps will reproduce the problem? -In order to cause the exception, a file already in the repo has to be unlocked, edited, and re-added; this re-adding must take place from four levels below the git directory. -Here is a minimal working example: - - git init - git annex init --version=6 - mkdir -p 1/2/3/4 - touch 1/2/3/4/foo - git annex add 1/2/3/4/foo - git annex sync - git annex unlock 1/2/3/4/foo - echo "bar" >> 1/2/3/4/foo - cd 1/2/3/4 - git annex add foo - -Specifically, trying to run 'git annex add foo' will result in the following errors being thrown: - - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - fatal: '../1/2/3/4/foo' is outside repository - git-annex: git check-attr EOF: user error - git-annex: smudge: 1 failed - error: external filter git-annex smudge --clean %f failed 1 - error: external filter git-annex smudge --clean %f failed - add foo ok - (recording state in git...) - - -### What version of git-annex are you using? On what operating system? -I'm currently running version 6.20160720-g9f0428e on Arch Linux (x86), though I've experienced this problem since at least February. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$ git init; git annex init --version=6 -Initialized empty Git repository in /mnt/.git/ -init ok -(recording state in git...) -$ mkdir -p 1/2/3/4 -$ touch 1/2/3/4/foo -$ git annex add 1/2/3/4/foo -add 1/2/3/4/foo ok -(recording state in git...) -$ git annex sync -commit -[master (root-commit) 25e1676] git-annex in -:/mntt - 1 file changed, 1 insertion(+) - create mode 120000 1/2/3/4/foo -ok -$ git annex unlock 1/2/3/4/foo -unlock 1/2/3/4/foo ok -(recording state in git...) -$ echo "bar" >> 1/2/3/4/foo -$ cd 1/2/3/4 -$ git annex add foo --debug -[2016-08-23 14:47:21.764271] read: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","foo"] -[2016-08-23 14:47:21.766481] read: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","ls-files","--modified","-z","--","foo"] -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -fatal: '../1/2/3/4/foo' is outside repository -git-annex: git check-attr EOF: user error -git-annex: smudge: 1 failed -error: external filter git-annex smudge --clean %f failed 1 -error: external filter git-annex smudge --clean %f failed -[2016-08-23 14:47:21.806128] chat: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"] -[2016-08-23 14:47:21.806624] read: git ["--version"] -[2016-08-23 14:47:21.809352] process done ExitSuccess -[2016-08-23 14:47:21.813764] chat: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","cat-file","--batch"] -add foo [2016-08-23 14:47:21.818268] read: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","symbolic-ref","-q","HEAD"] -[2016-08-23 14:47:21.82027] process done ExitSuccess -[2016-08-23 14:47:21.822862] read: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","show-ref","git-annex"] -[2016-08-23 14:47:21.825102] process done ExitSuccess -[2016-08-23 14:47:21.825233] read: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-08-23 14:47:21.82715] process done ExitSuccess -[2016-08-23 14:47:21.828549] chat: git -["--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","cat-file","--batch"] -ok -(recording state in git...) -[2016-08-23 14:47:21.832848] feed: xargs -["-0","git","--git-dir=../../../../.git","--work-tree=../../../..","--literal-pathspecs","add","--"] -[2016-08-23 14:47:21.836822] process done ExitSuccess -[2016-08-23 14:47:21.837518] chat: git -["--git-dir=../../../.git","--work-tree=../../../..","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] -[2016-08-23 14:47:21.838061] feed: git -["--git-dir=../../../.git","--work-tree=../../../..","--literal-pathspecs","update-index","-z","--index-info"] -[2016-08-23 14:47:21.843259] process done ExitSuccess -[2016-08-23 14:47:21.843444] read: git -["--git-dir=../../../.git","--work-tree=../../../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-08-23 14:47:21.847287] process done ExitSuccess -[2016-08-23 14:47:21.847602] read: git -["--git-dir=../../../.git","--work-tree=../../../..","--literal-pathspecs","write-tree"] -[2016-08-23 14:47:21.85106] process done ExitSuccess -[2016-08-23 14:47:21.851221] chat: git -["--git-dir=../../../.git","--work-tree=../../../..","--literal-pathspecs","commit-tree","b4a158d15da89e28ef5c2f1782c5b1e3c6f1176c","--no-gpg-sign","-p","refs/heads/git-annex"] -[2016-08-23 14:47:21.85892] process done ExitSuccess -[2016-08-23 14:47:21.85907] call: git -["--git-dir=../../../.git","--work-tree=../../../..","--literal-pathspecs","update-ref","refs/heads/git-annex","68381bac2ba0f559d37214c30b5e41a404b9c98b"] -[2016-08-23 14:47:21.861978] process done ExitSuccess -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -I've been happily using git-annex on my laptop and server for almost a year; it's saved me a great deal of time and effort. -Thanks for all your work! - -> [[fixed|done]] finally... --[[Joey]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_10_43aa4935ee42abc90546d166042d379b._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_10_43aa4935ee42abc90546d166042d379b._comment deleted file mode 100644 index 3bf8896294..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_10_43aa4935ee42abc90546d166042d379b._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="Error messages changed" - date="2017-06-15T22:59:42Z" - content=""" -Just a quick follow-up; it seems that one of the recent updates (I believe the version published of 11-June-2017) modified the error messages shown. Running the same code above, I no longer receive a string of `fatal: '../1/2/3/4/foo' is outside repository` followed by `git-annex: git check-attr EOF: user error`. Instead, it shows `git-annex: 1/2/3/4/foo: getFileStatus: does not exist (No such file or directory)`, followed by the rest of the output I originally posted. That is, the output is now: - - git-annex: 1/2/3/4/foo: getFileStatus: does not exist (No such file or directory) - git-annex: smudge: 1 failed - error: external filter 'git-annex smudge --clean %f' failed 1 - error: external filter 'git-annex smudge --clean %f' failed - add foo ok - -I don't know what this represents, but I find it interesting that something was changed recently. -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_11_499cdb675327aaed59877226f77b7077._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_11_499cdb675327aaed59877226f77b7077._comment deleted file mode 100644 index a92d8821d6..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_11_499cdb675327aaed59877226f77b7077._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="comment 11" - date="2017-06-15T23:07:48Z" - content=""" -More specifically, I noticed it first on version 6.20170519-gc6079c3ce8 (it's possible it was one or two commits before that, but I pull updates daily, so the change occured at most a day before). -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_12_d54f9cd6470cbaf6f066513e6fc66f69._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_12_d54f9cd6470cbaf6f066513e6fc66f69._comment deleted file mode 100644 index 924e0a4c0b..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_12_d54f9cd6470cbaf6f066513e6fc66f69._comment +++ /dev/null @@ -1,80 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 12""" - date="2018-07-17T15:52:47Z" - content=""" -Reproduced this today. ext4, git 2.18.0, git-annex 6.20180627-gbd6799ebe. -In an adjusted unlocked v6 repository. - -Running git annex add in 1/2/3/4/5/6/ failed, I then cd'd down to the top -of the repository, and it worked there. - -The bug seems to be intermittent; I was then not able to reproduce it for -a while, and now can again. - - joey@darkstar:~/tmp/t2/1/2/3/4/5/6#master(unlocked)>git annex add meow --debug - [2018-07-17 12:15:35.536935635] read: git ["--git-dir=../../../../../../.git","--work-tree=../../../../../..","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","meow"] - [2018-07-17 12:15:35.542108221] read: git ["--git-dir=../../../../../../.git","--work-tree=../../../../../..","--literal-pathspecs","ls-files","--modified","-z","--","meow"] - git-annex: 1/2/3/4/5/6/meow: getFileStatus: does not exist (No such file or directory) - git-annex: smudge: 1 failed - error: external filter 'git-annex smudge --clean %f' failed 1 - error: external filter 'git-annex smudge --clean %f' failed - -This is git ls-files running the smudge filter which then fails: - - joey@darkstar:~/tmp/t2/1/2/3/4/5/6#master(unlocked)>GIT_TRACE=1 git - --git-dir=../../../../../../.git --work-tree=../../../../../.. - --literal-pathspecs ls-files --modified - - 12:19:49.691639 git.c:415 trace: built-in: git ls-files --modified - 12:19:49.692166 run-command.c:637 trace: run_command: 'git-annex smudge --clean '\''1/2/3/4/5/6/meow'\''' - 12:19:49.700739 git.c:415 trace: built-in: git config --null --list - 12:19:49.704813 git.c:415 trace: built-in: git check-attr -z --stdin annex.backend annex.numcopies annex.largefiles -- - 12:19:49.705020 git.c:415 trace: built-in: git version - 12:19:49.707887 git.c:415 trace: built-in: git cat-file --batch - 12:19:49.707880 git.c:415 trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)' - git-annex: 1/2/3/4/5/6/meow: getFileStatus: does not exist (No such file or directory) - git-annex: smudge: 1 failed - -Note that the smudge filter is being passed the path from the top of the -repo to the file, despite being in the same directory as the file. -Same thing happens during a successful add though, so why is it -failing to process the filename here? Maybe git is normally running -the smudge filter with cwd in the top of the repo, but when this occurs -it's elsewhere? No, I checked and the smudge filter is always being run -at the top of the repository. - -Huh! It's somehow caused by the way that the path to the work-tree is -specified. - - joey@darkstar:~/tmp/t2/1/2/3/4/5/6#master(unlocked)>GIT_TRACE=1 git --work-tree=/home/joey/tmp/t2 --literal-pathspecs ls-files --modified12:32:34.639710 git.c:415 trace: built-in: git ls-files --modified - 12:32:34.640571 run-command.c:637 trace: run_command: 'git-annex smudge --clean '\''1/2/3/4/5/6/meow'\''' - # succeeds no error - -That's two different ways to specifiy the same path, one succeeds and one -fails. - -Hmm.. when git runs the smudge filter, pwd is the top of the repository -and `GIT_WORK_TREE=../../../../../..` -So the work tree in this case points outside the repository, -indeed it points to `/`. I guess this is why the smudge filter is -failing, since it's not finding the file in that wrong worktree. - -This is absolutely a bug in git, I posted to the git mailing list -in message-id 20180717165834.GA5615@kitenet.net about it. - -But why does this only happen sometimes? Well, running `git add` -in a subdirectory does not pass `GIT_WORK_TREE`, because none -was specified. So, the problem does not occur then. -When git-annex runs a git command such as ls-files --modified and passes -a relative work tree, the problem also sometimes doesn't occur. -Sometimes git doesn't need to run the smudge filter -(touching the file makes it need to). -I think it may have to do with the number of subdirectories somehow as -well. - -Since git 1.7.6, `GIT_PREFIX` is set when it runs these filters, -and it contains the path to the subdirectory of the working tree that -it was originally run in. So, git-annex can work around the -problem using that. Done. -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_13_61f13e76890340bd5ae97dab6d6c0141._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_13_61f13e76890340bd5ae97dab6d6c0141._comment deleted file mode 100644 index ada3fd8e18..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_13_61f13e76890340bd5ae97dab6d6c0141._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="Thanks!" - date="2018-07-19T19:44:25Z" - content=""" -Wow, I'm really appreciate the in-depth analysis. Unfortunately, I'm not familiar enough with the inner workings of git/git-annex to dig that deep, so I'm happy you were able to (intermittently) reproduce it. In particular, it seems you've done some great work with the smudge filters, but that's all way above my head still. - -That's good to know that it was actually a bug in git itself. Thanks for submitting the bug report; hopefully that takes care of the problem. - -Using `GIT_PREFIX` is a clever work-around. I appreciate all your help with this! -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment deleted file mode 100644 index a5d988faeb..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-16T18:49:09Z" - content=""" -I'm not able to reproduce the problem with your test case and git-annex -version 6.20161012. - -Can you still reproduce it after upgrading? -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment deleted file mode 100644 index 1046fb0665..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="comment 2" - date="2016-11-19T04:42:25Z" - content=""" -Thanks for looking into it; I just checked again, and even on the newest version (6.20161118 binary), I'm still experiencing the behavior. However, I checked on an older OpenSuse box I have, and there it works (6.20161031 from OpenSuse repo). - -Since my two machines experiencing the problem are both running arch, it seems it's somehow related to that distro. I've checked both installing via the binary (from kitenet) and from the arch community repo, but both produce the same behavior. Further, the OpenSuse install has the same build flags as the binaries, so that doesn't seem to be it. Are there any other diagnostics I can run? - -This particular problem isn't very troublesome (it doesn't seem to have any material impact aside from error messages); however, I also occasionally experience a more serious bug. Namely, when certain (seemingly random) files are added to the repo locked, their content disappears and the symlink is broken (this is the other problem I alluded to in the description). I suspect that problem is related to this one though, since it also only affects my arch machines. I haven't yet submitted a report for that bug yet, though, since I can't reliably replicate it. -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_3_d74835534f52c7f123b14e5d74194733._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_3_d74835534f52c7f123b14e5d74194733._comment deleted file mode 100644 index 918bb4bac7..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_3_d74835534f52c7f123b14e5d74194733._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-12-13T16:54:11Z" - content=""" -Perhaps it's caused by a particular/old version of git? -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_4_f9d6dffb2617715c58216f54016de3a4._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_4_f9d6dffb2617715c58216f54016de3a4._comment deleted file mode 100644 index af0b2030b9..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_4_f9d6dffb2617715c58216f54016de3a4._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="comment 4" - date="2016-12-20T23:08:44Z" - content=""" -Hmm, I don't think an old version of git is the cause. I'm currently running the most recent build of git (2.11.0), but have used a number of versions over the past year. - -I'm not sure if this is relevant, but this other bug reports similar behavior: [sync --content, fatal is outside repository errors](https://git-annex.branchable.com/forum/sync_--content__44___fatal_is_outside_repository_errors/). Specifically, it notes that there is an odd use of relative paths: -> The relative path ../Users is curious - -My error also appends an extra period. In particular, the path should be \"./1/2/3/4/foo\" but prints \"../1/2/3/4/foo\". -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_5_9b9a369fd07cf966bdb9a44699c0d8a4._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_5_9b9a369fd07cf966bdb9a44699c0d8a4._comment deleted file mode 100644 index 340d3e351c..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_5_9b9a369fd07cf966bdb9a44699c0d8a4._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="comment 5" - date="2017-01-08T06:43:48Z" - content=""" -So, I've done a bit more investigating, and it seems the specific command that causes the error is - - git --git-dir=../../../../.git --work-tree=../../../.. --literal-pathspecs ls-files --modified -- foo -In particular, if I execute the code: - - git init - git annex init --version=6 - mkdir -p 1/2/3/4 - touch 1/2/3/4/foo - git annex add 1/2/3/4/foo - git annex sync - git annex unlock 1/2/3/4/foo - echo \"bar\" >> 1/2/3/4/foo - cd 1/2/3/4 - git --git-dir=../../../../.git --work-tree=../../../.. --literal-pathspecs ls-files --modified -- foo -I get the above mentioned error. However, if I run the exact same code without any of the \"git annex\" commands (i.e. only initializing a standard git repository), the ls-files commands returns without error. - -I'm not sure what to make of this though; it doesn't seem to be any sort of corrupted log or bad config options (I ran the same commands on a different, working computer, copied the .git directory to the non-working computer, and still couldn't run the ls-files command). I'm rather at a loss of what to check next. -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_6_ce19be99100dfadc9e69729a7af98dff._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_6_ce19be99100dfadc9e69729a7af98dff._comment deleted file mode 100644 index bba777c388..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_6_ce19be99100dfadc9e69729a7af98dff._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2017-02-20T16:27:39Z" - content=""" -I also can't reproduce any problem running the script from comment #5 -here. - -(The reason that `git ls-files --modified` is -throwing the error is because that ends up running git-annex -when in a v6 repo. - -Seems like it must come down to the version of git, or some -other part of the environment, since it is only happening on one computer -and not others. - -Are there any symlinks in the path to the repository where this happens? -Does this happen if you run the script in `/tmp/newrepo`? -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_7_fc053d15c8a634fc7be744ee51470fc6._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_7_fc053d15c8a634fc7be744ee51470fc6._comment deleted file mode 100644 index e2d331ef5a..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_7_fc053d15c8a634fc7be744ee51470fc6._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="comment 7" - date="2017-04-02T04:17:55Z" - content=""" -Thanks for the suggestions! Just to clarrify, I've tried this on three of my machines: machines 1 and 2 both run arch linux and both experience the same error (even in `/tmp/newrepo`); machine 3 runs opensuse but does not experience the error. - -However, all three machines are using BTRFS for the underlying filesystem. I next tried running the script (on machine 1) in a partition that has Copy-on-Write turned off, and it completed successfully. So it seems that CoW has something to do with it (though the script runs fine even with CoW enabled on machine 3). So it seems we got a bit closer, but I'm still not sure what to make of it. -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_8_a6c330f5ad2f64d86d8a24c23c49115a._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_8_a6c330f5ad2f64d86d8a24c23c49115a._comment deleted file mode 100644 index 5ea68b6850..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_8_a6c330f5ad2f64d86d8a24c23c49115a._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 8""" - date="2017-04-05T15:26:59Z" - content=""" -git-annex does use CoW in a few situations; it does so by running `cp ---reflink` and letting it use CoW features when available. However, -I don't see where `git annex add` would use that, and of course I don't see -why that feature would break for you even if it did run cp that way. - -git also uses CoW, at least it uses `mmap` with `MAP_PRIVATE`. I'm not -clear if/how that involves the filesystem layer. - -This remains puzzling, but knowing it's limited to btrfs on Arch Linux -with CoW is certianly a good start. - -It seems like a bug in btrfs would not be out of the question. -Trying some different kernel versions might be useful. - -It would perhaps be useful to get `strace -ff` logs. -"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_9_9b91f93a66d3e38edc4490be20445a6d._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_9_9b91f93a66d3e38edc4490be20445a6d._comment deleted file mode 100644 index 586dd6b3a7..0000000000 --- a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_9_9b91f93a66d3e38edc4490be20445a6d._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="t.z.mates" - avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" - subject="comment 9" - date="2017-05-13T20:59:34Z" - content=""" -Thanks for the response! I've [linked](https://github.com/tzmates/GitAnnexStrace) to a repo where I posted the strace results (only for the offending line, otherwise there were a lot of files) as well as the code that generated it. I'm not very familiar with strace results, so let me know if I should supply anything else. - -It certainly could be a BTRFS bug, though it doesn't seem to be tied to a specific kernel version; I've been continually updating kernels for the last 2 years now. - -If it's any help, I've never had this sort of problem using `cp --reflink` day-to-day. I have no experience with `mmap` though, so that's a distinct possibility. - -Thanks for all your input on this so far! -"""]] diff --git a/doc/bugs/add_of_modified_file_applies_annex.largefiles_to_size_of_old_key.mdwn b/doc/bugs/add_of_modified_file_applies_annex.largefiles_to_size_of_old_key.mdwn deleted file mode 100644 index be03a8a5ea..0000000000 --- a/doc/bugs/add_of_modified_file_applies_annex.largefiles_to_size_of_old_key.mdwn +++ /dev/null @@ -1,43 +0,0 @@ -`git annex add` of an modified file when annex.largefiles is set -matches largerthan against the size of the old key, not the current -file size - - mkdir /tmp/repo; - cd /tmp/repo; - git init; - git annex init; - git config annex.largefiles '(largerthan=5b)' - git add .gitattributes; - git commit -m 'added .gitattri'; - echo 123456 > file; - git annex add file; - git commit -m add1; - #git config annex.largefiles '(largerthan=7b)' - git annex unlock file; - echo 123 >| file - git annex add file - -This test case adds the file to the annex, even though it's smaller than -5b, because the old key is 6b. If the line is uncommented, it gets added to -git instead. - -While the test case unlocks the file, deleting the annex link and writing -a new file and adding that has the same behavior. - -Using `git add` also has the same behavior. - -I'm pretty sure the user expects the file to be added to git in all -these situation. They configured annex.largefiles that way for a reason. - ----- - -The root cause is that Limit.limitSize uses lookupFileKey. - -It makes sense for that to look up the key and not look at the -current file content when it's being used by a preferred content expression, -or by --largerthan. - -But, for matching largefiles, it needs to look at the actual file on disk, -not an old key. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device.mdwn b/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device.mdwn deleted file mode 100644 index c2e0b5588c..0000000000 --- a/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device.mdwn +++ /dev/null @@ -1,38 +0,0 @@ -[[!meta title="adding remote server using ssh on an Android 4.1 device"]] - -### Please describe the problem. - -Unable to add remote server using ssh on a 4.1 device. - -The error message on the android is: Failed to ssh to the server. Transcript: Could not create directory '(null)/.ssh'. - -The message from sshd on the server is: Feb 20 11:32:37 thrain sshd[1662]: Did not receive identification string from 10.1.0.16 - -(thrain is the sshd server, 10.1.0.16 is the android) - -### What steps will reproduce the problem? - -On the android, go into the get-annex webpage, select add remote repository, -add the particulars - -hit check this server. - -### What version of git-annex are you using? On what operating system? - -The android version of git-annex is 5.20150219-gd24cgd3 -The version of address is 4.1.1 - -The sshd server is debian wheezy - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device/comment_1_ab8a227df71c70c05074b50dcb798acd._comment b/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device/comment_1_ab8a227df71c70c05074b50dcb798acd._comment deleted file mode 100644 index 9edb912099..0000000000 --- a/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device/comment_1_ab8a227df71c70c05074b50dcb798acd._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnbPKLjBONawBd74MKJZo05juCqdsP1jAU" - nickname="Ramon" - subject="comment 1" - date="2015-02-27T01:43:42Z" - content=""" -I had the same problem, also with Android 4.1.1 (an Asus TF201). This is what I did: - -- Download version for Android 4.3 and 4.4 (autobuilds) and install that one over the previous. -- Add the remote, which worked just fine. -- Reinstall the version for Android 4.1 (autobuilds) - -And things seem to be working (things are syncing to the Android) - -"""]] diff --git a/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device/comment_2_f88081ca768d0108936f1da1e509ff32._comment b/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device/comment_2_f88081ca768d0108936f1da1e509ff32._comment deleted file mode 100644 index a9ad7a4918..0000000000 --- a/doc/bugs/adding_remote_server_using_ssh_on_a_4.1_device/comment_2_f88081ca768d0108936f1da1e509ff32._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-05-08T18:53:46Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/addurl_results_in_different_file_to_wget.mdwn b/doc/bugs/addurl_results_in_different_file_to_wget.mdwn deleted file mode 100644 index 10dec894ea..0000000000 --- a/doc/bugs/addurl_results_in_different_file_to_wget.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. -addurl results in a different file than wget. Looks like git-annex is either decompressing it or triggering the server to serve it decompressed. This only happens with this one file in my usage, the other 32 .tar.gz that are added at the same time md5sum correctly. - -### What steps will reproduce the problem? - $ git annex addurl http://www.greenwoodsoftware.com/less/less-530.tar.gz - $ wget http://www.greenwoodsoftware.com/less/less-530.tar.gz - $ md5sum * - -### What version of git-annex are you using? On what operating system? -* git-annex version: 6.20180509-g0632c49c22 -* Arch Linux - -### Please provide any additional information below. - -[[!format sh """ -$ git annex init -init ok -(recording state in git...) -$ git annex addurl http://www.greenwoodsoftware.com/less/less-530.tar.gz -addurl http://www.greenwoodsoftware.com/less/less-530.tar.gz - -(to www.greenwoodsoftware.com_less_less_530.tar.gz) ok -(recording state in git...) -$ wget http://www.greenwoodsoftware.com/less/less-530.tar.gz ---2018-05-16 22:10:19-- http://www.greenwoodsoftware.com/less/less-530.tar.gz -Resolving www.greenwoodsoftware.com (www.greenwoodsoftware.com)... 104.200.21.227 -Connecting to www.greenwoodsoftware.com (www.greenwoodsoftware.com)|104.200.21.227|:80... connected. -HTTP request sent, awaiting response... 200 OK -Length: 339723 (332K) [application/x-gzip] -Saving to: ‘less-530.tar.gz’ - -less-530.tar.gz 100%[==============================================>] 331.76K 573KB/s in 0.6s - -2018-05-16 22:10:20 (573 KB/s) - ‘less-530.tar.gz’ saved [339723/339723] - -$ md5sum * -6a39bccf420c946b0fd7ffc64961315b less-530.tar.gz -3d8def818aa59f10218e2549dc16f6b1 www.greenwoodsoftware.com_less_less_530.tar.gz -$ file -L * -less-530.tar.gz: gzip compressed data, last modified: Tue Dec 5 22:56:50 2017, from Unix -www.greenwoodsoftware.com_less_less_530.tar.gz: POSIX tar archive (GNU) -$ du -L * -332 less-530.tar.gz -1272 www.greenwoodsoftware.com_less_less_530.tar.gz -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Of course! Still love git-annex to bits <3 - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/addurl_results_in_different_file_to_wget/comment_1_43449ff547a70f5fbfc6fa1d1d4bd464._comment b/doc/bugs/addurl_results_in_different_file_to_wget/comment_1_43449ff547a70f5fbfc6fa1d1d4bd464._comment deleted file mode 100644 index 99c037c8e6..0000000000 --- a/doc/bugs/addurl_results_in_different_file_to_wget/comment_1_43449ff547a70f5fbfc6fa1d1d4bd464._comment +++ /dev/null @@ -1,84 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 1" - date="2018-05-17T19:14:25Z" - content=""" -I thought the working ones might be because they are being redirected to https, but I found another one that works correctly that isn't behind https. - -# Broken (http://www.greenwoodsoftware.com/less/less-530.tar.gz) -## git-annex - - GET /less/less-530.tar.gz HTTP/1.1 - Host: www.greenwoodsoftware.com - Accept-Encoding: gzip - - HTTP/1.1 200 OK - Date: Thu, 17 May 2018 18:43:43 GMT - Server: Apache/2 - Last-Modified: Tue, 05 Dec 2017 22:57:13 GMT - ETag: \"52f0b-55f9fc1798dca\" - Accept-Ranges: bytes - Content-Length: 339723 - Vary: User-Agent - Content-Type: application/x-gzip - Content-Encoding: gzip - -## wget - - GET /less/less-530.tar.gz HTTP/1.1 - User-Agent: Wget/1.19.5 (linux-gnu) - Accept: */* - Accept-Encoding: identity - Host: www.greenwoodsoftware.com - Connection: Keep-Alive - - HTTP/1.1 200 OK - Date: Thu, 17 May 2018 18:43:53 GMT - Server: Apache/2 - Upgrade: h2,h2c - Connection: Upgrade, Keep-Alive - Last-Modified: Tue, 05 Dec 2017 22:57:13 GMT - ETag: \"52f0b-55f9fc1798dca\" - Accept-Ranges: bytes - Content-Length: 339723 - Vary: User-Agent - Keep-Alive: timeout=2, max=100 - Content-Type: application/x-gzip - Content-Encoding: x-gzip - -# Working (http://www.trout.me.uk/perl/Authen-Htpasswd-0.171.tar.gz) -## git-annex - GET /perl/Authen-Htpasswd-0.171.tar.gz HTTP/1.1 - Host: www.trout.me.uk - Accept-Encoding: gzip - - HTTP/1.1 200 OK - Date: Thu, 17 May 2018 19:09:55 GMT - Server: Apache/2.2.16 (Debian) - Last-Modified: Tue, 09 Aug 2011 12:09:31 GMT - ETag: \"10269-2096-4aa116fa394c0\" - Accept-Ranges: bytes - Content-Length: 8342 - Content-Type: application/x-gzip - -## wget - - GET /perl/Authen-Htpasswd-0.171.tar.gz HTTP/1.1 - User-Agent: Wget/1.19.5 (linux-gnu) - Accept: */* - Accept-Encoding: identity - Host: www.trout.me.uk - Connection: Keep-Alive - - HTTP/1.1 200 OK - Date: Thu, 17 May 2018 19:09:58 GMT - Server: Apache/2.2.16 (Debian) - Last-Modified: Tue, 09 Aug 2011 12:09:31 GMT - ETag: \"10269-2096-4aa116fa394c0\" - Accept-Ranges: bytes - Content-Length: 8342 - Keep-Alive: timeout=15, max=100 - Connection: Keep-Alive - Content-Type: application/x-gzip -"""]] diff --git a/doc/bugs/addurl_results_in_different_file_to_wget/comment_2_846c236798af74eaa071f59512b0ce6c._comment b/doc/bugs/addurl_results_in_different_file_to_wget/comment_2_846c236798af74eaa071f59512b0ce6c._comment deleted file mode 100644 index 41222b90d6..0000000000 --- a/doc/bugs/addurl_results_in_different_file_to_wget/comment_2_846c236798af74eaa071f59512b0ce6c._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 2" - date="2018-05-17T20:21:47Z" - content=""" -Forcing the use of curl by setting - - git config annex.web-options \"-4\" - -results in the correct download of the file with addurl. Looks like a bug or misbehaviour in http-conduit! - -(Sorry for the noise..) -"""]] diff --git a/doc/bugs/addurl_results_in_different_file_to_wget/comment_3_c8fd9ca4e8b22f6ba04a3530efc3da62._comment b/doc/bugs/addurl_results_in_different_file_to_wget/comment_3_c8fd9ca4e8b22f6ba04a3530efc3da62._comment deleted file mode 100644 index ee90e27883..0000000000 --- a/doc/bugs/addurl_results_in_different_file_to_wget/comment_3_c8fd9ca4e8b22f6ba04a3530efc3da62._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-05-21T18:30:53Z" - content=""" -haskell http-client has a strange default handling of compressed files. -It seems to want to decompress them unless the content-type is -"application/x-tar". It defaults to accept-encoding of gzip. - -That seems to be targeting being used to implement a web browser or -something, although I don't entirely understand how that behavior would -make sense for a web browser either; I'd expect it to only decompress -content that was transparently compressed in transit, but not other -content. Firefox does not decompress that tarball when downloading it; nor -does it display a foo.html.gz as a web page; it downloads it as-is. - -Very strange default for a general purpose http library; IMHO it's a bug. - -`Accept-Encoding: identity` and no transparent decompression seems to be -the way to go here, just like wget. -"""]] diff --git a/doc/bugs/addurl_youtube-dl_behavior_change.mdwn b/doc/bugs/addurl_youtube-dl_behavior_change.mdwn deleted file mode 100644 index 17455358b4..0000000000 --- a/doc/bugs/addurl_youtube-dl_behavior_change.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -I have often used a terminal window and prefixed my input with "git-annex -addurl" then drag links to the window for pasting. Often, I have to press the -up-arrow and run the command again. The addurl behavior with urls that are -already locally present, quvi responds "ok." However, when repeating a command -using yt-dl, when the url is already local, yt-dl refuses to overwrite, yet -returns "failed." I didn't know if you were aware of this. This isn't a -show-stopper, but just something I noticed. I generally do "addurl" manually. - -> I tried this, and it's not youtube-dl failing; but it re-downloads -> the whole content of the already present file, and then git-annex fails: -> -> whatever.mp4 already exists; not overwriting -> -> So I think it needs to ask youtube-dl for the filename first, and check -> if the local file already exists and already has the url, to get back to -> the old behavior. -> -- [[Joey]] - -[[fixed|done]] --[[Joey]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn deleted file mode 100644 index cb0ed5edf6..0000000000 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -I added new content to my git annex repo on my laptop, in the usual way: copying the new dir into the repo, then cd into the new directory, 'git annex add .' and then 'git commit -m '. Everything went well, with no errors, which means that the files were correctly moved to .git/annex/objects/ and symbolic links were created in the new dir. But now, if I do 'git annex fsck .', I get an error for each file: -[[!format sh """ -fsck (fixing location log) (checksum...) - - ** No known copies exist of -failed -"""]] -Unfortunately, I am not able to reproduce the problem on a toy-example repository. This means that my git annex repo may be broken. How do I fix it? -I use git v1.9.1 on Ubuntu 14.04 LTS, and git-annex version: 5.20150406-gb2814bc - -OK, in all honesty, I did a 'git annex sync' between the 'add' and the 'commit' above. But I synced with a clone of the repository that I keep on an external drive, which is less updated than my laptop. It is less updated because I always add content on my laptop and then sync/get from the external disk. So the sync did no harm, apparently. - -> Since this seems to be only a problem with messaging about accidentally -> marked dead repositories, I've made fsck mention when a file is only -> located in a dead repo, and I've made info tell when it's run in a -> supposedly-dead repo. [[done]] --[[Joey]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_1_b23c42004a3486d2409c1f96afa819aa._comment b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_1_b23c42004a3486d2409c1f96afa819aa._comment deleted file mode 100644 index c059040e19..0000000000 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_1_b23c42004a3486d2409c1f96afa819aa._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - subject="comment 1" - date="2016-02-13T22:27:56Z" - content=""" -Additional information: I have 62 files in the added directory. Git-annex info return this, with a suspicious \"numcopies -2: 62\": - - > git-annex info . - directory: . - local annex keys: 62 - local annex size: 377.19 megabytes - annexed files in working tree: 62 - size of annexed files in working tree: 377.19 megabytes - numcopies stats: - numcopies -2: 62 - -"""]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_2_e379c25d18ee1ae4ea7e0a5a33e1c75e._comment b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_2_e379c25d18ee1ae4ea7e0a5a33e1c75e._comment deleted file mode 100644 index c9e046aa62..0000000000 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_2_e379c25d18ee1ae4ea7e0a5a33e1c75e._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-02-14T19:13:05Z" - content=""" -Is the content of the files locally present? Either fsck incorrectly thinks -it's not present despite it being present, or fsck correctly noticed that -it somehow went missing.. - -Is this repository using direct mode? -"""]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_3_063e27ec1f2dd23fbf914a08213316df._comment b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_3_063e27ec1f2dd23fbf914a08213316df._comment deleted file mode 100644 index 6146fad5c3..0000000000 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_3_063e27ec1f2dd23fbf914a08213316df._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - subject="comment 3" - date="2016-02-15T09:47:24Z" - content=""" -Yes, the content is locally present. In the sense that each symlink in the current directory points to an actual file in .git/annex/objects/ . That is why, in my opinion, fsck incorrectly thinks the content is not present, despite it being present. - -Initially I thought that a possible explanation was that 'git commit' went wrong, so that I would have to do it again. I tried to git commit again, but git says there is nothing to commit. - -My repository is in indirect mode. All files in the repository, including the troubling ones are in .git/annex/objects. -"""]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_4_8688477bb694dbc9e6c7768f5f375f3f._comment b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_4_8688477bb694dbc9e6c7768f5f375f3f._comment deleted file mode 100644 index 1fa409f9c3..0000000000 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_4_8688477bb694dbc9e6c7768f5f375f3f._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - subject="repository marked as dead (!)" - date="2016-02-18T14:33:56Z" - content=""" -Update: I've just tried to add a 'test' directory to the repository with only a 'foo' file inside, then git commit. Surprisingly, if I do 'git annex fsck .' of it, the repository is marked as **dead** and no known copies of foo are available: - - (master)> mkdir test ; cd test - test (master) > cat > foo - bar - test (master)> git annex add . - add foo ok - (recording state in git...) - test (master)> git commit -m \"added fake content to test git annex repo\" - [master b9f0a8f] added fake content to test git annex repo - 1 file changed, 1 insertion(+) - create mode 120000 events/2015/test/foo - test (master)> git annex fsck . - Warning: Fscking a repository that is currently marked as dead. - fsck foo (checksum...) - ** No known copies exist of foo - failed - (recording state in git...) - git-annex: fsck: 1 failed - -At this point, I suspect that the repository on my laptop has some serious problem. Shall I move this discussion to the forum? It may be a git-annex bug but it can just be that the repository is damaged for other reasons. Moreover, what is the best course of action, at this point? -"""]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_5_a256583bd9b3815a23cd1ca40d6c19ca._comment b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_5_a256583bd9b3815a23cd1ca40d6c19ca._comment deleted file mode 100644 index 785d6c7b77..0000000000 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_5_a256583bd9b3815a23cd1ca40d6c19ca._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2" - nickname="emanuele.olivetti" - subject="'git-annex semitrust' seems to solve the issue" - date="2016-02-18T21:51:00Z" - content=""" -Given that the repository is marked as dead, I tried to bring it back with 'git-annex semitrust laptop' - 'laptop' being the name of the git annex repository on my laptop. Apparently, this action solved the problem. Fsck now works as expected, and I could sync and get the new files on the clone on the external hard disk as usual. - -Now, if this the correct solution to my problem, I am wondering how it is possible that the repository was marked as dead. I carefully checked the history of previous command, but no sign of 'git annex dead' o similar. Are there scenarios where a repository is automatically marked as dead? -"""]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_6_0999f9ec9c3d6f51889141344d4cfcb6._comment b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_6_0999f9ec9c3d6f51889141344d4cfcb6._comment deleted file mode 100644 index a2e678c1b8..0000000000 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies/comment_6_0999f9ec9c3d6f51889141344d4cfcb6._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-02-19T18:52:25Z" - content=""" -Ok, the repository being dead certianly explains why fsck found a problem. - -It may be that fsck should have a better message in this case. Like -"only dead repository had copies of the file". - -Repositories are only ever marked dead on user request. There are a few -ways besides `git annex dead` that you could have done it. Perhaps trying -to delete the repo in the webapp, or changing it in `git annex vicfg`. -You can check out the git-annex branch and examine the history of the -trust.log file to see when it was changed to dead. -"""]] diff --git a/doc/bugs/android_4.3_install_failed_.mdwn b/doc/bugs/android_4.3_install_failed_.mdwn deleted file mode 100644 index c073e2d2f2..0000000000 --- a/doc/bugs/android_4.3_install_failed_.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -### Please describe the problem. -Impossible installation on Android 4.3 - - -### What version of git-annex are you using? On what operating system? -The lastest version of git-annex, and Android 4.3, **without sdcard** (Wiko Wax) - -### Please provide any additional information below. - -The message given by git-annex: - - - Falling back to hardcoded app location; cannot find expected files in /data/app-lib - mkdir: can't create directory '/sdcard/git-annex.home': Permission denied - mkdir of /sdcard/git-annex.home failed ! - lib/lib.runshell.so: line 133: can't create /sdcard/git-annex.home/git-annex-install.log: Permission denied - Installation failed ! Please report a but and attach /sdcard/git-annex.home/git-annex-install.log - -[[!meta title="android 4.3 install failed on android device without sdcard"]] -[[!tag moreinfo]] - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/android_4.3_install_failed_/comment_1_82447f1e24d7e8df8048464d1b7df117._comment b/doc/bugs/android_4.3_install_failed_/comment_1_82447f1e24d7e8df8048464d1b7df117._comment deleted file mode 100644 index 682780cb2d..0000000000 --- a/doc/bugs/android_4.3_install_failed_/comment_1_82447f1e24d7e8df8048464d1b7df117._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="24.159.78.125" - subject="comment 1" - date="2014-06-02T16:28:42Z" - content=""" -git-annex needs a directory to use to store its repositories. If your android device does not have a /sdcard directory (which does not have to be a literal sd card, but just someplace you can write to), does it have any equivilant directory? -"""]] diff --git a/doc/bugs/android_4.3_install_failed_/comment_2_67ace7c454c7e962ca69e42178142e80._comment b/doc/bugs/android_4.3_install_failed_/comment_2_67ace7c454c7e962ca69e42178142e80._comment deleted file mode 100644 index 09374e8ee6..0000000000 --- a/doc/bugs/android_4.3_install_failed_/comment_2_67ace7c454c7e962ca69e42178142e80._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkPSASwemBzccJmjkotESlbUSs5GPFiPCs" - nickname="Lin" - subject="Ok, but ?" - date="2014-06-02T18:22:24Z" - content=""" -You mean that I have to create the missed files ? -"""]] diff --git a/doc/bugs/android_4.3_install_failed_/comment_3_051e39129a38e439f24703385f503cf4._comment b/doc/bugs/android_4.3_install_failed_/comment_3_051e39129a38e439f24703385f503cf4._comment deleted file mode 100644 index 3f6e86ce4e..0000000000 --- a/doc/bugs/android_4.3_install_failed_/comment_3_051e39129a38e439f24703385f503cf4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 3" - date="2014-06-04T18:08:39Z" - content=""" -I asked if your Android device has an eqivilant directory to /sdcard that you can write to. If so, I can fix git-annex to use that directory. But you need to tell me what it is first! -"""]] diff --git a/doc/bugs/android_4.3_install_failed_/comment_4_5083a8a3fa21c00f70b24c29ed8b6652._comment b/doc/bugs/android_4.3_install_failed_/comment_4_5083a8a3fa21c00f70b24c29ed8b6652._comment deleted file mode 100644 index ef6d01709c..0000000000 --- a/doc/bugs/android_4.3_install_failed_/comment_4_5083a8a3fa21c00f70b24c29ed8b6652._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2018-05-08T18:56:42Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. - -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable.mdwn b/doc/bugs/android__58___cannot_link_executable.mdwn deleted file mode 100644 index 8c8f60cac4..0000000000 --- a/doc/bugs/android__58___cannot_link_executable.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -### Please describe the problem. / What steps will reproduce the problem? -1. Download http://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk -2. Start the App -3. Error Message - * CANNOT LINK EXECUTABLE "git-annex": /data/app/ga.androidterm-1/lib/arm/lib.git-annex.so has text relocations - * error: git-annex died of signal 6 - -### What version of git-annex are you using? On what operating system? -* Android 7.0 -* Nexus 5X -* no root -* git-annex 5.0 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_1_17a502aba0bd260801c9ca01664abd1e._comment b/doc/bugs/android__58___cannot_link_executable/comment_1_17a502aba0bd260801c9ca01664abd1e._comment deleted file mode 100644 index ef682de31a..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_1_17a502aba0bd260801c9ca01664abd1e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-05T16:31:56Z" - content=""" -People have reported similar problems for years, and always on Nexus -devices. So it seems that something done to Android on Nexus is the root of -the problem. -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_2_1057c0477050e52e463c36e03fcab09d._comment b/doc/bugs/android__58___cannot_link_executable/comment_2_1057c0477050e52e463c36e03fcab09d._comment deleted file mode 100644 index a8469cfe0f..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_2_1057c0477050e52e463c36e03fcab09d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="moc514@eb7af2cd9147722b29f32b6606feb2b8563dfac8" - nickname="moc514" - avatar="http://cdn.libravatar.org/avatar/c8c98fc66ef014e61c163375ca9e7422" - subject="Nexus 6p" - date="2016-12-16T02:08:21Z" - content=""" -I also have the same issue with the Nexus 6p with 7.1.1 -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_3_0039743728e02ca27f5346c74e8bad50._comment b/doc/bugs/android__58___cannot_link_executable/comment_3_0039743728e02ca27f5346c74e8bad50._comment deleted file mode 100644 index 0bb2b832f1..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_3_0039743728e02ca27f5346c74e8bad50._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="https://itorres.net/" - nickname="Ignacio Torres " - avatar="http://cdn.libravatar.org/avatar/525cc09b4eb4dc770fe20209f4a240268cad5b027135556bd27acbca9d0d3bc8" - subject="Issue appeared on Android 6.0 (SDK 23)" - date="2016-12-31T14:33:25Z" - content=""" -> On previous versions of Android, if your app requested the system to load a shared library with text relocations, the system displayed a warning but still allowed the library to be loaded. Beginning in this release, the system rejects this library if your app's target SDK version is 23 or higher. - -Source: https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-runtime - -I experience the same issue on a CM14 (Android 7) Moto X -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_4_1e86ba33f6b709bf8bc72b70adbc73dd._comment b/doc/bugs/android__58___cannot_link_executable/comment_4_1e86ba33f6b709bf8bc72b70adbc73dd._comment deleted file mode 100644 index ea86f4d99d..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_4_1e86ba33f6b709bf8bc72b70adbc73dd._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://christian.amsuess.com/chrysn" - avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc" - subject="Issue also affects Samsung devices, git unaffected" - date="2017-09-11T18:07:51Z" - content=""" -I'm experiencing this on a Samsung SM-T813 (arm64) with Android 7.0. - -Running `git` commands or busybox commands in the shipped shell works, this seems to affect the git-annex binary only. -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_5_6c94c327f6dc1c039f9bc5cfaea455ee._comment b/doc/bugs/android__58___cannot_link_executable/comment_5_6c94c327f6dc1c039f9bc5cfaea455ee._comment deleted file mode 100644 index f39e4edb38..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_5_6c94c327f6dc1c039f9bc5cfaea455ee._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://christian.amsuess.com/chrysn" - avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc" - subject="Issue also affects LineageOS" - date="2017-12-17T12:04:52Z" - content=""" -I've installed LineageOS (Android 7.1.2 Nightly) on aforementioned SM-T813. - -The issue affects that setup as well, both in the \"current\" and the \"autobuild\" version for Android 5.0. - -Full message: - - Falling back to hardcoded app location; cannot find expected files in /data/app/ga.androidterm-1/lib - git annex webapp - gts210vewifi:/sdcard/git-annex.home $ git annex webapp - CANNOT LINK EXECUTABLE \"git-annex\": /data/app/ga.androidterm-1/lib/arm/lib.git-annex.so: has text relocations - error: git-annex died of signal 6 - 134|gts210vewifi:/sdcard/git-annex.home $ -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_6_059393465b26596c0af8cfaaef46c11d._comment b/doc/bugs/android__58___cannot_link_executable/comment_6_059393465b26596c0af8cfaaef46c11d._comment deleted file mode 100644 index 8563f0d709..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_6_059393465b26596c0af8cfaaef46c11d._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2018-04-16T20:36:19Z" - content=""" -Apparently this might have to do with ghc passing -no-pie to GCC, -and they added a -fPIE flag to request a PIE. - - -Since the git-annex for android autobuilder uses a hacked up ghc -cross compiler for android, which is quite out of date, that would need to -be updated, as well as probably refeshing all the cabal library patches and -hacks for android. -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_7_1d37b251f1f9bf31647eb13322b92cce._comment b/doc/bugs/android__58___cannot_link_executable/comment_7_1d37b251f1f9bf31647eb13322b92cce._comment deleted file mode 100644 index 51d6a1f127..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_7_1d37b251f1f9bf31647eb13322b92cce._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2018-04-16T23:49:20Z" - content=""" -Even with gcc and ld wrapped to pass `-pie` and strip `-no-pie`, -ghc is not producing PIE binaries. Verified with -"readelf -s git-annex | grep main", and the address for -main is a full address not an offset. - -The same android gcc toolchain does produce -PIE executables by default when building C code. - -Unclear why.. -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_8_ce4c16b0cc064fd6f8314167255c470a._comment b/doc/bugs/android__58___cannot_link_executable/comment_8_ce4c16b0cc064fd6f8314167255c470a._comment deleted file mode 100644 index 3c34530372..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_8_ce4c16b0cc064fd6f8314167255c470a._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 8""" - date="2018-04-25T17:49:30Z" - content=""" -We may be moving away from the git-annex Android app, and to running -git-annex in Termux on Android. - -I think that will avoid this particular problem, since it uses the linux -build of git-annex which bundles the linux linker, so the behavior of the -android linker is no longer an issue. - -If the people who have been bitten by this bug want to give it a try, -see -"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_9_fe04f4cff3d3cb3471edebb25ee37a4d._comment b/doc/bugs/android__58___cannot_link_executable/comment_9_fe04f4cff3d3cb3471edebb25ee37a4d._comment deleted file mode 100644 index fa38741377..0000000000 --- a/doc/bugs/android__58___cannot_link_executable/comment_9_fe04f4cff3d3cb3471edebb25ee37a4d._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 9""" - date="2018-05-08T18:46:53Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/android_ed25519_algorithm.mdwn b/doc/bugs/android_ed25519_algorithm.mdwn deleted file mode 100644 index 392e1d780a..0000000000 --- a/doc/bugs/android_ed25519_algorithm.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -### Please describe the problem. -Openssh was not compiled to support ed25519 algorithm - -### What steps will reproduce the problem? -only enable ed25519 on server and try to connect via ssh. -fails with "no hostkey alg" - -### What version of git-annex are you using? On what operating system? -5.20150219-gd24cfd3, Android 5.0.1 - -regards, -David - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/android_ed25519_algorithm/comment_1_d60c9a7c3a3f12c14a30a8790be6c65b._comment b/doc/bugs/android_ed25519_algorithm/comment_1_d60c9a7c3a3f12c14a30a8790be6c65b._comment deleted file mode 100644 index a431dfc3a4..0000000000 --- a/doc/bugs/android_ed25519_algorithm/comment_1_d60c9a7c3a3f12c14a30a8790be6c65b._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-08T18:53:06Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/android_ed25519_algorithm/comment_2_7669b8e5bbbd2c474f0516e7da407f09._comment b/doc/bugs/android_ed25519_algorithm/comment_2_7669b8e5bbbd2c474f0516e7da407f09._comment deleted file mode 100644 index 3e4e9604a8..0000000000 --- a/doc/bugs/android_ed25519_algorithm/comment_2_7669b8e5bbbd2c474f0516e7da407f09._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="gdkags@28c74e22834edcf63c178e595b8649e5af5151d4" - nickname="gdkags" - avatar="http://cdn.libravatar.org/avatar/d2cf888e824158a3b2d0efe35e163cf2" - subject="fine with me!" - date="2018-05-10T13:02:23Z" - content=""" -Thank you for the feedback! Have fun with the spring-cleaning :D -regards, -David -"""]] diff --git a/doc/bugs/android_installation_fails.mdwn b/doc/bugs/android_installation_fails.mdwn deleted file mode 100644 index 1286d4ca13..0000000000 --- a/doc/bugs/android_installation_fails.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -### Please describe the problem. -Error by installing git-annex on mobile phone - -### What steps will reproduce the problem? -Installation in Termux throws: unknown architecture armv71 - - -### What version of git-annex are you using? On what operating system? - -Android 8.0.0 -Motorola Moto Z2 Play - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -pkg install wget -wget https://git-annex.branchable.com/install/Android/git-annex-install -source git-annex-install - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yeah, almost every day - -> Updated the script per comments. [[done]] --[[Joey]] diff --git a/doc/bugs/android_installation_fails/comment_1_5d18aa98897d0dffb8e08e6ba0ad6037._comment b/doc/bugs/android_installation_fails/comment_1_5d18aa98897d0dffb8e08e6ba0ad6037._comment deleted file mode 100644 index 2894bd96f7..0000000000 --- a/doc/bugs/android_installation_fails/comment_1_5d18aa98897d0dffb8e08e6ba0ad6037._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-01-18T15:53:31Z" - content=""" -armv71 is 32 bit arm, so it may work to edit the git-annex-install script -that you downloaded, and add this to the case statement: - - armv71) - arch=armel - ;; -"""]] diff --git a/doc/bugs/android_installation_fails/comment_2_8b6cac06c55aa42f0f60fe229553c510._comment b/doc/bugs/android_installation_fails/comment_2_8b6cac06c55aa42f0f60fe229553c510._comment deleted file mode 100644 index cda8a62b5f..0000000000 --- a/doc/bugs/android_installation_fails/comment_2_8b6cac06c55aa42f0f60fe229553c510._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zsolt" - avatar="http://cdn.libravatar.org/avatar/ef26f34d5d953cf139c58e5dc4b5fe73" - subject="works!" - date="2019-01-18T22:40:39Z" - content=""" -thanks very much Joey! -"""]] diff --git a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible.mdwn b/doc/bugs/annex-checkuuid_renders_remotes_inaccessible.mdwn deleted file mode 100644 index 812d8e00fc..0000000000 --- a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -### Please describe the problem. - -Setting `remote..annex-checkuuid` to `false` renders remote `` inaccessible for git-annex, i.e., when using commands such as `get`. - -### What steps will reproduce the problem? - - $ cat git-annex-checkuuid.sh - pushd $(mktemp -d) - - git init origin - pushd origin - git annex init origin - touch blob - git annex add blob - git annex sync - - popd - git clone origin clone - pushd clone - git annex init clone - git config remote.origin.annex-checkuuid false - git annex get blob - - $ bash git-annex-checkuuid.sh - … - get blob - Unable to access these remotes: origin - - Try making some of these repositories available: - d27a9c2d-af76-4b01-8335-bc2d72a1d28a -- [origin] - failed - git-annex: get: 1 failed - -### What version of git-annex are you using? On what operating system? - - git-annex version: 6.20180529-g33834140e - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.4.2 http-client-0.5.12.1 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_1_451498fab01ae745eb33d42da8682ad3._comment b/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_1_451498fab01ae745eb33d42da8682ad3._comment deleted file mode 100644 index b88e5f7d87..0000000000 --- a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_1_451498fab01ae745eb33d42da8682ad3._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-06-04T16:44:39Z" - content=""" -I think checkuuid=false has always had this problem; it's never been -actually usable. - -Problem is that checkuuid=false prevents reading the git config, so -the Repo is LocalUnknown, and such repositories are assumed to not be -currently available to use. - -To get from LocalUnknown to Local, it would have to read the repo's -config to determine if the repo is bare or not. But reading the repo's -config every time is exactly what checkuuid=false is intended to prevent. - -Only path I can see is to make the DeferredUUIDCheck that's done -with checkuuid=false return the Local Repo. That could be done in -Remote.Git. But, other modules use Remote.repo to look at the Repo too, -including Command.Sync, and Assistant.TransferSlots. Remote.repo can't -be updated after it's constructed without some mess of updating the remote -list, which does not seem like a good idea. Seems that Remote.repo would -need to be converted to an IO action. - -(So would Remote.gitconfig, which incidentally doesn't contain the config -of the remote when checkuuid=false, which could also be considered a bug -with checkuuid=false.) -"""]] diff --git a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_2_298b1a8418380d932464962ca00fb2f3._comment b/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_2_298b1a8418380d932464962ca00fb2f3._comment deleted file mode 100644 index 625ed48de2..0000000000 --- a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_2_298b1a8418380d932464962ca00fb2f3._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-06-04T17:40:23Z" - content=""" -I've changed Remote.repo to Remote.getRepo so IO can be done there. - -The remaining problem is the remoteGitConfig part -of RemoteGitConfig. That is dependent on the git config of the remote being -read when a Remote is constructed, and when checkuuid=false, that won't be -done. Only a few things use it, but my first try at removing it failed. -"""]] diff --git a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_3_4e68ba8e7bc1e3d935093bf45c5afb10._comment b/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_3_4e68ba8e7bc1e3d935093bf45c5afb10._comment deleted file mode 100644 index 74868844e6..0000000000 --- a/doc/bugs/annex-checkuuid_renders_remotes_inaccessible/comment_3_4e68ba8e7bc1e3d935093bf45c5afb10._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-06-04T20:43:13Z" - content=""" -Since I have been working on this for 4 hours now and want to -end with something usable today, I went ahead with the fix. - -Opened a todo to keep track of the remaining problems with the remote's git -config not being read: -[[todo/need_to_remove_remoteGitConfig_for_checkuuid_support]] -"""]] diff --git a/doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths.mdwn b/doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths.mdwn deleted file mode 100644 index f08d822b61..0000000000 --- a/doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths.mdwn +++ /dev/null @@ -1,56 +0,0 @@ -### Please describe the problem. -Apparently, git-annex-lookupkey can't handle absolute paths to files to look for. - -### What steps will reproduce the problem? - - /tmp % mkdir some - /tmp % cd some - /tmp/some % git init - Initialized empty Git repository in /tmp/some/.git/ - /tmp/some % git annex init - init ok - (recording state in git...) - /tmp/some % echo some > some - /tmp/some % git annex add some - add some ok - (recording state in git...) - /tmp/some % git annex lookupkey some - SHA256E-s5--2922bee6973370915cc63ab5ab8b7a57e1cab909477d7a030b2e4661e7aa2202 - /tmp/some % echo $? - 0 - /tmp/some % git annex lookupkey /tmp/some/some - /tmp/some % echo $? - 1 - - - -### What version of git-annex are you using? On what operating system? - % git annex version - git-annex version: 6.20171018+gitgbb20b1ed3-1~ndall+1 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I do! I wouldn't even have my job, if it wasn't for git-annex. ;-) - -> Which warms the cockles of my heart, Ben! :) -> -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths/comment_1_b9aa0c69b8841c8fe885a5e2e9ec9a06._comment b/doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths/comment_1_b9aa0c69b8841c8fe885a5e2e9ec9a06._comment deleted file mode 100644 index 72ff677fc4..0000000000 --- a/doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths/comment_1_b9aa0c69b8841c8fe885a5e2e9ec9a06._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-12-08T18:58:18Z" - content=""" -This is due to lookupkey not passing the filename through git ls-files like -most (all?) other commands do. - -Using git ls-files would lead to other behavior changes though. It recurses into -directories. I don't think it makes sense for lookupkey to recurse into -directories, because its output format does not include the filename, so -listing a bunch of keys for annexed files is not clear. git annex find -can already recurse and can use a format with the key and the filename -that's suited for directory recursion. git annex lookupkey, as plumbing, -is supposed to be simpler than that. - -I suppose lookupkey could normalize absolute file paths, checking if they -point into the git repository. I don't think that git-annex contains -such normalization code, and it might be a lot more complicated than it at -first seems -- git has a lot of wrinkles with submodules, symlinks, etc etc. -git does not seem to have a suitable command to do it. - -So seems the best way is to use git ls-files and detect when it's recursing, -and exit nonzero then. -"""]] diff --git a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file.mdwn b/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file.mdwn deleted file mode 100644 index b4c8177098..0000000000 --- a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -### Please describe the problem. - -git-annex does not report percent-progress in the json-progress output if size is not listed in the key. But the file is available so git annex could easily report the %s. We will need to workaround in datalad atm where we assumed that percents are always reported - -[[!format sh """ -$> git annex copy --to=localhost --json --json-progress Why_is_git_annex_awesome__This_is_why_.webm -{"byte-progress":32768,"action":{"command":"copy","note":"to localhost...","key":"URL--quvi:https://www.youtube.com/watch,63v,614qCZFW_uGU0","file":"Why_is_git_annex_awesome__This_is_why_.webm"}} -{"command":"copy","note":"to localhost...","success":true,"key":"URL--quvi:https://www.youtube.com/watch,63v,614qCZFW_uGU0","file":"Why_is_git_annex_awesome__This_is_why_.webm"} - -$> du -scmL Why_is_git_annex_awesome__This_is_why_.webm -6 Why_is_git_annex_awesome__This_is_why_.webm -6 total - -$> git annex version -git-annex version: 6.20171018+gitgbb20b1ed3-1~ndall+1 -... - -$> ls -l Why_is_git_annex_awesome__This_is_why_.webm -lrwxrwxrwx 1 yoh yoh 150 Nov 3 09:02 Why_is_git_annex_awesome__This_is_why_.webm -> ../../.git/annex/objects/8f/XP/URL--quvi&chttps&c%%www.youtube.com%watch,63v,614qCZFW_uGU0/URL--quvi&chttps&c%%www.youtube.com%watch,63v,614qCZFW_uGU0 - -"""]] - -> [[done]], but see my caveat about needing to handle lack of progress -> output anyway. --[[Joey]] diff --git a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_1_8e8dd79385b523502b39247135385bc4._comment b/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_1_8e8dd79385b523502b39247135385bc4._comment deleted file mode 100644 index 631155c20a..0000000000 --- a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_1_8e8dd79385b523502b39247135385bc4._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-11-14T19:19:30Z" - content=""" -It indeed would be possible for `copy --to` to check the actual file -size when the key does not have a known size, and use that for progress. -I don't know how hard it would be. - -Note that, even if that were done, there's no guarantee that a given remote -will update progress information, and if it doesn't, --json-progress -won't result in any. So your code certianly needs to handle that case. -"""]] diff --git a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_2_85c2ca68a4611e684c147fc005470fab._comment b/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_2_85c2ca68a4611e684c147fc005470fab._comment deleted file mode 100644 index 29c1248453..0000000000 --- a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_2_85c2ca68a4611e684c147fc005470fab._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-11-14T19:29:21Z" - content=""" -Messages.Progress.metered is what looks at the keySize, and when it's -not known, displays no meter. So it would need an additional Maybe FilePath -that's the file being uploaded, to look at when the keySize is not known. - -That does not seem too hard a change to make; I'm not convinced the extra -complexity is worth it, since this would only add progress for uploads, -and not for downloads. - -There is something to be said for consistency; -and if some transfers of a key have progress and others do not, -it seems the user might get confused, while if nothing does, the user -can conclude that git-annex is not able to provide progress for a key -that does not contain a size, and if they don't like that, avoid -things that generate such keys. -"""]] diff --git a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_3_5866f9e2f21151f36d4fcf1b7d0ea83e._comment b/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_3_5866f9e2f21151f36d4fcf1b7d0ea83e._comment deleted file mode 100644 index 1034a63580..0000000000 --- a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_3_5866f9e2f21151f36d4fcf1b7d0ea83e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-11-14T20:17:10Z" - content=""" -I suppose that, since some remotes don't have progress display implemented, -in paricular some external special remotes, there's no point in worrying -about interface consistency. So, may as well display progress when we can. -"""]] diff --git a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_4_bc55ede32beee2a74b943132e6377005._comment b/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_4_bc55ede32beee2a74b943132e6377005._comment deleted file mode 100644 index 0f36e43963..0000000000 --- a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_4_bc55ede32beee2a74b943132e6377005._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="yarikoptic" - avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" - subject="thanks, what about 'find' with the same issue?" - date="2017-11-16T19:11:51Z" - content=""" -Shoudn't the same apply to \"find\" output? - -[[!format sh \"\"\" -$> git annex find --not --in localhost --json Brainhack2012__Share_your_tools__But_fear_the_wombat_.mp4 -{\"bytesize\":\"unknown\",\"mtime\":\"unknown\",\"keyname\":\"quvi:https://www.youtube.com/watch,63v,618t6znEOEDVo\",\"backend\":\"URL\",\"key\":\"URL--quvi:https://www.youtube.com/watch,63v,618t6znEOEDVo\",\"humansize\":\"unknown\",\"hashdirmixed\":\"kq/PM/\",\"file\":\"Brainhack2012__Share_your_tools__But_fear_the_wombat_.mp4\",\"hashdirlower\":\"8ba/bf9/\"} - -$> sudo dpkg -i /tmp/git-annex-standalone_6.20171114+gitg5e6c3ba30-1\~ndall+1_amd64.deb -[sudo] password for yoh: -(Reading database ... 706557 files and directories currently installed.) -Preparing to unpack .../git-annex-standalone_6.20171114+gitg5e6c3ba30-1~ndall+1_amd64.deb ... -Unpacking git-annex-standalone (6.20171114+gitg5e6c3ba30-1~ndall+1) over (6.20171018+gitgbb20b1ed3-1~ndall+1) ... -Setting up git-annex-standalone (6.20171114+gitg5e6c3ba30-1~ndall+1) ... -... - -$> git annex find --not --in localhost --json Brainhack2012__Share_your_tools__But_fear_the_wombat_.mp4 -{\"bytesize\":\"unknown\",\"mtime\":\"unknown\",\"keyname\":\"quvi:https://www.youtube.com/watch,63v,618t6znEOEDVo\",\"backend\":\"URL\",\"key\":\"URL--quvi:https://www.youtube.com/watch,63v,618t6znEOEDVo\",\"humansize\":\"unknown\",\"hashdirmixed\":\"kq/PM/\",\"file\":\"Brainhack2012__Share_your_tools__But_fear_the_wombat_.mp4\",\"hashdirlower\":\"8ba/bf9/\"} - -$> ls -lL Brainhack2012__Share_your_tools__But_fear_the_wombat_.mp4 --r-------- 1 yoh yoh 64354577 Mar 22 2014 Brainhack2012__Share_your_tools__But_fear_the_wombat_.mp4 - - -\"\"\"]] -"""]] diff --git a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_5_8c33fc01dd1de2abcd3782ff89b437de._comment b/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_5_8c33fc01dd1de2abcd3782ff89b437de._comment deleted file mode 100644 index 5645cb6755..0000000000 --- a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_5_8c33fc01dd1de2abcd3782ff89b437de._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2017-11-20T18:18:07Z" - content=""" -I don't understand what you mean with the find command. Are you talking -about the "unknown" values in the json? - -Oh, I suppose you mean particularly that the bytesize is unknown. - -Well, this would make `find` output differ depending on whether the key is -present or not, in cases where it would otherwise be the same. And it would -change machine-consumable output in a way that for all I know would break -stuff. - -So, changing that seems like a bad idea. -"""]] diff --git a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_6_4d5764187b03962cf7910ef805c57f06._comment b/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_6_4d5764187b03962cf7910ef805c57f06._comment deleted file mode 100644 index 10f8e3444b..0000000000 --- a/doc/bugs/annex_copy_might_not_report_percent-progress_when_it_has_actual_key_file/comment_6_4d5764187b03962cf7910ef805c57f06._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2017-12-05T16:26:09Z" - content=""" -I'd be more comfortable with adding a new "disksize" value -with the current space taken up by the key. - -However, adding that to find --json would mean that find would have to stat -the file to get its size, which would slow it down. Find often does already -stat the file via its inAnnex check, but eg `git annex find --in remote` does -not, and slowing that down further seems inadvisable. -"""]] diff --git a/doc/bugs/annex_ignores_pushurl_and_uses_only_url_upon___34__copy_--to__34__.mdwn b/doc/bugs/annex_ignores_pushurl_and_uses_only_url_upon___34__copy_--to__34__.mdwn deleted file mode 100644 index c7cd3addda..0000000000 --- a/doc/bugs/annex_ignores_pushurl_and_uses_only_url_upon___34__copy_--to__34__.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -### Please describe the problem. - -Cannot copy content to the remote whenever its url is http and pushurl is ssh - - -### What version of git-annex are you using? On what operating system? - -6.20170101+gitg93d69b1-1~ndall+1 - -### Please provide any additional information below. - -Having a remote which has Read-only http url but ssh pushurl: - -[[!format sh """ - - -hopa:/tmp/tmp.uCP6SjbQYt/orig -$> cat .git/config -[core] - repositoryformatversion = 0 - filemode = true - bare = false - logallrefupdates = true -[annex] - uuid = 1c81ccbf-e814-44cb-b2a4-3aef93d159e4 - version = 5 - backends = MD5E -[remote "target1"] - url = http://localhost:8082/demoannex/.git - fetch = +refs/heads/*:refs/remotes/target1/* - pushurl = localhost:/home/yoh/.tmp/tmp.uCP6SjbQYt/public_html/demoannex - annex-ignore = false - annex-bare = false - annex-uuid = d3720112-3b83-450d-a30e-cda370bf5a13 - push = master - push = git-annex - - -"""]] - -copy seems to try to push via http url, not succeeding. Interestingly, without --fast option, it doesn't even give a meaningful error message -- just says that it fails to find the file at the remote end (here are both calls outputs): - -[[!format sh """ - -hopa:/tmp/tmp.uCP6SjbQYt/orig -$> git annex copy --to target1 --debug --json --fast -[2017-02-03 09:58:09.433515455] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2017-02-03 09:58:09.43918477] process done ExitSuccess -[2017-02-03 09:58:09.43929589] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2017-02-03 09:58:09.443217439] process done ExitSuccess -[2017-02-03 09:58:09.444030163] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2017-02-03 09:58:09.444468521] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] -[2017-02-03 09:58:09.449625506] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"] - copying to non-ssh repo not supported - copying to non-ssh repo not supported - This could have failed because --fast is enabled. -{"command":"copy","note":"to target1...","success":false,"key":"MD5E-s0--d41d8cd98f00b204e9800998ecf8427e","file":"probe"} -git-annex: copy: 1 failed - - -$> git annex copy --to target1 --debug --json -[2017-02-03 09:57:51.713147198] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2017-02-03 09:57:51.717451798] process done ExitSuccess -[2017-02-03 09:57:51.717690883] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2017-02-03 09:57:51.721647463] process done ExitSuccess -[2017-02-03 09:57:51.72243661] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2017-02-03 09:57:51.722822231] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] -[2017-02-03 09:57:51.726838506] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"] -{"command":"copy","note":"not found","success":false,"key":"MD5E-s0--d41d8cd98f00b204e9800998ecf8427e","file":"probe"} -git-annex: copy: 1 failed - - -"""]] - -So far we found the way to rectify it by providing value of pushurl as a remote..url value for that git annex call. But it would be more "kosher" if git annex itself respected pushurl in such cases. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -lots - -[[!meta author="yoh"]] - -> [[done]] because there is already an annexUrl config to meet this need. -> --[[Joey]] diff --git a/doc/bugs/annex_ignores_pushurl_and_uses_only_url_upon___34__copy_--to__34__/comment_1_92ea74beb2f8beb449769404a7f57a77._comment b/doc/bugs/annex_ignores_pushurl_and_uses_only_url_upon___34__copy_--to__34__/comment_1_92ea74beb2f8beb449769404a7f57a77._comment deleted file mode 100644 index 55fe57947c..0000000000 --- a/doc/bugs/annex_ignores_pushurl_and_uses_only_url_upon___34__copy_--to__34__/comment_1_92ea74beb2f8beb449769404a7f57a77._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-02-07T19:13:28Z" - content=""" -Thing is, pushUrl is documented in git-push as "The is used for -pushes only.". And while git-annex is sending data to the remote, -that's not really the same as a push. - -Following that logic, if git has a pullUrl, then git-annex should -use that for `git annex get`, since that's similar to a pull. -But then there are other operations git-annex does to remotes -that are similar to neither a push or a pull. And if git doesn't have a -pullUrl, then `git annex get` probably shouldn't use pushUrl, because -perhaps git will later get a pullUrl. - -That's why annexUrl was added in 2011. Which is just used for all annex -operations. - -So, I suggest you just set annexUrl at the same time you set pushUrl, -and be happy. ;) -"""]] diff --git a/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download.mdwn b/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download.mdwn deleted file mode 100644 index 43080af33d..0000000000 --- a/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download.mdwn +++ /dev/null @@ -1,102 +0,0 @@ -### Please describe the problem. - -It seems fully and correctly obtain `get` a file but it ended up in tmp/, upon attempts to reget tries to reget it with incorrect range (since fully here already): - -[[!format sh """ -$> datalad install -g http://github.com/openneurodatasets/ds000001 -install(notneeded): /mnt/btrfs/scrap/tmp/openneuro/ds000001 (dataset) [dataset was already cloned from 'http://github.com/openneurodatasets/ds000001'] -[WARNING] Running get resulted in stderr output: download failed: Requested Range Not Satisfiable -download failed: Requested Range Not Satisfiable -git-annex: get: 1 failed - -[ERROR ] from s3-PUBLIC...; from s3-PUBLIC...; Unable to access these remotes: s3-PUBLIC; Try making some of these repositories available:; b5dd2e3d-825f-4bc2-b719-cba1059f6bfc -- root@93184394ac19:/datalad/ds000001; deaa691f-c824-4416-9bf8-a94a47dd31b5 -- [s3-PUBLIC]; ; (Note that these git remotes have annex-ignore set: origin) [get(/mnt/btrfs/scrap/tmp/openneuro/ds000001/sub-03/func/sub-03_task-balloonanalogrisktask_run-03_bold.nii.gz)] -[WARNING] could not get some content in /mnt/btrfs/scrap/tmp/openneuro/ds000001 ['/mnt/btrfs/scrap/tmp/openneuro/ds000001/sub-03/func/sub-03_task-balloonanalogrisktask_run-03_bold.nii.gz'] [get(/mnt/btrfs/scrap/tmp/openneuro/ds000001)] -action summary: - get (error: 1, impossible: 1) - install (notneeded: 1) -1 14492 ->1.....................................:Mon 05 Nov 2018 10:36:53 PM EST:. -smaug:/mnt/btrfs/scrap/tmp/openneuro -$> cd ds000001 -CHANGES dataset_description.json sub-01/ sub-03/ sub-05/ sub-07/ sub-09/ sub-11/ sub-13/ sub-15/ task-balloonanalogrisktask_bold.json -README participants.tsv sub-02/ sub-04/ sub-06/ sub-08/ sub-10/ sub-12/ sub-14/ sub-16/ -1 14493.....................................:Mon 05 Nov 2018 10:36:56 PM EST:. -(git)smaug:/mnt/btrfs/scrap/tmp/openneuro/ds000001[master] -$> git annex get --debug -[2018-11-05 22:36:59.665601708] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"] -[2018-11-05 22:36:59.669131907] process done ExitSuccess -[2018-11-05 22:36:59.669205841] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"] -[2018-11-05 22:36:59.672930992] process done ExitSuccess -[2018-11-05 22:36:59.673020181] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"] -get sub-03/func/sub-03_task-balloonanalogrisktask_run-03_bold.nii.gz [2018-11-05 22:36:59.686205786] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2018-11-05 22:36:59.690089151] process done ExitSuccess -[2018-11-05 22:36:59.690165258] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2018-11-05 22:36:59.693038961] process done ExitSuccess -[2018-11-05 22:36:59.693248238] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4fd548ce0d4e2bc67da62795e80880a7ae1f6abc","--pretty=%H","-n1"] -[2018-11-05 22:36:59.697945062] process done ExitSuccess -[2018-11-05 22:36:59.698564444] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2018-11-05 22:36:59.698998042] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] -(from s3-PUBLIC...) - -[2018-11-05 22:36:59.734434115] Request { - host = "openneuro.org.s3.amazonaws.com" - port = 80 - secure = False - requestHeaders = [("Range","bytes=46216487-"),("Accept-Encoding","identity"),("User-Agent","git-annex/6.20181011+git124-g94aa0e2f6-1~ndall+1")] - path = "/ds000001/sub-03/func/sub-03_task-balloonanalogrisktask_run-03_bold.nii.gz" - queryString = "?versionId=KKf9EeO6JyGQbKG_SyU51ehWSYeXiMX9" - method = "GET" - proxy = Nothing - rawBody = False - redirectCount = 10 - responseTimeout = ResponseTimeoutDefault - requestVersion = HTTP/1.1 -} - -download failed: Requested Range Not Satisfiable -(from s3-PUBLIC...) - -[2018-11-05 22:36:59.815117255] Request { - host = "openneuro.org.s3.amazonaws.com" - port = 80 - secure = False - requestHeaders = [("Range","bytes=46216487-"),("Accept-Encoding","identity"),("User-Agent","git-annex/6.20181011+git124-g94aa0e2f6-1~ndall+1")] - path = "/ds000001/sub-03/func/sub-03_task-balloonanalogrisktask_run-03_bold.nii.gz" - queryString = "?versionId=KKf9EeO6JyGQbKG_SyU51ehWSYeXiMX9" - method = "GET" - proxy = Nothing - rawBody = False - redirectCount = 10 - responseTimeout = ResponseTimeoutDefault - requestVersion = HTTP/1.1 -} - -download failed: Requested Range Not Satisfiable - - Unable to access these remotes: s3-PUBLIC - - Try making some of these repositories available: - b5dd2e3d-825f-4bc2-b719-cba1059f6bfc -- root@93184394ac19:/datalad/ds000001 - deaa691f-c824-4416-9bf8-a94a47dd31b5 -- [s3-PUBLIC] - - (Note that these git remotes have annex-ignore set: origin) -failed -[2018-11-05 22:36:59.852095523] process done ExitSuccess -[2018-11-05 22:36:59.85253563] process done ExitSuccess -git-annex: get: 1 failed - - -$> du -scb .git/annex/tmp/MD5E-s46216487--ec7b8fc23a313f1429e941fd94c2d268.nii.gz -46216487 .git/annex/tmp/MD5E-s46216487--ec7b8fc23a313f1429e941fd94c2d268.nii.gz -46216487 total - -$> md5sum .git/annex/tmp/MD5E-s46216487--ec7b8fc23a313f1429e941fd94c2d268.nii.gz -ec7b8fc23a313f1429e941fd94c2d268 .git/annex/tmp/MD5E-s46216487--ec7b8fc23a313f1429e941fd94c2d268.nii.gz - -$> git annex version -git-annex version: 6.20181011+git124-g94aa0e2f6-1~ndall+1 - -"""]] - -Not sure why it ended up not moved into the proper location but I think upon redownload, size should be verified, if "Full" - try to proceed to checksum verification etc. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_1_7393f680eb1f12ceee5f950bc5a2179c._comment b/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_1_7393f680eb1f12ceee5f950bc5a2179c._comment deleted file mode 100644 index 40a5389000..0000000000 --- a/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_1_7393f680eb1f12ceee5f950bc5a2179c._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-11-12T19:27:00Z" - content=""" -Thing is, git-annex does not always know the size of an annexed object, -and also the same download function is used for downloading other things -than annexed objects, which git-annex never knows the size of. -So trying to paper over this problem by checking the size first wouldn't -fix all cases. - -This is supposed to be handled by catching the 416 http error, -and checking that the Content-Range header looks like "bytes */$size" -which is at least one of the ways that http servers indicate the size of -the file. - -But if a http server doesn't send such a Content-Range, -it's not clear what to do. It could, I suppose, just give up -on resuming in that case, and re-download. - -Anyway, please show the output of `git annex version`, because this could -potentially have to do with the version of http-client that git-annex was -built with. - -Do you know of an url that still exists that can be used to reproduce this? -"""]] diff --git a/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_2_786158af6b36de925afce8ba6102ae62._comment b/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_2_786158af6b36de925afce8ba6102ae62._comment deleted file mode 100644 index b5b985449c..0000000000 --- a/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_2_786158af6b36de925afce8ba6102ae62._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-11-12T19:50:04Z" - content=""" -I was able to reproduce this with an apache web server. It seems apache -doesn't send back a Content-Range header when the requested range is empty, -though it does otherwise. - -Both wget and curl seem to accept that as indicating that nothing more -needs to be downloaded. - - joey@darkstar:~>wget -c http://localhost/~joey/foo -O foo - --2018-11-12 15:57:48-- http://localhost/~joey/foo - Resolving localhost (localhost)... ::1, 127.0.0.1 - Connecting to localhost (localhost)|::1|:80... connected. - HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable - - The file is already fully retrieved; nothing to do. - -Although, it's worth noting that the http server does the same thing -if a range larger than the url's size is requested.. And in this case wget -will behave the same as the above but hasn't actually downloaded the -current content of the file. So this seems like an ugly corner of http -that the two situations cannot be distinguished. - -I suppose I'll make git-annex behave the same as wget and curl do. -"""]] diff --git a/doc/bugs/apparent_regression_in_git_annex_p2p_--pair_usage_of_magic_wormhole_invocation.mdwn b/doc/bugs/apparent_regression_in_git_annex_p2p_--pair_usage_of_magic_wormhole_invocation.mdwn deleted file mode 100644 index 7f5b2c9315..0000000000 --- a/doc/bugs/apparent_regression_in_git_annex_p2p_--pair_usage_of_magic_wormhole_invocation.mdwn +++ /dev/null @@ -1,74 +0,0 @@ -### Please describe the problem. - -git annex p2p --pair does not successfully complete pairing - -### What steps will reproduce the problem? - -- run `git annex p2p --pair` -- optionally run `wormhole receive` on other host, and input pairing code - -### What version of git-annex are you using? On what operating system? - -6.20170101.1 on Debian 9/stretch - -magic wormhole version 0.9.1 - -### Please provide any additional information below. - -[[!format sh """ -git annex init -sudo git annex enable-tor $( id -u ) -git annex p2p --gen-addresses -git annex p2p --debug --pair -"""]] - -[[!format txt """ -p2p pair peer1 (using Magic Wormhole) -[2018-07-04 19:45:28.712958619] chat: wormhole ["receive","--accept-file","--output-file","/tmp/pairedEj5Y/recv"] -[2018-07-04 19:45:28.715141955] chat: wormhole ["send","/tmp/pairedEj5Y/send"] -Sending 105 Bytes file named 'send' -On the other computer, please run: wormhole receive -Wormhole code is: 3-quantity-fracture -"""]] - -Running the "wormhole receive" command gives a local file: -[[!format txt """ -user@chat:/tmp/bar$ wormhole receive -Enter receive wormhole code: 3-quantity-fracture -Receiving file (105 Bytes) into: send -ok? (y/n): y -Receiving (->tcp:10.137.6.42:36089).. -100%|| 105/105 [00:00<00:00, 519B/s] -Received file written to send -user@chat:/tmp/bar$ cat send -XXX -tor-annex::XXX.onion:18055 -"""]] - -and the `p2p --pair` command persists, but does not appear to be accepting input at any stage. - -[[!format txt """ -Sending (<-10.137.6.42:48778).. -100%|| 105/105 [00:00<00:00, 198KB/s] -File sent.. waiting for confirmation -Confirmation received. Transfer complete. -"""]] - -at this point `p2p --pair` seems to hang, but will exit on sigint w/ following error, and there's no need to press enter despite what's printed, not sure if that's annex or wormhole's output): - -[[!format txt """ -^C -Command interrupted: please press Return to quit -"""]] - -I do not see the expected message `Enter receive wormhole code:` message, which I do see when manually re-invoking `wormhole receive --accept-file --output-file /tmp/pairedEj5Y/recv` (in accordance with what `Wormhole.receiveFile` does), so I suspect some version incompatibility relating either to line buffering or pty mode assumed by magic wormhole itself, causing the `p2p --pair` command to wait indefinitely even though the `wormhole receive` process is not able to receive input. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, but not `p2p --pair`. - -`p2p --link` works, including syncing, no problems with the remote daemon itself. - -... and I wouldn't call it luck, i both trust and rely on git annex =) - -> [[fixed|done]] diff --git a/doc/bugs/apparent_regression_in_git_annex_p2p_--pair_usage_of_magic_wormhole_invocation/comment_1_d403b087693d766b8f902c27964268e2._comment b/doc/bugs/apparent_regression_in_git_annex_p2p_--pair_usage_of_magic_wormhole_invocation/comment_1_d403b087693d766b8f902c27964268e2._comment deleted file mode 100644 index e4efcb5b53..0000000000 --- a/doc/bugs/apparent_regression_in_git_annex_p2p_--pair_usage_of_magic_wormhole_invocation/comment_1_d403b087693d766b8f902c27964268e2._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-07-05T15:28:15Z" - content=""" -Thanks much for reporting this bug. It turns out that shortly after I -first implemented this, magic-wormhole switched to outputting that text on -stderr, which defeated git-annex's attempt to extract the code phrase. - -[[!commit 3dd7f450c1968f8bc2b9cc73c701b1f12f7e326a]] fixes the bug. - -Really unfortunate this feature has been broken since almost the beginning. -Especially because pairing with a friend will fail if they have an older -version of git-annex. Added a note about this to the documentation. - -Clearly some better testing of this is needed. Testing network stuff like -this is outside the bounds of git-annex's usual test suite, and perhaps it -needs an additional test suite that is allowed to make network connections. -(testremote is allowed to, but needs the remote to be manually set up, -so this is also outside its scope). Opened [[todo/network_test_suite]] -about this. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner.mdwn b/doc/bugs/assistant_crashes_in_TransferScanner.mdwn deleted file mode 100644 index 175a87c398..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner.mdwn +++ /dev/null @@ -1,38 +0,0 @@ -After updating git annex from version 6.20160613 to 6.20161011 on my Archlinux machine, the assistant crashes while scanning the files for transfer. - -I'm using a v6 repository. My repositories can be synced perfectly on the command line, only the assistant keeps crashing. - -Here is the daemon.log: - -[[!format sh """ -[2016-10-18 11:49:59.482873] main: starting assistant version 6.20161011-ge2dcbe6 -[2016-10-18 11:50:05.181469] TransferScanner: Syncing with annexsyncbackup, origin - - No known network monitor available through dbus; falling back to polling - -From /media/backup/annex-backup/annex - 318e381..9cc5e23 git-annex -> annexsyncbackup/git-annex -(merging annexsyncbackup/git-annex into git-annex...) -From ssh://FOO/annex-sync - 318e381..81ac41f git-annex -> origin/git-annex -(merging origin/git-annex into git-annex...) -(recording state in git...) -To /media/backup/annex-backup/annex - 318e381..a4931de git-annex -> synced/git-annex -To ssh://FOO/annex-sync.git - 318e381..a4931de git-annex -> synced/git-annex -(started...) -[2016-10-18 11:50:12.364643] Committer: Committing changes to git -(recording state in git...) -[2016-10-18 11:50:12.464943] Pusher: Syncing with annexsyncbackup, origin -Everything up-to-date -Everything up-to-date -TransferScanner crashed: fd:47: commitBuffer: invalid argument (invalid character) -[2016-10-18 11:50:15.016862] TransferScanner: warning TransferScanner crashed: fd:47: commitBuffer: invalid argument (invalid character) -"""]] - -[[!meta title="v6 repository problems with filename encoding when not in unicode locale"]] - -> This bug grew to encompass several problems. I believe all of them are -> now [[fixed|done]]. Please reopen a new bug report if you see a problem like this -> with current git-annex. --[[Joey]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_10_420d16e3d5343cf5dcc9dfcbb34689f4._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_10_420d16e3d5343cf5dcc9dfcbb34689f4._comment deleted file mode 100644 index 03ae5c254b..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_10_420d16e3d5343cf5dcc9dfcbb34689f4._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 10""" - date="2016-10-31T20:45:05Z" - content=""" -Was able to reproduce this pattern of output w/o filenames -by throwing an IOError from Command.Sync.syncFile, -in code that is outside of callCommandAction or includeCommandAction block. - -Unfortunately that does not narrow it down -enough to know there the problem lies. -I need a way to reproduce the bug to get any further. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_11_6a5fe92c433ca7b6e66bbb86a16aa3b1._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_11_6a5fe92c433ca7b6e66bbb86a16aa3b1._comment deleted file mode 100644 index f7f4f84f1c..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_11_6a5fe92c433ca7b6e66bbb86a16aa3b1._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="comment 11" - date="2016-10-31T20:59:30Z" - content=""" -Here is the complete log (which, imho, does not give any hint): - -(elided, I appreciate the info, but not needed. --[[Joey]]) -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_12_7c7267ab724b0da325d4cf15e33e6192._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_12_7c7267ab724b0da325d4cf15e33e6192._comment deleted file mode 100644 index ff2cb5c1d2..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_12_7c7267ab724b0da325d4cf15e33e6192._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 12""" - date="2016-10-31T21:16:53Z" - content=""" -Aha! It's something to do with unlocked files in v6 mode. - -Reproduced by unlocking a file, and LANG=C git annex sync --content - -With 1 unlocked file, I see the message twice, which makes sense -given --content's 2 passes. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_13_2ff6938256176b668b7d611a16b7a73e._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_13_2ff6938256176b668b7d611a16b7a73e._comment deleted file mode 100644 index 3413c1dd1f..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_13_2ff6938256176b668b7d611a16b7a73e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 13""" - date="2016-10-31T21:26:52Z" - content=""" -It's getFileNumCopies crashing, where the unlocked worktree -filename contains some non-ascii character. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_14_16d967c0ba173d122f645af2a6a487e6._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_14_16d967c0ba173d122f645af2a6a487e6._comment deleted file mode 100644 index 52b226f7f8..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_14_16d967c0ba173d122f645af2a6a487e6._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 14""" - date="2016-10-31T21:45:37Z" - content=""" -Tracked it back to Git.CheckAttr.checkAttr crashing when it sends the -filename "foö" (note the non-ascii) to the handle. -Which is odd as that handle is in filesystem encoding mode. - -But, I then unlocked an additional file in my repo and it stopped -crashing, and I have yet to reproduce it again. Urgh. - -Also, found an unrelated filename encoding crash: - - LANG=C git annex smudge --clean xx.oök < xx.oök - git-annex: recoverEncode: invalid argument (invalid character) -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_15_d940f66df8aa5850ed9425666ec08185._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_15_d940f66df8aa5850ed9425666ec08185._comment deleted file mode 100644 index bd5f270974..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_15_d940f66df8aa5850ed9425666ec08185._comment +++ /dev/null @@ -1,49 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 15""" - date="2016-11-01T18:04:33Z" - content=""" -Having difficulty reproducing this again. - -However, I did find one way that the git check-attr handle could not be in -raw mode. If for some reason the process was started and crashed, it would -be restarted and not be in raw mode. -Fixed in [[!commit e23028d19b493c7abae0dffb96da44591aacca7b]]. - ----- - -As to the `git annex smudge --clean` encoding problem, here's a full test -case: - - joey@darkstar:/tmp>git init repo3 - Initialized empty Git repository in /tmp/repo3/.git/ - joey@darkstar:/tmp>cd repo3 - joey@darkstar:/tmp/repo3>LANG=en_US.utf8 - joey@darkstar:/tmp/repo3>git annex init --version=6 - init ok - (recording state in git...) - joey@darkstar:/tmp/repo3>touch xx.oöo - joey@darkstar:/tmp/repo3>git annex add xx.oöo - add xx.oöo ok - (recording state in git...) - joey@darkstar:/tmp/repo3>LANG=C - joey@darkstar:/tmp/repo3>git annex unlock xx.oöo - unlock xx.oöo ok - (recording state in git...) - joey@darkstar:/tmp/repo3>git annex smudge --clean xx.oöo < xx.oöo - git-annex: recoverEncode: invalid argument (invalid character) - git-annex: smudge: 1 failed - -Only happens when the filename extension contains unicode, which then becomes part of the key. - -If the unlock is done in a unicode locale, the later smudge succeeds even -when done in LANG=C. - -Dumping the sqlite database, in the problem case, I see mokibake: - - INSERT INTO "associated" VALUES(1,'SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.o��o','"xx.o\56515\56502o"'); - -Compare with the working case: - - INSERT INTO "associated" VALUES(11,'SHA256E-s30--58ed27fa666794aa15b72609483e9b488b984b568d668959136302faa8bb2fde.oöo','good.oöo'); -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_16_0d32f7938c071553c3d3cec2b85ccb4f._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_16_0d32f7938c071553c3d3cec2b85ccb4f._comment deleted file mode 100644 index 574e2891ee..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_16_0d32f7938c071553c3d3cec2b85ccb4f._comment +++ /dev/null @@ -1,56 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="comment 16" - date="2016-11-04T10:27:26Z" - content=""" -FYI, with 20161101 I get the following errors: - - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - fatal: '../home/johannes/annex-sync/Documents/personal/Kontoauszüge/Konto_XXXXXXXXXX-Auszug_2016_016.PDF' is outside repository - - - git-annex: git check-attr EOF: user error - failed - - git-annex: fd:30: hFlush: resource vanished (Broken pipe) - failed - - git-annex: fd:30: hFlush: resource vanished (Broken pipe) - failed - - [...] - - git-annex: fd:30: commitBuffer: resource vanished (Broken pipe) - failed - - git-annex: fd:30: commitBuffer: resource vanished (Broken pipe) - failed - - git-annex: fd:30: hFlush: resource vanished (Broken pipe) - failed - - git-annex: fd:30: commitBuffer: resource vanished (Broken pipe) - failed - - git-annex: fd:30: commitBuffer: resource vanished (Broken pipe) - failed - - [...] - - git-annex: sync: 836 failed - -The `[...]` indicates that the last error appears a lot of times. - -The first (repeated) error might be unrelated though. Note that this is a file I recently added and locked. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment deleted file mode 100644 index 7978244f9a..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="Solution" - date="2017-01-06T12:19:46Z" - content=""" -After the update to 20161231, I tried again. Unfortunately, I am still getting the same error. - -However, I noticed that removing the file for which I get the \"is outside repository\" error actually fixes the problem. Once I dropped the file from the annex as well, I was able to re-add the file without triggering this error again. - -Please consider this issues as fixed. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_1_e626d6fc90a4af8906973121149eef7d._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_1_e626d6fc90a4af8906973121149eef7d._comment deleted file mode 100644 index 514c85a233..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_1_e626d6fc90a4af8906973121149eef7d._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="comment 1" - date="2016-10-19T10:28:13Z" - content=""" -I just noticed that I get the same error when executing `git annex sync --content`. Nevertheless, the following commands are running flawlessly: - -* `git annex sync` -* `git annex get --auto` -* `git annex copy -t origin --auto`. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_2_0beeaa83cbcea07b522c7b274e328a25._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_2_0beeaa83cbcea07b522c7b274e328a25._comment deleted file mode 100644 index c885252ede..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_2_0beeaa83cbcea07b522c7b274e328a25._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-10-26T18:21:13Z" - content=""" -This kind of thing tends to be due to a problem with locales, or a -filename in the repository that can't be represented under the current -locale. - -Just so happens that the version you upgraded to changed how the standalone -tarball for linux handles locales. Did you install using that tarball? - -What does `locale` say? -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_3_a56c8acec75c5862d3a407ffe9a385b3._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_3_a56c8acec75c5862d3a407ffe9a385b3._comment deleted file mode 100644 index 5507091ed4..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_3_a56c8acec75c5862d3a407ffe9a385b3._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="comment 3" - date="2016-10-28T10:17:19Z" - content=""" -Yes, I installed the standalone tarball. - -My locale is set to en_US.utf8, here is what `locale` tells me: - - LANG=en_US.utf8 - LC_CTYPE=\"en_US.utf8\" - LC_NUMERIC=\"en_US.utf8\" - LC_TIME=\"en_US.utf8\" - LC_COLLATE=\"en_US.utf8\" - LC_MONETARY=\"en_US.utf8\" - LC_MESSAGES=\"en_US.utf8\" - LC_PAPER=\"en_US.utf8\" - LC_NAME=\"en_US.utf8\" - LC_ADDRESS=\"en_US.utf8\" - LC_TELEPHONE=\"en_US.utf8\" - LC_MEASUREMENT=\"en_US.utf8\" - LC_IDENTIFICATION=\"en_US.utf8\" - LC_ALL= -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_4_cdc659b30d1cbcfdc9ce0d311ebc52c5._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_4_cdc659b30d1cbcfdc9ce0d311ebc52c5._comment deleted file mode 100644 index fd1be667bb..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_4_cdc659b30d1cbcfdc9ce0d311ebc52c5._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-10-31T18:16:51Z" - content=""" -What is the output when using `git annex sync --content` ? -I know, same basic error as the assistant, but it probably displays -some filenames which will hint at the particular filename it's crashing on. - -Investigating, it looks like there may be a recently -introduced bug in the standalone tarball where it contains -`git-annex.linux/i18n/i18n`. If you move the contents of -`git-annex.linux/i18n/i18n` to `git-annex.linux/i18n`, you might find that -it causes the crash to go away. I'm committing a fix for that problem. - -(I'd still like information about the filename that causes the crash -though, since that same crash could happen if the locale was misconfigured -or if you were using a non-utf8 locale.) -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_5_6565e422393e9c1f40d075af7058020e._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_5_6565e422393e9c1f40d075af7058020e._comment deleted file mode 100644 index eb2e53fa5f..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_5_6565e422393e9c1f40d075af7058020e._comment +++ /dev/null @@ -1,45 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="comment 5" - date="2016-10-31T18:51:17Z" - content=""" -The output of `git annex sync --content` looks like this: - - commit - [master 4b31758] git-annex in new latitude - 1 file changed, 2 insertions(+), 1 deletion(-) - ok - pull annexsyncbackup - ok - pull origin - Enter passphrase for key '/home/johanness/.ssh/id_rsa': - ok - - git-annex: fd:30: commitBuffer: invalid argument (invalid character) - failed - - git-annex: fd:30: commitBuffer: invalid argument (invalid character) - failed - - git-annex: fd:30: commitBuffer: invalid argument (invalid character) - failed - - git-annex: fd:30: commitBuffer: invalid argument (invalid character) - failed - - git-annex: fd:30: commitBuffer: invalid argument (invalid character) - failed - -These lines are repeated a bunch of times. In between git annex successfully uploads and drops a couple of files to/from the remotes. After that it successfully records the state in git and pushes to the remotes finishing with: - - git-annex: sync: 645 failed - -I moved the i18n folder but am still getting the same errors. - -`ls -l /opt/git-annex.linux/i18n`: - - charmaps locales SUPPORTED - -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_6_86389af01aaeabe8eb6c2af26449ec50._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_6_86389af01aaeabe8eb6c2af26449ec50._comment deleted file mode 100644 index dec8161f3d..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_6_86389af01aaeabe8eb6c2af26449ec50._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="SOLVED" - date="2016-10-31T19:08:16Z" - content=""" -I fixed it. It came to my mind that I'm using a rather antiquated PKGBUILD on my ArchLinux system to package the current git-annex tarball. - -(Fortunately, git-annex moved to the community repository a few months ago. Unfortunately, it's not maintained so that I was still using and updating the old PKGBUILD from the Archlinux User Repository (AUR).) - -Turned out this PKGBUILD removed some executables from the tarball. When I unpack the unmodified tarball, git annex works perfectly. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_7_d39a75177cc8fda77f3b4bcda6129a12._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_7_d39a75177cc8fda77f3b4bcda6129a12._comment deleted file mode 100644 index 262451a471..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_7_d39a75177cc8fda77f3b4bcda6129a12._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2016-10-31T19:26:38Z" - content=""" -Ok so you're using that monstrosity where Arch repackages the git-annex -standalone tarball into an Arch package? I never liked that because it's -prone to this kind of breakage. AIUI, `pacman -S git-annex` will install -a proper from-source build of git-annex and is the right thing to use. - -Anyway, I'm still wanting to get to the bottom of the problem -since as I noted the same problem could occur if using a non-UTF8 locale. - -Did you leave out the filenames from the `git annex sync` output, -or is it actually not printing any filenames there? It's very hard for me -to understand output where some lines have been left out. It's fine -if you replace all ASCII characters in your filenames with `X` in the paste -you share. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_8_099d19ffa8f769b69807fd2f39f77ed3._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_8_099d19ffa8f769b69807fd2f39f77ed3._comment deleted file mode 100644 index 56d8166627..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_8_099d19ffa8f769b69807fd2f39f77ed3._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2" - nickname="johannes" - avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c" - subject="comment 8" - date="2016-10-31T19:50:23Z" - content=""" -It's not printing any filenames. I modified my old PKGBUILD to create a package that only wraps the /opt/git-annex.linux directory. It still left me with the same error. I first suspected the Archlinux packaging of modifying the binaries in some awkward manner. But guess what, it's caused by the restrictive file/directory permissions on /opt/git-annex.linux. - -So here is how I can reproduce the error: - -- Step 1: Extract the git-annex standalone tarball to /opt/. -- Step 2: Change the owner and group of /opt/git-annex.linux to `root` (`chown -R root:root /opt/git-annex.linux`). - -So, what happens here? On the first execution of git-annex, it creates a `locales` directory in /opt/git-annex.linux. If the permissions are too restrictive, it silently fails to do that. I get the above error messages if the locales directory is not initialised. -"""]] diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_9_941f1a2911f25e74b0f610b5dbc9641c._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_9_941f1a2911f25e74b0f610b5dbc9641c._comment deleted file mode 100644 index 3570410e20..0000000000 --- a/doc/bugs/assistant_crashes_in_TransferScanner/comment_9_941f1a2911f25e74b0f610b5dbc9641c._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 9""" - date="2016-10-31T20:17:59Z" - content=""" -You say it prints no filenames, but earlier you said: "In between git annex -successfully uploads and drops a couple of files to/from the remotes." -... Which sounds like it must be printing some filenames. - -Even when I make the standalone tarball owned by root, and move all -system-wide locale files out of the way, I still can't reproduce this. -So I think it must have something to do with the filenames in your git -repository, or something else particular to your git repository. -"""]] diff --git a/doc/bugs/assistant_ignores_foreground_switch.mdwn b/doc/bugs/assistant_ignores_foreground_switch.mdwn deleted file mode 100644 index b4e50ddba2..0000000000 --- a/doc/bugs/assistant_ignores_foreground_switch.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. - -git annex assistant ignores the --foreground switch: - -``` -florian@marduk ~ % /usr/bin/git-annex assistant --foreground --autostart -git-annex autostart in /home/florian/.synced_configuration -ok -florian@marduk ~ % -``` - -The assistant ist started, but forks to background. This also breaks the systemd unit from https://git-annex.branchable.com/tips/Systemd_unit/ (add Type=forking to the service works around that) - -It seems to be connected to the autostart option, without --autostart it does not go background. - -### What steps will reproduce the problem? - - -### What version of git-annex are you using? On what operating system? - -6.20170101-15 at Arch. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -> Made it support this combination of switches. [[done]] --[[Joey]] diff --git a/doc/bugs/assistant_ignores_foreground_switch/comment_1_d9c812d6ea52e9fd45a7aed94921dc8a._comment b/doc/bugs/assistant_ignores_foreground_switch/comment_1_d9c812d6ea52e9fd45a7aed94921dc8a._comment deleted file mode 100644 index ab7dbb2e42..0000000000 --- a/doc/bugs/assistant_ignores_foreground_switch/comment_1_d9c812d6ea52e9fd45a7aed94921dc8a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-02-07T17:10:05Z" - content=""" ---autostart can start multiple daemons, one per registered repository. - -So, --autostart --foreground would need to start the daemons and child -processes, and then wait on them all. -"""]] diff --git a/doc/bugs/automatically_adding_metadata_fails_on_files_with_UTF-8_umlauts.mdwn b/doc/bugs/automatically_adding_metadata_fails_on_files_with_UTF-8_umlauts.mdwn deleted file mode 100644 index ba55b41d17..0000000000 --- a/doc/bugs/automatically_adding_metadata_fails_on_files_with_UTF-8_umlauts.mdwn +++ /dev/null @@ -1,70 +0,0 @@ -### Please describe the problem. -The recommended hook script does silently ignore files with non-ascii filenames. - -### What steps will reproduce the problem? -see below. - -### What version of git-annex are you using? On what operating system? -git-annex version: 6.20180112 -on NixOS i686 - -### Please provide any additional information below. -[[!format txt """ -[woffs@lapdoepp:/tmp] $ git init test -Leeres Git-Repository in /tmp/test/.git/ initialisiert - -[woffs@lapdoepp:/tmp] $ cd test -[woffs@lapdoepp:/tmp/test] (master #) $ git annex init -init ok -(recording state in git...) -[woffs@lapdoepp:/tmp/test] (master #) $ git config metadata.exiftool "CreateDate Model ImageSize FocusRange GPS FileType: NominalBitrate Title Artist Album Date: TrackNumber Year"l "CreateDate Model ImageSize FocusRange GPS FileType: NominalBitrate Title Artist Album Date: TrackNum - [woffs@lapdoepp:/tmp/test] (master #) $ git config annex.genmetadata true - [woffs@lapdoepp:/tmp/test] (master #) $ wget -O ./.git/hooks/pre-commit-annex http://git-annex.branchable.com/tips/automatically_adding_metadata/pre-commit-annex ---2018-02-26 10:28:42-- http://git-annex.branchable.com/tips/automatically_adding_metadata/pre-commit-annex -Auflösen des Hostnamens git-annex.branchable.com (git-annex.branchable.com)… 66.228.46.55, 2600:3c03::f03c:91ff:fedf:c0e5 -Verbindungsaufbau zu git-annex.branchable.com (git-annex.branchable.com)|66.228.46.55|:80 … verbunden. -HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK -Länge: 3035 (3,0K) -Wird in »./.git/hooks/pre-commit-annex« gespeichert. - -./.git/hooks/pre-commit-annex 100%[=====================================================================================>] 2,96K --.-KB/s in 0s - -2018-02-26 10:28:42 (75,8 MB/s) - »./.git/hooks/pre-commit-annex« gespeichert [3035/3035] - - [woffs@lapdoepp:/tmp/test] (master #) $ chmod +x ./.git/hooks/pre-commit-annex - wget http://git-a[woffs@lapdoepp:/tmp/test] (master #) $ wget http://git-annex.branchable.com/logo_small.png ---2018-02-26 10:28:52-- http://git-annex.branchable.com/logo_small.png -Auflösen des Hostnamens git-annex.branchable.com (git-annex.branchable.com)… 66.228.46.55, 2600:3c03::f03c:91ff:fedf:c0e5 -Verbindungsaufbau zu git-annex.branchable.com (git-annex.branchable.com)|66.228.46.55|:80 … verbunden. -HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK -Länge: 4749 (4,6K) [image/png] -Wird in »logo_small.png« gespeichert. - -logo_small.png 100%[=====================================================================================>] 4,64K --.-KB/s in 0s - -2018-02-26 10:28:52 (108 MB/s) - »logo_small.png« gespeichert [4749/4749] - - [woffs@lapdoepp:/tmp/test] (master #%) $ cp logo_small.png lögö_smäll.png -[woffs@lapdoepp:/tmp/test] (master #%) $ git annex add -add logo_small.png ok -add lögö_smäll.png ok -(recording state in git...) -[woffs@lapdoepp:/tmp/test] (master +) $ git annex sync -commit -adding metadata for logo_small.png -(recording state in git...) -[master (Basis-Commit) e3f8647] git-annex in woffs@lapdoepp:/tmp/test - 2 files changed, 2 insertions(+) - create mode 120000 logo_small.png - create mode 120000 "l\303\266g\303\266_sm\303\244ll.png" -ok - -[woffs@lapdoepp:/tmp/test] (master) $ -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -git annex is great. :) - -> [[fixed|done]]; caused by git diff-index defaulting to not emitting such -> characters, got it to by using -z. --[[Joey]] diff --git a/doc/bugs/aws_0.16_breaking_changes.mdwn b/doc/bugs/aws_0.16_breaking_changes.mdwn deleted file mode 100644 index e03180c347..0000000000 --- a/doc/bugs/aws_0.16_breaking_changes.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -### Please describe the problem. -aws-0.16 and 0.15.1 were just released. 0.16 has breaking changes. - -### What steps will reproduce the problem? -Try to build git-annex with the S3 flag with aws-0.16. - -Note that git-annex builds successfully with 0.15.1, and that 0.15 has its own problems since it constrains xml-conduit to < 1.4, which fails unless blaze-markup is also contrained to < 0.8.0.0. This is resolved by using 0.15.1 since it lifted the contraint on xml-conduit to < 1.5. - -### What version of git-annex are you using? On what operating system? -6.20170101 on macOS - -### Please provide any additional information below. -The build failure is -[[!format sh """ -[323 of 546] Compiling Remote.Glacier ( Remote/Glacier.hs, dist/dist-sandbox-8fbcd4b9/build/git-annex/git-annex-tmp/Remote/Glacier.o ) -[324 of 546] Compiling Remote.Helper.Http ( Remote/Helper/Http.hs, dist/dist-sandbox-8fbcd4b9/build/git-annex/git-annex-tmp/Remote/Helper/Http.o ) -[325 of 546] Compiling Remote.S3 ( Remote/S3.hs, dist/dist-sandbox-8fbcd4b9/build/git-annex/git-annex-tmp/Remote/S3.o ) - -Remote/S3.hs:224:49: error: - • The constructor ‘S3.UploadPartResponse’ should have 1 argument, but has been given 2 - • In the pattern: S3.UploadPartResponse _ etag - In a stmt of a 'do' block: - S3.UploadPartResponse _ etag <- sendS3Handle h req - In the expression: - do { let sz = ...; - let p' = offsetMeterUpdate p (toBytesProcessed pos); - let numchunks - = ceiling - (fromIntegral sz / fromIntegral defaultChunkSize :: Double); - let popper = handlePopper numchunks defaultChunkSize p' fh; - .... } -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-6.20170101 failed during the building phase. The exception was: -ExitFailure 1 -/usr/local/Homebrew/Library/Homebrew/debrew.rb:11:in `raise' -BuildError: Failed executing: cabal install --jobs=8 --max-backjumps=100000 --prefix=/usr/local/Cellar/git-annex/6.20170101_1 --flags=s3\ webapp -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! - -> [[fixed|done]] thanks --[[Joey]] diff --git a/doc/bugs/aws_0.16_breaking_changes/comment_1_32b0d5d388f2925335a4dd83bae228c7._comment b/doc/bugs/aws_0.16_breaking_changes/comment_1_32b0d5d388f2925335a4dd83bae228c7._comment deleted file mode 100644 index b4afc0a48c..0000000000 --- a/doc/bugs/aws_0.16_breaking_changes/comment_1_32b0d5d388f2925335a4dd83bae228c7._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="aristidb@4551cc1215222a56e271a796b92908680f3941b5" - nickname="aristidb" - avatar="http://cdn.libravatar.org/avatar/64e6cb35f87f56a7f13bac236afff510" - subject="comment 1" - date="2017-02-05T12:29:27Z" - content=""" -As explained in my duplicate report on : - -I suggest switching to {} pattern matching, like this: - -[[!format haskell \"\"\" -S3.UploadPartResponse { S3.uprEtag = etag } <- sendS3Handle h req -\"\"\"]] - -"""]] diff --git a/doc/bugs/aws_0.16_breaking_changes/comment_2_067794ef74712b4d6071df1ef5f3b314._comment b/doc/bugs/aws_0.16_breaking_changes/comment_2_067794ef74712b4d6071df1ef5f3b314._comment deleted file mode 100644 index 986d3002f4..0000000000 --- a/doc/bugs/aws_0.16_breaking_changes/comment_2_067794ef74712b4d6071df1ef5f3b314._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="aristidb@4551cc1215222a56e271a796b92908680f3941b5" - nickname="aristidb" - avatar="http://cdn.libravatar.org/avatar/64e6cb35f87f56a7f13bac236afff510" - subject="comment 2" - date="2017-02-05T12:49:22Z" - content=""" -I made a typo in my previous response: It should be ETag, not Etag. Corrected: - -[[!haskell \"\"\" -S3.UploadPartResponse { S3.uprETag = etag } <- sendS3Handle h req -\"\"\"] -"""]] diff --git a/doc/bugs/bash__58___git-annex-shell__58___command_not_found.mdwn b/doc/bugs/bash__58___git-annex-shell__58___command_not_found.mdwn deleted file mode 100644 index cc784bd2d3..0000000000 --- a/doc/bugs/bash__58___git-annex-shell__58___command_not_found.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -### Please describe the problem. - -I run a script (via cron) to sync my various git-annex repositories. Recently, I noticed the following error message (which I'd not seen before): - - bash: git-annex-shell: command not found - -I can't say for certain when it first appeared, but I first noticed it after recently upgrading to git-annex 6.20170519. - -### What steps will reproduce the problem? - - git annex sync -J5 - -(or using any other 'jobs' option via -Jx or --jobs=x, including setting 'jobs' to '1') - -### What version of git-annex are you using? On what operating system? - -6.20170519 on MacOS Sierra (installed via homebrew) - -### Please provide any additional information below. - -git annex sync (without a 'jobs' option) does not produce the error message. - -In the sample transcripts below, RAID10 is a local drive. unraid, manuel & drobo are all accessed via ssh. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -[tom:~/annex/dl] git annex sync -J1 -On branch master -nothing to commit, working tree clean -commit ok -bash: git-annex-shell: command not found -pull RAID10 ok -pull unraid ok -pull manuel ok -pull drobo ok - -[tom:~/annex/dl] git annex sync -commit -On branch master -nothing to commit, working tree clean -ok -pull RAID10 -ok -pull unraid -ok -pull manuel -ok -pull drobo -ok - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I've used git-annex for well over a year, syncing multiple repositories, without a problem. I don't know how I ever got along without it! :-) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/bash__58___git-annex-shell__58___command_not_found/comment_1_461a8d85738d63f9d276bb33d5c24255._comment b/doc/bugs/bash__58___git-annex-shell__58___command_not_found/comment_1_461a8d85738d63f9d276bb33d5c24255._comment deleted file mode 100644 index fda3bdf3c3..0000000000 --- a/doc/bugs/bash__58___git-annex-shell__58___command_not_found/comment_1_461a8d85738d63f9d276bb33d5c24255._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-06-06T16:21:53Z" - content=""" -One of the remotes of your repository is on a host -where git-annex-shell is either not installed, or perhaps -it is installed but `ssh thehost git-annex-shell` does not -work -- eg due to the problem decribed in -[[tips/get_git-annex-shell_into_PATH]]. - -There was indeed a change in 6.20170519 that explains why this -only happens in -J mode. [[!commit 6992fe133b37ec6d64498f3dd2c69613c4c37469]] -made it run git-annex-shell at startup in that mode. - -Hmm, I suppose one of your remotes could intentionally not have -git-annex-shell on it, and yet you'd still want `git annex sync` -to work to it, and so this message about git-annex-shell -being displayed is not ideal. - -So, I've made it skip trying to run git-annex-shell in this case unless -the remote has an annex-uuid set. If the remote has never had -git-annex-shell installed, it can't have an annex-uuid set. - -And, when it does fail to run git-annex-shell, I've made it say which -remote it was unable to run it on. -"""]] diff --git a/doc/bugs/btshowmetainfo_required_although_built_with_torrentparser.mdwn b/doc/bugs/btshowmetainfo_required_although_built_with_torrentparser.mdwn deleted file mode 100644 index 23e066ccdb..0000000000 --- a/doc/bugs/btshowmetainfo_required_although_built_with_torrentparser.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -A simple typo is causing this: https://github.com/dotlambda/git-annex/commit/a46eadab78efef81825302fc0de7963a46fc3b52 - -> Patch applied, thank you. [[done]] --[[Joey]] diff --git a/doc/bugs/build_failure_on_macOS_10.14.6.mdwn b/doc/bugs/build_failure_on_macOS_10.14.6.mdwn deleted file mode 100644 index 3e6c7cb7c5..0000000000 --- a/doc/bugs/build_failure_on_macOS_10.14.6.mdwn +++ /dev/null @@ -1,75 +0,0 @@ -### Please describe the problem. - - -Working to update the macOS Homebrew Formula for git-annex 7.20191009 and I'm receiving a build error using the Homebrew build system to build via ghc 8.6.5 on macOS 10.14.6: - -[[!format sh """ -[ 70 of 624] Compiling Utility.Shell ( Utility/Shell.hs, dist/dist-sandbox-11319d3/build/git-annex/git-annex-tmp/Utility/Shell.o ) -[ 71 of 624] Compiling Git.Types ( Git/Types.hs, dist/dist-sandbox-11319d3/build/git-annex/git-annex-tmp/Git/Types.o ) -[ 72 of 624] Compiling Utility.FileSystemEncoding ( Utility/FileSystemEncoding.hs, dist/dist-sandbox-11319d3/build/git-annex/git-annex-tmp/Utility/FileSystemEncoding.o ) -[ 73 of 624] Compiling Utility.Base64 ( Utility/Base64.hs, dist/dist-sandbox-11319d3/build/git-annex/git-annex-tmp/Utility/Base64.o ) -[ 74 of 624] Compiling Utility.Aeson ( Utility/Aeson.hs, dist/dist-sandbox-11319d3/build/git-annex/git-annex-tmp/Utility/Aeson.o ) -[ 75 of 624] Compiling Types.Messages ( Types/Messages.hs, dist/dist-sandbox-11319d3/build/git-annex/git-annex-tmp/Types/Messages.o ) -[ 76 of 624] Compiling Database.Handle ( Database/Handle.hs, dist/dist-sandbox-b74b6b12/build/git-annex/git-annex-tmp/Database/Handle.o ) - -Database/Handle.hs:273:28: error: - • Could not deduce (BackendCompatible SqlBackend backend) - arising from a use of ‘close'’ - from the context: (IsPersistBackend backend, - BaseBackend backend ~ SqlBackend) - bound by the type signature for: - closeRobustly :: forall backend. - (IsPersistBackend backend, BaseBackend backend ~ SqlBackend) => - backend -> IO () - at Database/Handle.hs:(260,1)-(263,16) - • In the second argument of ‘($)’, namely ‘close' conn’ - In a stmt of a 'do' block: r <- try $ close' conn - In the expression: - do r <- try $ close' conn - case r of - Right () -> return () - Left ex@(Sqlite.SqliteException {Sqlite.seError = e}) - | e == Sqlite.ErrorBusy -> do ... - | otherwise -> rethrow "while closing database connection" ex - | -273 | r <- try $ close' conn - | ^^^^^^^^^^^ -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-7.20191009-KZnzbjdUc2rE3oBBwl75Ho failed during the building phase. -The exception was: -ExitFailure 1 -"""]] - -Is this an artifact of ghc 8.6.5 vs 8.8.1? - -### What steps will reproduce the problem? - -Updated the Homebrew Formula with the appropriate changes. - -[[!format sh """ -# brew install ghc@8.6 -# brew install --verbose --build-bottle git-annex` -"""]] - -### What version of git-annex are you using? On what operating system? - -git-annex 7.20191009 -macOS 10.14.6 -The Glorious Glasgow Haskell Compilation System, version 8.6.5 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -git-annex has been awesome for managing a massive collection of raw images and video clips across several storage targets and editing systems. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/build_failure_on_macOS_10.14.6/comment_1_f7cd45b9132e5929f216918b0c7fdb03._comment b/doc/bugs/build_failure_on_macOS_10.14.6/comment_1_f7cd45b9132e5929f216918b0c7fdb03._comment deleted file mode 100644 index 2c9b7ecf42..0000000000 --- a/doc/bugs/build_failure_on_macOS_10.14.6/comment_1_f7cd45b9132e5929f216918b0c7fdb03._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="nrg@bd619d1ebf16e6324c546adea8be8fe1cc2b4325" - nickname="nrg" - avatar="http://cdn.libravatar.org/avatar/428b6c95b52769cf9eecdd351018eacb" - subject="Issue is with persistent > 2.9.2" - date="2019-10-17T13:30:28Z" - content=""" -The build issue is with a change in persistent >= 2.10.0. -persistent >= 2.8.1 && <= 2.9.2 resolves the build issue. -"""]] diff --git a/doc/bugs/build_failure_on_macOS_10.14.6/comment_2_da885d7d887035852d325a7427eba69e._comment b/doc/bugs/build_failure_on_macOS_10.14.6/comment_2_da885d7d887035852d325a7427eba69e._comment deleted file mode 100644 index d8c1cb9d67..0000000000 --- a/doc/bugs/build_failure_on_macOS_10.14.6/comment_2_da885d7d887035852d325a7427eba69e._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2019-10-17T15:04:29Z" - content=""" -Thank you for maintaining the homebrew build, and for tracking down the -persistent version. - -I've fixed this now, and will be making a new git-annex release today. - -FWIW, git-annex.cabal intentionally doesn't pin higher bounds of library -versions. My thinking is that people who want a build pinned at known -working versions should use stack to build, while people who are building -with cabal tend to be the kind of people who are integrating git-annex with -a larger system, and will probably want to build with whatever library -versions shipped with their system (eg in a linux distribution), or -with the latest and greatest. - -That does mean that everyone building with cabal is likely to run into this -kind of breakage now and then, rather than me not noticing it until I update -the pinned versions. Kind of offloading a bit of the work from me onto users, -I have to admit. - -You can of course patch git-annex.cabal to use an older version if -necessary. -"""]] diff --git a/doc/bugs/can__39__t_launch_assistant_on_latest_OSX_build.mdwn b/doc/bugs/can__39__t_launch_assistant_on_latest_OSX_build.mdwn deleted file mode 100644 index 0f11ddbb12..0000000000 --- a/doc/bugs/can__39__t_launch_assistant_on_latest_OSX_build.mdwn +++ /dev/null @@ -1,59 +0,0 @@ -### Please describe the problem. -I can't launch the Assistant on the latest OSX build. Also mentioned by a user at [install/OSX](http://git-annex.branchable.com/install/OSX/). - -I can launch the assistant fine with `6.20180409-gfb0780266` - -### What steps will reproduce the problem? -Download git-annex.dmg (6.20180430-g393fc79d5) and copy to /Applications folder - -Add `/Applications/git-annex.app/Contents/MacOS` to bash path - -Run `git-annex-webapp` from command-line: - - andrew@bumblebee ~$ git-annex-webapp - andrew@bumblebee ~$ uname: illegal option -- o - usage: uname [-amnprsv] - git-annex: user error (uname ["-o"] exited 1) - WebApp crashed: user error (uname ["-o"] exited 1) - [2018-05-04 09:32:07.67968] WebApp: warning WebApp crashed: user error (uname ["-o"] exited 1) - -### What version of git-annex are you using? On what operating system? -macOS Sierra 10.12.6 - -git-annex version: 6.20180430-g393fc79d5 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -andrew@bumblebee ~$ which git-annex-webapp -/Applications/git-annex.app/Contents/MacOS/git-annex-webapp -andrew@bumblebee ~$ git-annex version -git-annex version: 6.20180430-g393fc79d5 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -andrew@bumblebee ~$ git-annex-webapp -andrew@bumblebee ~$ uname: illegal option -- o -usage: uname [-amnprsv] -git-annex: user error (uname ["-o"] exited 1) -WebApp crashed: user error (uname ["-o"] exited 1) -[2018-05-04 09:32:07.67968] WebApp: warning WebApp crashed: user error (uname ["-o"] exited 1) - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yup! git-annex is great! Thanks for all your hard work on this project Joey!! - -—Andrew - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/cannot_talk_with_nextcloud_server.mdwn b/doc/bugs/cannot_talk_with_nextcloud_server.mdwn deleted file mode 100644 index 84f1841656..0000000000 --- a/doc/bugs/cannot_talk_with_nextcloud_server.mdwn +++ /dev/null @@ -1,134 +0,0 @@ -### Please describe the problem. - -I get a "Method not allowed" error when talking through WebDAV with a Nextcloud server hosted in a subdirectory. - -### What steps will reproduce the problem? - -I have configured the remote as a WebDAV server with the instructions -from [[special_remotes/webdav]], that is: - - $ WEBDAV_USERNAME=anarcat WEBDAV_PASSWORD=REDACTED git annex initremote example.net type=webdav url=https://example.net/nextcloud/remote.php/webdav/ encryption=none --verbose --debug - initremote example.net (testing WebDAV server...) - git-annex: WebDAV test failed: HttpExceptionRequest Request { - host = "example.net" - port = 443 - secure = True - requestHeaders = [("Authorization",""),("User-Agent","hDav-using application")] - path = "/" - queryString = "" - method = "MKCOL" - proxy = Nothing - rawBody = False - redirectCount = 10 - responseTimeout = ResponseTimeoutDefault - requestVersion = HTTP/1.1 - } - (StatusCodeException (Response {responseStatus = Status {statusCode = 405, statusMessage = "Method Not Allowed"}, responseVersion = HTTP/1.1, responseHeaders = [("Date","Sun, 07 Oct 2018 17:56:27 GMT"),("Server","Apache"),("Strict-Transport-Security","max-age=15768000"),("Allow","HEAD,HEAD,GET,HEAD,POST,OPTIONS"),("Content-Length","292"),("Content-Type","text/html; charset=iso-8859-1")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "\n\n405 Method Not Allowed\n\n

Method Not Allowed

\n

The requested method MKCOL is not allowed for the URL /index.html.

\n
\n
Apache Server at example.net Port 443
\n\n"): user error - failed - git-annex: initremote: 1 failed - -I have tried with and without chunking and with and without extra -paths (existing or not) in the `url` parameter. - -I was able to successfully use `rclone` to configure the remote, with -the following config: - - [example-nextcloud] - type = webdav - url = https://example.net/nextcloud/remote.php/webdav/ - vendor = nextcloud - user = anarcat - pass = *** ENCRYPTED *** - -`rclone ls` then works, which proves that Nextcloud is not -misbehaving. I can also create a rclone remote and git-annex is able -to store stuff on the nextcloud server through there: - - $ git annex initremote rclone type=external externaltype=rclone target=example-nextcloud prefix=git-annex encryption=none rclone_layout=lower - initremote rclone ok - (recording state in git...) - $ git annex copy --to rclone - copy test.txt 2018/10/07 13:31:45 ERROR : : error listing: directory not found 2018/10/07 13:31:45 Failed to size: directory not found - (to rclone...) - ok - (recording state in git...) - -The error message is actually just a warning and the directory is -created automatically. I checked and the file is present on the remote so rclone (and therefore webdav) works. Thunar can also browse the host as a Webdav remote without problems. - -Unfortunately, the rclone remote doesn't support [[git-annex-export]] -which makes it unusable for my use case (a publicly visible gallery -instead of a backup). - -### What version of git-annex are you using? On what operating system? - -Vanilla Debian buster package: - -[[!format txt """ -$ git annex version -git-annex version: 6.20180913 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -local repository version: 5 -"""]] - -The server is running Nextcloud 14 on Debian stable, I assume. I have checked and Nextcloud definitely [supports](https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html) the MKCOL verb. - -### Please provide any additional information below. - -Here's the debug output when creating the remote. It seems it fails on -the `MKCOL` verb, which is denied by the server: - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$ WEBDAV_USERNAME=anarcat WEBDAV_PASSWORD=REDACTED git annex initremote example.net type=webdav url=https://example.net/nextcloud/remote.php/webdav/ encryption=none --verbose --debug -[2018-10-07 13:22:30.794584586] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2018-10-07 13:22:30.797203114] process done ExitSuccess -[2018-10-07 13:22:30.79734081] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2018-10-07 13:22:30.799738604] process done ExitSuccess -[2018-10-07 13:22:30.800004526] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..6f8555ce9bda4c1a0e8f1cfdb5652a868f6bfd53","--pretty=%H","-n1"] -[2018-10-07 13:22:30.803058278] process done ExitSuccess -[2018-10-07 13:22:30.803540459] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2018-10-07 13:22:30.811553668] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] -initremote example.net (testing WebDAV server...) [2018-10-07 13:22:32.999000982] getProps / -[2018-10-07 13:22:33.202572045] mkCol / - -git-annex: WebDAV test failed: HttpExceptionRequest Request { - host = "example.net" - port = 443 - secure = True - requestHeaders = [("Authorization",""),("User-Agent","hDav-using application")] - path = "/" - queryString = "" - method = "MKCOL" - proxy = Nothing - rawBody = False - redirectCount = 10 - responseTimeout = ResponseTimeoutDefault - requestVersion = HTTP/1.1 -} - (StatusCodeException (Response {responseStatus = Status {statusCode = 405, statusMessage = "Method Not Allowed"}, responseVersion = HTTP/1.1, responseHeaders = [("Date","Sun, 07 Oct 2018 17:22:33 GMT"),("Server","Apache"),("Strict-Transport-Security","max-age=15768000"),("Allow","HEAD,HEAD,GET,HEAD,POST,OPTIONS"),("Content-Length","292"),("Content-Type","text/html; charset=iso-8859-1")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "\n\n405 Method Not Allowed\n\n

Method Not Allowed

\n

The requested method MKCOL is not allowed for the URL /index.html.

\n
\n
Apache Server at example.net Port 443
\n\n"): user error -failed -[2018-10-07 13:22:33.235310398] process done ExitSuccess -[2018-10-07 13:22:33.235869777] process done ExitSuccess -git-annex: initremote: 1 failed -# End of transcript or log. -"""]] - -Notice how the server is hosted on a subdirectory of `example.net` (a placeholder name of course, my hosting provide wants to stay private ;). Maybe that's the problem? The error message says `MKCOL is not allowed for the URL /index.html`, so that is probably `example.net/index.html` responding. I suspect it's failing to do `getProps /` right before and assumes the WebDAV server does not have a root directory (which makes no sense - the Nextcloud server endpoint is actually at `/nextcloud/remote.php/webdav`). I would argue that `getProps /` should never fail or rather, we should *assume* the server is hosted in a subdirectory in that case. - -Incidentally, the [[tips/owncloudannex]] remote also [fails](https://github.com/TobiasTheViking/owncloudannex/issues/5), but at the upload stage - it gives a 500 error message. But since it doesn't support the `exporttree` functionality, it's out of the question here as well. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I use git-annex every day! I hope to write a glowing review for LWN soon. ;) Cheers and hi joey! :) -- [[anarcat]] - -> So the problem is code was changed a while ago to `mkColRecursive "/"` -> which causes this wacky attempt to mkcol at the top of the server not -> underneath the path of the url. [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/cannot_talk_with_nextcloud_server/comment_1_88c3db7c862580da5c4ea0c29989c08b._comment b/doc/bugs/cannot_talk_with_nextcloud_server/comment_1_88c3db7c862580da5c4ea0c29989c08b._comment deleted file mode 100644 index 0eb0dca011..0000000000 --- a/doc/bugs/cannot_talk_with_nextcloud_server/comment_1_88c3db7c862580da5c4ea0c29989c08b._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-10-08T16:05:29Z" - content=""" -So are you saying this webdav server responds with an error when a -directory creation is attempted, but auto-creates directories as needed for -puts? - -Is that allowed by the webdav spec? -"""]] diff --git a/doc/bugs/cannot_talk_with_nextcloud_server/comment_2_6be3c252fac86e58affd2910ec0f3c22._comment b/doc/bugs/cannot_talk_with_nextcloud_server/comment_2_6be3c252fac86e58affd2910ec0f3c22._comment deleted file mode 100644 index 0ae3b8db1a..0000000000 --- a/doc/bugs/cannot_talk_with_nextcloud_server/comment_2_6be3c252fac86e58affd2910ec0f3c22._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7" - subject="comment 2" - date="2018-10-09T21:49:02Z" - content=""" -> So are you saying this webdav server responds with an error when a directory creation is attempted, - -well, not quite. the *webserver* responds with that error because git-annex tries to create https://example.net/ - it does not hit the nextcloud webdav endpoint, which is at https://example.net/nextcloud/remote.php/webdav - -> but auto-creates directories as needed for puts? -> -> Is that allowed by the webdav spec? - -I don't think it autocreates directories at all. The problem is `getProps /` fails because there's no webdav server at the root of the FWDN - it's in a sub-sub-directory instead.... -"""]] diff --git a/doc/bugs/cannot_talk_with_nextcloud_server/comment_3_f4163aeca38202707721299471f40e0b._comment b/doc/bugs/cannot_talk_with_nextcloud_server/comment_3_f4163aeca38202707721299471f40e0b._comment deleted file mode 100644 index 698be03762..0000000000 --- a/doc/bugs/cannot_talk_with_nextcloud_server/comment_3_f4163aeca38202707721299471f40e0b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7" - subject="thanks!" - date="2019-01-06T04:12:03Z" - content=""" -I confirm this is fixed - thanks! This makes exporttree, the webdav endpoint, and so many more things finally make sense to me! :) -"""]] diff --git a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly.mdwn b/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly.mdwn deleted file mode 100644 index fc098bb84b..0000000000 --- a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -
-
-***** summary
-
-if I run sync, and there is an annex-less git remote in the network
-the annex-less git repo will gain a v5 annex branch
-it knows it can't store binary files
-but all the properly initialized annex repos in the network don't know that
-
-when I run "sync --content",
-the initialized annex repos think that the uninitialized repo contains copies.
-
-I suspect this results in inaccurate "copies" count
-I know it results in an inaccurate "list files' location" graph
-and also inaccurate "whereis" readout
-
-***** reproduction
-
-repo "Alpha" is a git-annex repo with file "music"
-repo "Zeta" is a git repo cloned from Alpha
-
-@Alpha:
-git annex sync --content
-git annex list
-[shows music present on Zeta]
-git annex whereis
-[shows music present on Zeta]
-
-@Zeta
-git annex list
-[shows nothing]
-git annex whereis
-[shows music present on Zeta]
-
-***** proving that the problem is "sync --content"
-
-Hypothesis:
-
-maybe the issue is that I cloned the repo
-rather than creating it normally,
-thus leaving it in a half-annexed state?
-
-Experiment:
-
-tested by creating an independent git repo
-and then adding it as a remote to Alpha.
-
-then ran sync --content
-
-Result:
-
-no different than before.
-
-Conclusion:
-
-The problem lies with 
-git-annex sync --content
-
-***** ramifications
-
-It would appear this error can cause data loss
-due to a false numcopies count.
-
-Yet GitHub is supposed to work.
-So this error should've already been noticed.
-Contradiction detected.
-
-Positivity: I am planning on becoming a git-annex evangelist as part of a larger project.
-Emacs offers ergonomic control via magit and a dired plugin.
-
-***** environment
-
-git-annex version: 6.20170301-ga9e1e17d40
-build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-local repository version: unknown
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-operating system: linux x86_64
-
-
- -> [[done]] appears to be a confused user, not a bug. --[[Joey]] diff --git a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_1_6e85b0122fca46b9232f8fd34e8c9f6d._comment b/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_1_6e85b0122fca46b9232f8fd34e8c9f6d._comment deleted file mode 100644 index 16ab9423f0..0000000000 --- a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_1_6e85b0122fca46b9232f8fd34e8c9f6d._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="Cyberthal" - avatar="http://cdn.libravatar.org/avatar/1c619d65ee07d2343295c8f70f23c9df" - subject="knowing about annex-ignore and git-annex shell helps" - date="2017-03-26T10:06:35Z" - content=""" -When I wrote the above, -I was unaware of the annex-ignore flag -which can avert the above issue. - -This flag should've been automatically set. - -Also, I learned about the need for git-annex shell -which must be available at the default path -of remote servers. -"""]] diff --git a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_2_13989894486a9ff9f243c6b2071d788f._comment b/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_2_13989894486a9ff9f243c6b2071d788f._comment deleted file mode 100644 index 5ffd00d71f..0000000000 --- a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_2_13989894486a9ff9f243c6b2071d788f._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-04-07T16:42:11Z" - content=""" -This bug report is, to the best of my knowledge, totally wrong. - -Yes, git-annex sync pushes the git-annex branch to all git remotes. -This is intentional, and not a problem. That is just a git branch. -It's helpful to push it to eg, github, if you want to be able to pull it -from there into another clone. Pushing the git-annex branch to github does -*not* make git-annex think that github is holding the contents of annexed -files. - -In your "reproduction" section, I think you forgot to run `git annex sync` -in Zeta, so its working tree had not been updated with the files synced to -it from Alpha, which is why `git annex list` didn't show anything. Or -somethig like that. You did not provide quite enough information to guess -what you were doing. - -I'm going to close this. If you think it is still a problem, please provide -either a detailed transcript demontrating the problem or enough information -to reporoduce the problem, starting with an empty directory and -constructing the necessary git repositories to demonstrate the problem. -"""]] diff --git a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_3_79ddc1a3c554efb375b9575687e1ee04._comment b/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_3_79ddc1a3c554efb375b9575687e1ee04._comment deleted file mode 100644 index b44311d105..0000000000 --- a/doc/bugs/cause__58___fake_annex_repo___124___result__58___inflated_numcopies___124___workaround__58___initialize_properly/comment_3_79ddc1a3c554efb375b9575687e1ee04._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Cyberthal" - avatar="http://cdn.libravatar.org/avatar/1c619d65ee07d2343295c8f70f23c9df" - subject="PEBKAC" - date="2017-05-01T22:19:05Z" - content=""" -I was unable to duplicate the problem. Your explanation sounds likely. I shall strive to do better! -"""]] diff --git a/doc/bugs/checkpresentkey_batch_stops_at_97_or_98_keys.mdwn b/doc/bugs/checkpresentkey_batch_stops_at_97_or_98_keys.mdwn deleted file mode 100644 index ff761904db..0000000000 --- a/doc/bugs/checkpresentkey_batch_stops_at_97_or_98_keys.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -### Please describe the problem. - -**git annex checkpresentkey --batch $remote** doesn't check all the keys it is provided with. - -Depending how this is run, given 8000 keys, it may return info only the first handful or ~97. - -### What steps will reproduce the problem? - -The directory contains 8000 symlinks whose filename is the same as their key. The content is not in 'spearmint' (or any other configured remotes, but is present 'here'). - - $ find . -type l -printf "%f\n" | git annex checkpresentkey --batch | wc -l - 8000 - $ find . -type l -printf "%f\n" | git annex checkpresentkey --batch spearmint | wc -l - 97 - $ find . -type l -printf "%f\n" | git annex checkpresentkey --batch spearmint | wc -l - 97 - -Without a remote, all get checked.. - - $ git annex find --format '${key}\n' . | git annex checkpresentkey --batch | wc -l - 8000 - $ git annex find --format '${key}\n' . | git annex checkpresentkey --batch | sort | uniq -c - 8000 0 - -Specifying a remote only checks a small handful of keys (count changes each time).. - - $ git annex find --format '${key}\n' . | git annex checkpresentkey --batch spearmint | wc -l - 6 - $ git annex find --format '${key}\n' . | git annex checkpresentkey --batch spearmint | wc -l - 14 - $ git annex find --format '${key}\n' . | git annex checkpresentkey --batch spearmint | wc -l - 7 - $ git annex find --format '${key}\n' . | git annex checkpresentkey --batch spearmint | wc -l - 8 - -Putting the keys into a file seems to make this more consistent (more in line with *find -type f*) - - $ git annex find --format '${key}\n' . > /tmp/keys.txt - $ cat /tmp/keys.txt | git annex checkpresentkey --batch spearmint | wc -l - 96 - $ cat /tmp/keys.txt | git annex checkpresentkey --batch spearmint | wc -l - 96 - -Shuffling the key order doesn't matter much either.. - - $ shuf /tmp/keys.txt | git annex checkpresentkey --batch spearmint | wc -l - 97 - $ shuf /tmp/keys.txt | git annex checkpresentkey --batch spearmint | wc -l - 96 - $ shuf /tmp/keys.txt | git annex checkpresentkey --batch spearmint | wc -l - 97 - - -### What version of git-annex are you using? On what operating system? -git-annex version: 6.20161231-g8740cd971 - -Arch Linux (installed from 'community') - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I only find (what I think are) bugs because I use it and I use it because I like it. I like it because it works (except for when I find actual bugs :]). - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/checkpresentkey_batch_stops_at_97_or_98_keys/comment_1_f0d17735d01a04c3c2adeb5ab4c2c0ce._comment b/doc/bugs/checkpresentkey_batch_stops_at_97_or_98_keys/comment_1_f0d17735d01a04c3c2adeb5ab4c2c0ce._comment deleted file mode 100644 index 16d278f22a..0000000000 --- a/doc/bugs/checkpresentkey_batch_stops_at_97_or_98_keys/comment_1_f0d17735d01a04c3c2adeb5ab4c2c0ce._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-02-15T18:04:29Z" - content=""" -I am able to reproduce this, and it only happens when the remote being -checked is a ssh remote, not a local directory. - -So, presumably something in the verification that the remote has the -content is sometimes consuming the rest of stdin. - -The different numbers processed each time are probably due to buffering. If -the command feeding the list of keys takes a while to print them all, and -parts of its output are being thrown away, then that would explain the -different numbers processed. - -Using ssh -n to run git-annex-shell checkpresentkey avoids the problem. - -This could also impact git-annex being used in some script, when the script -is intended to consume stdin, but git-annex runs ssh, which consumes it -instead. Other commands like `git annex drop` could be affected -too in such situations. - -I've put in a comprehensive fix to all of git-annex's calls to ssh -that don't provide some other stdin. -"""]] diff --git a/doc/bugs/committing_files_into_git_doesn__39__t_work_with_explicitly_given_paths_in_V6.mdwn b/doc/bugs/committing_files_into_git_doesn__39__t_work_with_explicitly_given_paths_in_V6.mdwn deleted file mode 100644 index 35f198d67b..0000000000 --- a/doc/bugs/committing_files_into_git_doesn__39__t_work_with_explicitly_given_paths_in_V6.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. -If there are staged changes in two files (one in git, one in annex) and I want to commit them by explicitly giving git-commit both paths (in order to exclude other changes that are possibly staged), the not annexed file stays staged, while committing everything staged by not giving any path to git-commit works just fine. - -### What steps will reproduce the problem? -[[!format sh """ -mkdir testv6 -cd testv6 -git init -git annex init --version=6 -echo some > file_in_git -git -c annex.largefiles=nothing annex add file_in_git -echo more > file_in_annex -git annex add file_in_annex -git commit -m "files added" file_in_git file_in_annex -git status -"""]] - - -### What version of git-annex are you using? On what operating system? -[[!format sh """ -% git annex version -git-annex version: 6.20170307+gitg24ade8a25-1~ndall+1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 - -"""]] - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - - -[[ben]] - -> [[done]]; clean filter defaults to preserving git/annex state of file. -> --[[Joey]] diff --git a/doc/bugs/committing_files_into_git_doesn__39__t_work_with_explicitly_given_paths_in_V6/comment_1_1922f38b3620e94e90b16e3c14f59add._comment b/doc/bugs/committing_files_into_git_doesn__39__t_work_with_explicitly_given_paths_in_V6/comment_1_1922f38b3620e94e90b16e3c14f59add._comment deleted file mode 100644 index 5faf6b71ce..0000000000 --- a/doc/bugs/committing_files_into_git_doesn__39__t_work_with_explicitly_given_paths_in_V6/comment_1_1922f38b3620e94e90b16e3c14f59add._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-04-07T16:24:59Z" - content=""" -The root problem is, you have set annex.largefiles=nothing temporarily when -adding the file. But, when git commit re-smudges the file, that is not set, -so git-annex generates a v6 pointer, which is what gets committed. - -I don't think you will have these problems if use use .gitattributes to -configure annex.largefiles. - -(There is something going on that I don't quite understand with why -git status then thinks the file has changed. git diff --cached shows a diff -between the pointer that got committed and the actual file contents; -I would have expected that git would run the smudge/clean filter then and -not show that diff.) -"""]] diff --git a/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible.mdwn b/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible.mdwn deleted file mode 100644 index a61caca667..0000000000 --- a/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -### Please describe the problem. - -It appears that the bundled ssh is built without support for some configuration options supported by my system ssh. In particular it doesn't support GSSAPIKexAlgorithms. In principle it's fine to compile this ssh without support for GSS, since nobody uses it, but in practice it means that I can't even turn it off in my system config without breaking the bundled ssh. - -(I suppose the problem could also be that the bundled ssh tries to use the system ssh configuration instead of a bundled configuration.) - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -git-annex version: 6.20161231-gc8eeb17da -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -"""]] - -### Please provide any additional information below. - -See also [[todo/git-annex_ignores_GIT__95__SSH]] - -[[!format sh """ - db48x  ~  video  git-annex sync -commit -On branch master -Your branch is ahead of 'anglachel/master' by 20 commits. - (use "git push" to publish your local commits) -nothing to commit, working tree clean -ok -pull anglachel -/etc/crypto-policies/back-ends/openssh.config: line 3: Bad configuration option: gssapikexalgorithms -/etc/crypto-policies/back-ends/openssh.config: terminating, 1 bad configuration options -fatal: Could not read from remote repository. -Please make sure you have the correct access rights -and the repository exists. -failed -push anglachel -/etc/crypto-policies/back-ends/openssh.config: line 3: Bad configuration option: gssapikexalgorithms -/etc/crypto-policies/back-ends/openssh.config: terminating, 1 bad configuration options -fatal: Could not read from remote repository. -Please make sure you have the correct access rights -and the repository exists. - Pushing to anglachel failed. - (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config) -failed -git-annex: sync: 2 failed -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - -> [[done]]; moved ssh to extra directory. --[[Joey]] diff --git a/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible/comment_1_abdd5622dc1733a8b59dc11885083799._comment b/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible/comment_1_abdd5622dc1733a8b59dc11885083799._comment deleted file mode 100644 index 2024b296f3..0000000000 --- a/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible/comment_1_abdd5622dc1733a8b59dc11885083799._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-03-02T21:30:55Z" - content=""" -One way to deal with this would be to put the bundled ssh in the -git-annex.linux/extra/ directory. Programs in that directory are added to the -end of the path, so that system versions will be preferred when available. - -That was earlier done for gpg and didn't cause any problems. - -There is the potential for some sort of versioning problem. Currently the -only thing git-annex probes about the bundled ssh is if it supports -connection caching. That's quite an old feature by now, so a system ssh not -supporting it would either be super out of date and insecure openssh, or -perhaps some other ssh implementation. - -Seems worth moving the bundled ssh to the extra directory, and see what -breaks.. -"""]] diff --git a/doc/bugs/crippled_filesystem_direct_mode_sync_loop.mdwn b/doc/bugs/crippled_filesystem_direct_mode_sync_loop.mdwn deleted file mode 100644 index 2ace44e295..0000000000 --- a/doc/bugs/crippled_filesystem_direct_mode_sync_loop.mdwn +++ /dev/null @@ -1,76 +0,0 @@ -### Please describe the problem. -Two direct mode repos both on crippled filesystem (NTFS), although no file is modified, each "git annex sync" command will generate a new commit on master branch, which makes "git log" grow fast. - -### What steps will reproduce the problem? -Run the script below on NTFS filesystem - -### What version of git-annex are you using? On what operating system? -I tried multiple combination: -git version from 2.7.4 to 2.11.0; -git-annex version from 5.20150812 to 6.20161211; -OS includes ubuntu xenial&yakkety and Windows 10; -As long as the script is run on NTFS filesystem it reproudces the problem. -However, on non crippled file system the script works without problem. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -mkdir a -cd a -git init -git annex init first -git annex direct -echo foo > 1.txt -git annex add . -git annex sync -cd .. -git clone a b -cd b -git annex init second -git annex direct -git annex sync -cd ../a -git remote add second ../b -git annex sync -echo bar > 2.txt -git annex add 2.txt -git annex sync -cd ../b -git annex sync -cd ../a -git annex sync -cd ../b -git annex sync -cd ../a -git annex sync -cd ../b -git annex sync -cd ../a -git annex sync -cd ../b -git annex sync -cd ../a -git annex sync -cd ../b -git annex sync -cd ../a -git annex sync -cd ../b -git annex sync -cd ../a -git annex sync -cd ../b -git annex sync -git log | grep refs/heads/synced/master | wc - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I'm new to git-annex and immediately astonished by its unique strength. I fit the Archivist use case, and this could be the solution I wanted for so long. I'm planning to deploy it on 2 Windows boxes and several USB disks, all of them on NTFS. I learnt the idea that v6 repo is not yet good for Win/NTFS (double disk space), so I guess direct mode is the way to go? I have already got some test repos running and practicing, indeed this sync loop problem is the only remaining case I'm not confident with. Is it a bug or some safety measure feature? Am I good to go? Thanks and oh, Merry X'mas! - -> [[done]] --[[Joey]] diff --git a/doc/bugs/crippled_filesystem_direct_mode_sync_loop/comment_1_54fbe98e49d949cb6bed6122fcaec048._comment b/doc/bugs/crippled_filesystem_direct_mode_sync_loop/comment_1_54fbe98e49d949cb6bed6122fcaec048._comment deleted file mode 100644 index baa1bb91ed..0000000000 --- a/doc/bugs/crippled_filesystem_direct_mode_sync_loop/comment_1_54fbe98e49d949cb6bed6122fcaec048._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Asureus" - avatar="http://cdn.libravatar.org/avatar/f544d481d1e5adcd3b68c27d18680535" - subject="one more thing" - date="2016-12-25T14:46:46Z" - content=""" -Forgot to mention it, \"git annex test\" never passed on my Windows setup, always got 10-20 failed tests. Is that OK? -"""]] diff --git a/doc/bugs/crippled_filesystem_direct_mode_sync_loop/comment_2_81050b1206f47fa275627cc22b144086._comment b/doc/bugs/crippled_filesystem_direct_mode_sync_loop/comment_2_81050b1206f47fa275627cc22b144086._comment deleted file mode 100644 index 75bd327a0d..0000000000 --- a/doc/bugs/crippled_filesystem_direct_mode_sync_loop/comment_2_81050b1206f47fa275627cc22b144086._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2019-09-11T17:30:11Z" - content=""" -I have also seen sync loops in direct mode repos not on NTFS. - -git-annex has not supported direct mode on NTFS since earlier this year, -and now direct mode support has been removed entirely, replaced with v7 -adjusted unlocked branches. I tried replicating this bug on NTFS using -those, and the syncs quieted down immediately after changes stopped being -made. - -So, closing this bug. -"""]] diff --git a/doc/bugs/crypto-api_is_a_global_dependency_because_of_Utility.AuthToken.mdwn b/doc/bugs/crypto-api_is_a_global_dependency_because_of_Utility.AuthToken.mdwn deleted file mode 100644 index fcde456fd7..0000000000 --- a/doc/bugs/crypto-api_is_a_global_dependency_because_of_Utility.AuthToken.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -### Please describe the problem. - -Builds without Webapp and TestSuite fail at `Utility.AuthToken`. - - -### What steps will reproduce the problem? - -Build git-annex with Webapp and TestSuite disabled. - - -### What version of git-annex are you using? On what operating system? - -Version 6.20170101 on arch linux. - - -### Please provide any additional information below. - -We need to make `crypto-api` into a global dependency. Here is a [patch](https://gist.github.com/aroig/100c2977b6df8a2109823b715647d5fb). - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Oh yes! I use it everyday to sync collections of binary files across computers and VM's! - -> [[fixed|done]], thanks! --[[Joey]] diff --git a/doc/bugs/dashed_ssh_hostname_security_hole.mdwn b/doc/bugs/dashed_ssh_hostname_security_hole.mdwn deleted file mode 100644 index 056d049e66..0000000000 --- a/doc/bugs/dashed_ssh_hostname_security_hole.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -git-annex was vulnerable to the same class of security hole as -git's CVE-2017-1000117. In several cases, git-annex parses a repository -url, and uses it to generate a ssh command, with the hostname to ssh to -coming from the url. If the hostname it parses is something like -"-oProxyCommand=evil", this could result in arbitrary local code execution -via ssh. - -I have not bothered to try to exploit the problem, and some details of URL -parsing may prevent the exploit working in some cases. - -Exploiting this would involve the attacker tricking the victim into adding -a remote something like "ssh://-oProxyCommand=evil/blah". - -One possible avenue for an attacker that avoids exposing the URL to the -user is to use initremote with a ssh remote, so embedding the URL in the -git-annex branch. Then the victim would enable it with enableremote. - -This was fixed in version 6.20170818. Now there's a SshHost type that -is not allowed to start with a dash, and every invocation of ssh is -in a function that takes a SshHost. - -CVE-2017-12976 has been assigned for this issue. - -[[done]] - ---[[Joey]] - diff --git a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated.mdwn b/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated.mdwn deleted file mode 100644 index b989fee7dc..0000000000 --- a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated.mdwn +++ /dev/null @@ -1,114 +0,0 @@ -### Please describe the problem. -background: I'm trying to use git-annex to manage tracking/off-site replication of a borgbackup repository. This requires direct access to files, and it's not feasible for me to operate without annex.thin set. I'm trying to workaround some of borg's inconvenient behavior--sometimes, a borg transaction will do something that is effectively just a file rename, but internally, it truncates+deletes the original file and creates a new file with the old content. This leads to annex adding the "new" file as a reference to known content, but that content was already lost. (maybe) MWE below - -### What steps will reproduce the problem? - set -x && \ - mkdir tmp && cd tmp && \ - git init && \ - git-annex init --version 7 base && \ - git-annex config --set annex.thin true && \ - \ - echo "bar">foo && cat foo && git-annex add foo && ls -l && git-annex unlock foo && git-annex sync && \ - truncate -s 0 foo && rm foo && git-annex sync && \ - \ - echo "bar">ffoo && cat ffoo && git-annex add ffoo && ls -l && git-annex unlock ffoo && git-annex sync && \ - cat ffoo && git-annex whereis && git-annex fsck - -### What version of git-annex are you using? On what operating system? - # git-annex version - git-annex version: 7.20190129+git78-g3fa6be1fe-1~ndall+1 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - operating system: linux x86_64 - supported repository versions: 5 7 - upgrade supported from repository versions: 0 1 2 3 4 5 6 - - # lsb_release -a - LSB Version: core-9.20170808ubuntu1-noarch:printing-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch - Distributor ID: LinuxMint - Description: Linux Mint 19 Tara - Release: 19 - Codename: tara - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -+ mkdir tmp -+ cd tmp -+ git init -Initialized empty Git repository in /home/user/tmp/.git/ -+ git-annex init --version 7 base -init base ok -(recording state in git...) -+ git-annex config --set annex.thin true -annex.thin true ok -(recording state in git...) -+ echo bar -+ cat foo -bar -+ git-annex add foo -add foo ok -(recording state in git...) -+ ls -l -total 4 -lrwxrwxrwx 1 root root 178 Feb 23 13:34 foo -> .git/annex/objects/g7/9v/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 -+ git-annex unlock foo -unlock foo ok -(recording state in git...) -+ git-annex sync -commit -[master (root-commit) eebbbb5] git-annex in base - 1 file changed, 1 insertion(+) - create mode 100644 foo -ok -+ truncate -s 0 foo -+ rm foo -+ git-annex sync -commit -[master d043022] git-annex in base - 1 file changed, 1 deletion(-) - delete mode 100644 foo -ok -+ echo bar -+ cat ffoo -bar -+ git-annex add ffoo #content is discarded here -add ffoo ok -(recording state in git...) -+ cat ffoo -+ ls -l -total 4 -lrwxrwxrwx 1 root root 178 Feb 23 13:34 ffoo -> .git/annex/objects/g7/9v/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 -+ git-annex unlock ffoo -unlock ffoo ok -(recording state in git...) -+ git-annex sync -commit -[master fbc08bc] git-annex in base - 1 file changed, 1 insertion(+) - create mode 100644 ffoo -ok -+ cat ffoo -/annex/objects/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 -+ git-annex whereis -whereis ffoo (1 copy) - e470821b-a101-4acc-91ac-a0ae5d3aa40d -- base [here] -ok -+ git-annex fsck -fsck ffoo ok -(recording state in git...) - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -I'm hopeful! But just getting started :( - -> git-annex fsck made to detect and clean up after this, which I consider -> sufficient, so [[done]] --[[Joey]] diff --git a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_1_32748e7bd298d31347c68c9aabd17c77._comment b/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_1_32748e7bd298d31347c68c9aabd17c77._comment deleted file mode 100644 index 4b5f42e068..0000000000 --- a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_1_32748e7bd298d31347c68c9aabd17c77._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="david.j.buckmaster@984ff2704feacab53415ac5647206517d18f88f8" - nickname="david.j.buckmaster" - avatar="http://cdn.libravatar.org/avatar/1650cdf23a0999fd0e03650e20c90ee7" - subject="comment 1" - date="2019-02-24T01:20:14Z" - content=""" -I guess the issue here isn't specifically the truncation, but rather that annexed content isn't confirmed when committing an rm. - - set -x && \ - mkdir tmp && cd tmp && \ - git init && \ - git-annex init --version 7 base && \ - git-annex config --set annex.thin true && \ - \ - echo \"bar\">foo && cat foo && git-annex add foo && ls -l && git-annex sync && git-annex unlock foo && git-annex sync && \ - echo \"barbar\">foo && cat foo && rm foo && git-annex sync && \ - \ - echo \"bar\">ffoo && cat ffoo && git-annex add ffoo && git-annex sync && cat ffoo - -This results in ffoo containing the text \"barbar\" rather than \"bar\" (symlink to foo's last committed content), and unlocking ffoo after this leads to a pointer file instead of hardlink (and git-annex info ffoo shows present: false). - -I'm new to this, so apologies if I'm doing something stupid. -"""]] diff --git a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_2_5395837d61947644930285e65a4a8529._comment b/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_2_5395837d61947644930285e65a4a8529._comment deleted file mode 100644 index 6bfdee2f84..0000000000 --- a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_2_5395837d61947644930285e65a4a8529._comment +++ /dev/null @@ -1,65 +0,0 @@ -[[!comment format=mdwn - username="david.j.buckmaster@984ff2704feacab53415ac5647206517d18f88f8" - nickname="david.j.buckmaster" - avatar="http://cdn.libravatar.org/avatar/1650cdf23a0999fd0e03650e20c90ee7" - subject="comment 2" - date="2019-02-24T07:01:35Z" - content=""" -In case this is NOT a bug but rather an incompatibility between borg/git-annex, the bash snippet below seems to sidestep the issue if run AFTER a borg operation but BEFORE any other annex commit/sync. Unsure if I'm the only person in the world that wants a not-permanently-append-only borg repository in an unlocked+thin git-annex...but...after a borg operation that truncates+deletes files, the function uses the status printout to identify all missing, borg-controlled files, and for each - -1. Reverts the deletion (git checkout -- ..) -2. Checks if the restored file is a (dead) file pointer (file contents start with /annex/objects). If no, redo the delete and continue loop; if yes, truncate (but do not delete) the file and stage a commit. - -Truncations are then committed to force annex to see that contents have changed, and all deletions are repeated. After that, git annex add-ing a new file with old content restores the annex content that borg truncated, rather than ending up with a pointer file and missing contents. - -Test case: - - set -x && \ - mkdir tmp && cd tmp && \ - git init && \ - git-annex init --version 7 base && \ - git-annex config --set annex.thin true && \ - \ - echo \"bar\">foo && cat foo && git-annex add foo && ls -l && git-annex sync && git-annex unlock foo && git-annex sync && \ - echo \"barbar\">foo && cat foo && rm foo && \ - \ - git checkout -- foo && truncate -s 0 foo && git add foo && git-annex sync && \ - rm foo && git-annex sync && \ - \ - echo \"bar\">ffoo && cat ffoo && git-annex add ffoo && git-annex sync && cat ffoo - -Bash function: - - handleborgdeletes() { - echo \"(handleborgdeletes\" - - local PTRFILES=() - local HAVETRUNCS= - local f - - for f in $(IFS=$'\n' $GITANNEX status | grep ^D | grep -E '(index|hints|integrity|data/)'); do - f=${f:2} - - $GIT checkout -- \"$f\" #restore - if [ -n \"$(grep -F --text '/annex/objects' $f)\" ]; then #is broken annex pointer file - echo \"$f is a pointer file\" - HAVETRUNCS=1 - truncate -s 0 \"$f\" #truncate - PTRFILES+=(\"$f\") #track - $GIT add \"$f\" #stage content change - else - echo \"$f is not a pointer file\" - rm \"$f\" - fi - done - - if [ -n \"$HAVETRUNCS\" ]; then - $GIT commit -m \"truncating borg deletions\" #commit content changes - - for f in ${PTRFILES[@]}; do - rm \"$f\" #repeat delete to be committed later - done - fi - echo \"handleborgdeletes)\" - } -"""]] diff --git a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_3_82afe6abb793aef90e3ddc42c2e5c3f2._comment b/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_3_82afe6abb793aef90e3ddc42c2e5c3f2._comment deleted file mode 100644 index e14adcc5ba..0000000000 --- a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_3_82afe6abb793aef90e3ddc42c2e5c3f2._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2019-03-18T18:16:53Z" - content=""" -annex.thin does allow data loss to happen, and just because there's -another annex link in the repository that points at the same object -file does not mean data loss is not acceptable. - -While it might seem that, when adding the file with dup content, git-annex -could notice that the object file has been modified, and so replace it with -the new copy from ffoo, that would leave the same problem in -this equivilant situation: - - # echo hi > 1 - # echo hi > 2 - # git annex add 1 2 - # git annex unlock 1 - # echo bye > 1 - # cat 2 - bye - -The surprising thing to me is that `git annex fsck 2` (or ffoo in your -example) doesn't find any problem with it, despite it pointing at a -changed object file that doesn't have the right hash. - -Fsck doesn't want to complain about *expected* data loss when an unlocked -file has been modified and annex.thin caused the old version to be lost. -But, when fscking an annex symlink, that shouldn't apply. -"""]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn deleted file mode 100644 index 1afed590ed..0000000000 --- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -### Please describe the problem. - -When `git annex direct` is interrupted (either through a power outage or deliberate `control-c`) it may leave the repository in an inconsistent state. - -A typical situation is `git-annex` believing that the repo is in `indirect` mode while the files are not symlinks anymore. - -I believe I have described this problem here before, but the bug report was deleted as part of the may 29th purge (222f78e9eadd3d2cc40ec94ab22241823a7d50d9, [[bugs/git_annex_indirect_can_fail_catastrophically]]). - -### What steps will reproduce the problem? - -`git annex direct` on a large repository, `control-c` before it finishes. - -Observe how a lot of files are now considered to be in the famous [[typechange status|forum/git-status_typechange_in_direct_mode/]] in git. - -### What version of git-annex are you using? On what operating system? - -5.20140717 on Debian Jessie, ext4 filesystem. - -### Please provide any additional information below. - -I wish i could resume the `git annex direct` command, but this will do a `git commit -a` and therefore commit all those files to git directly. It still seems to me that `git annex` should never run `git commit -a` for exactly that kind of situations. - -I think that's it for now. -- [[anarcat]] - -Update: i was able to get rid of the `typechange` situation by running `git annex lock` on the repository, but then all files are found to be missing by `git annex fsck`: - -[[!format txt """ -fsck films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP (fixing location log) - ** Based on the location log, films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP - ** was expected to be present, but its content is missing. - - Only 1 of 2 trustworthy copies exist of films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP - Back it up with git-annex copy. -"""]] - -Oddly enough, the repo still uses hundreds of gigs, because all the files ended up in `.git/annex/misctmp`. Not sure I remember what happened there. - -Similar issues and discussions: - -* [[bugs/direct_mode_merge_interrupt/]] -* [[forum/Cleaning_up_after_aborted_sync_in_direct_mode/]] -* [[bugs/failure_to_return_to_indirect_mode_on_usb/]] -* [[forum/git-status_typechange_in_direct_mode/]] - -[[!meta title="git annex lock --force deletes only copy of content after interrupted switch to direct mode"] - -[[!meta tag=deprecateddirectmode]] - -> direct mode has been removed from git-annex, so [[done]] --[[Joey]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment deleted file mode 100644 index 4d7246eda7..0000000000 --- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 1" - date="2014-08-12T17:26:46Z" - content=""" -The way it's supposed to work is that `git annex direct` does not set the repository into direct mode until it's entirely done moving files around. So, if it is interrupted at any point, you are left with an indirect mode repository, with some unlocked files. Which can be put back to indirect by `git annex add`, or the conversion restarted with `git annex direct`. - -That seems to work in my tests; I can interrupt `git annex direct` and resume with `git annex direct` with a good result; `git annex add` reverts back to indirect mode. Even `git commit -a` reverts back to indirect mode, thanks to the pre-commit hook. I have tested that all these recovery methods work as intended. - -That leaves `git annex lock --force` (it has to be forced) after an interrupted switch to direct mode. I have reproduced that in this situation, that will delete your file's contents (I cannot reproduce them ending up in misctmp, but [[!commit d8be828734704c78f91029263b59eed75174e665]] may have had something to do with that). In a sense, `git annex lock --force` is doing what you told it to -- git-annex lock throws unlocked file contents away, under the assumption that they might contain modified changes. Since normally, `git annex unlock` makes a copy of the file, there is not normally data loss, unless the unlocked files got modified. But that's why it requires the --force; it can result in data loss. - -I a having a hard time thinking of a modification to `git annex lock` that would make sense. The best I can come up with is, if the file's content is not present in the annex, it could switch to what `git annex add` does, and re-add the file content to the annex if it's unchanged. While, I guess, throwing away the content if it is changed. That seems a bit complicated. - -(BTW, if you do still have the files in misctmp, you can `git annex import` their content back into the repository.) -"""]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment deleted file mode 100644 index b55e3c2a39..0000000000 --- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 2" - date="2014-08-15T17:39:14Z" - content=""" -I still cannot see a way that more than one file's content could end up in misctemp, since `git annex direct` moves just one file there at a time, so max of one should be there if interrupted. However, there was really no reason to be moving files through misctemp at all, so `git annex direct` now moves them into place completely atomically. - -Bug report retitled appropriatly for the `git annex lock --force` suprise. -"""]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_3_2acff7b667e8618251075031cbef6b9a._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_3_2acff7b667e8618251075031cbef6b9a._comment deleted file mode 100644 index 5de6726aa4..0000000000 --- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_3_2acff7b667e8618251075031cbef6b9a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="131.252.200.111" - subject="comment 3" - date="2014-08-31T22:29:44Z" - content=""" -Occurs to me that your repo may not have a pre-commit hook; if not then `git commit -a` would not behave as I described.. -"""]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_4_c3a4a1ce24fcbe1087041850f490a58a._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_4_c3a4a1ce24fcbe1087041850f490a58a._comment deleted file mode 100644 index 82b77f78bf..0000000000 --- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_4_c3a4a1ce24fcbe1087041850f490a58a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://andrew.aylett.co.uk/" - nickname="andrew" - subject="comment 4" - date="2014-09-07T18:41:28Z" - content=""" -I, too, have seen this issue -- took me a while to recover from it. I do (now, at least) have a pre-commit hook that calls git annex pre-commit; I didn't set that up myself. -"""]] diff --git a/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state.mdwn b/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state.mdwn deleted file mode 100644 index 98440ef13f..0000000000 --- a/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state.mdwn +++ /dev/null @@ -1,64 +0,0 @@ -### Please describe the problem. - -Running `git annex direct` in a repository may results with the following error message: - - git-annex: /home/mildred/Music/.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.map898.tmp: rename: permission denied (Permission denied) -failed - git-annex: direct: 1 failed - - -The major problem is that git-annex doesn't roll back the changes it did for the files it could successfully put in direct mode. Running git status show many files with typechange. The solution was to run `git add` on those files (although the hashing backend changed, so a commit must be created) - -### What steps will reproduce the problem? - -Don't know yet why the rename failed, but the direct mode should be rolled back if there is a problem. Restarting `git-annex direct` didn't result in an error. - -### What version of git-annex are you using? On what operating system? - -git-annex 5.20140405-g8729abc -arch-linux Linux moiraine 3.15.3-1-ARCH #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014 x86_64 GNU/Linux - -### Please provide any additional information below. - -[[!format sh """ - -$ git annex direct -commit -(Recording state in git...) -On branch master -nothing to commit, working directory clean -ok -direct .gitrefs/heads/annex/direct/master ok -direct .gitrefs/heads/git-annex ok -direct .gitrefs/heads/master ok -direct .gitrefs/heads/synced/master ok -direct .gitrefs/remotes/ashley/git-annex ok -direct .gitrefs/remotes/ashley/master ok -direct .gitrefs/remotes/ashley/synced/git-annex ok -direct .gitrefs/remotes/ashley/synced/master ok -direct .gitrefs/remotes/kylae/git-annex ok -direct .gitrefs/remotes/kylae/master ok -direct .gitrefs/remotes/kylae/synced/git-annex ok -direct ... ok -direct ... ok -direct ... ok - /home/mildred/Music/.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.map897.tmp: rename: permission denied (Permission denied) - - leaving this file as-is; correct this problem and run git annex fsck on it -direct ... ok -direct ... ok -direct ... ok -direct ... ok -direct ... ok - -git-annex: /home/mildred/Music/.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.map898.tmp: rename: permission denied (Permission denied) -failed -git-annex: direct: 1 failed - -"""]] - -[[!tag moreinfo]] -[[!meta tag=deprecateddirectmode]] - -> direct mode has been removed from git-annex, so closing this old bug -> [[done]] --[[Joey]] diff --git a/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment b/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment deleted file mode 100644 index c0455b9924..0000000000 --- a/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.2" - subject="comment 1" - date="2014-07-10T18:11:22Z" - content=""" -The most likely problem would be if your repository contained annexed objects owned by different user than the one running `git annex direct`. - -However, I cannot reproduce this problem: - -
-direct foo 
-  /home/joey/tmp/r/.git/annex/objects/pV/7j/SHA256E-s30--2754b7f82f6994005b97256273756f14d4abc17165c8819c06c07340d03351fa: setFileMode: permission denied (Operation not permitted)
-
-  leaving this file as-is; correct this problem and run git annex fsck on it
-direct  ok
-
- -Since version 4.20130921, any exception when moving a file to direct mode should be caught like that. - -I will need more information to reproduce your bug. Or are you sure you wrote down the right version of git-annex? -"""]] diff --git a/doc/bugs/direct_mode_merge_interrupt.mdwn b/doc/bugs/direct_mode_merge_interrupt.mdwn deleted file mode 100644 index 500325951d..0000000000 --- a/doc/bugs/direct_mode_merge_interrupt.mdwn +++ /dev/null @@ -1,58 +0,0 @@ -Seems to me there is a bug in how merges are done in direct mode. This is -done in two steps: - -1. Merge the remote branch into the local branch, with work tree directed - to a temp dir. -2. Use the temp dir and the newly merged branch to update the work tree. - -If this is interrupted between 1 and 2, by eg the user ctrl-Cing or power -being lost, the result is a repository that thinks the current branch has -been merged, but does not have an updated work tree. The next sync in that -repository will see the files as deleted (or as being an old version), and -commit the current work tree state to the branch. - -Result is files appear to be lost, although `git revert` in an indirect -mode repo can get them back. - -To fix this, direct mode merge would need to avoid updating the current -branch when merging the remote branch into it (how?). It should first -update the whole work tree, and only after it's updated should it update -the index and the current branch to reflect the merge. - -This way, if the merge is interrupted, the work tree may have uncommitted -changed -- but it's fine if they get accidentally committed, since when -the merge is re-done, those changes will by the same ones made by the -merge. (I assume this is how `git merge` normally works.) --[[Joey]] - -> Implemented that. And then realized that even updating the index -> as part of a merge results in the work tree being out of sync with the -> index. Which will cause the next sync to again delete any files that -> are in the index but not the work tree. Urgh. -> -> Seems that a direct mode -> merge also needs to use a different index file to stage its changes? -> (Ugh) -> > done --[[Joey]] - -> > > I had to revert the fix on FAT/Windows due to -> > > a git bug: -> > > Once that bug's fixed, I can revisit this. --[[Joey]] - -[[!meta title="direct mode merge interrupt (fixed for all except FAT, Windows)"]] - -## other options - -> Or could perhaps use `git-merge-tree` -> and avoid staging the merge in the index until the work-tree is updated. -> -> Alternatively, could use another strategy.. Add a lock file which is held while -> the merge is in progress and contains the pre-merge sha. -> If the lock file is present but not held, state is inconsistent. -> `git-annex sync` and the SanityChecker should -> then run mergeDirectCleanup to recover, before any commits can be made -> from the inconsistent state. This approach seems to get complicated -> quickly.. --[[Joey]] - -[[!meta tag=deprecateddirectmode]] - -> direct mode has been removed. [[done]] --[[Joey]] diff --git a/doc/bugs/direct_mode_should_refuse_to_merge_with_illegal_filenames.mdwn b/doc/bugs/direct_mode_should_refuse_to_merge_with_illegal_filenames.mdwn deleted file mode 100644 index 7db4e2b441..0000000000 --- a/doc/bugs/direct_mode_should_refuse_to_merge_with_illegal_filenames.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -Some filesystems have stupid rules about characters not allowed in filenames. For example, FAT doesn't allow '?' '*' ':' etc. - -The direct mode merge code lets `git merge` update a temp directory with the new files from the merge, before doing its work tree update and committing. This can fail: - -
-error: unable to create file non-rus/Dance/Dream_Dance_Vol15/CD1/09-??.mp3 (Invalid argument)
-
- -This leaves the work tree without the file, and the index knows about the file. Result is that the next time a commit is done, this file appears to have been deleted, and that is committed and propigates out. Which can be surprising. - ----- - -It would probably be better if, when the working tree cannot be updated, it left the repository in some state that would not make the next commit remove anything. - -Ie, direct mode should replicate this behavior: - -
-root@darkstar:/home/joey/mnt>git init
-root@darkstar:/home/joey/mnt>git merge FETCH_HEAD 
-error: unable to create file foo? (Invalid argument)
-fatal: read-tree failed
-root@darkstar:/home/joey/mnt>git status
-On branch master
-
-Initial commit
-
-nothing to commit (create/copy files and use "git add" to track)
-
- -Problem is, the call to `git merge` can also fail due to a conflict. In that case, git-annex wants to continue with automatic conflict resolution. -So, how to detect when `git merge` has skipped creating illegal filenames? - ----- - -Alternatively, git-annex could learn/probe the full set of characters not allowed in filenames, and examine merges before performing them, and refuse to do anything if the merge added an illegal filename.a - -[[!tag confirmed]] -[[!meta tag=deprecateddirectmode]] - -> direct mode has been removed. [[done]] --[[Joey]] diff --git a/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn b/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn deleted file mode 100644 index ff03aa87f5..0000000000 --- a/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -Upgrade from a direct mode repo to a v7 repo can cause annexed files to -get checked into git, in an edge case. - -The annexed files need to be already v7 unlocked files, and their content -needs to be present in the direct mode repo. Of course this is an unusual -situation. - -Then, the upgrade to v7 from direct mode makes a commit -"commit before upgrade to annex.version 6" which converts the pointer -files into the full file content. - -Also, `git annex sync` in the direct mode repo before the upgrade -converted the v7 unlocked files back to locked files. (While also a bug, -this helped mask the other bug..) - -Both [[fixed|done]] now. - ---[[Joey]] diff --git a/doc/bugs/direct_mode_upgrade_with_deleted_file.mdwn b/doc/bugs/direct_mode_upgrade_with_deleted_file.mdwn deleted file mode 100644 index dd9eb69720..0000000000 --- a/doc/bugs/direct_mode_upgrade_with_deleted_file.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -Upgrading a direct mode repo to v7 while it has a deleted file in it -behaves strangely. This is after my recent change to not make it commit. - -A `git checkout` of the file checks out the pointer file, as the content -of the file is not present. This is as expected. - -But `git whereis` thinks the content is present, which it's not any longer. -Seems that the upgrade process needs to notice when a deleted file was the -only copy of the content, and set its content as not present. - -> [[done]] --[[Joey]] - -And `git fsck` doesn't find a problem, despite the content not being -present. And does not fix the location log. -This part may not be specific to this case, seems it must be some bug in -fsck? - -> It was, a new bug introduced while removing the direct mode code. Fixed -> that part. --[[Joey]] diff --git a/doc/bugs/does_not_build_on_OpenBSD_5.9.mdwn b/doc/bugs/does_not_build_on_OpenBSD_5.9.mdwn deleted file mode 100644 index 3185c9fc88..0000000000 --- a/doc/bugs/does_not_build_on_OpenBSD_5.9.mdwn +++ /dev/null @@ -1,216 +0,0 @@ -### Please describe the problem. - -git-annex will not build on OpenBSD 5.9-stable for amd64 - -### What steps will reproduce the problem? - -$ stack install git-annex - -### What version of git-annex are you using? On what operating system? - -git-annex-6.20160511, the version from stack resolver lts-6.7 - -### Please provide any additional information below. - -[[!format sh """ -$ stack install git-annex -Run from outside a project, using implicit global project config -git-annex-6.20160511: configure -git-annex-6.20160511: build - --- While building package git-annex-6.20160511 using: - /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file" - Process exited with code: ExitFailure 1 - Logs have been written to: /home/scott/.stack/global-project/.stack-work/logs/git-annex-6.20160511.log - - [ 1 of 32] Compiling Utility.FileSize ( Utility/FileSize.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/FileSize.o ) - [ 2 of 32] Compiling Utility.Process.Shim ( Utility/Process/Shim.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Process/Shim.o ) - [ 3 of 32] Compiling Utility.Applicative ( Utility/Applicative.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Applicative.o ) - [ 4 of 32] Compiling Utility.PosixFiles ( Utility/PosixFiles.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/PosixFiles.o ) - [ 5 of 32] Compiling Utility.Env ( Utility/Env.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Env.o ) - [ 6 of 32] Compiling Utility.UserInfo ( Utility/UserInfo.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/UserInfo.o ) - [ 7 of 32] Compiling Utility.OSX ( Utility/OSX.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/OSX.o ) - [ 8 of 32] Compiling Utility.PartialPrelude ( Utility/PartialPrelude.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/PartialPrelude.o ) - [ 9 of 32] Compiling Utility.Data ( Utility/Data.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Data.o ) - [10 of 32] Compiling Utility.Exception ( Utility/Exception.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Exception.o ) - [11 of 32] Compiling Utility.FileSystemEncoding ( Utility/FileSystemEncoding.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/FileSystemEncoding.o ) - [12 of 32] Compiling Utility.Tmp ( Utility/Tmp.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Tmp.o ) - [13 of 32] Compiling Utility.Monad ( Utility/Monad.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Monad.o ) - [14 of 32] Compiling Utility.Misc ( Utility/Misc.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Misc.o ) - [15 of 32] Compiling Utility.Process ( Utility/Process.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Process.o ) - [16 of 32] Compiling Utility.SafeCommand ( Utility/SafeCommand.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/SafeCommand.o ) - [17 of 32] Compiling Utility.Directory ( Utility/Directory.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Directory.o ) - [18 of 32] Compiling Build.Version ( Build/Version.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Build/Version.o ) - [19 of 32] Compiling Utility.Network ( Utility/Network.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Network.o ) - [20 of 32] Compiling Utility.ExternalSHA ( Utility/ExternalSHA.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/ExternalSHA.o ) - [21 of 32] Compiling Utility.Path ( Utility/Path.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/Path.o ) - [22 of 32] Compiling Build.TestConfig ( Build/TestConfig.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Build/TestConfig.o ) - [23 of 32] Compiling Common ( Common.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Common.o ) - [24 of 32] Compiling Utility.DottedVersion ( Utility/DottedVersion.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/DottedVersion.o ) - [25 of 32] Compiling Git.Version ( Git/Version.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Git/Version.o ) - [26 of 32] Compiling Utility.FreeDesktop ( Utility/FreeDesktop.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Utility/FreeDesktop.o ) - [27 of 32] Compiling Config.Files ( Config/Files.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Config/Files.o ) - [28 of 32] Compiling Assistant.Install.AutoStart ( Assistant/Install/AutoStart.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Assistant/Install/AutoStart.o ) - [29 of 32] Compiling Assistant.Install.Menu ( Assistant/Install/Menu.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Assistant/Install/Menu.o ) - [30 of 32] Compiling Build.Configure ( Build/Configure.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Build/Configure.o ) - [31 of 32] Compiling Build.DesktopFile ( Build/DesktopFile.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Build/DesktopFile.o ) - [32 of 32] Compiling Main ( /tmp/stack29275/git-annex-6.20160511/Setup.hs, /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/Main.o ) - Linking /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/setup ... - /usr/local/lib/ghc/rts/libHSrts.a(RtsFlags.o): In function `copyArg': - - rts/RtsFlags.c:1685:0: - warning: warning: strcpy() is almost always misused, please use strlcpy() - /usr/local/lib/ghc/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(IO__1.o): In function `ghczuwrapperZC0ZCbaseZCSystemziIOZCrand': - (.text+0x1): warning: warning: rand() may return deterministic values, is that what you want? - /usr/local/lib/ghc/rts/libHSrts.a(RtsUtils.o): In function `showStgWord64': - - rts/RtsUtils.c:204:0: - warning: warning: sprintf() is often misused, please use snprintf() - checking version...fatal: Not a git repository (or any parent up to mount point /tmp) - Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). - 6.20160511 - checking UPGRADE_LOCATION... not available - checking git... yes - checking git version... 2.7.0 - checking cp -a... no - checking cp -p... yes - checking cp --preserve=timestamps... no - checking cp --reflink=auto... no - checking xargs -0... yes - checking rsync... yes - checking curl... yes - checking wget... yes - checking wget supports -q --show-progress... yes - checking bup... no - checking nice... yes - checking ionice... no - checking nocache... no - checking gpg... not available - checking lsof... not available - checking git-remote-gcrypt... not available - checking ssh connection caching... yes - checking sha1... not available - checking sha256... not available - checking sha512... not available - checking sha224... not available - checking sha384... not available - Configuring git-annex-6.20160511... - Linking /tmp/stack29275/git-annex-6.20160511/.stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/setup/setup ... - /usr/local/lib/ghc/rts/libHSrts.a(RtsFlags.o): In function `copyArg': - - rts/RtsFlags.c:1685:0: - warning: warning: strcpy() is almost always misused, please use strlcpy() - /usr/local/lib/ghc/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(IO__1.o): In function `ghczuwrapperZC0ZCbaseZCSystemziIOZCrand': - (.text+0x1): warning: warning: rand() may return deterministic values, is that what you want? - /usr/local/lib/ghc/rts/libHSrts.a(RtsUtils.o): In function `showStgWord64': - - rts/RtsUtils.c:204:0: - warning: warning: sprintf() is often misused, please use snprintf() - Building git-annex-6.20160511... - Preprocessing executable 'git-annex' for git-annex-6.20160511... - - /tmp/stack29275/git-annex-6.20160511/Assistant/Threads/MountWatcher.hs:35:0: - warning: #warning Building without dbus support; will use mtab polling - [ 1 of 538] Compiling Utility.Dot ( Utility/Dot.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Dot.o ) - [ 2 of 538] Compiling Utility.Mounts ( Utility/Mounts.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Mounts.o ) - [ 3 of 538] Compiling Utility.SRV ( Utility/SRV.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/SRV.o ) - [ 4 of 538] Compiling BuildFlags ( BuildFlags.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/BuildFlags.o ) - [ 5 of 538] Compiling Utility.Yesod ( Utility/Yesod.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Yesod.o ) - [ 6 of 538] Compiling Utility.Touch ( Utility/Touch.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Touch.o ) - [ 7 of 538] Compiling Assistant.Types.BranchChange ( Assistant/Types/BranchChange.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Assistant/Types/BranchChange.o ) - [ 8 of 538] Compiling Assistant.Types.TransferSlots ( Assistant/Types/TransferSlots.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Assistant/Types/TransferSlots.o ) - [ 9 of 538] Compiling Assistant.Types.ThreadName ( Assistant/Types/ThreadName.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Assistant/Types/ThreadName.o ) - [ 10 of 538] Compiling Utility.Tense ( Utility/Tense.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Tense.o ) - [ 11 of 538] Compiling Assistant.Types.Alert ( Assistant/Types/Alert.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Assistant/Types/Alert.o ) - [ 12 of 538] Compiling Utility.OptParse ( Utility/OptParse.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/OptParse.o ) - [ 13 of 538] Compiling Utility.PID ( Utility/PID.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/PID.o ) - [ 14 of 538] Compiling Utility.Shell ( Utility/Shell.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Shell.o ) - [ 15 of 538] Compiling Logs.TimeStamp ( Logs/TimeStamp.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Logs/TimeStamp.o ) - [ 16 of 538] Compiling Utility.JSONStream ( Utility/JSONStream.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/JSONStream.o ) - [ 17 of 538] Compiling Utility.HumanNumber ( Utility/HumanNumber.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/HumanNumber.o ) - [ 18 of 538] Compiling Utility.Percentage ( Utility/Percentage.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Percentage.o ) - [ 19 of 538] Compiling Utility.Glob ( Utility/Glob.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Glob.o ) - [ 20 of 538] Compiling Utility.DataUnits ( Utility/DataUnits.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/DataUnits.o ) - [ 21 of 538] Compiling Types.Creds ( Types/Creds.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/Creds.o ) - [ 22 of 538] Compiling Assistant.Types.CredPairCache ( Assistant/Types/CredPairCache.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Assistant/Types/CredPairCache.o ) - [ 23 of 538] Compiling Types.Availability ( Types/Availability.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/Availability.o ) - [ 24 of 538] Compiling Utility.Bloom ( Utility/Bloom.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Bloom.o ) - [ 25 of 538] Compiling Utility.LockFile.LockStatus ( Utility/LockFile/LockStatus.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/LockFile/LockStatus.o ) - [ 26 of 538] Compiling Utility.QuickCheck ( Utility/QuickCheck.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/QuickCheck.o ) - - /tmp/stack29275/git-annex-6.20160511/Utility/QuickCheck.hs:19:1: Warning: - The qualified import of `Data.Map' is redundant - except perhaps to import instances from `Data.Map' - To import instances alone, use: import Data.Map() - - /tmp/stack29275/git-annex-6.20160511/Utility/QuickCheck.hs:20:1: Warning: - The qualified import of `Data.Set' is redundant - except perhaps to import instances from `Data.Set' - To import instances alone, use: import Data.Set() - [ 27 of 538] Compiling Types.DesktopNotify ( Types/DesktopNotify.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/DesktopNotify.o ) - [ 28 of 538] Compiling Types.UUID ( Types/UUID.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/UUID.o ) - [ 29 of 538] Compiling Types.Group ( Types/Group.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/Group.o ) - [ 30 of 538] Compiling Types.BranchState ( Types/BranchState.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/BranchState.o ) - [ 31 of 538] Compiling Utility.Process.Shim ( Utility/Process/Shim.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Process/Shim.o ) - [ 32 of 538] Compiling Utility.FileSize ( Utility/FileSize.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/FileSize.o ) - [ 33 of 538] Compiling Utility.PosixFiles ( Utility/PosixFiles.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/PosixFiles.o ) - [ 34 of 538] Compiling Utility.Applicative ( Utility/Applicative.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Applicative.o ) - [ 35 of 538] Compiling Utility.PartialPrelude ( Utility/PartialPrelude.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/PartialPrelude.o ) - [ 36 of 538] Compiling Utility.ThreadScheduler ( Utility/ThreadScheduler.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/ThreadScheduler.o ) - [ 37 of 538] Compiling Utility.HumanTime ( Utility/HumanTime.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/HumanTime.o ) - [ 38 of 538] Compiling Utility.Hash ( Utility/Hash.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Hash.o ) - [ 39 of 538] Compiling Utility.Env ( Utility/Env.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Env.o ) - [ 40 of 538] Compiling Utility.UserInfo ( Utility/UserInfo.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/UserInfo.o ) - [ 41 of 538] Compiling Utility.Verifiable ( Utility/Verifiable.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Verifiable.o ) - [ 42 of 538] Compiling Utility.Format ( Utility/Format.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Format.o ) - [ 43 of 538] Compiling Build.SysConfig ( Build/SysConfig.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Build/SysConfig.o ) - [ 44 of 538] Compiling Config.Cost ( Config/Cost.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Config/Cost.o ) - [ 45 of 538] Compiling Types.Messages ( Types/Messages.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/Messages.o ) - [ 46 of 538] Compiling Types.TrustLevel ( Types/TrustLevel.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/TrustLevel.o ) - [ 47 of 538] Compiling Types.Test ( Types/Test.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/Test.o ) - [ 48 of 538] Compiling Utility.Data ( Utility/Data.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Data.o ) - [ 49 of 538] Compiling Utility.Exception ( Utility/Exception.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Exception.o ) - [ 50 of 538] Compiling Utility.FileMode ( Utility/FileMode.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/FileMode.o ) - [ 51 of 538] Compiling Git.FileMode ( Git/FileMode.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Git/FileMode.o ) - [ 52 of 538] Compiling Utility.FileSystemEncoding ( Utility/FileSystemEncoding.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/FileSystemEncoding.o ) - [ 53 of 538] Compiling Utility.Base64 ( Utility/Base64.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Base64.o ) - [ 54 of 538] Compiling Utility.Tmp ( Utility/Tmp.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Tmp.o ) - [ 55 of 538] Compiling Database.Handle ( Database/Handle.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Database/Handle.o ) - [ 56 of 538] Compiling Utility.LockFile.Posix ( Utility/LockFile/Posix.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/LockFile/Posix.o ) - [ 57 of 538] Compiling Utility.DiskFree ( Utility/DiskFree.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/DiskFree.o ) - [ 58 of 538] Compiling Utility.Monad ( Utility/Monad.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Monad.o ) - [ 59 of 538] Compiling Utility.Misc ( Utility/Misc.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Misc.o ) - [ 60 of 538] Compiling Utility.Process ( Utility/Process.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Process.o ) - [ 61 of 538] Compiling Utility.SafeCommand ( Utility/SafeCommand.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/SafeCommand.o ) - [ 62 of 538] Compiling Git.Types ( Git/Types.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Git/Types.o ) - [ 63 of 538] Compiling Utility.Network ( Utility/Network.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Network.o ) - [ 64 of 538] Compiling Utility.Scheduled ( Utility/Scheduled.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Scheduled.o ) - [ 65 of 538] Compiling Utility.Scheduled.QuickCheck ( Utility/Scheduled/QuickCheck.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Scheduled/QuickCheck.o ) - [ 66 of 538] Compiling Utility.ExternalSHA ( Utility/ExternalSHA.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/ExternalSHA.o ) - [ 67 of 538] Compiling Utility.Directory ( Utility/Directory.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Directory.o ) - [ 68 of 538] Compiling Utility.Path ( Utility/Path.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/Path.o ) - [ 69 of 538] Compiling Common ( Common.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Common.o ) - [ 70 of 538] Compiling Git ( Git.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Git.o ) - [ 71 of 538] Compiling Git.Filename ( Git/Filename.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Git/Filename.o ) - [ 72 of 538] Compiling Git.FilePath ( Git/FilePath.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Git/FilePath.o ) - [ 73 of 538] Compiling Git.DiffTreeItem ( Git/DiffTreeItem.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Git/DiffTreeItem.o ) - [ 74 of 538] Compiling Logs.MapLog ( Logs/MapLog.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Logs/MapLog.o ) - [ 75 of 538] Compiling Types.MetaData ( Types/MetaData.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/MetaData.o ) - [ 76 of 538] Compiling Annex.MetaData.StandardFields ( Annex/MetaData/StandardFields.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Annex/MetaData/StandardFields.o ) - [ 77 of 538] Compiling Types.Key ( Types/Key.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/Key.o ) - [ 78 of 538] Compiling Messages.JSON ( Messages/JSON.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Messages/JSON.o ) - [ 79 of 538] Compiling Utility.InodeCache ( Utility/InodeCache.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Utility/InodeCache.o ) - [ 80 of 538] Compiling Types.KeySource ( Types/KeySource.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/KeySource.o ) - [ 81 of 538] Compiling Types.Backend ( Types/Backend.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Types/Backend.o ) - [ 82 of 538] Compiling Database.Types ( Database/Types.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.5.0/build/git-annex/git-annex-tmp/Database/Types.o ) - ghc: /usr/local/lib/libidn.a: unknown symbol `libintl_bindtextdomain' - ghc: unable to load package `gnuidn-0.2.2' -"""]] - -> So git-annex dropped xmpp and the libidn.a -> library will no longer be pulled in. -> -> Also, you were right about `stack install git-annex` -> being problimatic. The build instuctions have since been changed to -> run stack inside the git-annex source tree. -> Since that worked for you, closing this bug. [[done]] --[[Joey]] diff --git a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_1_e69ed5e0c9e474158da6764d27f67b67._comment b/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_1_e69ed5e0c9e474158da6764d27f67b67._comment deleted file mode 100644 index 5cac7c971a..0000000000 --- a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_1_e69ed5e0c9e474158da6764d27f67b67._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-11T16:14:37Z" - content=""" -The build error suggests a problem with either the libidn.a library in -openbsd, or the haskell bindings to it in gnuidn. - -A similar problem is discussed in [[More_build_oddities_under_OpenBSD]]. - -Disabling XMPP support in git-annex makes it not need either library, -so should avoid the problem. Eg: `stack build --flag git-annex:-XMPP` - -(Although AFAICS, XMPP support is disabled by default in stack.yaml anyway, -so I am not sure why your stack build included it.) -"""]] diff --git a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment b/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment deleted file mode 100644 index 2466bd932d..0000000000 --- a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="quisquous" - subject="comment 2" - date="2016-07-11T17:59:56Z" - content=""" -Perhaps running ````stack install git-annex```` (using the implicit global project) ignores the flags in stack.yaml, see [#1313](https://github.com/commercialhaskell/stack/issues/1313). Following your suggestion, I tried cloning the repo and building using `stack build` both with and without the XMPP flag. Without the flag works fine, it seems the default ````false```` setting form xmpp flag in stack.yaml is honored when building *this* way. - -In any case, this worked: - -```` -$ git clone git://git-annex.branchable.com/ git-annex -$ cd git-annex -$ git checkout 6.20160511 -$ stack build -$ stack install -```` -"""]] diff --git a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_3_8a563d9ccba5e912713812c77d34ea1f._comment b/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_3_8a563d9ccba5e912713812c77d34ea1f._comment deleted file mode 100644 index 87b1c4c127..0000000000 --- a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_3_8a563d9ccba5e912713812c77d34ea1f._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-07-12T18:31:17Z" - content=""" -Not sure if that stack bug you linked to is quite a match for what it's -doing, so I opened a new one: - - -I don't currently see anything I could do in git-annex to avoid this -problem. - -What version of stack are you using? It could be that a newer version of -stack doesn't have the problem. -"""]] diff --git a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_4_557f5a38ae78b21b18a63d3ba16bc099._comment b/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_4_557f5a38ae78b21b18a63d3ba16bc099._comment deleted file mode 100644 index 7ea3e42947..0000000000 --- a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_4_557f5a38ae78b21b18a63d3ba16bc099._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="quisquous" - subject="comment 4" - date="2016-07-12T18:59:55Z" - content=""" -```` -~ ❯❯❯ stack --version -Version 1.1.2 x86_64 hpack-0.14.0 -```` -"""]] diff --git a/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected.mdwn b/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected.mdwn deleted file mode 100644 index a70f5848a3..0000000000 --- a/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected.mdwn +++ /dev/null @@ -1,43 +0,0 @@ -### Please describe the problem. -*As of filing:* - -* [downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg.info](https://downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg.info) contains: `distributionVersion = "7.20190508"` whereas: `distributionReleasedate = 2019-06-15 16:47:53.122405093 UTC` -* when installed `git annex version` reports -`git-annex version: 7.20190508-g9c4744c3c` - -*Expected behavior:* - -* `distributionVersion` and included `git-annex`'s version matches an announced released version: - * [version_7.20190615/](http://git-annex.branchable.com/news/version_7.20190615/) - * [version_7.20190507/](http://git-annex.branchable.com/news/version_7.20190507/) - -### What steps will reproduce the problem? - -1. On macOS (or Mac OS X), download and deploy the current [git-annex.dmg](https://downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg) -2. Open a terminal session and enter `git-annex version` - -### What version of git-annex are you using? On what operating system? - - - 7.20190508-g9c4744c3c - - /usr/bin/sw_vers - ProductName: Mac OS X - ProductVersion: 10.12.6 - BuildVersion: 16G2016 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Absolutely! I've been using git-annex for a few years now to version control and distribute a [Munki](https://www.munki.org) repository of Mac software distribution packages and their meta-data. git-annex integrates well with [Ansible](https://docs.ansible.com/#project), and has been rock solid. Thank you! - -> [[fixed|done]], OSX build is current with today's release. --[[Joey]] diff --git a/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/comment_1_afa8ad9963ef1a49433fb41eefaa45a8._comment b/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/comment_1_afa8ad9963ef1a49433fb41eefaa45a8._comment deleted file mode 100644 index 8757413ff9..0000000000 --- a/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/comment_1_afa8ad9963ef1a49433fb41eefaa45a8._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-06-26T00:08:15Z" - content=""" -Yeah, the OSX autobuilder has I think not had a sucessful build since May. - -I just copy over the latest autobuild when doing a release. - -I tried a manual build and it failed with "hdiutil: create failed - -Resource busy" which is a way that hdiutil seems to just fail from time to -time, with no indication anywhere on the internet of why. In my experience -such failures tend to clear up after maybe 24 hours, presumably when -whatever resource it's trying to use stops being busy. -"""]] diff --git a/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/comment_2_7f88bf1d7821ea2dd0eed624563d5482._comment b/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/comment_2_7f88bf1d7821ea2dd0eed624563d5482._comment deleted file mode 100644 index 3f0f5174af..0000000000 --- a/doc/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/comment_2_7f88bf1d7821ea2dd0eed624563d5482._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="leej" - avatar="http://cdn.libravatar.org/avatar/eb1c6bd57680f694fb4658388e6de4ed" - subject="Currently, 7.20190730 is expected but 7.20190709-gee3885d15 present on OSX/current" - date="2019-08-02T15:48:52Z" - content=""" -The distribution directories are all showing 2019-07-30, but the build and distribution at downloads.kitenet.net/git-annex/OSX/current// -distributionVersion = \"7.20190709\", distributionReleasedate = 2019-07-30 20:37:03.710335378 UTC - - -Let me know if you'd like a new ticket opened instead of re-opening this issue. - -"""]] diff --git a/doc/bugs/dropunused_does_nothing.mdwn b/doc/bugs/dropunused_does_nothing.mdwn deleted file mode 100644 index 3e6f359daa..0000000000 --- a/doc/bugs/dropunused_does_nothing.mdwn +++ /dev/null @@ -1,132 +0,0 @@ -### Please describe the problem. - -there are files in my repo that i cant get rid of. - - $ git annex unused - unused . (checking for unused data...) (checking master...) - Some annexed data is no longer used by any files: - NUMBER KEY - 1 SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif - 2 SHA256E-s6133555--b394dd9889feded875396fc32ce98ff9b206bc203ad826b316f0da98969ba5f9.done.tif - 3 SHA256E-s5409067--6db75a42d002f6ab52ff5dc57ad9c65bcb34fa6371f22134532546b269cd47f6.done.tif - 4 SHA256E-s6431447--76582d83e519d5c1286d073f330b10213ae05c17a4baf5434fe786fce1ac7c23.done.tif - 5 SHA256E-s6234195--019cb086986c258e746dbff9f188d58f0f561824ca2d2a888fafb12e7ac1c6ce.done.tif - 6 SHA256E-s6993729--79c73a0402181b0c557249243fa5f593b6284027d5fb7f74fb9ac6deb8800235.done.tif - 7 SHA256E-s6046931--68522cefd3b009367c1efcc3ae002dce9d405fd3ae27b52ae7c9076349d2c58b.done.tif - 8 SHA256E-s5909711--8541a1d4aa4ef1d6a0b6de9f13648f8c97aedd0d371f26ddf1c4a52fb05063b6.done.tif - 9 SHA256E-s5872619--5e2ba7852213574878a72e5a1867c6c0154ed487fa633def60e5398bd44ca68c.done.tif - 10 SHA256E-s6473539--2353ac9d339afe417e9069e7a7d69b8a8cf1370fef489e27f0e19cee7a3e86bd.done.tif - 11 SHA256E-s6218095--0f32ecb974fa9ed1c7736f728385cd1ee3b89e4d6b41f2c5e4c00497e40932cd.done.tif - 12 SHA256E-s6573461--202751374b7f1d5872c0e6afc251467036dae782eb2b301a1b79a8927abe0180.done.tif - 13 SHA256E-s6441483--bbda783c7f27e90180de717b09c412a3b3500cdc7cdcf84dddb6f222232c9156.done.tif - 14 SHA256E-s7265337--abfe156e61f18b9cb93ecf64ffe77e206782554dbebe05b9118057f9cb4a97a1.done.tif - 15 SHA256E-s6779531--a6f9912f86d6f734b031e0deb76d7a4015c2884e0e21b22464656056bd993357.done.tif - 16 SHA256E-s5216075--8c5a57b75eb8687643f139e7ae82742253e6dfc11b6b76e8053f806257d18999.done.tif - 17 SHA256E-s5559823--2a7276cae88871489c8ae20c2164f4f4fa66ad06b79db63daa74de35ed433d55.done.tif - 18 SHA256E-s6055855--f9cd8d75dd568abf3980f0c0374d95b66f7f196639142efb0fa37b2917650ec0.done.tif - 19 SHA256E-s6506577--a9b79e417801ac365f6ab509ff4cadf713e74fe83bdae601fe5c35b3114705a1.done.tif - (To see where data was previously used, try: git log --stat -S'KEY') - - To remove unwanted data: git-annex dropunused NUMBER - -and i do a git annex dropunused --force all i get this - - - dropunused 1 ok - dropunused 2 ok - dropunused 3 ok - dropunused 4 ok - dropunused 5 ok - dropunused 6 ok - dropunused 7 ok - dropunused 8 ok - dropunused 9 ok - dropunused 10 ok - dropunused 11 ok - dropunused 12 ok - dropunused 13 ok - dropunused 14 ok - dropunused 15 ok - dropunused 16 ok - dropunused 17 ok - dropunused 18 ok - dropunused 19 ok - -and i have this again: - - $ git annex unused - unused . (checking for unused data...) (checking master...) - Some annexed data is no longer used by any files: - NUMBER KEY - 1 SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif - 2 SHA256E-s6133555--b394dd9889feded875396fc32ce98ff9b206bc203ad826b316f0da98969ba5f9.done.tif - 3 SHA256E-s5409067--6db75a42d002f6ab52ff5dc57ad9c65bcb34fa6371f22134532546b269cd47f6.done.tif - 4 SHA256E-s6431447--76582d83e519d5c1286d073f330b10213ae05c17a4baf5434fe786fce1ac7c23.done.tif - 5 SHA256E-s6234195--019cb086986c258e746dbff9f188d58f0f561824ca2d2a888fafb12e7ac1c6ce.done.tif - 6 SHA256E-s6993729--79c73a0402181b0c557249243fa5f593b6284027d5fb7f74fb9ac6deb8800235.done.tif - 7 SHA256E-s6046931--68522cefd3b009367c1efcc3ae002dce9d405fd3ae27b52ae7c9076349d2c58b.done.tif - 8 SHA256E-s5909711--8541a1d4aa4ef1d6a0b6de9f13648f8c97aedd0d371f26ddf1c4a52fb05063b6.done.tif - 9 SHA256E-s5872619--5e2ba7852213574878a72e5a1867c6c0154ed487fa633def60e5398bd44ca68c.done.tif - 10 SHA256E-s6473539--2353ac9d339afe417e9069e7a7d69b8a8cf1370fef489e27f0e19cee7a3e86bd.done.tif - 11 SHA256E-s6218095--0f32ecb974fa9ed1c7736f728385cd1ee3b89e4d6b41f2c5e4c00497e40932cd.done.tif - 12 SHA256E-s6573461--202751374b7f1d5872c0e6afc251467036dae782eb2b301a1b79a8927abe0180.done.tif - 13 SHA256E-s6441483--bbda783c7f27e90180de717b09c412a3b3500cdc7cdcf84dddb6f222232c9156.done.tif - 14 SHA256E-s7265337--abfe156e61f18b9cb93ecf64ffe77e206782554dbebe05b9118057f9cb4a97a1.done.tif - 15 SHA256E-s6779531--a6f9912f86d6f734b031e0deb76d7a4015c2884e0e21b22464656056bd993357.done.tif - 16 SHA256E-s5216075--8c5a57b75eb8687643f139e7ae82742253e6dfc11b6b76e8053f806257d18999.done.tif - 17 SHA256E-s5559823--2a7276cae88871489c8ae20c2164f4f4fa66ad06b79db63daa74de35ed433d55.done.tif - 18 SHA256E-s6055855--f9cd8d75dd568abf3980f0c0374d95b66f7f196639142efb0fa37b2917650ec0.done.tif - 19 SHA256E-s6506577--a9b79e417801ac365f6ab509ff4cadf713e74fe83bdae601fe5c35b3114705a1.done.tif - (To see where data was previously used, try: git log --stat -S'KEY') - - To remove unwanted data: git-annex dropunused NUMBER - - -### What version of git-annex are you using? On what operating system? - -im using a ubuntu bionic with the latest standalone version: - - - $ git annex version - git-annex version: 7.20181106-g352f88226 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B25» - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - operating system: linux x86_64 - supported repository versions: 5 7 - upgrade supported from repository versions: 0 1 2 3 4 5 6 - local repository version: 7 - - - $ git annex info - repository mode: indirect - trusted repositories: 0 - semitrusted repositories: 5 - 00000000-0000-0000-0000-000000000001 -- web - 00000000-0000-0000-0000-000000000002 -- bittorrent - 007097b0-39f5-42c8-b85f-76f128cdaffa -- [jay] - 72033f8d-940b-4999-9a18-d1897c217308 -- preuss@CKC-BS-N0288:~/Bilder [here] - d9effa4c-961c-4521-a2c7-38f4ebbc455e -- marv@rorschach:~/Bilder [rorschach] - untrusted repositories: 0 - transfers in progress: none - available local disk space: 155.98 gigabytes (+1 megabyte reserved) - local annex keys: 18096 - local annex size: 86.67 gigabytes - annexed files in working tree: 18531 - size of annexed files in working tree: 86.84 gigabytes - bloom filter size: 32 mebibytes (3.6% full) - backend usage: - SHA256E: 18531 - - - -### Please provide any additional information below. - -i have recorded a asciinema: https://asciinema.org/a/O8ZjZp2TVO3mnuB4ZtmJxgceC - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -yeah. i try to use git-annex for just everything. lately im building a little script of using git-annex to save content from my blog. i love it alot :) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/dropunused_does_nothing/comment_1_493d556a74bfc7bec15f4c9881977b0c._comment b/doc/bugs/dropunused_does_nothing/comment_1_493d556a74bfc7bec15f4c9881977b0c._comment deleted file mode 100644 index d3ded08813..0000000000 --- a/doc/bugs/dropunused_does_nothing/comment_1_493d556a74bfc7bec15f4c9881977b0c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-12-03T17:27:14Z" - content=""" -I wonder if the problem is with `unused` somehow listing files whose -content is not present, or with `dropunused` somehow failing to remove the -content. If you run `find -ls .git/annex/objects | grep SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif` -what does it output? -"""]] diff --git a/doc/bugs/dropunused_does_nothing/comment_2_1de1a1027f1b238134ff10f6a1bdef72._comment b/doc/bugs/dropunused_does_nothing/comment_2_1de1a1027f1b238134ff10f6a1bdef72._comment deleted file mode 100644 index 50ed937d4e..0000000000 --- a/doc/bugs/dropunused_does_nothing/comment_2_1de1a1027f1b238134ff10f6a1bdef72._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="xsteadfastx" - avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e" - subject="comment 2" - date="2018-12-04T09:46:46Z" - content=""" - $ find ls .git/annex/objects | grep SHA256E- s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif - find: ‘ls’: Datei oder Verzeichnis nicht gefunden - .git/annex/objects/jK/8x/SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif - .git/annex/objects/jK/8x/SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif/SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif - -it looks like the object is still there. -"""]] diff --git a/doc/bugs/dropunused_does_nothing/comment_3_8f80959997f6963728a8aee3765dc349._comment b/doc/bugs/dropunused_does_nothing/comment_3_8f80959997f6963728a8aee3765dc349._comment deleted file mode 100644 index 2206573e7e..0000000000 --- a/doc/bugs/dropunused_does_nothing/comment_3_8f80959997f6963728a8aee3765dc349._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-12-04T15:46:05Z" - content=""" -Indeed, the object seems to be there, but it looks like `dropunused` -probably for some reason fails its `inAnnex` check and so skips it. - -Does `git config annex.thin` output true? If so, and if the object file you -found does not checksum to the right value, `dropunused` would skip it. - -That seems to me to be a bug, it probably should delete even modified files -in this case. But I don't know if it's the bug you're seeing. -"""]] diff --git a/doc/bugs/dropunused_does_nothing/comment_4_7e04e71d0eb03185148ab544bc24724c._comment b/doc/bugs/dropunused_does_nothing/comment_4_7e04e71d0eb03185148ab544bc24724c._comment deleted file mode 100644 index 92ca25affa..0000000000 --- a/doc/bugs/dropunused_does_nothing/comment_4_7e04e71d0eb03185148ab544bc24724c._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2018-12-04T15:52:52Z" - content=""" -Test case for the annex.thin with modified file bug: - - git annex init - git annex upgrade - git config annex.thin true - touch foo - git add foo - git commit -m add - echo foo >> foo - rm foo - git commit -m rm -a - git annex unused - git annex dropunused 1 - git annex unused - -Now, dropunused is supposed to honor numcopies, and if an object file -has been modified, that's probably the only existing copy of that object, -and so dropunused should refuse to drop it by default. There ought to be a -warning, and the user should be able to use --force to override and drop it -anyway. I've implemented that now. -"""]] diff --git a/doc/bugs/dropunused_does_nothing/comment_5_da289a4648ed1a976572cea3352ce15e._comment b/doc/bugs/dropunused_does_nothing/comment_5_da289a4648ed1a976572cea3352ce15e._comment deleted file mode 100644 index 1dd3124c9a..0000000000 --- a/doc/bugs/dropunused_does_nothing/comment_5_da289a4648ed1a976572cea3352ce15e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="xsteadfastx" - avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e" - subject="comment 5" - date="2018-12-05T09:57:36Z" - content=""" -yes i have it set to thin. i forgot to tell. i edited the jpegs listed there and saved them under the same filename. that would explain why the checksums differ. but i thought a `git annex add .` would get it right. so this could be the bug you talk about? -"""]] diff --git a/doc/bugs/dropunused_does_nothing/comment_6_f2d5208352384443e027c78a64b1a0b1._comment b/doc/bugs/dropunused_does_nothing/comment_6_f2d5208352384443e027c78a64b1a0b1._comment deleted file mode 100644 index 7f2ebd6bd5..0000000000 --- a/doc/bugs/dropunused_does_nothing/comment_6_f2d5208352384443e027c78a64b1a0b1._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2018-12-05T16:14:16Z" - content=""" -Thanks, what you describe matches the bug I've fixed. -"""]] diff --git a/doc/bugs/dropunused_does_nothing/comment_7_d64a42b91dc46fd56320b4c328b75b7b._comment b/doc/bugs/dropunused_does_nothing/comment_7_d64a42b91dc46fd56320b4c328b75b7b._comment deleted file mode 100644 index 7d5af2f180..0000000000 --- a/doc/bugs/dropunused_does_nothing/comment_7_d64a42b91dc46fd56320b4c328b75b7b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="xsteadfastx" - avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e" - subject="comment 7" - date="2018-12-06T09:09:48Z" - content=""" -thank you so much for your fix and overall awesome work!!! -"""]] diff --git a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android.mdwn b/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android.mdwn deleted file mode 100644 index 54676b5710..0000000000 --- a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -It would be nice to allow LAN sync on the android client. This would allow for easily syncing files when in an out-of-service area, or rapidly syncing to a device with a better network connection. - -> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]] diff --git a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_1_de6b49a56df51ef872a3f80a3f9f7340._comment b/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_1_de6b49a56df51ef872a3f80a3f9f7340._comment deleted file mode 100644 index 14a634a011..0000000000 --- a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_1_de6b49a56df51ef872a3f80a3f9f7340._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-13T18:17:47Z" - content=""" -It would be "easy" except that - -a) Getting a ssh *server* running on Android is not exactly easy. - -b) Local pairing needs multicast to be supported, and IIRC this needs porting - to work with - Android's Bionic libc. -"""]] diff --git a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_2_471d2dfee80033072cf8732bb532eca5._comment b/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_2_471d2dfee80033072cf8732bb532eca5._comment deleted file mode 100644 index 94aa4a8787..0000000000 --- a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_2_471d2dfee80033072cf8732bb532eca5._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="Farhan" - subject="Interested" - date="2016-06-24T03:22:38Z" - content=""" -I would like to help (though I have not enough time to fully make the feature for sure). - -With regards to: - -1) It seems that there is a library which implements an SSH server on Android. I see it [at this repo](https://github.com/barryk/android_external_dropbear) as well as at [this repo](https://github.com/berserker/android_dropbear), both of which are owned by the makers of popular sshd apps on the Google Play Store - -2) Do you mean that that library needs to be ported to Android/Java? If so, I could take a crack at it! -"""]] diff --git a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_3_58e569cb01b6e9ce5bd6428ee106cdad._comment b/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_3_58e569cb01b6e9ce5bd6428ee106cdad._comment deleted file mode 100644 index 28297b2381..0000000000 --- a/doc/bugs/easy_feature_request__58___enable_lan_sync_on_android/comment_3_58e569cb01b6e9ce5bd6428ee106cdad._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-05-08T18:48:11Z" - content=""" -I'm closing this bug report because the git-annex Android app that it -was reported on is now deprecated. Instead, we have -a way to run the regular git-annex build for linux on Android in termux: - - -There were a lot of problems with the way the git-annex Android app was -put together, and I hope this new approach avoids them. If you try it and -still have the bug you reported, please followup and I'll reopen it. -"""]] diff --git a/doc/bugs/enable-tor_fails_with_quoting_issue.mdwn b/doc/bugs/enable-tor_fails_with_quoting_issue.mdwn deleted file mode 100644 index 41a6cb6b55..0000000000 --- a/doc/bugs/enable-tor_fails_with_quoting_issue.mdwn +++ /dev/null @@ -1,83 +0,0 @@ -### Please describe the problem. - -git annex enable-tor fails with an error in the KDE su dialog window: - - Cannot execute command ' ''\''/home/adam/software/scm/git-annex.static/git-annex'\'' '\''enable-tor'\'' '\''1000'\''''. - -The console shows the following: - -``` -enable-tor - You may be prompted for a password -org.kde.kdesud: priority set to 50 -org.kde.kdesud: Scheduler set to 0 - -git-annex: Failed to run as root: /home/adam/software/scm/git-annex.static/git-annex enable-tor 1000 -failed -git-annex: enable-tor: 1 failed -``` - -Interestingly this happens on my openSUSE Tumbleweed system running XFCE4 (*not* KDE), but not on the peer I'm trying to pair with, which is an older openSUSE Leap 15.0 box. On the latter, for some reason that uses `gksu`, even though both systems are running XFCE4: - -``` -enable-tor - You may be prompted for a password -gksu-run: gksu/'|home|adam|software|scm|git-annex.static|git-annex' 'enable-tor' '1000'/9140-0-pacific_TIME0 -gksu-run: e680f4b50a49c297709613029db91b7a - - Tor hidden service is configured. Checking connection to it. This may take a few minutes. - - Tor hidden service is working. -ok -``` - -### What steps will reproduce the problem? - -Simply run `git-annex enable-tor` - -### Workaround - -I found that a valid workaround is to `su` to `root`, `cd` to the same repo, and run `git annex enable-tor 1000`. - -### What version of git-annex are you using? On what operating system? - -The identical statically compiled 7.20190912-g05bc37910 is running on both the failing Tumbleweed system and the succeeding Leap 15.0 system. - -### Please provide any additional information below. - -Here is the relevant fragment of the process tree: - -``` - | |-zsh,9829 - | | |-git,21554 annex enable-tor - | | | `-git-annex,21555 --library-path /home/adam/software/scm/git-annex.static//usr/lib/x86_64-linux-gnu/gconv:/home/adam/software/scm/git-annex.static//usr/lib/x86_64-linux-gnu/audit> - | | | |-kdesu,21584 '/home/adam/software/scm/git-annex.static/git-annex' 'enable-tor' '1000' - | | | | |-{kdesu},21585 - | | | | |-{kdesu},21586 - | | | | |-{kdesu},21588 - | | | | |-{kdesu},21589 - | | | | |-{kdesu},21591 - | | | | `-{kdesu},21595 - | | | |-{git-annex},21579 - | | | |-{git-annex},21580 - | | | |-{git-annex},21581 - | | | `-{git-annex},21583 -``` - -You can clearly see that the arguments to `kdesu` have extra quotes, which I'm guessing is part of the problem: - -``` -$ xxd /proc/21584/cmdline -00000000: 6b64 6573 7500 272f 686f 6d65 2f61 6461 kdesu.'/home/ada -00000010: 6d2f 736f 6674 7761 7265 2f73 636d 2f67 m/software/scm/g -00000020: 6974 2d61 6e6e 6578 2e73 7461 7469 632f it-annex.static/ -00000030: 6769 742d 616e 6e65 7827 2027 656e 6162 git-annex' 'enab -00000040: 6c65 2d74 6f72 2720 2731 3030 3027 00 le-tor' '1000'. -``` - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, lots and lots for many years :-) - -> turns out kdesu needs -c in order to treat the single parameter that is -> passed to it as a command line. [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/external_remote_hGetContents_handle_error.mdwn b/doc/bugs/external_remote_hGetContents_handle_error.mdwn deleted file mode 100644 index a3414780fc..0000000000 --- a/doc/bugs/external_remote_hGetContents_handle_error.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -### Please describe the problem. - -A follow on from https://git-annex.branchable.com/bugs/Failing_to_execute_bash_remotes_windows/ - -After noticing your note about it still being possible to run external scripts locally (don't know why I didn't try this!), I tried it. I guess this is related to the reading of the shebang? -This may be fixed already, so I'm sorry if I'm rehashing things! - - -### What steps will reproduce the problem? - -[[!format sh """ -$ git init -$ git annex init -$ cp `which git-annex-remote-rclone` . -$ git annex initremote test type=external externaltype=rclone encryption=none - -initremote test -git-annex: git-annex-remote-rclone: hGetContents: illegal operation (delayed read on closed handle) -failed -git-annex: initremote: 1 failed -"""]] - - - -### What version of git-annex are you using? On what operating system? - -Same as before, windows, git-bash - - git-annex version: 6.20170214-g2233a50 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParser Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 2 3 4 5 - operating system: mingw32 i386 - - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Thanks for the quick response earlier. I hope this is helpful information. Keep up the great work! :) - -> Reproduced this bug, and I've committed a fix. [[done]] --[[Joey]] diff --git a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces.mdwn b/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces.mdwn deleted file mode 100644 index 4180678c95..0000000000 --- a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -It's possible for a key to contain whitespace in its name. This breaks the -external special remote protocol, which uses whitespace to separate the key -parameter from subsequent parameters. - -I think that this only causes problems for WORM keys. --[[Joey]] - -> Ok, went with my last approach, rather than complicating all special -> remotes due to this problem, we'll deprecate WORM keys with spaces in -> their name, and provide a migratipon path. -> -> The error message looks like this: - -> > Sorry, this file cannot be stored on an external special remote because its key's name contains a space. To avoid this problem, you can run: git-annex migrate --backend=WORM - -> This is fixed as well as is feasible, so while that kind of sucks, -> calling it [[done]]. --[[Joey]] diff --git a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_1_c9095cf16c9b044a4eae6b9b445b2512._comment b/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_1_c9095cf16c9b044a4eae6b9b445b2512._comment deleted file mode 100644 index 611508b6bd..0000000000 --- a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_1_c9095cf16c9b044a4eae6b9b445b2512._comment +++ /dev/null @@ -1,60 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-08-15T18:45:21Z" - content=""" -It would be kind of nice to not have to worry about keys containing spaces. -(Only space is allowed currently, not other whitespace.) But that ship has -long sailed and it would be very ugly to force changing repositories using -WORM keys with spaces to WORM keys without spaces. About as ugly as -entirely dropping WORM, which might not be a bad long-term goal. - -Here's a few approaches for fixing this in the external special remote protocol: - -1. Mangle keys containing spaces as they are sent via the protocol - and de-mangle as they're received. - Eg, convert ' ' to 's' and convert 's' to 'ss' etc. - (Perhaps pick a better letter than 's' -- '%' and ',' and '&' are - already used for other escaping.) -2. Make "VERSION 2" be the same as the current protocol, except Key - (and other parameters) are quoted in some way. -3. Make "VERSION 2" be the same as the current protocol, except using NUL - rather than space to separate parameters. Perhaps also to separate - protocol commands from their parameters, but then "VERSION 2" would - be an exception to the rule. - -Of course the advantage of #1 is that it doesn't need any modifications to all -the external special remotes. Such modifications would take quite a while, -and probably wouldn't even start until a git-annex supporting "VERSION 2" -was widely available, ie years even to start. - -Using NUL is conceptually the simplest implementation, but it may cause -issues for implementing external special remotes in some languages. Shell -scripts are probably not good at NULs, for example. - -One problem with approach #1 is, what if a key containing a space in the -protocol happened to already work with the protocol parser in an external -special remote? This seems at least possible. And so content would already -be stored on the external special remote under the real key, not the -mangled key. When git-annex starts mangling the key, retreiving the content -from the special remote would then fail. - -For that to happen, the external special remote would need a parser that -when it sees "TRANSFER STORE Key File", parses it with File as the last -word, so supporting multi-word Key. The documentation does currently say -that "The filename will not contain any whitespace." Actually, I tested it, -and with a WORM key with spaces, that documentation is generally wrong, -since the File is based on the Key, it also contains whitespace, most of -the time. One exception is when using direct mode, if the work tree file -has been renamed to not contain whitespace. - -So, approach #1 seems to call for auditing of external special remotes -and/or a warning to their implementors about that issue. This would also -be an opportunity to correct the documentation about spaces in the -filename, and make sure that they all support that. - -Another problem with key mangling is if an external special remote takes -the mangled key, and passes it to some other git-annex command, like `git annex -setpresentkey` or something. I seem to remember datalad doing this kind of -thing. -"""]] diff --git a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_2_ed1299a6e12acf728bfa91e60a3706e9._comment b/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_2_ed1299a6e12acf728bfa91e60a3706e9._comment deleted file mode 100644 index 9ef839f1df..0000000000 --- a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_2_ed1299a6e12acf728bfa91e60a3706e9._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-08-15T19:40:44Z" - content=""" -git-annex could set something in the environment to let the external -special remote know that it supports version 2. Or, git-annex could -reply to "VERSION 2" with a new request to indicate it would -like to use NUL or whatever. That would not break older clients; -they'd reply with "UNSUPPORTED-REQUEST". - -Of these, the environment variable seems cleaner. -"""]] diff --git a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_3_ec5eddd2f345bb8c22168ad34334565e._comment b/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_3_ec5eddd2f345bb8c22168ad34334565e._comment deleted file mode 100644 index 86f38917f0..0000000000 --- a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_3_ec5eddd2f345bb8c22168ad34334565e._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""simpler approach""" - date="2017-08-17T18:35:33Z" - content=""" -Notice that nooone has ever complained about encountering this problem. -Not many users are affected. So, a change that prevents the problem -occuring going forward, without fixing old repositories, is not going to -bother many users. - -* Make `preSanitizeKeyName` escape out spaces, so new WORM keys - won't have spaces. -* Let WORM keys with spaces be able to be migrated to not have spaces, - using `git annex migrate` -* Make the Remotes.External refuse to have anything to do with keys - with spaces, and suggest that the user migrate them. -"""]] diff --git a/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn b/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn deleted file mode 100644 index 2e4db4f463..0000000000 --- a/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. - -git annex fsck complains about no known copies of files which seem to be there - -### What steps will reproduce the problem? - -run git annex fsck in a bare repo? At least I tried 3, two from one set of mirrors, and one from another - -### What version of git-annex are you using? On what operating system? - -╰─% apt-cache policy git-annex -git-annex: - Installed: 5.20141125 - Candidate: 5.20141125 - Version table: - *** 5.20141125 0 - 900 http://http.debian.net/debian/ jessie/main amd64 Packages - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$ cd /media/usbdata3/data/audio.git/ -$ tail /tmp/usbdata3.audio.log - ** No known copies exist of SHA256E-s22382--ceaa24fd4ef186b90146cbfc48a2da261e85d63288520aa3efd80705f1976117.jpg - ** No known copies exist of SHA256E-s6532--4cf24963db72d1c06b03310a83922875bfff4d82b7285096a7bf76ecdba39552.jpg - ** No known copies exist of SHA256E-s9539--eb1db62f33125aee2093ecf530f94497f8c890b3ffddb5214cbd2ad99ce5a4c4.jpg - ** No known copies exist of SHA256E-s13710--5d69a49a290012f480e6848f88122e90f803177c610524234e16136d95bc7715.jpg - ** No known copies exist of SHA256E-s3515--3a225ae6b26571a27d7e70f49948e2be4d78f1fb29e64308880e208e20bc2868.jpg - ** No known copies exist of SHA256E-s8359--9291d7b0bf3a862901607ec7c56d5e1ee6a0f3889e775e4db23999b38322e83f.jpg - ** No known copies exist of SHA256E-s3157--4c43cf5618f939a09dada21b45b3860bcb4c6968fa166daf3215f879a25e504d.gif - ** No known copies exist of SHA256E-s2676--13b4b08525ce90b44ea9eb703630646f2d8f41d9a07b65d130aaf653a072d408.gif - ** No known copies exist of SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg -git-annex: fsck: 10484 failed -$ find . -name SHA256E-s5863--f0eb8c34ea1aa834280c7\* -./annex/objects/5b3/5c3/SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg -./annex/objects/5b3/5c3/SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg/SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg -$ sha256sum ./annex/objects/5b3/5c3/SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg/SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg -f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746 ./annex/objects/5b3/5c3/SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg/SHA256E-s5863--f0eb8c34ea1aa834280c78f1ec28d50aef81379ba62fb0bbf084664c7a7e2746.jpg -$ - -# End of transcript or log. -"""]] - -[[!tag moreinfo]] - -> closing as I don't know how to reproduce this and there has been no -> followup for years. [[done]] --[[Joey]] diff --git a/doc/bugs/false_positives_from_fsck_in_bare_repo/comment_1_e13d7e142e4f3c33afb1e445a1a4c093._comment b/doc/bugs/false_positives_from_fsck_in_bare_repo/comment_1_e13d7e142e4f3c33afb1e445a1a4c093._comment deleted file mode 100644 index e369bb3d47..0000000000 --- a/doc/bugs/false_positives_from_fsck_in_bare_repo/comment_1_e13d7e142e4f3c33afb1e445a1a4c093._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-02-25T18:22:00Z" - content=""" -I tried to reproduce this by eg, making a bare repo that contained -the only known copy of a file. No problem. - -
-joey@darkstar:~/tmp/2.git>git annex fsck
-(merging synced/git-annex into git-annex...)
-fsck
-SHA256E-s30--20c71ffd77c7f25e52416eb6afd36bf8df9410a9942d8a42e7caf74f6cfa5fb8 (checksum...)
-ok
-
- -I then purposefully told git-annex the file was not located in the bare -repo, even though it was there, fscked again, and it had no trouble -fixing the location log to reflect reality: - -
-joey@darkstar:~/tmp/2.git>git annex fsck
-fsck SHA256E-s30--20c71ffd77c7f25e52416eb6afd36bf8df9410a9942d8a42e7caf74f6cfa5fb8 (fixing location log) (checksum...)
-ok
-(recording state in git...)
-
- -You will need to investigate further why git-annex is not seeing the file. -"""]] diff --git a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees.mdwn b/doc/bugs/fatal__58___git-write-tree__58___error_building_trees.mdwn deleted file mode 100644 index c3d205faf4..0000000000 --- a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees.mdwn +++ /dev/null @@ -1,110 +0,0 @@ -### Please describe the problem. -Not able to successfully git-annex sync with a remote due to a git fatal. Caused by masters diverging? - -### What steps will reproduce the problem? -git-annex sync, or, letting the assistant try. - -### What version of git-annex are you using? On what operating system? -git-annex version: 5.20131221+b1 on my laptop -git-annex version: 5.20131224-g6ca5271 on the remote server - -### Please provide any additional information below. - -Output of a manual git-annex sync in the directory: - -[[!format sh """ -greg@x200s:~/Documents$ git-annex sync -commit (Recording state in git...) -Copyright Office/Orphan Works/ARROW/170409_ARROW_Leaflet.pdf: unmerged (783afced6bc43138373fda43edfda0c33be36525) -Copyright Office/Orphan Works/ARROW/ARROWproject_results1.pdf: unmerged (b536e5f3d93e7905e05510f26db1f743e9eae16e) -Copyright Office/Orphan Works/ARROW/ARROWproject_results1.ppt: unmerged (5543049b8940cc5702d37aff18b03c67d9c8374d) -Copyright Office/Orphan Works/ARROW/ARROWstandardPresent2010.pdf: unmerged (54d751bc98cb5da29d3d568856b74675e842072e) -Copyright Office/Orphan Works/ARROW/ARROWstandardPresent2010.ppt: unmerged (efe0e94b51eccb9a6a0c352f4a210bd5a6105050) -Copyright Office/Orphan Works/ARROW/ARROWtrifoldMAR2011.pdf: unmerged (b52ff16178e29261fe00a518c23610a3b0826482) -Copyright Office/Orphan Works/Documentation/20110531/Documentation.doc.odt: unmerged (1348d5f42f7e34706407f7936f4fb0438e4b8ffa) -Copyright Office/Orphan Works/Documentation/AAPpublishers.pdf: unmerged (3f448a03d31a38adb095e3031e4ee13771d22d70) -Copyright Office/Orphan Works/Documentation/Documentation.doc: unmerged (265fdff7787f560e3ba20789a12e15ffb165ec7f) -Copyright Office/Orphan Works/Documentation/Documentation.pdf: unmerged (7a9ff92663ed42b42b9baaefaf4721499d18d82d) -... -fatal: git-write-tree: error building trees -git-annex: failed to read sha from git write-tree -"""]] - -See also: - -1. the [partial daemon log](http://paste.debian.net/73176/) from the assistant running in that directory on the laptop and -2. the output of [git fsck](http://paste.debian.net/73175/) on the remote. - -git-annex repair on the laptop and the server: -[[!format sh """ -greg@x200s:~/Documents$ git-annex repair -Running git fsck ... -No problems found. -ok -"""]] - - -### How I ended up fixing it: -[[!format sh """ -greg@x200s:~/Documents$ killall git-annex -greg@x200s:~/Documents$ git-annex indirect -blah............... -indirect ok -ok -greg@x200s:~/Documents$ git status -On branch master -Your branch and 'rose/master' have diverged, -and have 294 and 1 different commit each, respectively. - (use "git pull" to merge the remote branch into yours) - -Untracked files: - (use "git add ..." to include in what will be committed) - - .gitrefs/ - -nothing added to commit but untracked files present (use "git add" to track) -greg@x200s:~/Documents$ git pull -Merge made by the 'recursive' strategy. - Copyright Office/Orphan Works/staging/reporting/process_report.txt.2 | 1 + - Copyright Office/Orphan Works/staging/reporting/with-title.xls | 1 + - Copyright Office/Orphan Works/staging/with-title.xls | 1 + - Copyright Office/Orphan Works/worker_emails.txt | 1 + - git.fsck.log | 1 + - 5 files changed, 5 insertions(+) - create mode 120000 Copyright Office/Orphan Works/staging/reporting/process_report.txt.2 - create mode 120000 Copyright Office/Orphan Works/staging/reporting/with-title.xls - create mode 120000 Copyright Office/Orphan Works/staging/with-title.xls - create mode 120000 Copyright Office/Orphan Works/worker_emails.txt - create mode 120000 git.fsck.log -greg@x200s:~/Documents$ git-annex sync -commit ok -pull rose - -Already up-to-date. -ok -push rose -Counting objects: 1658, done. -Delta compression using up to 2 threads. -Compressing objects: 100% (904/904), done. -Writing objects: 100% (1604/1604), 138.97 KiB | 0 bytes/s, done. -Total 1604 (delta 892), reused 1298 (delta 688) -To greg@rose.makesad.us:/home/greg/Documents/ - f1d206e..e836b9b master -> synced/master -ok -greg@x200s:~/Documents$ -"""]] - -I restarted the assistant and the daemon.log looks good. - -After sync'ing on the server, it appears that this has been the case for quite some time (based off of what symlinks were created). - -Lastly: Joey, this is probably what caused that weird behavior in the webapp where it showed the bad transfer each day after the fsck at noon. I never diagnosed that more but I bet I won't see it tomorrow. - -[[!tag moreinfo]] - -> I think this was a corrupt .git/annex/index. The "..." in the above -> transcript is where the actual useful part of the error message would be, -> so pity it was trimmed in this bug report. Based on @yarikoptic's -> occurance of the problem below, deleting .git/annex/index will recover. -> And I would expect `git annex repair` would also recover in this -> situation. [[done]] --[[Joey]] diff --git a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_2_4412fe19280551109bed2fde7a921079._comment b/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_2_4412fe19280551109bed2fde7a921079._comment deleted file mode 100644 index ba0aec5c83..0000000000 --- a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_2_4412fe19280551109bed2fde7a921079._comment +++ /dev/null @@ -1,47 +0,0 @@ -[[!comment format=mdwn - username="yarikoptic" - avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" - subject="old issue bites back" - date="2018-04-16T05:53:00Z" - content=""" -Sorry to bring the old issue up but we just ran into the same situation, and I wonder if any idea on how to mediate -- unlike other cases where it happens due to corrupt index, here I guess it goes about \"git-annex\" branch (or its some kind of local index cache?) - -[[!format sh \"\"\" -nastase@head1:~/attention/raw_bids/stimuli$ git add README.md -nastase@head1:~/attention/raw_bids/stimuli$ git commit -m 'README for stimuli' README.md -(recording state in git...) -error: invalid object 100644 fd601b9139518bd6737ad20e55198dd1854fa0f9 for '001/92f/MD5E-s1413--241f0946a6aecfe12a7c031cb2339f9d.pklz.log' -fatal: git-write-tree: error building trees -git-annex: failed to read sha from git write-tree -CallStack (from HasCallStack): - error, called at ./Git/Sha.hs:18:15 in main:Git.Sha - -nastase@head1:~/attention/raw_bids/stimuli$ git annex fsck -curl: (22) The requested URL returned error: 404 Not Found - - Remote openfmri not usable by git-annex; setting annex-ignore -fsck bird_eating_1.mp4 (checksum...) ok -... -fsck ungulate_swimming_2.mp4 (checksum...) ok -(recording state in git...) -error: invalid object 100644 fd601b9139518bd6737ad20e55198dd1854fa0f9 for '001/92f/MD5E-s1413--241f0946a6aecfe12a7c031cb2339f9d.pklz.log' -fatal: git-write-tree: error building trees -git-annex: failed to read sha from git write-tree -CallStack (from HasCallStack): - error, called at ./Git/Sha.hs:18:15 in main:Git.Sha - -nastase@head1:~/attention/raw_bids/stimuli$ git --version -git version 2.13.0.rc1.294.g07d810a77f - -nastase@head1:~/attention/raw_bids/stimuli$ git annex version -git-annex version: 6.20180329+gitga5fe62bed-1~ndall+1 - -\"\"\"]] - -NB The issue came earlier and I have just upgraded git from elderly 2.7.0 and git-annex-standalone from a few months back. - -Any advice would be welcome - -[[!meta author=yoh]] - -"""]] diff --git a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_2_77295c0b749e984a6fb200d3b73b5765._comment b/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_2_77295c0b749e984a6fb200d3b73b5765._comment deleted file mode 100644 index dabc1d4f35..0000000000 --- a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_2_77295c0b749e984a6fb200d3b73b5765._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.35" - subject="comment 2" - date="2014-01-06T16:14:29Z" - content=""" -As far as I can tell from git's code, this involves a \"cache-tree\" data structure stored in git's index file. git-annex has nothing to do with writing index files, beyond running git plumbing. So I don't see how this could be anything other than a corrupt index file (of a sort that git fsck doesn't detect), or a git bug. The best thing to do would be to send an example of a repository having this problem to the git developers for analysis. -"""]] diff --git a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_3_6bd0caa81cb87d30355cc8ed9fc6d958._comment b/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_3_6bd0caa81cb87d30355cc8ed9fc6d958._comment deleted file mode 100644 index 389b9d79fc..0000000000 --- a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_3_6bd0caa81cb87d30355cc8ed9fc6d958._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2018-04-16T20:24:33Z" - content=""" -@yarikoptic, yes, the filename there is a git-annex branch filename. -So, .git/annex/index is where the problem lies in your case. - -(Probably in the original bug reporter's case too; they trimmed out the -important part of the error message it seems. git fsck won't detect a -problem with .git/annex/index.) - -The best thing to do in this case is to delete .git/annex/index, -since git-annex can always recover from that by creating a new one that -does not point to git objects that have mysteriously vanished from your -disk. - -Since information that was being written to the git-annex branch has -apparently been lost, you'll also want to `git annex fsck --fast` -"""]] diff --git a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_4_f3af2244be7bf7461882b0e9e527922a._comment b/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_4_f3af2244be7bf7461882b0e9e527922a._comment deleted file mode 100644 index f14e42d1b4..0000000000 --- a/doc/bugs/fatal__58___git-write-tree__58___error_building_trees/comment_4_f3af2244be7bf7461882b0e9e527922a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="yarikoptic" - avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" - subject="comment 4" - date="2018-04-17T03:52:55Z" - content=""" -thank you Joey. It seems to be healed now (after ` rm ../.git/annex/index*`, since there also was .lck file, just killed them together, annex fsck didn't raise any alarm) -"""]] diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory.mdwn b/doc/bugs/fatal__58___unable_to_normalize_object_directory.mdwn deleted file mode 100644 index 29e694f2c0..0000000000 --- a/doc/bugs/fatal__58___unable_to_normalize_object_directory.mdwn +++ /dev/null @@ -1,82 +0,0 @@ -### Please describe the problem. - -I'm getting `fatal: unable to normalize object directory` while issuing `git annex copy` from an annex in my laptop to a vanilla remote annex located in a USB disk. -As far as I can tell there are no hardware problems with the disk or the laptop. - -``` -$ git annex copy --auto --to usbdrive . -copy vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts (to usbdrive...) -SHA256E-s1256869488--28edfd2c4eb08e6782c806a85db7bc10595c16df6f64d3d46ebc2802b3ba5038.ts - 1,256,869,488 100% 52.96MB/s 0:00:22 (xfr#1, to-chk=0/1) -(checksum...) fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects - - fd:24: hGetLine: end of file - -SHA256E-s1256869488--28edfd2c4eb08e6782c806a85db7bc10595c16df6f64d3d46ebc2802b3ba5038.ts - 1,256,869,488 100% 56.08MB/s 0:00:21 (xfr#1, to-chk=0/1) -(checksum...) - fd:23: hFlush: resource vanished (Broken pipe) - - fd:23: hClose: resource vanished (Broken pipe) -ok -(recording state in git...) -``` - -But note that the command did not abort. After copying, `fsck` reports no error: - -``` -$ git annex fsck --from=usbdrive 'vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts' -fsck vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts (checksum...) ok -(recording state in git...) -``` - -I get the same errors with `drop`, which fails: - -``` -$ git annex drop --from usbdrive 'vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts' -drop usbdrive vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects -fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects - -git-annex: fd:27: hGetLine: end of file -failed -git-annex: drop: 1 failed -``` - -But the same `drop` works if executed again: - -``` -$ git annex drop --from usbdrive 'vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts' -drop usbdrive vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts ok -(recording state in git...) -``` - -### What version of git-annex are you using? On what operating system? - -git-annex version: 6.20161231-gc8eeb17da - -Linux XXX 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64 GNU/Linux - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! I use git-annex without a problem since years. This is the first time I have really no idea what's going on. - -> Seems to be fixed in git version 2.19.0 [[done]] --[[Joey]] diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_1_a2b90b2111bee705afa399fdb8fad23d._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_1_a2b90b2111bee705afa399fdb8fad23d._comment deleted file mode 100644 index ebebdb3a9b..0000000000 --- a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_1_a2b90b2111bee705afa399fdb8fad23d._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="jesrui@51c25da8d6f34e6df8e3e7ed0277335ed7ddf6a6" - nickname="jesrui" - avatar="http://cdn.libravatar.org/avatar/079b86efcbbb1c0c54be3759a0c2b223" - subject="comment 1" - date="2017-01-21T15:08:20Z" - content=""" -I found the problem: I was cd'ing into the local repository via a symbolic link, instead of using the \"canonical\" path. -You can mark the bug as solved or delete it. Sorry for the noise. -"""]] diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_2_bd39c124ebb1f505fc6a7fb6815ff49b._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_2_bd39c124ebb1f505fc6a7fb6815ff49b._comment deleted file mode 100644 index 1df44e8eb2..0000000000 --- a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_2_bd39c124ebb1f505fc6a7fb6815ff49b._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-06-06T19:38:00Z" - content=""" -"fatal: unable to normalize object directory" is an error message that -git emits, not git-annex. - -I wonder if git-annex's use of --work-tree and --git-dir with -relative paths confuses git in some way? - -It would be good to explain how to reproduce this problem. -I tried a few things involving symlinks in the path I `cd`ed to, -but was not able to cause the problem. -"""]] diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_3_c49df6a33bbf8c3238f5eec1ef3e8152._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_3_c49df6a33bbf8c3238f5eec1ef3e8152._comment deleted file mode 100644 index 3910a24eda..0000000000 --- a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_3_c49df6a33bbf8c3238f5eec1ef3e8152._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="rfourquet" - avatar="http://cdn.libravatar.org/avatar/2c78d7b5b3c6a417e5d666666ec40d51" - subject="comment 3" - date="2017-11-05T12:04:50Z" - content=""" -I ran into the same problem: assuming I have a repo at \"/mnt/hd/repo\", then `$ cd /; sudo ln -s /mnt/hd/ .; cd /hd/repo; git annex copy --to=someremote ./some-file` exhibits the problem. Thanks! -"""]] diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_4_c4cf3df34625b17ed44077bec53b0ac4._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_4_c4cf3df34625b17ed44077bec53b0ac4._comment deleted file mode 100644 index 85e51a9633..0000000000 --- a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_4_c4cf3df34625b17ed44077bec53b0ac4._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2017-11-07T18:19:39Z" - content=""" -Thanks for the reproducion recipe, @rfourquet. That worked for me. - -The bug submitter closed this bug, but I'm reopening it since this seems a -legitimate bug report and we know how to reproduce it too. -"""]] diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_5_cb5332119c54764b4ef1e000b3767b0e._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_5_cb5332119c54764b4ef1e000b3767b0e._comment deleted file mode 100644 index 5cc9dc6787..0000000000 --- a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_5_cb5332119c54764b4ef1e000b3767b0e._comment +++ /dev/null @@ -1,36 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2017-11-07T18:21:20Z" - content=""" -With somerepo in ~/tmp/repo, and pwd in /hd/repo, which is a symlink from /tmp/hd/repo, -this happens: - - chat: git ["--git-dir=../../../home/joey/tmp/repo/.git","--work-tree=../../../home/joey/tmp/repo","--literal-pathspecs","--literal-pathspecs","cat-file","--batch"] - fatal: unable to normalize object directory: /hd/repo/../../../home/joey/tmp/repo/.git/objects - -Here it's making git operate on the remote git repo. The relative paths it uses -to it seem legitimate, in that "ls ../.." shows the content of "/tmp" and -"ls ../../.." shows the root directory. - -This is a very confusing situation, and different ways of getting the current -directory give different results in this situation. In particular `$PWD` -contains "/hd/repo" while getcwd(3) will return "/tmp/hd/repo". Paths -need to be relative to "/tmp/hd/repo" as that's the *actual* cwd. - -It seems that git is looking at `$PWD` to get "/hd/repo" and normalizing -the relative path via that. So there's no possible relative path -that git will accept in this situation. This kind of seems like buggy -behavior on git's part. I've posted about it to the git mailing list. - - -git-annex could avoid the problem by not using relative paths of course, -but there are reasons including shorter path length (generally) -for its use of relative paths. - -git-annex could unset PWD before running git, which forces git to fall -back to using getcwd(3). I've verified that does avoid the problem. -Going to see if this just gets fixed in git before I put in such ugly -and kind of expensive workarounds. (Expensive because, to unset PWD -from the environment, git-annex would have to copy it.) -"""]] diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_6_19c9dbdbcc2875cd6429f0ba06336fd2._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_6_19c9dbdbcc2875cd6429f0ba06336fd2._comment deleted file mode 100644 index 11d32e5f67..0000000000 --- a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_6_19c9dbdbcc2875cd6429f0ba06336fd2._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2017-11-13T17:09:31Z" - content=""" -The git bug is fixed in git's `pu` branch, or as Peff says, -at least "papered over", and I've tested the fix with git-annex and -it seems to avoid the problem. So as long as -5eb0e541132208a9027cc090943276fa52f29c71 gets into a git release, -this bug can be closed without any changes to git-annex. -"""]] diff --git a/doc/bugs/feed_dependency.mdwn b/doc/bugs/feed_dependency.mdwn deleted file mode 100644 index 789a94f54e..0000000000 --- a/doc/bugs/feed_dependency.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -It looks like the latest version of `git-annex` currently published on -Hackage has a dependency on `feed` package without an upper bound -specified. - -FYI, as per https://github.com/bergmark/feed/pull/20, a new version of -`feed` will be released soon, incorporating non-backwards compatible -changes to `feed` interface (`String` was replaced with `Text` -throughout and `xml-types` types were adopted). Changes are largely -mechanical but you'll probably want to ensure that future version of -`git-annex` can build with newer `feed`. - -To prevent breakage for users, you may want to release a new version -of `git-annex` with an upper bound specified now, then push a version -compatible with `feed-1.0` after that comes out later. - -Use the tip of the PR to test your package against: -https://github.com/dzhus/feed/commit/259bab0 . With Stack, you just -need to put the following in the `packages` section of your -`stack.yaml`: - -     - location: -         git: git@github.com:dzhus/feed -         commit: 259bab0dd16853656ce1d2a005c4009d4747edc1 -       extra-dep: true - -Please report any feedback / issues to the aforementioned PR thread -or here if that works for you. - --- Dmitry Dzhus - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/file_extensions_of___62__4_chars_ignored_by___42__E_backends.mdwn b/doc/bugs/file_extensions_of___62__4_chars_ignored_by___42__E_backends.mdwn deleted file mode 100644 index f6432fd9ca..0000000000 --- a/doc/bugs/file_extensions_of___62__4_chars_ignored_by___42__E_backends.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -### Please describe the problem. -It seems that SHA256E, MD5E etc backends ignore file extensions longer than 4 characters, considering files with such extensions to have an empty extension. -But it's not uncommon to have longer extensions; e.g. .fasta and .fasta.gz files are common in bioinformatics. -Is it possible to remove this 4-character limit, or make it configurable? - -### What steps will reproduce the problem? -(master_env_py27_v28) [12:37 PM /data/ilya-work/sw]$ cp c10.yyy c11.yyyy -(master_env_py27_v28) [12:37 PM /data/ilya-work/sw]$ git annex calckey c11.yyyy -SHA256E-s18841--9fd9a2607e019b7726c722d9d6f6171e6578f255bc60a0b79c525f8a3ffa05de.yyyy -(master_env_py27_v28) [12:37 PM /data/ilya-work/sw]$ cp c10.yyy c12.yyyyy -(master_env_py27_v28) [12:37 PM /data/ilya-work/sw]$ git annex calckey c12.yyyyy -SHA256E-s18841--9fd9a2607e019b7726c722d9d6f6171e6578f255bc60a0b79c525f8a3ffa05de - -(master_env_py27_v28) [12:43 PM /data/ilya-work/sw]$ git annex calckey c10.yyyy.gz -SHA256E-s2168--21bb6c514473754cc49a455f45bc84961fe4fceb2cb0527ba2a1cfabdce6bf80.yyyy.gz -(master_env_py27_v28) [12:43 PM /data/ilya-work/sw]$ mv c10.yyyy.gz c10.yyyyy.gz -(master_env_py27_v28) [12:43 PM /data/ilya-work/sw]$ git annex calckey c10.yyyyy.gz -SHA256E-s2168--21bb6c514473754cc49a455f45bc84961fe4fceb2cb0527ba2a1cfabdce6bf80.gz - -### What version of git-annex are you using? On what operating system? - -git-annex version: 6.20180807-gebc1bb5 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feed\ -s Testsuite -dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-s\ -qlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\ -24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\ -2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256\ - BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -local repository version: 5 - - - -> This was filed redundantly with [[todo/support_longer_file_extensions]] -> by I think the same person?! [[done]] diff --git a/doc/bugs/find_with_batch_does_not_apply_matching_options.mdwn b/doc/bugs/find_with_batch_does_not_apply_matching_options.mdwn deleted file mode 100644 index 813ae9caf1..0000000000 --- a/doc/bugs/find_with_batch_does_not_apply_matching_options.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -### Please describe the problem. -Using `git annex find --batch` with matching options seems to not apply them. - -### What steps will reproduce the problem? - - find -type l | git annex find --batch --copies 2 - ... list of files that include files with only 1 copy ... - -### What version of git-annex are you using? On what operating system? -I'd rather not say ~~because it is ancient~~. Joey says this is reproducible on recent git-annex versions though. - -> Not only find, but a bunch of commands supporting --batch had this -> oversight. Fixed them all. [[done]] --[[Joey]] diff --git a/doc/bugs/fingertree___62____61___0.1.2_causes_build_to_fail_on_reducers.mdwn b/doc/bugs/fingertree___62____61___0.1.2_causes_build_to_fail_on_reducers.mdwn deleted file mode 100644 index a3169be3b1..0000000000 --- a/doc/bugs/fingertree___62____61___0.1.2_causes_build_to_fail_on_reducers.mdwn +++ /dev/null @@ -1,57 +0,0 @@ -### Please describe the problem. -git-annex's dependencies fail to install unless fingertree is constrained to < 0.1.2.0 - -Note this has already been fixed upstream in reducers https://github.com/ekmett/reducers/commit/f18a111d66c343bd472f914baaa948191f8ecf55 - -However, there hasn't been a new release yet of reducers so it still affects git-annex currently. - -### What steps will reproduce the problem? -cabal install --jobs=8 --max-backjumps=100000 --only-dependencies --flags=s3\ webapp - - -### What version of git-annex are you using? On what operating system? -6.20171003 on macOS - -### Please provide any additional information below. - -The error is -[[!format sh """ -Failed to install reducers-3.12.1 -Build log ( /private/tmp/git-annex-20171003-61223-1v5jyd4/git-annex-6.20171003/.cabal-sandbox/logs/ghc-8.2.1/reducers-3.12.1-5Of5cjMdWsgHjbctJQaaa4.log ): -cabal: Entering directory '/tmp/cabal-tmp-62861/reducers-3.12.1' -Configuring reducers-3.12.1... -clang: warning: -Wl,-headerpad_max_install_names: 'linker' input unused -clang: warning: argument unused during compilation: '-L/usr/local/opt/gettext/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/libffi/lib' -clang: warning: argument unused during compilation: '-L/usr/local/opt/icu4c/lib' -clang: warning: argument unused during compilation: '-L/usr/local/lib' -clang: warning: argument unused during compilation: '-L/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries' -Preprocessing library for reducers-3.12.1.. -Building library for reducers-3.12.1.. -[ 1 of 14] Compiling Data.Semigroup.Instances ( src/Data/Semigroup/Instances.hs, dist/dist-sandbox-c97b5ef4/build/Data/Semigroup/Instances.o ) - -src/Data/Semigroup/Instances.hs:11:10: error: - Duplicate instance declarations: - instance Measured v a => Semigroup (FingerTree v a) - -- Defined at src/Data/Semigroup/Instances.hs:11:10 - instance [safe] Measured v a => Semigroup (FingerTree v a) - -- Defined in ‘Data.FingerTree’ - | -11 | instance Measured v a => Semigroup (FingerTree v a) where - | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -cabal: Leaving directory '/tmp/cabal-tmp-62861/reducers-3.12.1' -"""]] - -Full log is here: https://gist.github.com/ilovezfs/544d546785addbe2c5ef41656fa7eda0 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes :) - -> I see this was fixed in the meantime in fingertree-0.1.2. -> -> Also, I'd prefer not to complicate git-annex's dependencies with -> versioning for indirect dependencies like this one, unless there's -> some long drawn-out breakage to contend with. -> -> [[done]] --[[Joey]] diff --git a/doc/bugs/fingertree___62____61___0.1.2_causes_build_to_fail_on_reducers/comment_1_cbb3c9f16cf834466cbc31fd129b3559._comment b/doc/bugs/fingertree___62____61___0.1.2_causes_build_to_fail_on_reducers/comment_1_cbb3c9f16cf834466cbc31fd129b3559._comment deleted file mode 100644 index 31e7547849..0000000000 --- a/doc/bugs/fingertree___62____61___0.1.2_causes_build_to_fail_on_reducers/comment_1_cbb3c9f16cf834466cbc31fd129b3559._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="ilovezfs" - avatar="http://cdn.libravatar.org/avatar/f2b3954cf2ed0a551de9a49d3b6a64d0" - subject="comment 1" - date="2017-10-19T05:50:11Z" - content=""" -reducers 3.12.2 was released with the fix included. -"""]] diff --git a/doc/bugs/g-a_move_has_force_option_described_twice.mdwn b/doc/bugs/g-a_move_has_force_option_described_twice.mdwn deleted file mode 100644 index 93e7a2896d..0000000000 --- a/doc/bugs/g-a_move_has_force_option_described_twice.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -The **force** option in [[git-annex-move]] is described twice. - -* `--force` - - Override numcopies and required content checking, and always remove - files from the source repository once the destination repository has a - copy. - - Note that, even without this option, you can move the content of a file - from one repository to another when numcopies is not satisfied, as long - as the move does not result in there being fewer copies. - -* `--force` - - When moving content from a remote, ignore location tracking information - and always check if the remote has content. Can be useful if the location - tracking information is out of date. - -> Removed the latter, and as far as I could gather on irc, the desired -> behavior was the former. So, [[done]] --[[Joey]] diff --git a/doc/bugs/g-a_move_has_force_option_described_twice/comment_1_1ff90a7b1df3ebad2e1f17726d7d4fd7._comment b/doc/bugs/g-a_move_has_force_option_described_twice/comment_1_1ff90a7b1df3ebad2e1f17726d7d4fd7._comment deleted file mode 100644 index 140c1ff52a..0000000000 --- a/doc/bugs/g-a_move_has_force_option_described_twice/comment_1_1ff90a7b1df3ebad2e1f17726d7d4fd7._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-05-21T16:42:51Z" - content=""" -Worse, it's forcing two unrelated behaviors and the user may only -want one of them. - -The numcopies check override --force was only recently -added. - -The location tracking ignore --force is older, but is unlike -other uses of --force in git-annex. It's so off the radar that it was an -undocumented option from 2013 until I noticed the documentation was missing -in 2017! Also, it's not clear if/when anyone would use that. Seems like -running `git annex sync` first would be more efficient and have the same -result. - -So, I'm inclined to keep the numcopies check --force, which matches other -uses of --force in git-annex (eg drop --force), and remove the other ---force behavior, or make it be a differently named option. --slow -would be a good name, by contrast with move --fast. -"""]] diff --git a/doc/bugs/g-a_move_has_force_option_described_twice/comment_2_71eed2cf7fd21634a2b60ef5cd9ccb93._comment b/doc/bugs/g-a_move_has_force_option_described_twice/comment_2_71eed2cf7fd21634a2b60ef5cd9ccb93._comment deleted file mode 100644 index daa49e540c..0000000000 --- a/doc/bugs/g-a_move_has_force_option_described_twice/comment_2_71eed2cf7fd21634a2b60ef5cd9ccb93._comment +++ /dev/null @@ -1,32 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-05-21T17:04:56Z" - content=""" -Actually the --force documentation re location tracking is not a good -description of the behavior. It only affects --from, and with --force -it still contacts the remote to check if it has the content. Only -if that check fails to return a result (ie, the remote can't be contacted), -does it assume that the remote has the content, rather than the default -behavior of falling back to looking at the location tracking information. - -It's hard to see how that could be useful at all; if it fails in -communication with the remote, presumably the content transfer will later -fail as well. - -The only actual behavior change would be when the remote cannot be -contacted, and the location tracking information says it does not contain a -file. Then `move --force --from remote` will fail, because it tries -to perform the move and can't contact the remote, while `move --from -remote` will succeed, because it assumes the location tracking is right. - -That does not seem a useful distinction. And that was the behavior all the -way back to the first commit of this "feature" in 2013. - -So, removing that. - ----- - -There may be room for a new option that actually does whatever you were -hoping --force did. So let's talk about that.. -"""]] diff --git a/doc/bugs/gcrypt_repository_not_found.mdwn b/doc/bugs/gcrypt_repository_not_found.mdwn deleted file mode 100644 index f54c050a67..0000000000 --- a/doc/bugs/gcrypt_repository_not_found.mdwn +++ /dev/null @@ -1,79 +0,0 @@ -### Please describe the problem. - -I seem to be incapable of creating an encrypted git-annex repository with the instructions provided at [[tips/fully_encrypted_git_repositories_with_gcrypt/]]. The setup step fails with *gcrypt: Repository not found: (path-to-repo)*. - -### What steps will reproduce the problem? - -I *think* I naively followed the tips page, but I might be wrong. Here's the minimal reproducer I could find, but originally the problem occured with an SSH remote which I thought was the culprit. - - git init a - git init --bare b - cd a - git annex init - echo > foo - git annex add foo - git commit -m'test repo' - git annex initremote encrypted type=gcrypt gitrepo=~/tmp/b keyid=8DC901CE64146C048AD50FBB792152527B75921E - - -### What version of git-annex are you using? On what operating system? - -This is Debian stretch with backports, so git-annex is actually from backports (6.20180509-1~bpo9+1): - - git-annex version: 6.20180509 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - local repository version: unknown - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -git-remote-gcrypt is the vanilla version from stretch (1.0.1-1) but the bug can be reproduced with the 1.1 version from sid. - -### Please provide any additional information below. - -[[!format sh """ - -[18]anarcat@curie:tmp$ git init a -Dépôt Git vide initialisé dans /home/anarcat/dist/tmp/a/.git/ -[19]anarcat@curie:tmp$ git init --bare b -Dépôt Git vide initialisé dans /home/anarcat/dist/tmp/b/ -[20]anarcat@curie:tmp$ cd a -/home/anarcat/dist/tmp/a -[21]anarcat@curie:a$ git annex init -init ok -(recording state in git...) -[22]anarcat@curie:a$ echo > foo -[23]anarcat@curie:a$ git annex add foo -add foo ok -(recording state in git...) -[24]anarcat@curie:a$ git commit -m'test repo' -[master (commit racine) f759ebe] test repo - 1 file changed, 1 insertion(+) - create mode 120000 foo -[25]anarcat@curie:a$ git annex initremote encrypted type=gcrypt gitrepo=~/tmp/b keyid=8DC901CE64146C048AD50FBB792152527B75921E -initremote encrypted (encryption setup) (to gpg keys: 792152527B75921E) gcrypt: Repository not found: /home/anarcat/tmp/b -gcrypt: Repository not found: /home/anarcat/tmp/b -fatal: helper gcrypt does not support --signed=if-asked -git-annex: unable to determine gcrypt-id of remote -"""]] - -Note that this failure leaves the repository with an half-configured remote. Trying to rerun the setup gives this error: - - git-annex: There is already a remote named "encrypted" - -Removing the remote seems to be sufficient to restore a working state and try again: - - git remote rm encrypted - -I also note that the `encryption step` part takes a looong time when we try to reproduce the issue multiple time... I will report this in a separate issue. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Of course! As you very likely know, I use git-annex daily and I'm a really happy user. :) This is, however, the first time I give gcrypt a shot. - -Thanks for your hard work! --[[anarcat]] - -Update: turns out this is a bug in git-remote-gcrypt and this probably doesn't need to be tracked in git-annex. the workaround is to comment out the `push.sign=ifAsked` entry in the git config, or to make git-remote-gcrypt ignore unknown options. so [[done]]. --[[anarcat]] diff --git a/doc/bugs/gcrypt_repository_not_found/comment_1_40b31c79eedb59e66ef34e27ed7d137d._comment b/doc/bugs/gcrypt_repository_not_found/comment_1_40b31c79eedb59e66ef34e27ed7d137d._comment deleted file mode 100644 index fa0a135f81..0000000000 --- a/doc/bugs/gcrypt_repository_not_found/comment_1_40b31c79eedb59e66ef34e27ed7d137d._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="spwhitton" - avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb" - subject="analysis" - date="2018-05-17T19:49:04Z" - content=""" -\"Repository not found\" is expected when you have not yet pushed with gcrypt. - -I think the error is rather that git-annex is passing `--signed=if-asked` to git-remote-gcrypt and it does not like that, dies and never sets up the repository. - -I am not sure whether git-annex should stop passing that option, or git-remote-gcrypt should accept the option and do nothing with it. -"""]] diff --git a/doc/bugs/gcrypt_repository_not_found/comment_2_bc67619191380b6cb2555998b2da9e88._comment b/doc/bugs/gcrypt_repository_not_found/comment_2_bc67619191380b6cb2555998b2da9e88._comment deleted file mode 100644 index f9b2ebd0f8..0000000000 --- a/doc/bugs/gcrypt_repository_not_found/comment_2_bc67619191380b6cb2555998b2da9e88._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7" - subject=".gitconfig was the cause, git-remote-gcrypt probably at fault" - date="2018-05-17T20:42:37Z" - content=""" -I understand, thanks for the analysis! - -As it turns out, the problem was that I had this block in my `~/.gitconfig`: - - [push] - gpgSign = if-asked - -This means that git-annex is not the component that was passing the -argument. That's why I couldn't find it anywhere in the source. git -itself was passing this along. - -I would then make the argument that git-remote-gcrypt is the one that -should be more tolerant to those arguments. Should I send a pull -request for this? -"""]] diff --git a/doc/bugs/gcrypt_repository_not_found/comment_3_6278a373a323b621edfe1995a8685e8c._comment b/doc/bugs/gcrypt_repository_not_found/comment_3_6278a373a323b621edfe1995a8685e8c._comment deleted file mode 100644 index eb94ebfac5..0000000000 --- a/doc/bugs/gcrypt_repository_not_found/comment_3_6278a373a323b621edfe1995a8685e8c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="spwhitton" - avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb" - subject="patches welcome" - date="2018-05-17T21:31:00Z" - content=""" -Patches would be very welcome! -"""]] diff --git a/doc/bugs/gcrypt_repository_not_found/comment_4_166597e046b4bc1d3770c1e8a4191832._comment b/doc/bugs/gcrypt_repository_not_found/comment_4_166597e046b4bc1d3770c1e8a4191832._comment deleted file mode 100644 index 05467d60c4..0000000000 --- a/doc/bugs/gcrypt_repository_not_found/comment_4_166597e046b4bc1d3770c1e8a4191832._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7" - subject="comment 4" - date="2018-05-22T20:54:13Z" - content=""" -sent a crude patch by email. -"""]] diff --git a/doc/bugs/get_from_exporttree_remote_sometimes_fails.mdwn b/doc/bugs/get_from_exporttree_remote_sometimes_fails.mdwn deleted file mode 100644 index 5d0fd48aef..0000000000 --- a/doc/bugs/get_from_exporttree_remote_sometimes_fails.mdwn +++ /dev/null @@ -1,91 +0,0 @@ -I have a case where `whereis` knows that a file is present in an exporttree -remote, but `get` fails: - - joey@darkstar:/tmp/bench/repoclone>git annex whereis bar - whereis bar (1 copy) - b1a73a91-5f79-4b4b-b838-683e602b2888 -- joey@darkstar:/tmp/bench/repo - - The following untrusted locations may also have copies: - 163219a6-fdc1-4d3e-98a6-7aed3e9d605d -- [dir] - ok - joey@darkstar:/tmp/bench/repoclone>git annex get bar - get bar - Unable to access these remotes: dir - - Try making some of these repositories available: - 163219a6-fdc1-4d3e-98a6-7aed3e9d605d -- [dir] - b1a73a91-5f79-4b4b-b838-683e602b2888 -- joey@darkstar:/tmp/bench/repo - failed - git-annex: get: 1 failed - - exit 1 - -Reproducible with git-annex 7.20181106-g58d1b2510 using this script. - -It looks like the export database is not getting updated to reflect the -export that was made in the other clone of the repository. - ---[[Joey]] - -> Hmm, `git annex sync --content` complains that there was an export -> conflict, and unexports bar to resolve it. And indeed, there is a -> conflict, since export was run in the two different repos without -> syncing in between. -> -> When there's no conflict, the `git annex get` does succeed. -> -> So the real problem here is that, during an export conflict, there -> is no indication in `git annex get` about why retrival from the export -> fails. -> -> Also, `git annex get --from dir` / `git annex copy --from dir` -> silently does nothing. - -> Both turn out to only happen with a directory special remote, because it -> has checkPresentCheap = True. Other special remotes will fail -> with "unknown export location", which is not a great error message -> either but at least hints at the problem. -> -> Made it display a better error message. [[done]] - -
-#!/bin/sh
-set -e
-mkdir /tmp/bench
-cd /tmp/bench
-mkdir d
-git init repo
-cd repo
-git annex init
-echo foo > foo
-git add foo
-git commit -m add
-git annex initremote dir type=directory directory=../d encryption=none exporttree=yes
-cd ..
-git clone repo repoclone
-cd repoclone
-git annex enableremote dir directory=../d
-set +e
-git-annex export --tracking master --to dir
-echo "above expected to fail as foo's content is not present"
-set -e
-cd ../repo
-git-annex export --tracking master --to dir
-cd ../repoclone
-git fetch
-git annex whereis foo
-git annex get foo
-git-annex export --tracking master --to dir
-
-cd ../repo
-echo bar > bar
-git annex add
-git commit -m add
-git-annex export --tracking master --to dir
-
-cd ../repoclone
-git fetch
-git merge
-git annex whereis bar
-git remote rm origin
-git annex get bar
-
diff --git a/doc/bugs/git-annex-drop_docs_and_git-annex-requires.mdwn b/doc/bugs/git-annex-drop_docs_and_git-annex-requires.mdwn deleted file mode 100644 index 5b86a6e24d..0000000000 --- a/doc/bugs/git-annex-drop_docs_and_git-annex-requires.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -The [[`git-annex-drop`|git-annex-drop]] man page warns for several options: "bypasses checking the .gitattributes `annex.numcopies` setting". I'm guessing these also bypass [[`git-annex-required`|git-annex-required]] ? If yes, maybe add that to the manpage. - -> Good spotting, I've done so. [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__.mdwn b/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__.mdwn deleted file mode 100644 index 83a418e59e..0000000000 --- a/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__.mdwn +++ /dev/null @@ -1,53 +0,0 @@ -### Please describe the problem. -When exporting a treeish with a subdir to a dir special remote, it fails with the error: -[[!format sh """ -git annex export master:subdir --to exportdir - -fatal: Path 'subdir:' does not exist (neither on disk nor in the index). -git-annex: unknown tree -"""]] - -I tried other treeish variations such as :./subdir, master:subdir but it didn't work either. -What is very strange to me is the ':' appended at the end of the path in the error. -Any idea what is going on here ? - - -### What steps will reproduce the problem? -[[!format sh """ -mkdir annex -mv annex -git init annex -git annex init --version=6 -touch a.txt -mkdir subdir -touch subdir/b.txt -git commit -m "initial commit" -mkdir ../exportdir -git annex initremote exportdir type=directory directory=../exportdir/ encryption=none exporttree=yes -git annex export master:subdir --to exportdir - -fatal: Path 'subdir:' does not exist (neither on disk nor in the index). -git-annex: unknown tree -"""]] - - -### What version of git-annex are you using? On what operating system? -[[!format sh """ -git annex version - -git-annex version: 6.20171003 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -dependency versions: aws-0.13.0 bloomfilter-2.0.1.0 cryptonite-0.10 DAV-1.2 feed-0.3.10.4 ghc-7.10.3 http-client-0.4.26.2 persistent-sqlite-2.2 torrent-10000.0.0 uuid-1.3.11 yesod-1.4.2 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -"""]] - - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yep, it has been a long time since I used it but I am back to see what I can do to manage my files properly :) - -> [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__/comment_1_ef090d1e29d1724aa1751b6cf874c537._comment b/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__/comment_1_ef090d1e29d1724aa1751b6cf874c537._comment deleted file mode 100644 index 42a4155453..0000000000 --- a/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__/comment_1_ef090d1e29d1724aa1751b6cf874c537._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="webanck" - avatar="http://cdn.libravatar.org/avatar/cd273f76ef8c4218510b4f50ef7e1f3d" - subject="comment 1" - date="2018-07-31T12:41:44Z" - content=""" -Well, I can answer myself now. -It wasn't working because my version of git was too old. -I updated to version 2.18.0 and it works very well now ! -It might be a good idea to find and specify the minimal git version needed to make this work next in the man page of git annex export for instance ;) -"""]] diff --git a/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__/comment_2_d3808b85328fbbc6f4aef5086e225187._comment b/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__/comment_2_d3808b85328fbbc6f4aef5086e225187._comment deleted file mode 100644 index 68aea9ad74..0000000000 --- a/doc/bugs/git-annex-export_treeish_subdir_path_does_not_exist__91____91__done__93____93__/comment_2_d3808b85328fbbc6f4aef5086e225187._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-08-03T17:31:39Z" - content=""" -It wasn't upgrading git that fixed it. The bug you reported was present in -git-annex versions before 6.20171109. You had an older version listed -in the bug report, so I assume you also upgraded git-annex to the fixed -version. -"""]] diff --git a/doc/bugs/git-annex-init_with_no_args_overwrites_existing_repo_description.mdwn b/doc/bugs/git-annex-init_with_no_args_overwrites_existing_repo_description.mdwn deleted file mode 100644 index 6687d61cc4..0000000000 --- a/doc/bugs/git-annex-init_with_no_args_overwrites_existing_repo_description.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -### Please describe the problem. -The man page for [[`git-annex-init`|git-annex-init]] suggests that it is idempotent. But, when run with no args, it will overwrite an existing repo description with an automatically-generated one. Same for [[`git-annex-describe`|git-annex-describe]]. - -### What version of git-annex are you using? On what operating system? -(master_env_v135_py36) 13:44 [r2] $ git annex version -git-annex version: 7.20190507-g0c2cc3d -build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.4.2 http-client-0.5.14 persistent-sq\ -lite-2.9.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_\ -224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLA\ -KE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP\ -256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -operating system: linux x86_64 -supported repository versions: 5 7 -upgrade supported from repository versions: 0 1 2 3 4 5 6 -local repository version: 5 -(master_env_v135_py36) 13:47 [r2] $ uname -a -Linux ip-172-31-90-58.ec2.internal 4.14.114-105.126.amzn2.x86_64 #1 SMP Tue May 7 02:26:40 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex-init_with_no_args_overwrites_existing_repo_description/comment_1_7facb84de8c8148e8f12ba2c4bd5c74b._comment b/doc/bugs/git-annex-init_with_no_args_overwrites_existing_repo_description/comment_1_7facb84de8c8148e8f12ba2c4bd5c74b._comment deleted file mode 100644 index 1dd9222c99..0000000000 --- a/doc/bugs/git-annex-init_with_no_args_overwrites_existing_repo_description/comment_1_7facb84de8c8148e8f12ba2c4bd5c74b._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-05-23T16:40:50Z" - content=""" -Yikes, I was surprised to see this behavior. fixed for `init`. - -For `describe`, I see that when it's run with no parameter for the -description, it sets the description to "". I suppose that's what you -meant. - -I suppose something could conceivably depend on the current `git annex -describe remote` behavior, but I checked and it's nowhere documented that -describe with no description is allowed -- even the --help doesn't say that -luckily. So I have also disallowed that. -"""]] diff --git a/doc/bugs/git-annex-migrate_fails.mdwn b/doc/bugs/git-annex-migrate_fails.mdwn deleted file mode 100644 index 23c5d2d54b..0000000000 --- a/doc/bugs/git-annex-migrate_fails.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -Migrating from a URL key to an MD5E key (after addurl --fast using an external special remote) fails: - - (master_env_py27_v28) [03:15 PM /data/ilya-work]$ git annex --verbose --debug migrate A4.taxfilt.bam - [2018-10-29 15:15:55.197015] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","A4.taxfilt.bam"] - [2018-10-29 15:15:55.232756] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"] - [2018-10-29 15:15:55.232934] read: git ["--version"] - [2018-10-29 15:15:55.233841] process done ExitSuccess - migrate A4.taxfilt.bam failed - [2018-10-29 15:15:55.263931] process done ExitSuccess - git-annex: migrate: 1 failed - (master_env_py27_v28) [03:15 PM /data/ilya-work]$ git annex info A4.taxfilt.bam - file: A4.taxfilt.bam - size: 12.75 megabytes - key: URL-s12750247--dx://file-FJZjKx800YQPJ5j589Q2Kfzv/A4.taxfilt.bam - present: true - (master_env_py27_v28) [03:16 PM /data/ilya-work]$ git annex whereis A4.taxfilt.bam - whereis A4.taxfilt.bam (2 copies) - 0928dfcc-4dbe-4c24-a5a0-ac05c4a2c829 -- ilyas_main_repo [here] - 6803648c-87e6-41ef-9570-48adb13ff59a -- [mydx] - - mydx: dx://file-FJZjKx800YQPJ5j589Q2Kfzv/A4.taxfilt.bam - ok - (master_env_py27_v28) [03:16 PM /data/ilya-work]$ git annex --verbose --debug migrate A4.taxfilt.bam --backend MD5E - [2018-10-29 15:17:15.621264] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","A4.taxfilt.bam"] - migrate A4.taxfilt.bam failed - git-annex: migrate: 1 failed - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex-migrate_fails/comment_1_4f8fb57ce001e0a2e1636bd7b3b79d43._comment b/doc/bugs/git-annex-migrate_fails/comment_1_4f8fb57ce001e0a2e1636bd7b3b79d43._comment deleted file mode 100644 index 65dc057c50..0000000000 --- a/doc/bugs/git-annex-migrate_fails/comment_1_4f8fb57ce001e0a2e1636bd7b3b79d43._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-10-29T20:04:48Z" - content=""" -To reproduce this bug: - - joey@darkstar:/tmp/t>git annex addurl --fast --raw http://www.google.com/ --file A4.taxfilt.bam - addurl http://www.google.com/ (to A4.taxfilt.bam) ok - (recording state in git...) - joey@darkstar:/tmp/t>git annex get A4.taxfilt.bam - get A4.taxfilt.bam (from web...) - - ok - (recording state in git...) - joey@darkstar:/tmp/t>git annex migrate --backend=MD5E A4.taxfilt.bam - migrate A4.taxfilt.bam failed - git-annex: migrate: 1 failed - -Seems to be a bug in handling backends with fastMigrate = Nothing, causing -it to stop immediately without doing anything. Reversion introduced in -[[!commit 4ecba916a14e02dd62f8ba4257db810fa859f017]]. - -And calling `stop` in a CommandPerform causes this failure without an -explanation. I think that would be worth cleaning up at some point; -[[todo/do_not_allow_using_stop_in_CommandPerform]]. -"""]] diff --git a/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH.mdwn b/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH.mdwn deleted file mode 100644 index cae97ba438..0000000000 --- a/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -### Please describe the problem. -git-annex-shell -c configlist /home/annex/test2.git, when ran via sudo (login shell or otherwise), works fine. When executed equivalently over SSH, this error is given: -[[!format sh """ -git-annex-shell: failed to read git config of git repository in unknown on /home/annex/test2.git; perhaps this repository is not set up correctly or has moved -"""]] - -(note: I am using a workaround necessary due to another bug with git-annex-shell, I will also post that bug) - -### What steps will reproduce the problem? -See the transcript. - -### What version of git-annex are you using? On what operating system? -6.20180529 on NixOS. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -[leo60228@nixos:~/test]$ ssh annex@localhost 'git-annex-shell -c configlist /home/annex/test2.git' -git-annex-shell: failed to read git config of git repository in unknown on /home/annex/test2.git; perhaps this repository is not set up correctly or has moved - -[leo60228@nixos:~/test]$ sudo -i -u annex git-annex-shell -c configlist /home/annex/test2.git -annex.uuid=425c1e27-97df-4c14-8bf3-d7473e78dbfd -core.gcrypt-id= - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes. - -[[done]] diff --git a/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH/comment_1_5d80f357a7f6513ccd949e58da572637._comment b/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH/comment_1_5d80f357a7f6513ccd949e58da572637._comment deleted file mode 100644 index f674929b8c..0000000000 --- a/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH/comment_1_5d80f357a7f6513ccd949e58da572637._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://openid-provider.appspot.com/iakornfeld" - nickname="iakornfeld" - avatar="http://cdn.libravatar.org/avatar/c0369f5727cad81d1ecf6c2e657b42a1b756284aad0229351f9027a2cfcb2037" - subject="Please close" - date="2018-07-22T19:07:16Z" - content=""" -This was my fault. -"""]] diff --git a/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH/comment_2_6d1fa3ebc5bf20ebc3422a660f2c9632._comment b/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH/comment_2_6d1fa3ebc5bf20ebc3422a660f2c9632._comment deleted file mode 100644 index e4cfa8e130..0000000000 --- a/doc/bugs/git-annex-shell_configlist_doesn__39__t_work_over_SSH/comment_2_6d1fa3ebc5bf20ebc3422a660f2c9632._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="andrew" - avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" - subject="comment 2" - date="2018-07-23T22:37:39Z" - content=""" -OK. You can add [[done]] to the end of the original bug description to close it for future reference. I'll do that now. - -Andrew -"""]] diff --git a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch.mdwn b/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch.mdwn deleted file mode 100644 index ee81fa86dc..0000000000 --- a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -### Please describe the problem. -I have a V6 annex in adjusted branch with a submodule, which also is a V6 annex in adjusted branch. -There staged changes in the superproject, while the submodule is clean. Calling git-annex-sync in the superproject now leads to: - -[[!format sh """ -% git annex sync -commit (recording state in git...) - -[adjusted/master(unlocked) 3c8d350] git-annex in me@mycomputer:/tmp/datalad_temp_test_AnnexRepo_statusGmqM5E - 4 files changed, 4 insertions(+), 2 deletions(-) - create mode 100644 fifth - create mode 100644 sub/third -ok -fatal: entry 'submod' object type (blob) doesn't match mode type (commit) - -git-annex: user error (git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","mktree","--batch","-z"] exited 128) -failed -git-annex: sync: 1 failed -"""]] - -### What steps will reproduce the problem? - -Sadly I wasn't able to reproduce it outside the datalad test it is happening in. -I will provide the steps to achieve that situation, whenever I figured them out. -But may be just the error message is sufficient to address the problem ... - -### What version of git-annex are you using? On what operating system? -[[!format sh """ -% git annex version -git-annex version: 6.20170307+gitg24ade8a25-1~ndall+1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 3 5 6 -upgrade supported from repository -"""]] -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - -[[ben]] - -[[!tag confirmed]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_1_f85e1b0af1a1f67c39806ba69cb0c4ed._comment b/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_1_f85e1b0af1a1f67c39806ba69cb0c4ed._comment deleted file mode 100644 index 98808a39a8..0000000000 --- a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_1_f85e1b0af1a1f67c39806ba69cb0c4ed._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-10-26T17:04:09Z" - content=""" -Have you ever seen this again or have any more information about how to -reproduce it? - -This seems similar to the problem fixed by [[!commit a13c0ce66c6dd5d8cf5b09ee2fc5a58f43db4b14]] -but the version you were using already had that commit in it. -"""]] diff --git a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_2_553ef5764840412a5942cc686338f19c._comment b/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_2_553ef5764840412a5942cc686338f19c._comment deleted file mode 100644 index 9bf47f64a5..0000000000 --- a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_2_553ef5764840412a5942cc686338f19c._comment +++ /dev/null @@ -1,41 +0,0 @@ -[[!comment format=mdwn - username="https://tribut.de/" - nickname="Felix" - avatar="http://cdn.libravatar.org/avatar/d7508a030fd9902a76b02f7feff1327e80400a1317ee98e463c68ef4c9c40bb8" - subject="comment 2" - date="2019-09-09T09:01:26Z" - content=""" -Just encountered the same error. I can reproduce like this: - - $ git init foobar - $ cd foobar/ - $ git annex init - $ git annex upgrade - $ touch baz - $ git add baz - $ git commit -m \"baz\" - $ git annex adjust --unlock - $ git submodule add https://github.com/tribut/homeassistant-docker-venv.git qux - $ git add qux - $ git commit -m \"qux\" - $ git annex sync - commit - On branch adjusted/master(unlocked) - nothing to commit, working tree clean - ok - fatal: entry 'qux' object type (blob) doesn't match mode type (commit) - git-annex: user error (git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"mktree\",\"--batch\",\"-z\"] exited 128) - -May it is related to gpg signatures? When I ran the exact same thing on my main machine, where `commit.gpgSign` is `true` I got instead: - - $ git annex sync - commit - On branch adjusted/master(unlocked) - nothing to commit, working tree clean - ok - git-annex: bad srcsha - CallStack (from HasCallStack): - error, called at ./Git/DiffTree.hs:113:39 in main:Git.DiffTree - -I'm running git-annex 7.20190731-gbb16a2610 using the standalone version. -"""]] diff --git a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_3_63ae1e0e0437c83516d167be142a8179._comment b/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_3_63ae1e0e0437c83516d167be142a8179._comment deleted file mode 100644 index e15ab3380e..0000000000 --- a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_3_63ae1e0e0437c83516d167be142a8179._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://tribut.de/" - nickname="Felix" - avatar="http://cdn.libravatar.org/avatar/d7508a030fd9902a76b02f7feff1327e80400a1317ee98e463c68ef4c9c40bb8" - subject="comment 3" - date="2019-10-14T09:33:34Z" - content=""" -`git annex sync` fails even when `commit.gpgSign` is `false` and I use a repository without signatures as submodule. So my hunch about signatures was probably not correct. -"""]] diff --git a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_4_6967c227baf07eae6c8e94661531cf11._comment b/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_4_6967c227baf07eae6c8e94661531cf11._comment deleted file mode 100644 index 034cc005b0..0000000000 --- a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_4_6967c227baf07eae6c8e94661531cf11._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2019-10-22T19:30:57Z" - content=""" -Reproduced using Felix's recipe, with current git-annex. -"""]] diff --git a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_5_13ab25e3e05d88c755270c3dca3ddffc._comment b/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_5_13ab25e3e05d88c755270c3dca3ddffc._comment deleted file mode 100644 index 25583e15de..0000000000 --- a/doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_5_13ab25e3e05d88c755270c3dca3ddffc._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2019-10-22T19:43:21Z" - content=""" -Instrumenting, this is fed into git mktree: - - 160000 blob 6941fd9c7ad9640f75a02c993245b8de784105e1\tqux\NUL - -So the problem is it's got the mode for a submodule, but the wrong type, blob. - -Internally, git-annex has generated this, which seems wrong. It should be a TreeCommit. - - TreeBlob (TopFilePath {getTopFilePath = "qux"}) 57344 (Ref "6941fd9c7ad9640f75a02c993245b8de784105e1") - -(57344 = 160000 oct) - -So need to debug the parsing of the input git tree next.. -"""]] diff --git a/doc/bugs/git-annex_6.20161031_fails_with_filenames_containing_newlines.mdwn b/doc/bugs/git-annex_6.20161031_fails_with_filenames_containing_newlines.mdwn deleted file mode 100644 index 03ae68fa69..0000000000 --- a/doc/bugs/git-annex_6.20161031_fails_with_filenames_containing_newlines.mdwn +++ /dev/null @@ -1,46 +0,0 @@ -### Please describe the problem. - -I tried to add a bunch of files and one of the files contained a newline in its name. -When doing 'git annex add .' it failed with an error that contained only the part of the filename before the newline. - -### What steps will reproduce the problem? - -Create a file with a newline in its name: - - ~/tmp $ touch 'file with newline'$'\n''line 2' - ~/tmp $ mkdir annex - ~/tmp $ cd annex/ - ~/tmp/annex $ git init - ~/tmp/annex $ git annex init - init ok - (recording state in git...) - ~/tmp/annex $ cp ../file* . - ~/tmp/annex $ git annex add . - add file with newline - line 2 git-annex: unknown response from git cat-file ("HEAD:./file with newline missing",Ref "HEAD:./file with newline\nline 2") - ~/tmp/annex $ - -### What version of git-annex are you using? On what operating system? - -6.20161031 on Gentoo Linux - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. - -please see above - -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I hope to have very soon ;-) - -> This is a duplicate of [[this bug report|git_annex_import_fails_on_filenames_with_newlines_in_them]]. -> Closing as dup. [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn deleted file mode 100644 index baf7d4355e..0000000000 --- a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -### Please describe the problem. - -Received the following error upon syncing a large repo. - - git-annex: unable to decommit memory: Invalid argument - -### What steps will reproduce the problem? - -Not sure. I tried creating a small test repo, adding files, and syncing, but it did not produce the error. - -### What version of git-annex are you using? On what operating system? - - git-annex version: 6.20161211+gitgc3ab3c6-1~ndall+1 - -... via the neurodebian repo. On Xubuntu 14.04 64x - - uname -r: 3.13.0-106-generic - -### Please provide any additional information below. - -My files appear to be okay, and otherwise the annex seems to be functioning normally. - -Nonetheless I'm hesitant to use it while this error occurs. Is safe to keep using my annex in spite of the error? - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I've been using git-annex for at least a year now. It's one of the greatest tools I've ever found, and is indispensable for some of my work. I can't recall any other problems I've had that weren't user-caused. So thank you! - -> According to yoh, this is fixed in the neurodebian build now. [[done]] -> --[[Joey]] diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_1_9b81586657226bf010145d1cd661885a._comment b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_1_9b81586657226bf010145d1cd661885a._comment deleted file mode 100644 index c00a7465f2..0000000000 --- a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_1_9b81586657226bf010145d1cd661885a._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-12-30T22:26:10Z" - content=""" -This is a known bug, that is supposed to be fixed in 6.20161210. - -However, the fix involved upgrading the ghc compiler. I think that probably -this has not been done in the neurodebian build yet. I will mention it to -yoh again. -"""]] diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_2_792e40149bb2ae55206ebe9cea151831._comment b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_2_792e40149bb2ae55206ebe9cea151831._comment deleted file mode 100644 index 67d5734986..0000000000 --- a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_2_792e40149bb2ae55206ebe9cea151831._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="ghen1" - avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6" - subject="To Reproduce" - date="2016-12-31T14:19:07Z" - content=""" -I've successfully reproduced the error. - -Steps: - -1. Create 5k small files using a script. (I used one given here: ) -2. Init git and git-annex -3. Add files to git-annex. **The error occurs here** after/while (recording state in git...) - -If no error occurs, try increasing the number of files to 10k or more. - -I ran both *status* and *fsck* in both git and git-annex, with no errors, so AFAIK it hasn't corrupted anything. -"""]] diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment deleted file mode 100644 index 28e3296324..0000000000 --- a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da" - subject="fresh git annex standalone was uploaded to NeuroDebian" - date="2017-01-03T16:03:52Z" - content=""" -just uploaded 6.20170101+gitg93d69b1-1~ndall+1 which was built using ghc 8.0.1-17 on stretch. Enjoy -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum.mdwn b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum.mdwn deleted file mode 100644 index ec8d57b652..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum.mdwn +++ /dev/null @@ -1,52 +0,0 @@ -### Please describe the problem. -Files with special unicode characters(in this case japanese) for some reason have the characters added to the file key. - -This is an issue because it causes errors when using glacier-cli when uploading copies to Glacier vault. - -[[!meta title="kanji in key extension cause glacier-cli upload error"]] - -### What steps will reproduce the problem? -Here's how it looks for me: - -[[!format sh """ -% ls -l 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -lrwxrwxrwx 1 sochan sochan 221 Mar 3 13:37 12. Change The World (feat. 웅산).mp3 -> ../../../.git/annex/objects/6G/8K/SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3/SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - % g an info 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -file: 12. Change The World (feat. 웅산).mp3 -size: 7.48 megabytes -key: SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 -present: true - % g an calckey 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - % sha256sum 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09 12. Change The World (feat. 웅산).mp3 -"""]] - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ - % git-annex version -git-annex version: 6.20170101.1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -% lsb_release -a -No LSB modules are available. -Distributor ID: Debian -Description: Debian GNU/Linux 9.3 (stretch) -Release: 9.3 -Codename: stretch -"""]] - -### Please provide any additional information below. -Here's a sample file: -https://www.dropbox.com/s/kghlz41ooaqfr0h/12.%20Change%20The%20World%20%28feat.%20%EC%9B%85%EC%82%B0%29.mp3?dl=0 - -### Have you had any luck using git-annex before? -Dude, I love git-annex. I use it to have multiple copies of my HUGE music collection. I love that I can just have partial copies of my whole collection on my laptop/phone/remote servers/usb drive backup and have that all documented properly. This is some amazing software my man! - -> [[done]]; see comments --[[Joey]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_1_360b2731bde42fc3fcb621b9fa467153._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_1_360b2731bde42fc3fcb621b9fa467153._comment deleted file mode 100644 index 8a0b6120d9..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_1_360b2731bde42fc3fcb621b9fa467153._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="i@f4fc1d4ed8c7cc91fc284462cb631c270a5195e9" - nickname="i" - avatar="http://cdn.libravatar.org/avatar/661785c9bf4c87cc795f130b47a1c4ae" - subject="checked 6.20180112 and it's the same" - date="2018-03-03T16:21:06Z" - content=""" -I installed git-annex from Debian buster(6.20180112) and checked, I get the same thing from calckey: - -[[!format sh \"\"\" - % g an version -git-annex version: 6.20180112 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.1 persistent-sqlite-2.6.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 - % g an calckey 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 -\"\"\"]] -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_2_2c0729d9beb09c0392be6d63b491d9ca._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_2_2c0729d9beb09c0392be6d63b491d9ca._comment deleted file mode 100644 index 7d404f0574..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_2_2c0729d9beb09c0392be6d63b491d9ca._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="i@f4fc1d4ed8c7cc91fc284462cb631c270a5195e9" - nickname="i" - avatar="http://cdn.libravatar.org/avatar/661785c9bf4c87cc795f130b47a1c4ae" - subject="I've also upgraded the repo to version 6" - date="2018-03-03T16:23:37Z" - content=""" -[[!format sh \"\"\" - % g an upgrade -upgrade (v5 to v6...) (scanning for unlocked files...) -ok - % g an info 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -file: 12. Change The World (feat. 웅산).mp3 -size: 7.48 megabytes -key: SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 -present: true - % g an calckey 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 -\"\"\"]] - -Same thing with upgraded repo version. -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_3_4e95c616da82eea1437744aaf02f39dd._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_3_4e95c616da82eea1437744aaf02f39dd._comment deleted file mode 100644 index 70e14e80f3..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_3_4e95c616da82eea1437744aaf02f39dd._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="i@f4fc1d4ed8c7cc91fc284462cb631c270a5195e9" - nickname="i" - avatar="http://cdn.libravatar.org/avatar/661785c9bf4c87cc795f130b47a1c4ae" - subject="this has something to do with the dot and space" - date="2018-03-03T16:43:27Z" - content=""" -I did some tests and apparently this happens only if the characters are proceeded by a dot and/or space: - -[[!format sh \"\"\" - sochan@melchior: 2011 - Kaleidoscope% g an calckey Change.\ 웅산\).mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - sochan@melchior: 2011 - Kaleidoscope% g an calckey Change.\ 웅산.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - sochan@melchior: 2011 - Kaleidoscope% g an calckey Change.웅산.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - sochan@melchior: 2011 - Kaleidoscope% g an calckey test_.웅산.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - sochan@melchior: 2011 - Kaleidoscope% g an calckey test_웅산.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.mp3 - sochan@melchior: 2011 - Kaleidoscope% g an calckey test_.\ 웅산.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - sochan@melchior: 2011 - Kaleidoscope% g an calckey test_.\ \ 웅산.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - sochan@melchior: 2011 - Kaleidoscope% g an calckey test_.\ \ \ 웅산.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.mp3 -\"\"\"]] - -This leads me to thinking that this MIGHT have something to do with code that deals with file extensions. -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_5_7f5a6ba6ed7b6f720874f8ded6edaa3c._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_5_7f5a6ba6ed7b6f720874f8ded6edaa3c._comment deleted file mode 100644 index 1d8e1cabeb..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_5_7f5a6ba6ed7b6f720874f8ded6edaa3c._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2018-03-05T14:47:20Z" - content=""" -The easy workaround to bugs like this migrate the file to the -SHA256 backend rather than SHA256E. - -It may be obvious to us that a file ending in "(feat. xy).mp3" -has an extension of ".mp3" and not of ". xy).mp3", but this is not very -obvious to git-annex, which would like to treat a file ending in ".tar.gz" -as having that compound extension. - -The only rule I can think of that would help git-annex understand this is -to not allow punctuation (other than "." in file extensions). Which it -actually already filters out of extensions, which is why the extension it -comes up with is ".xy.mp3". But it could notice the space and closing paren -in the filename and assume those are not part of an extension. It might -bite some file with an extension like .foo_", I can't recall seeing many -such extensions. Ok, made this change. - -It remains a bug in the glacier special remote if unicode characters -prevent uploading to it. We can't limit file -extensions to ascii, it's perfectly reasonable to use your native language -characters in a file extension. Leaving bug open since my change does -nothing about whatever upload bug glacier-cli has. Is the python program -failing? -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_5_a160bb3ce6b8b6e1fe03d649f710806e._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_5_a160bb3ce6b8b6e1fe03d649f710806e._comment deleted file mode 100644 index f3e504313c..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_5_a160bb3ce6b8b6e1fe03d649f710806e._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="i@f4fc1d4ed8c7cc91fc284462cb631c270a5195e9" - nickname="i" - avatar="http://cdn.libravatar.org/avatar/661785c9bf4c87cc795f130b47a1c4ae" - subject="fixed prev commend" - date="2018-03-03T16:55:16Z" - content=""" -Oh man, yes, yes it does have something to do with extensions, it does not matter what it is, it gets added at the end if it is prefixed by a dot, even if there is something like a closing bracket in there: - -[[!format sh \"\"\" - % g an calckey test.wtf.mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.wtf.mp3 - % g an calckey test.wtf\).mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.wtf.mp3 -\"\"\"]] - -So it looks like I can avoid this issue by simply adding a space within the last segment after the dot, for example: - -[[!format sh \"\"\" - % g an calckey 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.웅산.mp3 - % g an calckey 12.\ Change\ The\ World\ \(feat.\ 웅산\ \).mp3 -SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.mp3 -\"\"\"]] -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_6_c39d87c005f82da6424064f61b8ccd58._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_6_c39d87c005f82da6424064f61b8ccd58._comment deleted file mode 100644 index a6b40418ff..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_6_c39d87c005f82da6424064f61b8ccd58._comment +++ /dev/null @@ -1,33 +0,0 @@ -[[!comment format=mdwn - username="i@f4fc1d4ed8c7cc91fc284462cb631c270a5195e9" - nickname="i" - avatar="http://cdn.libravatar.org/avatar/661785c9bf4c87cc795f130b47a1c4ae" - subject="thanks for the quick response!" - date="2018-03-05T17:19:19Z" - content=""" -That was really quick, thanks. I had no idea that the E in SHA256E stands for adding extensions. That makes the fix much easier, and much neater than adding spaces to filenames. Although it does make me wonder, what's the advantage of having the file extension in the key? - -And yes, the python glacier-cli is failing with: - -[[!format sh \"\"\" -% git annex copy 12.\ Change\ The\ World\ \(feat.\ 웅산\).mp3 --to glacier -copy 12. Change The World (feat. 웅산).mp3 (checking glacier...) Traceback (most recent call last): - File \"/usr/local/bin/glacier\", line 737, in - main() - File \"/usr/local/bin/glacier\", line 733, in main - App().main() - File \"/usr/local/bin/glacier\", line 719, in main - self.args.func() - File \"/usr/local/bin/glacier\", line 600, in archive_checkpresent - self.args.vault, self.args.name) - File \"/usr/local/bin/glacier\", line 161, in get_archive_last_seen - result = self._get_archive_query_by_ref(vault, ref).one() - File \"/usr/local/bin/glacier\", line 136, in _get_archive_query_by_ref - if ref.startswith('id:'): -UnicodeDecodeError: 'ascii' codec can't decode byte 0xec in position 83: ordinal not in range(128) -(user error (glacier [\"--region=eu-west-1\",\"archive\",\"checkpresent\",\"music\",\"--quiet\",\"SHA256E-s7479642--957208748ae03fe4fc8d7877b2c9d82b7f31be0726e4a3dec9063b84cc64cf09.\50885\49328.mp3\"] exited 1)) failed -git-annex: copy: 1 failed -\"\"\"]] - -I'll open an issue in their GitHub in a moment since now I can give them some more context. Cheers! -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_7_9503988854499ceb75c39ec248f7b238._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_7_9503988854499ceb75c39ec248f7b238._comment deleted file mode 100644 index 73aac58abf..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_7_9503988854499ceb75c39ec248f7b238._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="i@f4fc1d4ed8c7cc91fc284462cb631c270a5195e9" - nickname="i" - avatar="http://cdn.libravatar.org/avatar/661785c9bf4c87cc795f130b47a1c4ae" - subject="opened github issue with glacier-cli" - date="2018-03-05T17:28:53Z" - content=""" -Here's the issue: -https://github.com/basak/glacier-cli/issues/72 -"""]] diff --git a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_8_8dd44353d46d774ad376b24ecca3e56e._comment b/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_8_8dd44353d46d774ad376b24ecca3e56e._comment deleted file mode 100644 index 31f2089212..0000000000 --- a/doc/bugs/git-annex_adds_unicode_characters_at_end_of_checksum/comment_8_8dd44353d46d774ad376b24ecca3e56e._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 8""" - date="2018-03-06T17:40:50Z" - content=""" -There are a few programs that look at filename extensions and when asked to -open a git-annex symlink, resolve the symlink and look at the extension of -the file it *points* to. Mostly such programs are on OSX I think, -although there may be one or two on Linux. The extension is in the keys by -default because of that insanity. - -It might be that you could mess with your locale settings and get python to -manage to decode the unicode character. - -Since it looks like everything that it makes sense to do in git-annex has -been done, and you opened the glacier-cli bug, I suppose I'll close this -one. -"""]] diff --git a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow.mdwn b/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow.mdwn deleted file mode 100644 index b8f0d1281c..0000000000 --- a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow.mdwn +++ /dev/null @@ -1,46 +0,0 @@ -### Please describe the problem. - -i try to load add a URL to git (for later download) which is behind a CDN. -> git-annex addurl https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 - -it tells me: - -> addurl cdn.media.ccc.de_congress_2018_h264_sd_35c3_9462_eng_deu_fra_What_The_Fax_sd.mp4 (downloading https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 ...) -> Configuration does not allow accessing https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 -failed -> git-annex: addurl: 1 failed - -looking around, I find that curl itself does also not load the file. wget does out-of-the-box -hint: curl -L "--location" seems to work, as this follows the http 30x - ---> how to fix this ? - -### What steps will reproduce the problem? - -examples on top - -### What version of git-annex are you using? On what operating system? - -debian stretch, x64. git-annex as out-of-box - -> $ apt-show-versions | grep git-annex - -> git-annex:amd64/stretch 6.20170101-1+deb9u2 uptodate - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -yes ! wunderful tool. -managing my video, photo & music with it. - -> Appears to have been a local misconfiguration, not a bug. [[done]] -> --[[Joey]] diff --git a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_1_10ad677cc7b1d57c82dd46fb9849f835._comment b/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_1_10ad677cc7b1d57c82dd46fb9849f835._comment deleted file mode 100644 index 470aac142b..0000000000 --- a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_1_10ad677cc7b1d57c82dd46fb9849f835._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 1" - date="2019-01-03T12:29:41Z" - content=""" -I think this might be from a security change that was introduced recently-ish: [[news/security_fix_release/]]. - -Perhaps the redirect is not in the whitelisted schemes (or you have no schemes whitelisted)? -"""]] diff --git a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_2_d216b61f356f20245e3f65d574ef6749._comment b/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_2_d216b61f356f20245e3f65d574ef6749._comment deleted file mode 100644 index 5a833b22e5..0000000000 --- a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_2_d216b61f356f20245e3f65d574ef6749._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="ka7" - avatar="http://cdn.libravatar.org/avatar/653da3a21d59dd218e84be58bfa8ed4c" - subject="got it" - date="2019-01-03T14:10:19Z" - content=""" -adding this to .git/config - -[annex \"security\"] - allowed-url-schemes = http https - allowed-http-addresses = all - -workend for me. YMMV -"""]] diff --git a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_3_4544008749e6399d61c203d5b9ce1fff._comment b/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_3_4544008749e6399d61c203d5b9ce1fff._comment deleted file mode 100644 index 535ac041e1..0000000000 --- a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_3_4544008749e6399d61c203d5b9ce1fff._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="ka7" - avatar="http://cdn.libravatar.org/avatar/653da3a21d59dd218e84be58bfa8ed4c" - subject="(better formating..)" - date="2019-01-03T14:15:21Z" - content=""" -adding this to .git/config - ->[annex \"security\"] - -> allowed-url-schemes = http https - -> allowed-http-addresses = all - -workend for me. YMMV - -"""]] diff --git a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_4_8ecc02cb75adfaf0c0aa2f642713ebf4._comment b/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_4_8ecc02cb75adfaf0c0aa2f642713ebf4._comment deleted file mode 100644 index 7a19b481a8..0000000000 --- a/doc/bugs/git-annex_addurl___38___CDN__58___curl_does_not_follow/comment_4_8ecc02cb75adfaf0c0aa2f642713ebf4._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2019-01-21T18:29:18Z" - content=""" -allowed-url-schemes defaults to including https and http and ftp. This error -message could only happen if you had earlier set allowed-url-schemes to something -other than the default: - - joey@darkstar:/tmp/xxx>git config annex.security.allowed-url-schemes "foo" - joey@darkstar:/tmp/xxx>git annex addurl https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 - addurl https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 Configuration does not allow accessing https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 - - download failed: Configuration does not allow accessing https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 - failed - git-annex: addurl: 1 failed - joey@darkstar:/tmp/xxx>git config --unset annex.security.allowed-url-schemes - joey@darkstar:/tmp/xxx>git annex addurl https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 - addurl https://cdn.media.ccc.de/congress/2018/h264-sd/35c3-9462-eng-deu-fra-What_The_Fax_sd.mp4 - 0% 735.48 KiB 96 KiB/s 33m53s - -Whatever redirect might be involved in that url is not relevant because -this error message only occurs when the url you provided does not use an -allowed url scheme. If it had started to download and then redirected to -some other scheme, that would have resulted in a different error message. - -So, this was a local misconfiguration not a bug. -"""]] diff --git a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD.mdwn b/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD.mdwn deleted file mode 100644 index ffcf21cd1b..0000000000 --- a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -### Please describe the problem. - -git-annex can't compile on FreeBSD; specifically, the build fails while satisfying dependencies. - -### What steps will reproduce the problem? - -1. git clone git://git-annex.branchable.com/ git-annex -2. cd git-annex -3. cabal install -j -f-assistant -webapp -webdav -pairing -xmpp -dns -dbus -magicmime --only-dependencies - -### What version of git-annex are you using? On what operating system? - -git-annex HEAD. - -FreeBSD 11.1-RELEASE r321309 GENERIC amd64 - -### Please provide any additional information below. - -The full log is available at [https://gitlab.com/snippets/1743708](https://gitlab.com/snippets/1743708). Summary below: - - cabal: Error: some packages failed to install: - esqueleto-2.5.3-J2ccnERt7unG9UdXfc7jAa depends on esqueleto-2.5.3 which failed to install. - persistent-2.7.0-IWtmEvQAI3yHscMZvQrE6P failed during the building phase. The exception was: ExitFailure 1 - persistent-sqlite-2.6.4-3aF88LYjPwqbsHGVQ1VUp depends on - persistent-sqlite-2.6.4 which failed to install. - persistent-template-2.5.4-2tn9hCQqx2e2mAPIKgHBFO depends on - persistent-template-2.5.4 which failed to install. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -No, I'm afraid. But it looks really good! I'm trying to use it to add a bunch of high-res images to my Jeykll website, all managed through Git, with the images stored in S3. - -> [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD/comment_1_a959c15b7144acc5d68bb3891107a480._comment b/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD/comment_1_a959c15b7144acc5d68bb3891107a480._comment deleted file mode 100644 index 456fd77967..0000000000 --- a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD/comment_1_a959c15b7144acc5d68bb3891107a480._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-08-13T16:35:43Z" - content=""" -This is caused by this bug in esquelito: -https://github.com/bitemyapp/esqueleto/issues/80 - -The best way to avoid this kind of transient breakage in the haskell -dependencies of git-annex is to build it using stack, instead of cabal. -stack pins packages to a consistent working set. - -I don't really see this as something that warrants a change to git-annex. -Using bleeding edge versions of all build dependencies will break, that's -why the build docs recommend not using cabal if you don't want to be involved -in fixing that kind of breakage. -"""]] diff --git a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD/comment_2_e93c0bf6b2134814b490c3bc1362425a._comment b/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD/comment_2_e93c0bf6b2134814b490c3bc1362425a._comment deleted file mode 100644 index ad12693a8a..0000000000 --- a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD/comment_2_e93c0bf6b2134814b490c3bc1362425a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="duncan_bayne" - avatar="http://cdn.libravatar.org/avatar/2fc23e2009234ad965f9d5d796400417" - subject="RTFM" - date="2018-08-16T04:25:26Z" - content=""" -Ah, right, I might have missed the line in the docs that say \"and it's not uncommon for it to be broken from time to time.\" :-/ - -Reinstalling with stack, thanks for the tip :) -"""]] diff --git a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack.mdwn b/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack.mdwn deleted file mode 100644 index e5ed9c881f..0000000000 --- a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack.mdwn +++ /dev/null @@ -1,51 +0,0 @@ -### Please describe the problem. - -git-annex can't compile on FreeBSD; specifically, the build fails while compiling Utility.DirWatcher.Kqueue. - -### What steps will reproduce the problem? - -1. git clone git://git-annex.branchable.com/ git-annex -2. cd git-annex -3. stack setup -4. stack install - -### What version of git-annex are you using? On what operating system? - -git-annex HEAD. - -FreeBSD 11.1-RELEASE r321309 GENERIC amd64 - -### Please provide any additional information below. - -Compilation failure is as follows: - - [126 of 586] Compiling Utility.DirWatcher.Kqueue ( Utility/DirWatcher/Kqueue.hs, .stack-work/dist/x86_64-freebsd/Cabal-1.24.2.0/build/git-annex/git-annex-tmp/Utility/Di - rWatcher/Kqueue.o ) - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:112:49: error: - Variable not in scope: - openFd :: FilePath -> t0 -> Maybe a0 -> t1 -> IO t - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:112:60: error: - Data constructor not in scope: ReadOnly - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:112:77: error: - Variable not in scope: defaultFileFlags - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:132:15: error: - Variable not in scope: closeFd :: Fd -> IO b0 - - /usr/home/duncan/code/git-annex/Utility/DirWatcher/Kqueue.hs:170:14: error: - Variable not in scope: closeFd :: Fd -> IO () - Completed 210 action(s). - - -- While building custom Setup.hs for package git-annex-6.20180807 using: - /usr/home/duncan/code/git-annex/.stack-work/dist/x86_64-freebsd/Cabal-1.24.2.0/setup/setup --builddir=.stack-work/dist/x86_64-freebsd/Cabal-1.24.2.0 build exe:git - -annex --ghc-options " -ddump-hi -ddump-to-file" - Process exited with code: ExitFailure 1 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Not yet. But I'm used to issues compiling new tools on FreeBSD, so I'm in no way disheartened by this :) - -> [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_1_ca05260b9dd2feb9530dab17250c0b8d._comment b/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_1_ca05260b9dd2feb9530dab17250c0b8d._comment deleted file mode 100644 index 4184ac6efc..0000000000 --- a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_1_ca05260b9dd2feb9530dab17250c0b8d._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-08-29T16:07:48Z" - content=""" -I've fixed those problems. - -It looks like noone has compiled on FreeBSD in a long time. Maybe since I -first developed that module in 2013. So there may be other problems. Please -open bugs if so. -"""]] diff --git a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_2_7a5ff239751a2dc0547ad19b5bfa761f._comment b/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_2_7a5ff239751a2dc0547ad19b5bfa761f._comment deleted file mode 100644 index abd4e6f772..0000000000 --- a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_2_7a5ff239751a2dc0547ad19b5bfa761f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="duncan_bayne" - avatar="http://cdn.libravatar.org/avatar/2fc23e2009234ad965f9d5d796400417" - subject="Thanks :)" - date="2018-09-03T00:39:08Z" - content=""" -Thanks :) Will open further bugs if necessary. -"""]] diff --git a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_3_3b38a1dc9b5d3b74f937206a90967c57._comment b/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_3_3b38a1dc9b5d3b74f937206a90967c57._comment deleted file mode 100644 index 95317f9086..0000000000 --- a/doc/bugs/git-annex_can__39__t_compile_on_FreeBSD_using_stack/comment_3_3b38a1dc9b5d3b74f937206a90967c57._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="duncan_bayne" - avatar="http://cdn.libravatar.org/avatar/2fc23e2009234ad965f9d5d796400417" - subject="Bug raised" - date="2018-09-16T22:15:23Z" - content=""" -Hi Joey, - -I've raised a bug ( https://git-annex.branchable.com/bugs/Can__39__t_compile_on_FreeBSD__58____Issues_with_System.Posix.Files/ ) as requested. I also happen to have a machine sitting around at home that I can configure for SSH access, if you or anyone would like a current (FreeBSD 11.1) dev environment to use. Let me know. - -Yours, -Duncan -"""]] diff --git a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2.mdwn b/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2.mdwn deleted file mode 100644 index 9fd7fdc7c4..0000000000 --- a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -### Please describe the problem. - -git-annex requires a `gpg -> gpg2` alias, which is dangerous for other software to misuse. - -### What steps will reproduce the problem? - -Run any gpg-requiring operation on a machine that has only gpg2 installed and no gpg alias. - - gpg: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory) - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20150710 - -OS X, gpg2 installed with brew - -### Have you had any luck using git-annex before? - -git-annex took some time to get in the mentality and configure, but now it's a beautiful perfectly oiled file management system. Thanks! - -> git.program support now implemented, [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment b/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment deleted file mode 100644 index b48cfbca3f..0000000000 --- a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-09T21:12:01Z" - content=""" -git-annex should work ok with gpg version 2; there was one minor -incompatibility vs gpg version 1, but it was ironed out in 2013. - -If you build it from source, and have only gpg2 in PATH, and not gpg, it -will build a git-annex that runs gpg2. - -You're using OSX.. the git-annex.app for OSX bundles its own gpg command, -and git-annex will use that one. I guess the brew build is built to use -gpg, and not gpg2. Would it then make sense for the brew package of -git-annex to depend on the package that contains gpg? - -I don't really think it makes sense for git-annex to probe -around at runtime to find which of gpg and gpg2 is in PATH and pick which -one to use. - -I suppose I could make git-annex look at git config gpg.program and use -that program when it's set. This would mirror the behavior of git. -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box.mdwn b/doc/bugs/git-annex_can_no_longer_copy_files_to_box.mdwn deleted file mode 100644 index 940ae3ad16..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -### Please describe the problem. - -With the upgrade to git-annex 6.20170925 I can no longer copy files to box via webdav. I notice that the changelog suggests that there were many changes to the webdav backend, including a new path for temporary files and url-escaping of file names. I have been using webdav + Box successfully for almost two years. My box/webdav backed was set up with chunking and encryption: - - WEBDAV_USERNAME=[username] WEBDAV_PASSWORD=[passwd] git annex initremote box type=webdav url=https://dav.box.com/dav/mystuff/annex chunk=100mb keyid=[keyid] - -Now when I try to add and copy a file to webdav I get the following error: - - (checking box...) - DAV failure: Status {statusCode = 405, statusMessage = "Method Not Allowed"} "\n\n Sabre_DAV_Exception_MethodNotAllowed\n The resource you tried to create - already exists\n\n" - CallStack (from HasCallStack): - error, called at ./Remote/WebDAV.hs:381:78 in main:Remote.WebDAV failed - (recording state in git...) - -### What steps will reproduce the problem? - -Add a file to an annex repo with a webdav backend set up per the settings above: - - git add test.pdf - -Attempt to copy that file to the webdav backend: - - git-annex copy -t box test.pdf - -### What version of git-annex are you using? On what operating system? - -OS = arch linux (Linux archbook 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux) - -git annex version = - - git-annex version: 6.20170925-g76c9b580b - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.24 DAV-1.3.1 feed-1.0.0.0 ghc-8.2.1 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: unknown - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! A huge word of thanks for this amazing software! Since I work on multiple linux boxes, git annex keeps track of all my big files and enables me to move them back and forth with minimal fuss. - -> [[done]]; seems this is fixed. --[[Joey]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_10_dfe3426a2cb3622d405002e7275dbcd6._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_10_dfe3426a2cb3622d405002e7275dbcd6._comment deleted file mode 100644 index 111bbf11c2..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_10_dfe3426a2cb3622d405002e7275dbcd6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="comment 10" - date="2017-10-09T15:46:09Z" - content=""" -I should add that the automated standalone build downloaded from the git-annex website reliably uploads to box, though slowly (per the other bug report). -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_11_c5b5e449eddd6fa7111a31041699b657._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_11_c5b5e449eddd6fa7111a31041699b657._comment deleted file mode 100644 index 45d81bdae7..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_11_c5b5e449eddd6fa7111a31041699b657._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 11""" - date="2017-10-11T15:10:51Z" - content=""" -Looks related to the other bug report, it's failing creating the -directory for the temp file at the top of the repository, which -already exists. - -So, the fix I just committed to fix the other bug report may have -fixed this too.. Can you test? - -(It's also possible that the nonsensicalness of "MKCOL ." -means it's not widely supported, or may even be out of the webdav spec -entirely. The fix for the other bug report avoids that behavior.) -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_12_9f50a33f47e73283c93e37fe85dd788e._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_12_9f50a33f47e73283c93e37fe85dd788e._comment deleted file mode 100644 index 987bcc3587..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_12_9f50a33f47e73283c93e37fe85dd788e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="comment 12" - date="2017-10-12T00:58:04Z" - content=""" -I rebuilt using stack and everything works as expected now. Thanks! -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_1_8d075cae09f3f4c4ef3f30b68099b39c._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_1_8d075cae09f3f4c4ef3f30b68099b39c._comment deleted file mode 100644 index ef61529f79..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_1_8d075cae09f3f4c4ef3f30b68099b39c._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-09-28T15:39:45Z" - content=""" -I'm not reproducing the problem here. - -The only change recent that affected storing files in any -way was the temporary location change. But I don't see how that -would lead to such a failure. - -I've improved the webdav error message to include information about the -request that failed. That should help with debugging the problem. An -updated autobuild will be available within an hour or two. -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_2_4471a1be63212346253729238a7da470._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_2_4471a1be63212346253729238a7da470._comment deleted file mode 100644 index e903f51ad1..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_2_4471a1be63212346253729238a7da470._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="comment 2" - date="2017-09-29T13:00:40Z" - content=""" -Thank you for testing. The standalone works fine. This must be a problem with the way archlinux builds git-annex and/or its dependencies (e.g., haskell-dav). - -Sorry for the false alarm. I will be sure to test with the standalone before reporting bugs next time. -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_2_dc4345abb59fbfaf4982a88753286fe2._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_2_dc4345abb59fbfaf4982a88753286fe2._comment deleted file mode 100644 index e254ce7fcc..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_2_dc4345abb59fbfaf4982a88753286fe2._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-09-29T16:17:15Z" - content=""" -Hmm, the arch version info you posted originally shows the same version -of the DAV library as I have here, so I had assumed it was not a -version problem. May be something else in the dependency tree below -DAV though. - -Are you sure it's not an intermittent problem; does it consistently fail -with the arch build and work with the standalone build? - -Also, which arch build of git-annex are you using? -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_4_1eec270febdd1a9fa28ac437c089c5e6._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_4_1eec270febdd1a9fa28ac437c089c5e6._comment deleted file mode 100644 index 045234442a..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_4_1eec270febdd1a9fa28ac437c089c5e6._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="comment 4" - date="2017-09-29T17:22:43Z" - content=""" -Yes, copying to box consistently fails with the arch linux build (6.20170925-g76c9b580b) and consistently succeeds with the standalone build (6.20170929-gffc127582). - -I am using the git-annex build in the official arch repositories (community). I've submitted an arch linux bug report here: - -https://bugs.archlinux.org/task/55808?project=5&cat%5B0%5D=33&string=git-annex -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_5_c758613d1d407e8ff1565822a9f36951._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_5_c758613d1d407e8ff1565822a9f36951._comment deleted file mode 100644 index e8b556edff..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_5_c758613d1d407e8ff1565822a9f36951._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2017-09-29T19:41:08Z" - content=""" -https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/haskell-dav&id=3053316bdef797ade4abd9e94c76258468deb9bc - -Could be the new version of aeson that broke it. The autobuilder is using -aeson-1.1.2.0. -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_6_11a5b8e90d7c5f3ec4bfe854b4778fea._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_6_11a5b8e90d7c5f3ec4bfe854b4778fea._comment deleted file mode 100644 index 476350de57..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_6_11a5b8e90d7c5f3ec4bfe854b4778fea._comment +++ /dev/null @@ -1,47 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="comment 6" - date="2017-10-06T23:45:13Z" - content=""" -I had a chance to do some more testing. I build the latest git-annex using stack (after uninstalling the arch-linux git annex and all its dependencies). I was able to reproduce the bug with the build. - -git-annex version: - - git-annex version: 6.20171006-g676000770 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Quvi - dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.21 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.6.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -Steps to reproduce (assumes the webdav repo initiation from the original bug report): - -Create a file test.txt that contains \"Hello, world!\". - - git add test.txt - git annex --verbose --debug copy -t box test.txt - -This results in: - - [2017-10-06 18:32:00.036289708] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"] - [2017-10-06 18:32:00.039256791] process done ExitSuccess - [2017-10-06 18:32:00.039344582] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] - [2017-10-06 18:32:00.041786875] process done ExitSuccess - [2017-10-06 18:32:00.042888138] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"] - [2017-10-06 18:32:00.043236927] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"] - [2017-10-06 18:32:00.064572923] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"test.txt\"] - copy test.txt [2017-10-06 18:32:00.078377684] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] - [2017-10-06 18:32:00.16669294] process done ExitSuccess - (checking box...) (to box...) - [2017-10-06 18:32:01.195900381] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"19\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"] - [2017-10-06 18:32:32.159837783] process done ExitSuccess - - DAV failure: Status {statusCode = 405, statusMessage = \"Method Not Allowed\"} \"\n\n Sabre_DAV_Exception_MethodNotAllowed\n The resource you tried to create already exists\n\n\" HTTP request: \"MKCOL\" \"/dav/mystuff/annex/.\" - failed - [2017-10-06 18:32:32.163143388] process done ExitSuccess - [2017-10-06 18:32:32.163958789] process done ExitSuccess - git-annex: copy: 1 failed - - - -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_7_654cda20c0775e16c14ae8b1134aa042._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_7_654cda20c0775e16c14ae8b1134aa042._comment deleted file mode 100644 index eeac2f5495..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_7_654cda20c0775e16c14ae8b1134aa042._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2017-10-07T18:08:49Z" - content=""" -It's interesting you reproduced it when building with stack. I'm a bit -confused because in your other bug report, you seemed to have git-annex -built with stack working without this bug? - -In any case, IIRC stack will use haskell libraries installed system-wide in -some cases, so it may be picking up whatever the problimatic library is -from Arch Linux. - -If you can reproduce it with stack on a system that does not have a -system-wide ghc installed, I'd think I should also be able to build with -stack and reproduce it.. - -Also, I've just made --debug log all webdav operations, which should help -track down what operation is failing.. -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_8_81ef2faa317c1f5d4d6d051baa48ceff._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_8_81ef2faa317c1f5d4d6d051baa48ceff._comment deleted file mode 100644 index 3d0d3b6577..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_8_81ef2faa317c1f5d4d6d051baa48ceff._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="comment 8" - date="2017-10-09T14:52:54Z" - content=""" -Yes, I am confused as well. Sometimes the stack build works, sometimes it doesn't. So I can't reliably reproduce the bug. You can see an example of a failure (with debug information) on the other bug report. I'll see if I can get stack without a system wide install and rebuild. -"""]] diff --git a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_9_999697b83fa2451b1cf28110b27f9a1a._comment b/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_9_999697b83fa2451b1cf28110b27f9a1a._comment deleted file mode 100644 index 4cdf3b1b84..0000000000 --- a/doc/bugs/git-annex_can_no_longer_copy_files_to_box/comment_9_999697b83fa2451b1cf28110b27f9a1a._comment +++ /dev/null @@ -1,48 +0,0 @@ -[[!comment format=mdwn - username="madalu" - avatar="http://cdn.libravatar.org/avatar/c00d4aa29fd053f08a2ef35531592914" - subject="Reproduction of bug with "pure" stack build" - date="2017-10-09T15:43:16Z" - content=""" -I am able to reproduce this bug with an entirely local stack build (i.e., no global haskell installs) on arch linux. To make sure I began with a clean build, I removed local directories (rm -r ~/.ghc, rm -r ~/.stack, rm -r ~/.cabal) and then uninstalled all arch linux haskell packages (including ghc and ghc-libs). I downloaded the standalone stack and then ran stack clean, stack setup, stack install in a cloned git-annex repo. - -git-annex-version - - git-annex version: 6.20171009-g92577980f - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Quvi - dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.21 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.6.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -Here is the debug information: - -git annex --verbose --debug copy -t box test.txt - - [2017-10-09 10:37:02.174210625] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"] - [2017-10-09 10:37:02.1773328] process done ExitSuccess - [2017-10-09 10:37:02.177437562] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] - [2017-10-09 10:37:02.179955262] process done ExitSuccess - [2017-10-09 10:37:02.18033415] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..4c46223e7ccc1c3569fc43e3dbfe1c89fdf9a628\",\"--pretty=%H\",\"-n1\"] - [2017-10-09 10:37:02.18512832] process done ExitSuccess - [2017-10-09 10:37:02.185946927] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"] - [2017-10-09 10:37:02.186427574] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"] - [2017-10-09 10:37:02.209479037] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"test.txt\"] copy test.txt - [2017-10-09 10:37:02.222741576] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] - [2017-10-09 10:37:02.31191458] process done ExitSuccess - (checking box...) [2017-10-09 10:37:02.355350066] getProps 90a/d4d/GPGHMACSHA1--53636e5e7a50bc58eae478ddc260bb5abd899d03/GPGHMACSHA1--53636e5e7a50bc58eae478ddc260bb5abd899d03 - (to box...) - [2017-10-09 10:37:03.30749556] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"19\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"] - [2017-10-09 10:37:03.361698513] getProps . - [2017-10-09 10:37:33.376085151] mkCol . - [2017-10-09 10:37:34.066994173] process done ExitSuccess - - DAV failure: Status {statusCode = 405, statusMessage = \"Method Not Allowed\"} \"\n\n Sabre_DAV_Exception_MethodNotAllowed\n The resource you tried to create already exists\n\n\" HTTP request: \"MKCOL\" \"/dav/mystuff/annex/.\" failed - [2017-10-09 10:37:34.069044148] process done ExitSuccess - [2017-10-09 10:37:34.069370655] process done ExitSuccess - git-annex: copy: 1 failed - -"""]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules.mdwn b/doc/bugs/git-annex_confuses_Git_with_nested_submodules.mdwn deleted file mode 100644 index a9ce6b348c..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -### Please describe the problem. -The way git-annex deals with submodules (replacing the .git file in the submodule, with a link to the corresponding gitdir of the submodule) seems to confuse Git when creating another submodule in an annex-init'ed submodule. - -### What steps will reproduce the problem? - % mkdir some ; cd some; git init - Initialized empty Git repository in /tmp/some/.git/ - % git submodule add /src/somegitrepo sub_lvl1 - Cloning into 'sub_lvl1'... - done. - % cd sub_lvl1 - % git annex init - init (merging origin/git-annex into git-annex...) - (recording state in git...) - ok - (recording state in git...) - % git submodule add /src/somegitrepo sub_lvl2 - Cloning into 'sub_lvl2'... - done. - fatal: Could not chdir to '../../../sub_lvl2': No such file or directory - Unable to checkout submodule 'sub_lvl2' - -### What version of git-annex are you using? On what operating system? - % apt-cache policy git-annex-standalone - git-annex-standalone: - Installed: 6.20160213+gitg9597a21-1~ndall+1 - -Debian stretch, git-annex from NeuroDebian. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, lots! Using it for some of its original use cases for more than five years now -- I was actually surprised to learn, just now, that the oldest commit in my music repository is exactly 5 years and 6 days old. Thanks for longevity and reliability! - -More recently I aim exploring the use of git annex for managing datasets and their dependencies, i.e. going from raw to some processed state over multiple levels, where each level is a useful starting point for some analysis, and each previous level is a dependency (input) to the next. With just one level above "raw" this has massively improved collaboration workflows in student/teacher settings for me. Deeper nesting levels would allow for even more interesting applications, but see above ;-) I think Git seems needlessly confused, but I don't fully grasp what is happening yet. I'd appreciate any insight you may have. Although it is Git that shows the undesired behavior, it seems it is git-annex that ultimately confused it. Hence I came here first. - -BTW: What a nice idea to ask for something like this in a bug report. - - -[[!meta author=mih]] - -> I've verified this is fixed on git's side. With git 2.23.0, my simple -> reproduction script that uses only git does not fail as it used to. -> And, yoh previously followed up that it was fixed in actual git-annex -> use. -> So, [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_1_fb01d4b5af500affc08a5c3b3b1849dd._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_1_fb01d4b5af500affc08a5c3b3b1849dd._comment deleted file mode 100644 index 41068b5a9b..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_1_fb01d4b5af500affc08a5c3b3b1849dd._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-03-01T20:25:13Z" - content=""" -Reproduced this. - -This really does feel like a git bug. git is supposed to treat "gitlink" -files and .git symlinks the same. While modern versions of git set up -gitlink files for submodules, older versions of git used .git symlinks, and -git should still support that. - -Looks like the problem can be worked around, by setting -`GIT_DIR`. In your example, `GIT_DIR=../.git/modules/sub_lvl1/ git -submodule add /src/somegitrepo sub_lvl2` -"""]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_2_094baf6c3738691879fd907dd1729c56._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_2_094baf6c3738691879fd907dd1729c56._comment deleted file mode 100644 index 50d2f709a7..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_2_094baf6c3738691879fd907dd1729c56._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-03-01T20:36:43Z" - content=""" -Here's a more minimal test case, not involving git-annex at all: - - git init gitdir - mkdir worktree - cd worktree - ln -s ../gitdir/.git .git - git submodule add /any/git/repo sub - - fatal: Could not chdir to '../../../sub': No such file or directory - -I have forwarded that test case to the git ML. -"""]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_3_e1bc8eb7f6ce0d6f2d2f2b0ea6f20862._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_3_e1bc8eb7f6ce0d6f2d2f2b0ea6f20862._comment deleted file mode 100644 index 49e883c7ca..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_3_e1bc8eb7f6ce0d6f2d2f2b0ea6f20862._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-03-02T16:48:24Z" - content=""" -[git bug report](http://news.gmane.org/find-root.php?message_id=20160301204218.GA4083%40kitenet.net) - -So far, the git devs admit this is a problem, but don't seem too keen on fixing -it, even though it breaks backwards compatability with repositories git -submodule add created (circa 2012). - -It might be that git-annex init could work around git's bugginess by, -instead of making submodule/.git a symlink to ../.git/modules/dir, making -submodule/.git be the git directory, and converting ../.git/modules/dir -to a symlink. In very limited testing, that setup seems to work. - -I don't know if all the submodule stuff would work, perhaps it would break moving -submodules etc. And, since git likes to chdir around (not the best idea), -if it expected to be able to chdir from .git/modules to dir and chdir .. to -get back, changing that to a symlink would defeat it. - -BTW, I found another way, unrelated to git-annex or symlinks at all, -that git submodule add's broken path handling makes it fall over with -nested submodules. -. - -(It's almost like myrepos was a better idea than this submodule stuff, or -something...) -""]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment deleted file mode 100644 index d663f33700..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="mih" - subject="Thanks" - date="2016-03-02T19:30:49Z" - content=""" -Thanks for investigating this further. - -One aspect that may make switching the location of the .git directory into the worktree of the submodule less desirable is this: With the actual .git in ../.git/modules/... one can easily rm -rf the submodule, deinit it, and re-init/update from the (still present) ../.git/modules/... at a later point in time. Especially, when a submodule is a more complicated beast (e.g. with multiple configured remotes) the required steps to regenerate the same setup get more complex. -"""]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_5_c35478d4fbe6dde21d22369494414fe8._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_5_c35478d4fbe6dde21d22369494414fe8._comment deleted file mode 100644 index 47cf7624dc..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_5_c35478d4fbe6dde21d22369494414fe8._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 5" - date="2016-04-19T14:47:58Z" - content=""" -Hi Joey, since git people agreed that it was a regression, should we expect this issue to be fixed on their side? Could you please follow up since discussion on the mailing list you have referenced has ended without closure -"""]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_6_11528378e8c509940190cf84db7ed3d6._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_6_11528378e8c509940190cf84db7ed3d6._comment deleted file mode 100644 index a6362816a7..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_6_11528378e8c509940190cf84db7ed3d6._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-05-16T20:14:57Z" - content=""" -I hope this will be fixed on the git side, but I don't know when it will -be. Probably comes down to someone developing a patch. - -Occurs to me that git-annex could use adjusted branches to deal with this. -When initializing in a submodule, it could enter an adjusted branch with -`git annex adjust --fix`. This way, symlinks would be re-written to point -to the submodule's git repository. The .git dotfile would not need to be -converted to a symlink at all. -"""]] diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_7_a257e5ccf264b662ce9becd5f76d2f53._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_7_a257e5ccf264b662ce9becd5f76d2f53._comment deleted file mode 100644 index c253716ead..0000000000 --- a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_7_a257e5ccf264b662ce9becd5f76d2f53._comment +++ /dev/null @@ -1,50 +0,0 @@ -[[!comment format=mdwn - username="yarikoptic" - avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" - subject="comment 7" - date="2018-03-23T15:58:15Z" - content=""" -I think it is fixed now, either by git or git-annex . Here is my full protocol to reproduce (needed to adjust paths etc): -[[!format sh \"\"\" -$> mkdir some ; cd some; git init -Initialized empty Git repository in /tmp/some/.git/ -1 9949.....................................:Fri 23 Mar 2018 11:55:02 EDT:. -(git)hopa:/tmp/some[master] -$> git submodule add /src/somegitrepo sub_lvl1 - -fatal: repository '/src/somegitrepo' does not exist -fatal: clone of '/src/somegitrepo' into submodule path '/tmp/some/sub_lvl1' failed -1 9950 ->128.....................................:Fri 23 Mar 2018 11:55:13 EDT:. -(git)hopa:/tmp/some[master] -$> git clone http://datasets.datalad.org/.git /tmp/somegitrepo -Cloning into '/tmp/somegitrepo'... -1 9951.....................................:Fri 23 Mar 2018 11:55:57 EDT:. -(git)hopa:/tmp/some[master]git -$> git submodule add /tmp/src/somegitrepo sub_lvl1 -fatal: repository '/tmp/src/somegitrepo' does not exist -fatal: clone of '/tmp/src/somegitrepo' into submodule path '/tmp/some/sub_lvl1' failed -1 9952 ->128.....................................:Fri 23 Mar 2018 11:56:12 EDT:. -(git)hopa:/tmp/some[master]git -$> git submodule add /tmp/somegitrepo sub_lvl1 -Cloning into '/tmp/some/sub_lvl1'... -done. -cached/staged changes: - .gitmodules | 3 +++ - sub_lvl1 | 1 + -1 9953.....................................:Fri 23 Mar 2018 11:56:18 EDT:. -(git)hopa:/tmp/some[master]git -$> cd sub_lvl1 -abide/ adhd200/ crcns/ dbic/ dicoms/ indi/ labs/ nidm/ workshops/ -abide2/ corr/ datapackage.json devel/ hbnssi/ kaggle/ neurovault/ openfmri/ -1 9954.....................................:Fri 23 Mar 2018 11:56:24 EDT:. -(git)hopa:/tmp/some/sub_lvl1[master]git -$> git annex init -init ok -(recording state in git...) -1 9955.....................................:Fri 23 Mar 2018 11:56:27 EDT:. -(git)hopa:/tmp/some/sub_lvl1[master]git -$> git submodule add /tmp/somegitrepo sub_lvl2 -Cloning into '/tmp/some/sub_lvl1/sub_lvl2'... -done. -\"\"\"]] -"""]] diff --git a/doc/bugs/git-annex_does_not_build_with_aws_0.16.mdwn b/doc/bugs/git-annex_does_not_build_with_aws_0.16.mdwn deleted file mode 100644 index 9af3726009..0000000000 --- a/doc/bugs/git-annex_does_not_build_with_aws_0.16.mdwn +++ /dev/null @@ -1,51 +0,0 @@ -### Please describe the problem. - -aws 0.16 has a breaking change, causing git-annex' usage of S3.UploadPartResponse to fail. - -[[!format haskell """ -[325 of 546] Compiling Remote.S3 ( Remote/S3.hs, dist/dist-sandbox-8fbcd4b9/build/git-annex/git-annex-tmp/Remote/S3.o ) - -Remote/S3.hs:224:49: error: - • The constructor ‘S3.UploadPartResponse’ should have 1 argument, but has been given 2 - • In the pattern: S3.UploadPartResponse _ etag - In a stmt of a 'do' block: - S3.UploadPartResponse _ etag <- sendS3Handle h req - In the expression: - do { let sz = ...; - let p' = offsetMeterUpdate p (toBytesProcessed pos); - let numchunks - = ceiling - (fromIntegral sz / fromIntegral defaultChunkSize :: Double); - let popper = handlePopper numchunks defaultChunkSize p' fh; - .... } -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -"""]] - -I suggest switching to {} pattern matching, like this: - -[[!format haskell """ -S3.UploadPartResponse { S3.uprEtag = etag } <- sendS3Handle h req -"""]] - -### What steps will reproduce the problem? - -Try to build git-annex with aws 0.16. - -### What version of git-annex are you using? On what operating system? - -Not sure, I got this build failure report from ilovezfs who I think uses Max OS X, and git-annex master. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -> [[fixed|done]], thanks --[[Joey]] diff --git a/doc/bugs/git-annex_doesn__39__t_find_adb_device.mdwn b/doc/bugs/git-annex_doesn__39__t_find_adb_device.mdwn deleted file mode 100644 index 5a37559cc9..0000000000 --- a/doc/bugs/git-annex_doesn__39__t_find_adb_device.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -### Please describe the problem. -git-annex claims that adb does not list any devices. `adb devices` however shows the device. - -### What steps will reproduce the problem? - $ git annex initremote phone type=adb androiddirectory=/storage/external/annex encryption=none exporttree=yes - initremote handy git-annex: adb does not list any connected android devices. Plug in an Android device, or configure adb, and try again.. - $ adb devices - List of devices attached - 6c12eba7d440 device - - -### What version of git-annex are you using? On what operating system? - git-annex version: 6.20180529-g33834140e - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.4.3 http-client-0.5.12.1 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex_doesn__39__t_find_adb_device/comment_1_56070e29ea7f19d24d4ff0f56adf08a0._comment b/doc/bugs/git-annex_doesn__39__t_find_adb_device/comment_1_56070e29ea7f19d24d4ff0f56adf08a0._comment deleted file mode 100644 index f030295f5a..0000000000 --- a/doc/bugs/git-annex_doesn__39__t_find_adb_device/comment_1_56070e29ea7f19d24d4ff0f56adf08a0._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-06-12T17:39:51Z" - content=""" -It's expecting a serial number 16 digits long, -and your adb is using a 12 digit one. I suppose this means that the length -can vary. Hopefully because of a difference in the android device and not -the version of adb. I'll change it to accept shorter serials. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_find_adb_device/comment_2_7e59d3e5a6273e737626cf73013c334d._comment b/doc/bugs/git-annex_doesn__39__t_find_adb_device/comment_2_7e59d3e5a6273e737626cf73013c334d._comment deleted file mode 100644 index 843a74ceb5..0000000000 --- a/doc/bugs/git-annex_doesn__39__t_find_adb_device/comment_2_7e59d3e5a6273e737626cf73013c334d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="lykos@d125a37d89b1cfac20829f12911656c40cb70018" - nickname="lykos" - avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2" - subject="comment 2" - date="2018-06-13T10:46:25Z" - content=""" -Thanks! I think it's independent from adb, as it's the same serial number shown by dmesg. -"""]] diff --git a/doc/bugs/git-annex_in_nixpkgs_fails_with_git-2.13.0.mdwn b/doc/bugs/git-annex_in_nixpkgs_fails_with_git-2.13.0.mdwn deleted file mode 100644 index 53e12b5fce..0000000000 --- a/doc/bugs/git-annex_in_nixpkgs_fails_with_git-2.13.0.mdwn +++ /dev/null @@ -1,359 +0,0 @@ -### Please describe the problem. - -Tests fail on Nix when git is upgraded to 2.13. - - -### What steps will reproduce the problem? - -On NixOS or a system with Nix installed, check out nixpkgs ce8662e693b5756e8457d94bb1765d853310afdb, try to build git-annex (`nix-build -I . -A pkgs.gitAndTools.gitAnnex`). - - -### What version of git-annex are you using? On what operating system? - -git-annex 6.20170321 on Nix ce8662e6. - - -### Please provide any additional information below. - -I ran a git bisect that concluded: - -[[!format sh """ -8 out of 285 tests failed (281.73s) - (This could be due to a bug in git-annex, or an incompatibility - with utilities, such as git, installed on this system.) -builder for ‘/nix/store/908y9923fnjmi87apji6q14smgc2rf3d-git-annex-6.20170321.drv’ failed with exit code 1 -error: build of ‘/nix/store/908y9923fnjmi87apji6q14smgc2rf3d-git-annex-6.20170321.drv’ failed -ce8662e693b5756e8457d94bb1765d853310afdb is the first bad commit -commit ce8662e693b5756e8457d94bb1765d853310afdb -Author: Tim Steinbach -Date: Tue May 9 21:57:24 2017 -0400 - - git: 2.12.2 -> 2.13.0 - -:040000 040000 4155c091e7156a4e15cf073640e0be3c76b1b7f3 48ca917e5578b405cf8517e1f113433b2d076e15 M pkgs -bisect run success -"""]] - - -[[!format sh """ - adjusted branch merge regression: Switched to branch 'adjusted/master(unlocked)' -[adjusted/master(unlocked) ca9719e] git-annex in .t/tmprepo39 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -From ../../.t/tmprepo40 - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master -To ../../.t/tmprepo40 - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master -Switched to branch 'adjusted/master(unlocked)' -[adjusted/master(unlocked) b29e8de] git-annex in .t/tmprepo40 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo39 - * [new branch] adjusted/master(unlocked) -> r1/adjusted/master(unlocked) - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -To ../../.t/tmprepo39 - * [new branch] git-annex -> synced/git-annex - ! [rejected] master -> synced/master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. -To ../../.t/tmprepo39 - ! [rejected] master -> master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. - Pushing to r1 failed. -FAIL (2.32s) -"""]] - - -[[!format sh """ - conflict resolution (adjusted branch): [master b0dd758] git-annex in .t/tmprepo44 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -[master 8295bae] git-annex in .t/tmprepo45 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -Switched to branch 'adjusted/master(unlocked)' -On branch master -nothing to commit, working tree clean -From ../../.t/tmprepo45 - * [new branch] adjusted/master(unlocked) -> r2/adjusted/master(unlocked) - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master - * [new branch] synced/master -> r2/synced/master -Auto-merging conflictor -CONFLICT (add/add): Merge conflict in conflictor -Automatic merge failed; fix conflicts and then commit the result. -conflictor: needs merge -[master 14ffa24] git-annex automatic merge conflict fix -Already up-to-date. -To ../../.t/tmprepo45 - 8295bae..14ffa24 master -> synced/master - * [new branch] git-annex -> synced/git-annex -On branch adjusted/master(unlocked) -nothing to commit, working tree clean -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo44 - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -FAIL (2.34s) -"""]] - -[[!format sh """ - adjusted branch merge regression: Switched to branch 'adjusted/master(unlocked)' -[adjusted/master(unlocked) 7ccad36] git-annex in .t/tmprepo39 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -From ../../.t/tmprepo40 - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master -To ../../.t/tmprepo40 - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master -Switched to branch 'adjusted/master(unlocked)' -[adjusted/master(unlocked) cfb04fd] git-annex in .t/tmprepo40 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo39 - * [new branch] adjusted/master(unlocked) -> r1/adjusted/master(unlocked) - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -To ../../.t/tmprepo39 - * [new branch] git-annex -> synced/git-annex - ! [rejected] master -> synced/master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. -To ../../.t/tmprepo39 - ! [rejected] master -> master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. - Pushing to r1 failed. -FAIL (1.79s) -"""]] - -[[!format sh """ - conflict resolution (adjusted branch): [master ea63ee5] git-annex in .t/tmprepo44 - 1 file changed, 1 insertion(+) - create mode 120000 conflictor -[master 07d129c] git-annex in .t/tmprepo45 - 1 file changed, 1 insertion(+) - create mode 120000 conflictor -Switched to branch 'adjusted/master(unlocked)' -On branch master -nothing to commit, working tree clean -From ../../.t/tmprepo45 - * [new branch] adjusted/master(unlocked) -> r2/adjusted/master(unlocked) - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master - * [new branch] synced/master -> r2/synced/master -Auto-merging conflictor -CONFLICT (add/add): Merge conflict in conflictor -Automatic merge failed; fix conflicts and then commit the result. -conflictor: needs merge -[master 5d5a674] git-annex automatic merge conflict fix -Already up-to-date. -To ../../.t/tmprepo45 - 07d129c..5d5a674 master -> synced/master - * [new branch] git-annex -> synced/git-annex -On branch adjusted/master(unlocked) -nothing to commit, working tree clean -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo44 - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -FAIL (1.35s) -"""]] - -[[!format sh """ - adjusted branch merge regression: Switched to branch 'adjusted/master(unlocked)' -[adjusted/master(unlocked) 6601699] git-annex in .t/tmprepo39 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -From ../../.t/tmprepo40 - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master -To ../../.t/tmprepo40 - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master -Switched to branch 'adjusted/master(unlocked)' -[adjusted/master(unlocked) b37ecc1] git-annex in .t/tmprepo40 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo39 - * [new branch] adjusted/master(unlocked) -> r1/adjusted/master(unlocked) - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -To ../../.t/tmprepo39 - * [new branch] git-annex -> synced/git-annex - ! [rejected] master -> synced/master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. -To ../../.t/tmprepo39 - ! [rejected] master -> master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. - Pushing to r1 failed. -FAIL (1.54s) -"""]] - -[[!format sh """ - conflict resolution (adjusted branch): [master dcd2368] git-annex in .t/tmprepo44 - 1 file changed, 1 insertion(+) - create mode 120000 conflictor -[master c933362] git-annex in .t/tmprepo45 - 1 file changed, 1 insertion(+) - create mode 120000 conflictor -Switched to branch 'adjusted/master(unlocked)' -On branch master -nothing to commit, working tree clean -From ../../.t/tmprepo45 - * [new branch] adjusted/master(unlocked) -> r2/adjusted/master(unlocked) - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master - * [new branch] synced/master -> r2/synced/master -Auto-merging conflictor -CONFLICT (add/add): Merge conflict in conflictor -Automatic merge failed; fix conflicts and then commit the result. -conflictor: needs merge -[master 9f19aa7] git-annex automatic merge conflict fix -Already up-to-date. -To ../../.t/tmprepo45 - c933362..9f19aa7 master -> synced/master - * [new branch] git-annex -> synced/git-annex -On branch adjusted/master(unlocked) -nothing to commit, working tree clean -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo44 - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -FAIL (1.44s) -"""]] - -[[!format sh """ - adjusted branch merge regression: On branch master -nothing to commit, working tree clean -On branch master -nothing to commit, working tree clean -Already on 'adjusted/master(unlocked)' -[adjusted/master(unlocked) 70b8469] git-annex in .t/tmprepo39 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -From ../../.t/tmprepo40 - * [new branch] annex/direct/master -> r2/annex/direct/master - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master -To ../../.t/tmprepo40 - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master -Already on 'adjusted/master(unlocked)' -[adjusted/master(unlocked) 353957d] git-annex in .t/tmprepo40 - 1 file changed, 1 insertion(+) - create mode 100644 conflictor -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo39 - * [new branch] adjusted/master(unlocked) -> r1/adjusted/master(unlocked) - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -To ../../.t/tmprepo39 - * [new branch] git-annex -> synced/git-annex - ! [rejected] master -> synced/master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. -To ../../.t/tmprepo39 - ! [rejected] master -> master (non-fast-forward) -error: failed to push some refs to '../../.t/tmprepo39' -hint: Updates were rejected because a pushed branch tip is behind its remote -hint: counterpart. Check out this branch and integrate the remote changes -hint: (e.g. 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. - Pushing to r1 failed. -FAIL (1.87s) -"""]] - -[[!format sh """ - conflict resolution (adjusted branch): On branch master -nothing to commit, working tree clean -On branch master -nothing to commit, working tree clean -Already on 'adjusted/master(unlocked)' -From ../../.t/tmprepo45 - * [new branch] adjusted/master(unlocked) -> r2/adjusted/master(unlocked) - * [new branch] git-annex -> r2/git-annex - * [new branch] master -> r2/master - * [new branch] synced/master -> r2/synced/master -Auto-merging conflictor -CONFLICT (add/add): Merge conflict in conflictor -Automatic merge failed; fix conflicts and then commit the result. -conflictor: needs merge -To ../../.t/tmprepo45 - 372f97c..cebbf06 annex/direct/master -> synced/master - * [new branch] git-annex -> synced/git-annex -On branch adjusted/master(unlocked) -nothing to commit, working tree clean -merge: refs/heads/synced/master - not something we can merge -From ../../.t/tmprepo44 - * [new branch] annex/direct/master -> r1/annex/direct/master - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master -merge: refs/remotes/r1/master - not something we can merge -merge: refs/remotes/r1/synced/master - not something we can merge -FAIL (1.50s) -"""]] - -[[!format sh """ - -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -git-annex is an essential building block in my digital life style! It keeps backups of all my precious family photos. I'm a big git-annex shill when I get the chance, especially to nix, guix and decentralized hacker types. - -> Workaround is in [[!commit 9bcaef1ec496b4ffd3033ae5080949bd8cc3edd5]]. [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex_in_nixpkgs_fails_with_git-2.13.0/comment_1_364f69b47889486ab006811406324c44._comment b/doc/bugs/git-annex_in_nixpkgs_fails_with_git-2.13.0/comment_1_364f69b47889486ab006811406324c44._comment deleted file mode 100644 index 9e7d1928a2..0000000000 --- a/doc/bugs/git-annex_in_nixpkgs_fails_with_git-2.13.0/comment_1_364f69b47889486ab006811406324c44._comment +++ /dev/null @@ -1,38 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-05-16T15:42:53Z" - content=""" -Not nix-specific, I can reproduce with self-built git. - -Bisecting git itself (rather than nix): - - f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 is the first bad commit - commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 - Author: Nguyễn Thái Ngọc Duy - Date: Sun Mar 26 09:42:24 2017 +0700 - - files-backend: remove the use of git_path() - -That commit seems has to do with paths used for refs, and the test suite is -failing due to something involving pushing/merging the -synced/master branch. So, it's looking like a git bug. - -In particular, this just seems outright wrong: - - From ../../.t/tmprepo44 - * [new branch] git-annex -> r1/git-annex - * [new branch] master -> r1/master - * [new branch] synced/master -> r1/synced/master - merge: refs/remotes/r1/master - not something we can merge - merge: refs/remotes/r1/synced/master - not something we can merge - -So, it's just pulled synced/master to r1/synced/master, but then it claims -refs/remotes/r1/synced/master is not mergable. - -This only affects adjusted branches because git has a reversion in the -`GIT_COMMON_DIR` that they use. - -Posted on the git ML about this reversion, message-id -<20170516171028.5eagqr2sw5a2i77d@kitenet.net> -"""]] diff --git a/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path.mdwn b/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path.mdwn deleted file mode 100644 index 23720ebd84..0000000000 --- a/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -### Please describe the problem. -git-annex prefixes all paths used with SSH remotes with a /, which breaks the default git behavior of using the home directory by default. - -### What steps will reproduce the problem? -Start an SSH server. Use it as a remote with a URL like annex@localhost:test.git or annex@localhost:~/test.git. - -### What version of git-annex are you using? On what operating system? -NixOS - -[[!format sh """ -[leo60228@nixos:~/test]$ git annex version -git-annex version: 6.20180529 -build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite -dependency versions: aws-0.18 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12.1 persistent-sqlite-2.6.4 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -"""]] - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -# Don't know how to make a reduced test-case for an issue with a specific protocol. - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes, I use it on my laptop without issues. I'm trying to set up a server on my desktop. - -> [[done]], apparently the reporter was mistaken --[[Joey]] diff --git a/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path/comment_1_f328d7248e7eac4d69bc543feb90da7c._comment b/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path/comment_1_f328d7248e7eac4d69bc543feb90da7c._comment deleted file mode 100644 index 73bd7de882..0000000000 --- a/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path/comment_1_f328d7248e7eac4d69bc543feb90da7c._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-08-03T18:19:38Z" - content=""" -I use home-relative paths in ssh remotes with git-annex all the time. -It works fine. - -Seems to me that this, as well as your other bug report about using -[git-annex-shell in a very strange way](http://git-annex.branchable.com/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/), suggest that you are doing something -strange that you need to go into detail about in order for this to be a -useful bug report. -"""]] diff --git a/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path/comment_2_406afc475368b5680be6c99514fbda74._comment b/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path/comment_2_406afc475368b5680be6c99514fbda74._comment deleted file mode 100644 index 341f72912f..0000000000 --- a/doc/bugs/git-annex_requires_an_SSH_remote_to_have_an_absolute_path/comment_2_406afc475368b5680be6c99514fbda74._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://openid-provider.appspot.com/iakornfeld" - nickname="iakornfeld" - avatar="http://cdn.libravatar.org/avatar/c0369f5727cad81d1ecf6c2e657b42a1b756284aad0229351f9027a2cfcb2037" - subject="Sorry" - date="2018-08-07T14:12:20Z" - content=""" -This was me misreading the debug output. -"""]] diff --git a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent.mdwn b/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent.mdwn deleted file mode 100644 index eb619a93df..0000000000 --- a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -In the sandbox environment used by git-annex standalone, the gpg binary exists, but not gpg-agent (or gpgconf or other potentially needed binaries). This causes problems when the host system provides a different version of gpg that does provide these programs. E.g. git-annex-test crypto tests seem to (indirectly?) use gpg-agent. - -If I want to use my own gpg version (compatible with my own gpg-agent), is it safe to just delete all files named 'gpg' from the git-annex.linux directory? - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_1_2207035f56959691346af0fac57edcc0._comment b/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_1_2207035f56959691346af0fac57edcc0._comment deleted file mode 100644 index d748224564..0000000000 --- a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_1_2207035f56959691346af0fac57edcc0._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-03-18T17:49:05Z" - content=""" -What problem does this bug cause when running the test suite? -"""]] diff --git a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_2_f2b6e4e863e99f6acef44f8e4e013b0d._comment b/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_2_f2b6e4e863e99f6acef44f8e4e013b0d._comment deleted file mode 100644 index d14613f9fe..0000000000 --- a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_2_f2b6e4e863e99f6acef44f8e4e013b0d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Ilya_Shlyakhter" - avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" - subject="comment 2" - date="2019-03-18T18:08:06Z" - content=""" -Tests that rely on gpg fail. I think the latest gpg versions always run gpg-agent. So if you package gpg but not gpg-agent it will try to run the host's gpg-agent which may be incompatible with the gpg included in the standalone package. -"""]] diff --git a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_3_2c93bb456d7884a5cadd57b240ee42f7._comment b/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_3_2c93bb456d7884a5cadd57b240ee42f7._comment deleted file mode 100644 index 35804fda91..0000000000 --- a/doc/bugs/git-annex_standalone_provides_gpg_but_not_gpg-agent/comment_3_2c93bb456d7884a5cadd57b240ee42f7._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2019-03-18T20:03:29Z" - content=""" -If I move gpg-agent out of path and presumably reproduce the problem, -I get this output from the test suite: - - crypto: gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory - gpg: can't connect to the agent: No such file or directory - gpg: error getting the KEK: No agent running - FAIL - Exception: user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--import","-q"] exited 2) - -Which is the kind of information I was asking for. - -[[!commit aee9adbadc2f17c5b5394fc2fde6c57c26917024]] has some relevant info. -I tried making git-annex not pass --use-agent, but it still tries -to use the agent: - - crypto: gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory - gpg: can't connect to the agent: No such file or directory - gpg: error getting the KEK: No agent running - FAIL - Exception: user error (gpg ["--quiet","--trust-model","always","--import","-q"] exited 2) - preferred content: wanted . ok - -I guess the easist thing would be to drop gpg fraom the standalone bundle. -Including gpg-agent in there seems like a bad idea; it's a daemon that -other gpg versions than the bundled one might try to talk to. -"""]] diff --git a/doc/bugs/git-clone_--single-branch_confuses_git-annex-init_and_git-annex-sync.mdwn b/doc/bugs/git-clone_--single-branch_confuses_git-annex-init_and_git-annex-sync.mdwn deleted file mode 100644 index f5f3f5d9dd..0000000000 --- a/doc/bugs/git-clone_--single-branch_confuses_git-annex-init_and_git-annex-sync.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -If a repo is cloned using `git clone --single-branch --depth 1`, `git-annex-init` and `git-annex-sync` do not seem to correctly fetch the `git-annex` and `synced/git-annex` branches. `git-annex-info` does not list remotes that were known at the cloned repo. - -> This is not a bug. You have cloned a repository without cloning the -> git-annex branch, so as far as git-annex can *possibly* know, this is a -> git repository in which git-annex has never been used before. -> -> As soon as you fetch the git-annex branch from origin, git-annex will -> know all the information that you expected it to know. So all you have to -> do is: `git fetch origin git-annex` -> -> There is no possible change I can make that will prevent or amelorate -> this particular means of shooting yourself in the foot. -> -> [[done]] --[[Joey]] diff --git a/doc/bugs/git_annex___36__command_--help_not_recoginized.mdwn b/doc/bugs/git_annex___36__command_--help_not_recoginized.mdwn deleted file mode 100644 index a48221edf5..0000000000 --- a/doc/bugs/git_annex___36__command_--help_not_recoginized.mdwn +++ /dev/null @@ -1,53 +0,0 @@ -### Please describe the problem. - -"git annex help" says to run "git-annex command --help", but doing so reports unrecognized option. - - -### What steps will reproduce the problem? - -15:25:14 -0500 adam@tooz:/tmp$ git annex help -The most frequently used git-annex commands are: - init initialize git-annex - add add files to annex - drop indicate content of files not currently wanted - get make content of annexed files available - move move content of files to/from another repository - copy copy content of files to/from another repository - sync synchronize local repository with remotes - whereis lists repositories that have file content - fsck check for problems - -Run 'git-annex' for a complete command list. -Run 'git-annex command --help' for help on a specific command. -Run `git annex help options' for a list of common options. - -15:26:27 -0500 adam@tooz:/tmp$ git annex add --help -git-annex: unrecognized option `--help' - -Usage: git-annex add [PATH ...] [option ...] - --include-dotfiles don't skip dotfiles - -To see additional options common to all commands, run: git annex help options - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20141125 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - -> [[done]]; ancient version; fixed long ago --[[Joey]] diff --git a/doc/bugs/git_annex___36__command_--help_not_recoginized/comment_1_63aa3512fd49c0c3b232eb85ed0cf4f3._comment b/doc/bugs/git_annex___36__command_--help_not_recoginized/comment_1_63aa3512fd49c0c3b232eb85ed0cf4f3._comment deleted file mode 100644 index 7a39b1fe4a..0000000000 --- a/doc/bugs/git_annex___36__command_--help_not_recoginized/comment_1_63aa3512fd49c0c3b232eb85ed0cf4f3._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-08-28T17:28:10Z" - content=""" -You are using a version of git-annex from 2014! You really ought to -upgrade. The current version has rather a lot of changes, including, -it happens, a fix for this small bug. Lots of other much larger bugs, -including at least one security hole, have also been fixed since 2014.. -"""]] diff --git a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn b/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn deleted file mode 100644 index 92a454c187..0000000000 --- a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn +++ /dev/null @@ -1,120 +0,0 @@ -### Please describe the problem. - -Git-Annex enableremote ignores encryption changes to a hybrid-cypher gcrypt remote. So it is not possible to add or remove keys. - - -### What steps will reproduce the problem? - -Having a bare repo prepared do: - - git annex initremote $remotename type=gcrypt encryption=hybrid gitrepo=ssh://giessen@magierenklave.de/annex/test keyid=$myfirstkey - initremote $remotename (encryption setup) (to gpg keys: $myfirstkey) $user@$hosts's password: - (...) - git annex sync $remotename - (...) - git annex info $remotename - (...) - uuid: $remoteuuid - (...) - encryption: hybrid (to gpg keys: $myfirstkey) - (...) - git config --get remote.$remotename.gcrypt-participants - $myfirstkey - -So far, so good. Now we try adding another key - - git annex enableremote $remotename keyid+=$mysecondkey - enableremote $remotename ok - -The command returns instantly, no interaction with the remote. - - git annex sync $remotename - (...) - git annex info $remotename - (...) - uuid: $remoteuuid - (...) - encryption: hybrid (to gpg keys: $myfirstkey) - (...) - git config --get remote.$remotename.gcrypt-participants - $myfirstkey - -Obviously our change had no effect. This can be verified by the repository being inaccessible to the second key. - -A very hacky workaround seems to be: - - git remote remove server.test -(we need this or git will complain about the remote already existing and annex will fail) - git annex enableremote $remoteuuid keyid+=$mysecondkey - enableremote $remoteuuid (encryption update) (to gpg keys: $myfirstkey $mysecondkey) $user@$hosts's password: - (...) - git annex info $remotename - (...) - encryption: hybrid (to gpg keys: $myfirstkey $mysecondkey) - (...) - git config --get remote.$remotename.gcrypt-participants - $myfirstkey $mysecondkey - -...which yields the expected results but is somewhat counterintuitive and probably a bad abuse of enableremote. - -### What version of git-annex are you using? On what operating system? - -git annex version: - - git-annex version: 6.20170302-gb35a50cca - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 6 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -uname -a - - Linux $host.$domain 4.9.3-1-default #1 SMP PREEMPT Thu Jan 12 11:32:53 UTC 2017 (2c7dfab) x86_64 x86_64 x86_64 GNU/Linux - -### Please provide any additional information below. - -gpg is running with -vvv so please don't mind the extra-verbose gpg-output. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -:~/test> git annex enableremote test keyid+=$mysecondkey -enableremote test ok -:~/test> git remote remove test -:~/test> git annex enableremote 1291d1b4-dac1-5c44-b09e-e04c03b755d6 keyid+=$mysecondkey -enableremote 1291d1b4-dac1-5c44-b09e-e04c03b755d6 (encryption update) (to gpg keys: $myfirstkey $mysecondkey) user@server's password: -gcrypt: Decrypting manifest -gpg: Signatur vom Mi 22 Mär 2017 14:50:39 CET -gpg: mittels RSA-Schlüssel 0144XXXXXXXXXXXXXXXXXXXXXXX -gpg: Korrekte Signatur von "XXXXXX" [ultimativ] -gcrypt: Remote ID is :id:Zfhze/U8YGNRIWmfNUV5 -Von gcrypt::ssh://user@server/annex/test - * [neuer Branch] synced/git-annex -> test/synced/git-annex - * [neuer Branch] synced/master -> test/synced/master - * [neuer Branch] git-annex -> test/git-annex - * [neuer Branch] master -> test/master -user@server's password: -gcrypt: Decrypting manifest -gpg: Signatur vom Mi 22 Mär 2017 14:50:39 CET -gpg: mittels RSA-Schlüssel 0144XXXXXXXXXXXXXXXXXXXXXX -gpg: Korrekte Signatur von "XXXXXX" [ultimativ] -Everything up-to-date -user@server's password: -ok -ok -(recording state in git...) -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, definitively. I enjoy using annex to backup and manage my data. I would love to see it used more often and am currently trying to get my boss to introduce it for storage of the digital backups of our documents. While preparing an encrypted test-setup I stumbled upon this. :) - -Thanks - -Jörn - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_1_e3924c02186d962e4dc1e1af8e968891._comment b/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_1_e3924c02186d962e4dc1e1af8e968891._comment deleted file mode 100644 index 9d0193d9b4..0000000000 --- a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_1_e3924c02186d962e4dc1e1af8e968891._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-04-07T16:54:19Z" - content=""" -This does not happen when I do the same thing with a directory special -remote. - -I do reproduce it with gcrypt. It must be missing a call to the code that -handles keyid+=. - -Thanks for an excellent bug report! -"""]] diff --git a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_2_5b36cd7f8ec4dd4f8787b60959512157._comment b/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_2_5b36cd7f8ec4dd4f8787b60959512157._comment deleted file mode 100644 index 22a6cdf601..0000000000 --- a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_2_5b36cd7f8ec4dd4f8787b60959512157._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-04-07T16:58:42Z" - content=""" -Huh, so it seems that for gcrypt remotes, enableremote just doesn't -call their setup function at all! - -Ah, it's because it sees the remote has an url, so it is not treated -as a special remote, but as a regular git remote, and so the -special remote encryption changes are ignored. (Since 6.20160527) - -So, enableremote needs to fail when it thinks it's enabling a regular git -remote and has been passed some parameters which cannot apply to such a -remote. Done. - -And, enableremote needs fixed to treat existing gcrypt remotes as special -remotes. Done. - -Also, gcrypt special remotes didn't actually support being re-enabled -either. I made that work. When an encryption key is added, that -automatically makes it change the gcrypt-participants, too. - -I suppose enableremote could even be made to do the `GCRYPT_FULL_REPACK` -and forced push, but that seems like too much for it to do! -"""]] diff --git a/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information.mdwn b/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information.mdwn deleted file mode 100644 index 5c76e9494f..0000000000 --- a/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information.mdwn +++ /dev/null @@ -1,156 +0,0 @@ -### Please describe the problem. - -If multiple remotes edit group information and one of them does `git annex forget --force --drop-dead` some of those edits can be lost on sync. - -### What steps will reproduce the problem? - -Make a temporary directory and `cd` into it. Then run this script: - -[[!format sh """ -#!/bin/bash - -git annex version - -git init a -cd a -git annex init -touch test -git annex add test -git annex sync -cd .. -git clone a b -cd b -git annex sync - -cd ../a -git annex group here ga -git annex sync -cd ../b -git annex group here gb -git annex forget --force --drop-dead -git annex sync - -cd ../a -git annex sync -cd ../b -git annex sync - -cd ../a -echo "A IS IN GROUP:" -git annex group . -cd ../b -echo "B IS IN GROUP:" -git annex group . - -"""]] - - -### What version of git-annex are you using? On what operating system? - -6.20170101-1+deb9u2 on Debian Stretch but I also tested this occurs in version 6.20180719 - -### Please provide any additional information below. - -Here's the output of the above script. The interesting part is the last two lines which show that remote 'b' is not in any group despite being added to group 'gb'. - -[[!format sh """ -git-annex version: 6.20170101.1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -Initialized empty Git repository in /home/matthew/test-git-annex/a/.git/ -init ok -(recording state in git...) -add test ok -(recording state in git...) -commit -[master (root-commit) ffcf48d] git-annex in matthew@thorium:~/test-git-annex/a - 1 file changed, 1 insertion(+) - create mode 120000 test -ok -Cloning into 'b'... -done. -(merging origin/git-annex into git-annex...) -commit (recording state in git...) - -On branch master -Your branch is up-to-date with 'origin/master'. -nothing to commit, working tree clean -ok -pull origin -ok -push origin -Counting objects: 3, done. -Delta compression using up to 4 threads. -Compressing objects: 100% (3/3), done. -Writing objects: 100% (3/3), 409 bytes | 0 bytes/s, done. -Total 3 (delta 0), reused 0 (delta 0) -To /home/matthew/test-git-annex/a - * [new branch] git-annex -> synced/git-annex -ok -group here ok -(recording state in git...) -commit -On branch master -nothing to commit, working tree clean -ok -group here ok -(recording state in git...) -forget git-annex (recording state in git...) -ok -(recording state in git...) -commit -On branch master -Your branch is up-to-date with 'origin/master'. -nothing to commit, working tree clean -ok -pull origin -remote: Counting objects: 3, done. -remote: Compressing objects: 100% (3/3), done. -remote: Total 3 (delta 0), reused 0 (delta 0) -Unpacking objects: 100% (3/3), done. -From /home/matthew/test-git-annex/a - e9a879d..000eb8e git-annex -> origin/git-annex -ok -(merging origin/git-annex into git-annex...) -(recording state in git...) -(recording state in git...) -push origin -Counting objects: 11, done. -Delta compression using up to 4 threads. -Compressing objects: 100% (10/10), done. -Writing objects: 100% (11/11), 1.03 KiB | 0 bytes/s, done. -Total 11 (delta 3), reused 0 (delta 0) -To /home/matthew/test-git-annex/a - + e9a879d...00986fa git-annex -> synced/git-annex (forced update) -ok -(merging synced/git-annex into git-annex...) -(recording state in git...) -commit -On branch master -nothing to commit, working tree clean -ok -commit -On branch master -Your branch is up-to-date with 'origin/master'. -nothing to commit, working tree clean -ok -pull origin -remote: Counting objects: 3, done. -remote: Compressing objects: 100% (3/3), done. -remote: Total 3 (delta 0), reused 0 (delta 0) -Unpacking objects: 100% (3/3), done. -From /home/matthew/test-git-annex/a - + 000eb8e...965b6af git-annex -> origin/git-annex (forced update) -ok -(merging origin/git-annex into git-annex...) -A IS IN GROUP: -ga -B IS IN GROUP: -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes, git-annex is slowly replacing all of my other sync and backup systems I've cobbled together over the years. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information/comment_1_f4b78aeaf9163b374254c08057222661._comment b/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information/comment_1_f4b78aeaf9163b374254c08057222661._comment deleted file mode 100644 index 75bd9bd1ac..0000000000 --- a/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information/comment_1_f4b78aeaf9163b374254c08057222661._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-08-06T19:49:06Z" - content=""" -Great bug report! - -There is a general data loss problem in this scenario, it's not specific to -group changes at all. Changes that were only present in a sibling git-annex -branch are not being preserved when the repository updates its git-annex -branch index file for a transition. - -The index file lacking those changes then gets committed with the sibling -branches as parent(s). So the changes are effectively reverted. - -The root cause is that the handleTransitions uses getRaw -to get the contents of files. That uses git cat-file git-annex:$file, which -gets the version last committed to the git-annex branch, -not the version from the git-annex branch index file. And handleTransitions is -run after all sibling branches have been union merged in the index file -but not committed yet. - -The fix is to instead use git cat-file :$file, so it will get the version -from the index. -"""]] diff --git a/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information/comment_2_1468e26d2da85bcaf50715fbe3c38490._comment b/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information/comment_2_1468e26d2da85bcaf50715fbe3c38490._comment deleted file mode 100644 index 8fe3936bc1..0000000000 --- a/doc/bugs/git_annex_forget_--drop-dead_can_lose_group_information/comment_2_1468e26d2da85bcaf50715fbe3c38490._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-08-06T21:26:36Z" - content=""" -If you lost things from the git-annex branch due this bug, -you can find the commit that contained them by `git log git-annex`, -and look for the commit before the "continuing transition" commit. - -It's then possible to get those changes applied back to the git-annex -brannch; there should be no permanent data loss due to this bug. - -Eg, here the commit that contained the lost group change was -261d1be6a2093f1e4059ed3030016c365f29413f. To get that back into the -git-annex branch, I ran: - - git update-ref git-annex 261d1be6a2093f1e4059ed3030016c365f29413f - git annex merge -"""]] diff --git a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file.mdwn b/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file.mdwn deleted file mode 100644 index 0e6f5d256a..0000000000 --- a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -### Please describe the problem. -If `git annex fsck --from web` encounters a URL that is no longer available, -it will remove all URLs from the appropriate file's location log. -Surprisingly, adding one of the URLs the file was associated to before brings back all of them. - -### What steps will reproduce the problem? - - $ git annex whereis file.txt - whereis file.txt (3 copies) - ... - - The following untrusted locations may also have copies: - 00000000-0000-0000-0000-000000000001 -- web - - web: http://example.org/dead/file.txt - web: http://example.org/alive/file.txt - ok - $ git annex fsck --from web - fsck file.txt (checking http://example.org/dead/file.txt...) (fixing location log) - ** Based on the location log, file.txt - ** was expected to be present, but its content is missing. - failed - (recording state in git...) - git-annex: fsck: 1 failed - $ git annex whereis file.txt - whereis file.txt (3 copies) - ... - ok - $ git annex addurl http://example.org/alive/file.txt - addurl file.txt ok - (recording state in git...) - $ git annex whereis file.txt - whereis file.txt (3 copies) - ... - - The following untrusted locations may also have copies: - 00000000-0000-0000-0000-000000000001 -- web - - web: http://example.org/dead/file.txt - web: http://example.org/alive/file.txt - ok - - -The only fix that seems to fix this is using `rmurl` on the dead one. - -### What version of git-annex are you using? On what operating system? - $ git annex version - git-annex version: 6.20171026 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -I'm running NixOS btw. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -I'm lovin' it! - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_1_e1503374a87da976c831cd7fa0749e58._comment b/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_1_e1503374a87da976c831cd7fa0749e58._comment deleted file mode 100644 index 6c6957f60c..0000000000 --- a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_1_e1503374a87da976c831cd7fa0749e58._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-11-07T19:58:14Z" - content=""" -I think that the real bug here is that, as long as one url still has the -content, it's still present in the web, so should not be marked as not -present. The rest of the operations in the web special remote work that -way, trying urls until one succeeds, and so should `checkKey`. -"""]] diff --git a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_2_d941d47c79ae9b72a936703aaba50ddd._comment b/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_2_d941d47c79ae9b72a936703aaba50ddd._comment deleted file mode 100644 index ae6ac88e4c..0000000000 --- a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_2_d941d47c79ae9b72a936703aaba50ddd._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="robert.schuetz@7942237bf71a2ae4f5d3cb047d167612b8c9e311" - nickname="robert.schuetz" - avatar="http://cdn.libravatar.org/avatar/89879460a9e84b9c736d982d9489d3d9" - subject="comment 2" - date="2017-11-07T20:22:04Z" - content=""" -If you want it that way, that's fine with me. -But I think it would make more sense to let `fsck` call `rmurl` on all URLs that don't hold the content anymore. -"""]] diff --git a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_3_e0a2822d931a3129dde3e280a15cf500._comment b/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_3_e0a2822d931a3129dde3e280a15cf500._comment deleted file mode 100644 index f124fe7f52..0000000000 --- a/doc/bugs/git_annex_fsck_--from_web_removes_all_urls_of_a_file/comment_3_e0a2822d931a3129dde3e280a15cf500._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-11-07T21:02:59Z" - content=""" -There may be one url that works in one situation, and another that always -works. Eg, a url on the work LAN, and a public, slower url. In such a -situation, the user would not want fsck to remove an url that is -temporarily not available. -"""]] diff --git a/doc/bugs/git_annex_help_options_not_piped_through_PAGER.mdwn b/doc/bugs/git_annex_help_options_not_piped_through_PAGER.mdwn deleted file mode 100644 index 3125014711..0000000000 --- a/doc/bugs/git_annex_help_options_not_piped_through_PAGER.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. - -Long help output doesn't honor PAGER - -### What steps will reproduce the problem? - -* Open a small terminal -* Run "git annex help options" -* Note how it displays the full text. -* Run "git help add" -* Docs are viewed via the PAGER - - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20141125 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - - -> [[done]] per my comment --[[Joey]] diff --git a/doc/bugs/git_annex_help_options_not_piped_through_PAGER/comment_1_c581374b7581708da315e53338ef40c7._comment b/doc/bugs/git_annex_help_options_not_piped_through_PAGER/comment_1_c581374b7581708da315e53338ef40c7._comment deleted file mode 100644 index c5eb45ffcf..0000000000 --- a/doc/bugs/git_annex_help_options_not_piped_through_PAGER/comment_1_c581374b7581708da315e53338ef40c7._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-08-28T17:31:03Z" - content=""" -"git annex help options" is not a thing in the current version of -git-annex. Please upgrade to a current version before filing bug reports. - -git-annex outputs to stderr when it's run with invalid -parameters. So `git annex` will output to stderr (`2>&1 | less` to page -it). `git annex add --help` outputs to stdout since the user requested -usage help and didn't do anything wrong. `git annex help add` displays the -man page, which uses a pager. That is all consistent with git's -behavior, and is fairly typical for unix programs. -"""]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn deleted file mode 100644 index eb2f6fa9cd..0000000000 --- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. -I am importing a lot of old documents into my annex. Some of these old files apparently have newlines in their filename. A run of `git annex import` aborts when it encounters such a file; the file is moved to the annex, but it is left unstaged. - -### What steps will reproduce the problem? -[[!format sh """ -bram@durian% mkdir annex -bram@durian% cd annex -bram@durian% git init -Initialized empty Git repository in /home/bram/tmp/t/annex/.git/ -bram@durian% git annex init -init ok -(Recording state in git...) -bram@durian% echo foo > ../$'foo\nbar' -bram@durian% ls -lb .. -total 8 -drwxr-xr-x 3 bram bram 4096 Jul 26 18:20 annex/ --rw-r--r-- 1 bram bram 4 Jul 26 18:20 foo\nbar -bram@durian% git annex import ../foo$'\n'bar -import foo -bar git-annex: unknown response from git cat-file ("HEAD:./foo missing","HEAD:./foo\nbar") -bram@durian% ls -lb -total 4 --r--r--r-- 2 bram bram 4 Jul 26 18:20 foo\nbar -bram@durian% git status -On branch master - -Initial commit - -Untracked files: - (use "git add ..." to include in what will be committed) - - "foo\nbar" - -nothing added to commit but untracked files present (use "git add" to track) -bram@durian% cat $'foo\nbar' -foo -"""]] - - -### What version of git-annex are you using? On what operating system? - Debian unstable - git-annex version: 5.20140717 - git version 2.0.1 - Linux durian 3.14-1-amd64 #1 SMP Debian 3.14.9-1 (2014-06-30) x86_64 GNU/Linux - -[[!tag confirmed git-bug]] -[[!title git limitations prevent using git-annex on filenames containing newlines]] - -> [[fixed|done]] with a workaround that is less efficient at handling such -> filenames, but does work at least as far as I've tested it. --[[Joey]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment deleted file mode 100644 index c4d78fa03f..0000000000 --- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 1" - date="2014-08-12T18:24:57Z" - content=""" -Congrats on being the guy with newlines in his filenames.. someone had to do it! - -Similarly, `git annex add` on the file will fail with the same error and leave it where it is and not added. - -The problem here is that while git-annex is careful to use git commands with -z, so it gets \"foo\nbar\" with a literal newline from git ls-files, `git cat-file --batch` speaks a line-based protocol. And, it parses filenames like `git ref-parse` does -- and AFAICS, that does not provide a way to input something like \"foo\\nbar\" with an escaped newline. Normally this doesn't matter, since the whole line of input is taken to be a filename, so there's no need to escape anything, but of course it fails with newlines. - -IMHO, the solution to this is to make `git cat-file --batch` have a -z option that enables NUL-delimited input (and probably output). If you want to see this happen, take it to the git developers.. - -(Should git annex import put files back if it fails to add them rather than leaving them sitting in the work tree?) -"""]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_2_7320c7806da93d0862f8f768092ef073._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_2_7320c7806da93d0862f8f768092ef073._comment deleted file mode 100644 index e1e6b9283b..0000000000 --- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_2_7320c7806da93d0862f8f768092ef073._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s" - nickname="Matthias" - subject="git and newlines" - date="2014-11-25T11:56:18Z" - content=""" -git does not support file names with newlines in them, and probably never will. Linus decided that quite early. -"""]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_3_032d4a64e2f010fcf9359e4f77b6d784._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_3_032d4a64e2f010fcf9359e4f77b6d784._comment deleted file mode 100644 index 184a77af24..0000000000 --- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_3_032d4a64e2f010fcf9359e4f77b6d784._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2014-12-01T22:33:23Z" - content=""" -Mattias seems to be wrong. It may be that some of the shell script parts of -git don't support it, or that parts of git has bugs. But as far as git's -data representation is concerned, \n is a character like any other, and -eg `git add` and `git commit` deal with it just fine. - -(\0 is a different story..) -"""]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_4_3f5e17f5d73892784640e468578819c4._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_4_3f5e17f5d73892784640e468578819c4._comment deleted file mode 100644 index af72fcb88a..0000000000 --- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_4_3f5e17f5d73892784640e468578819c4._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="graboluk@f6de53961ab0f884e203f602f65eb5cdc0fb7513" - nickname="graboluk" - subject="very annoying for new users" - date="2015-09-25T17:06:45Z" - content=""" -Hi, I'd just spent better part of a day trying to figure out why git-annex keeps crashing. I've set up everything as in the instructional video for git-annex assistant, and proceeded to add my document directory with 3000 files (latex projects, etc). git-latex started to complain about unrecognized response from git. I tried many times again, to make long story short, turns out one of my files had newline in its name (I don't even know how it happened) - -This was extremely annoying because the message which the assistant was giving me was always about some other file, the name of the offending file did not appear. So I've spent a day trying to figure out a minimal offending example (there were more obvious potential culprits - like the fact that I have many read-only dirs and so on...) - -Also, it's not a great first impression considering I'm trying to migrate from dropbox, which hasn't had any problems. - -Anyway, it's a great project. Is there a way to donate? (if it replaces dropbox for me for a month of my usual workflow I'd be very happy to donate!) - -"""]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_5_b495622a0e115484c5b6f18f21b8bf4f._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_5_b495622a0e115484c5b6f18f21b8bf4f._comment deleted file mode 100644 index 709a1a7fce..0000000000 --- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_5_b495622a0e115484c5b6f18f21b8bf4f._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2016-09-05T17:12:11Z" - content=""" -A couple others have reported dups of this bug. - -While this needs git changes to fix, it would be possible for git-annex to -eg, warn and skip whenever a filename contains a newline. Probably better -than crashing... -"""]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode.mdwn b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode.mdwn deleted file mode 100644 index cc91f24351..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode.mdwn +++ /dev/null @@ -1,59 +0,0 @@ -### Please describe the problem. -If a submodule is in direct mode, `git annex status` fails. -Apparently the recursive inspection of submodules is done by an internal call to `git status`, which then misses a working tree in the submodule. -### What steps will reproduce the problem? -[[!format sh """ -#!/bin/bash - -set -ex -d=$(mktemp -d) -echo "directory: $d" -cd $d -git init -git annex init -echo whatever > file -git annex add file -git commit -m "file added" -mkdir sub -cd sub -git init -git annex init -echo something > subfile -git annex add subfile -git commit -m "subfile added." -cd .. -git submodule add ./sub sub -git commit -m "submodule added" -cd sub -git annex direct -cd .. -git annex status -"""]] -### What version of git-annex are you using? On what operating system? -[[!format sh """ -% git annex version -git-annex version: 6.20170209+gitg16be7b5cc-1~ndall+1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: unknown -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -"""]] - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! I think it's a great piece of software! - -> direct mode has been removed from git-annex, so [[done]] --[[Joey]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_1_0258db936120767e8e41cd926cb5bfd5._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_1_0258db936120767e8e41cd926cb5bfd5._comment deleted file mode 100644 index 63cceedd9c..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_1_0258db936120767e8e41cd926cb5bfd5._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-02-20T18:30:54Z" - content=""" -Error is: - - fatal: This operation must be run in a work tree - fatal: 'git status --porcelain' failed in submodule sub - -`git status` fails the same way, and it seems that the only way -to make it work would be to pass --ignore-submodules to it. - -But I suppose then, it would need to replicate git status's submodule -traversal. - -I'm not too keen on adding complicated stuff involving submodules to direct -mode. My goal with direct mode is to eliminate the need for it. -"""]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_2_0d16964586347e6447d9193508f0d7f8._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_2_0d16964586347e6447d9193508f0d7f8._comment deleted file mode 100644 index a3e7198a4e..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_2_0d16964586347e6447d9193508f0d7f8._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3" - nickname="benjamin.poldrack" - avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d" - subject="comment 2" - date="2017-02-20T19:06:58Z" - content=""" -Yes, that's what I assumed. Therefore this bug was linked in the datalad issue regarding --ignore-submodules. - -May be we are the only ones, who are actually effected, since we heavily use submodules. If it's too much of an effort, I will find a way around it, I guess. -Either way: Thank you for having a look at it. -[[ben]] -"""]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_3_8cce6890bf13af8bfd1ed19ccd904162._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_3_8cce6890bf13af8bfd1ed19ccd904162._comment deleted file mode 100644 index e15c59a51f..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_3_8cce6890bf13af8bfd1ed19ccd904162._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-02-20T20:13:06Z" - content=""" -Would it suffice for datalad to have git-annex status --ignore-submodules -pass the option on to git status? -"""]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_4_9041ccdacce602c6c09c3fc09e95ce8d._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_4_9041ccdacce602c6c09c3fc09e95ce8d._comment deleted file mode 100644 index c5bd51a1ea..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_4_9041ccdacce602c6c09c3fc09e95ce8d._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3" - nickname="benjamin.poldrack" - avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d" - subject="comment 4" - date="2017-02-21T06:20:34Z" - content=""" -Yes, it saves half the work and eases to deal with this one. - -[[ben]] -"""]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_5_e7c09850009e961354e26f169ccdc6e3._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_5_e7c09850009e961354e26f169ccdc6e3._comment deleted file mode 100644 index a2af5ca080..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_5_e7c09850009e961354e26f169ccdc6e3._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3" - nickname="benjamin.poldrack" - avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d" - subject="comment 5" - date="2017-02-22T16:48:04Z" - content=""" -Just noticed another thing: If that failure happens, git-annex exits zero. Therefore it's hard to detect for us. We have just an empty json as return value as if the repo was clean. -It would be nice to have either a non-zero exit or something within the json to indicate that the command failed. - -[[ben]] -"""]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_6_be8774764b7892dcbf8bfa8f1fc00ab8._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_6_be8774764b7892dcbf8bfa8f1fc00ab8._comment deleted file mode 100644 index 8d86421bcf..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_6_be8774764b7892dcbf8bfa8f1fc00ab8._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2017-03-02T18:05:39Z" - content=""" -`git annex status --ignore-submodules=when` has been supported for a week -or so. - -I've fixed the nonzero exit status propigation. - -Leaving bug open for the general problem but don't anticipate working on -it. -"""]] diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_7_4e4d2ae552e2394197c2688b0dd04f48._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_7_4e4d2ae552e2394197c2688b0dd04f48._comment deleted file mode 100644 index 85573f3a26..0000000000 --- a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_7_4e4d2ae552e2394197c2688b0dd04f48._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3" - nickname="benjamin.poldrack" - avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d" - subject="comment 7" - date="2017-03-06T09:03:56Z" - content=""" -Thank you! - -[[ben]] -"""]] diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree.mdwn b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree.mdwn deleted file mode 100644 index 89f6bac1f9..0000000000 --- a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -### Please describe the problem. - -In a direct mode repo (crippled/uncrippled filesystem does not matter), when a symlink is marked using `git update-index --skip-worktree ` and removed, git annex sync still `git rm`s the symlink. This does not happen in indirect mode (git annex sync leaves the symlink in git intact). - -### What steps will reproduce the problem? - -[[!format sh """ -mkdir test-repo; cd test-repo -git init -git annex init -echo file1 >file1 -git annex add -git commit -m"update" -cd .. -git clone test-repo test-repo2; cd test-repo2 -git annex init -git annex direct -git update-index --skip-worktree file1 -rm file1 -git annex sync -"""]] - -Output of `git annex sync` indicates file has been removed from git. Repeating these steps without the `git annex direct` above to set the second repo to direct mode will succeed in retaining the symlink in git. - -### What version of git-annex are you using? On what operating system? - -4.20130521 using git-annex-standalone AUR build (uses Linux executable tarball) on Arch Linux - -### Please provide any additional information below. - -I'd like to use the skip-worktree scheme in order to be able to rm the symlink files (from the filesystem, not git), specifically for my Android devices. Syncing my music annex creates .mp3 symlinks that aren't actually MP3s, which gives the stock apps some fits. This would only be for clearing out symlinks; I fully understand that trying to doing this for downloaded content in a direct repo would be a Class A no-no. :-) - -I did a little digging in the code, and it looks like the source of this is the stageDirect step done specifically by `git annex sync` in direct repos (which makes sense, since indirect repos work). It does `git ls-files --others --exclude-standard --stage`. This list includes files marked skip-worktree, which means skip-worktree files would be treated like normal, and deleted because it's no longer there. There is an additional `-t` argument that could be added to ls-files that would provide the tag field to indicate if a file was marked skip-worktree, and they could be filtered out of processing. - -I wonder if this would have side effects, or if there are other places in the code where skip-worktree files would need to be handled, though. I'm particularly motivated to solve this, so let me know if it doesn't look like it would get looked at right away, and I'll have an excuse to get a Haskell dev environment setup again and shake the rust off. - -[[!tag confirmed]] -[[!meta tag=deprecateddirectmode]] - -> direct mode has been removed from git-annex, so [[done]] --[[Joey]] diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_1_69baeb997086c885f34fd1dc385cf5d6._comment b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_1_69baeb997086c885f34fd1dc385cf5d6._comment deleted file mode 100644 index e7baee584a..0000000000 --- a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_1_69baeb997086c885f34fd1dc385cf5d6._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 1" - date="2013-05-29T16:45:03Z" - content=""" -I'm a little worried about -t being \"semi-deprecated\". I don't know if it would be possible to use either of the other commands the man page suggests to get the info needed by `stageDirect`. (Particularly the Sha of their staged contents.) - -All of git-annex's access to the repository tree goes via Git.LsFiles and AFAICS, all the other git commands used there do respect skip-worktree. - -I encourage you to work on this, since you're motivated. -"""]] diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_2_fb8c0bebb9aaa75ee7eaf6999b1db49e._comment b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_2_fb8c0bebb9aaa75ee7eaf6999b1db49e._comment deleted file mode 100644 index a252c5ea99..0000000000 --- a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_2_fb8c0bebb9aaa75ee7eaf6999b1db49e._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="EvanDeaubl" - ip="12.130.123.174" - subject="comment 2" - date="2013-05-31T13:38:43Z" - content=""" -I share the concerns about the semi-deprecated status, although it's probably safer than they make it sound in the man page. The git test suite for sparse checkouts uses the same command to find files with skip-worktree set, and there are other tools that use it as well (magit being one example). The git maintainers couldn't remove it, or even fully deprecate it for eventual removal. It's been semi-deprecated for almost 3 years. - -I have a patch that fixes `git annex sync` and `git annex get` (it retrieved files marked skip-worktree) and it passes `git annex test`, but I'm going to more rigorously test it out on my particular use case before calling it good. When it is ready, I didn't see instructions on how you would like patches submitted anywhere in the wiki. How would you like to receive it? -"""]] diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_3_6bfd4e9a7853af93e72b717249de9439._comment b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_3_6bfd4e9a7853af93e72b717249de9439._comment deleted file mode 100644 index b92ec0f131..0000000000 --- a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_3_6bfd4e9a7853af93e72b717249de9439._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 3" - date="2013-05-31T18:22:12Z" - content=""" -I accept patches by email, or pull requests. -"""]] diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_4_a7eab4171af7e46bcc637aacf630e9db._comment b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_4_a7eab4171af7e46bcc637aacf630e9db._comment deleted file mode 100644 index c593d41e15..0000000000 --- a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_4_a7eab4171af7e46bcc637aacf630e9db._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.102" - subject="ping?" - date="2014-03-19T20:54:57Z" - content=""" -You had a patch, but never shared it. I'm curious to see it.. -"""]] diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_5_cb98789c50c58f01055183dbaf7b4eba._comment b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_5_cb98789c50c58f01055183dbaf7b4eba._comment deleted file mode 100644 index d40d2d7891..0000000000 --- a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_5_cb98789c50c58f01055183dbaf7b4eba._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="EvanDeaubl" - ip="24.251.129.149" - subject="comment 5" - date="2014-04-09T03:28:24Z" - content=""" -I'm afraid I abandoned this patch. It worked, but was still fidgety for being able to ignore parts of the tree. I found another way to do what I wanted by loading an indirect repo into /data and taking advantage of a surprise side effect in how the /sdcard filesystem translated the symlinks from the ext4 filesystem. - -I can probably scare it up from my archives, but it hasn't been kept up to date. The good news is (as I recall) the patch was pretty small. - -"""]] diff --git a/doc/bugs/git_annex_test_fails.mdwn b/doc/bugs/git_annex_test_fails.mdwn deleted file mode 100644 index 39668b60f6..0000000000 --- a/doc/bugs/git_annex_test_fails.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -### Please describe the problem. -git annex test fails outside a git repository. - -[[!format sh """ -$ git annex test -git-annex: Not in a git repository. -"""]] - -and then some tests fail once you work around that. -[[!format sh """ -Exception: getCurrentDirectory:getWorkingDirectory: resource exhausted (Too many open files) -"""]] - -Exception: getCurrentDirectory:getWorkingDirectory: resource exhausted - -### What steps will reproduce the problem? -Run `git annex test`. - -### What version of git-annex are you using? On what operating system? -HEAD at 425a3a1 built with GHC 8.2.1. - -### Please provide any additional information below. - -Full log is here: https://gist.github.com/ilovezfs/1ed886b43d534b239be25f4aa8b7394e - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! - -[[!meta title="OSX git-annex test fails: Too many open files"]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_test_fails/comment_1_5e107e34b28a48c16d1240ea02d09439._comment b/doc/bugs/git_annex_test_fails/comment_1_5e107e34b28a48c16d1240ea02d09439._comment deleted file mode 100644 index c36a360411..0000000000 --- a/doc/bugs/git_annex_test_fails/comment_1_5e107e34b28a48c16d1240ea02d09439._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-09-29T18:26:39Z" - content=""" -[Two separate problems reported in one bug report always makes extra work and -risks one of the probles being forgotten about. -Separate bug reports for separate problems, please.] - -I can reproduce test not working outside of a git repository. -That is a reversion from 6.20170818. Bisected to commit -db2a06b66f0aaf5a8e8822a0c01aa614a8e7a5a9. Fixed. - -The too many open files was also mentioned by another OSX user (also in a -bug report about something else; that bug was closed...). I have not quite -reproduced it, but running git-annex test on OSX I did see it was using 600 -or more open files and had quite a few git processes stacked up. There may -be a small leak there, that's more likely to trip over a smaller limit on -OSX. -"""]] diff --git a/doc/bugs/git_annex_test_fails/comment_2_057ba348486dfb45eafeaea4260e8642._comment b/doc/bugs/git_annex_test_fails/comment_2_057ba348486dfb45eafeaea4260e8642._comment deleted file mode 100644 index 4e5b0688fa..0000000000 --- a/doc/bugs/git_annex_test_fails/comment_2_057ba348486dfb45eafeaea4260e8642._comment +++ /dev/null @@ -1,51 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-09-29T19:13:19Z" - content=""" -On linux I'm seeing only around 90 open files max (mostly pipes to git), -and maybe 30 git processes max. It does not seem to be leaking a -git process per test directory or anything like that on linux. - -On OSX, more accurate look at the open files (75868 is the pid of the -git-annex test process) - - while sleep 1; do lsof -p 75868|wc -l; done - 24 - 32 - 36 - 46 - 47 - 49 - 41 - 32 - 24 - 30 - 27 - ... - -Never went above 80 open files. Similarly: - - while sleep 1; do ps | grep git |wc -l; done - 20 - 17 - 18 - 17 - 15 - 22 - 9 - 14 - 11 - 19 - 9 - 11 - 17 - - ... - -Never went over 30 processes. - -It would be very helpful to pause git-annex test when it starts failing -and take a look at lsof and ps to see what open files and child processes -it has. -"""]] diff --git a/doc/bugs/git_annex_test_fails/comment_3_8a60a3c79e6f0f3d4a29c886e63bffba._comment b/doc/bugs/git_annex_test_fails/comment_3_8a60a3c79e6f0f3d4a29c886e63bffba._comment deleted file mode 100644 index 7b3763139a..0000000000 --- a/doc/bugs/git_annex_test_fails/comment_3_8a60a3c79e6f0f3d4a29c886e63bffba._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2017-09-29T19:35:28Z" - content=""" -Above was with daily OSX build, which is currently built with ghc 8.0.2. -My linux test was also with ghc 8.0.2. - -It may be that ghc 8.2.1 has different cleanup behavior which -causes more open files. The other reporter was also using ghc 8.2.1. -"""]] diff --git a/doc/bugs/git_annex_test_fails/comment_4_a4bbb2efcf75167ac938b00128b340fd._comment b/doc/bugs/git_annex_test_fails/comment_4_a4bbb2efcf75167ac938b00128b340fd._comment deleted file mode 100644 index 7c132a808d..0000000000 --- a/doc/bugs/git_annex_test_fails/comment_4_a4bbb2efcf75167ac938b00128b340fd._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2017-09-30T01:24:35Z" - content=""" -Built with ghc 8.2.1 on linux, I am seeing significantly more sub-processes -and open files. Up to 170 sub-processes and 350 open files. - -Most of the open files are pipes. -Most of the sub-processes are git cat-file --batch, and these are -definitely lingering from test repos it's no longer using. - -Kind of looks like the annex state created by Test.annexeval -is not getting garbage collected, and so the handles it has open are -not getting closed. Hmm, I don't normally rely on GC to close handles, -and am a bit surprised that ever worked, since the handles are pipes to -processes that have no reason to exit unless the handles are closed. - -Made it explicitly stop the co-processes, and that seems to have fixed it. -Indeed, the number of git subprocesses dropped to mostly below 10 since -they get cleaned up without waiting for GC now. -"""]] diff --git a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn deleted file mode 100644 index 5a5bf61c9e..0000000000 --- a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn +++ /dev/null @@ -1,89 +0,0 @@ -### Please describe the problem. - -Created a special remote using one drive. -ran git annex testremote -got errors, apparently starting with: - - retrieveKeyFile: usage: mktemp [-d] [-q] [-t prefix] [-u] template ... - mktemp [-d] [-q] [-u] -t prefix - FAIL (0.01s - -### What steps will reproduce the problem? - -As above. - -### What version of git-annex are you using? On what operating system? -OSX 10.10.5 https://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg - -### Please provide any additional information below. - -Verified that using gnu coreutils mktemp fixes the problem. -Suggestion: Bundle that with the distribution. -Along those lines, consider also including rclone and the script git-annex-remote-rclone, - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -testremote alanr-onedrive (generating test keys...) Remote Tests - unavailable remote - removeKey: Cannot run git-annex-remote-!dne! -- Make sure it's in your PATH and is executable. -OK - storeKey: Cannot run git-annex-remote-!dne! -- Make sure it's in your PATH and is executable. -OK (0.43s) - checkPresent: OK - retrieveKeyFile: OK - retrieveKeyFileCheap: OK - key size Just 1048576; NoChunks; encryption none - removeKey when not present: 2017/03/09 21:48:42 Waiting for deletions to finish 2017/03/09 21:48:42 directory not found -OK (3.80s) - present False: 2017/03/09 21:48:44 directory not found -OK (1.89s) - storeKey: 2017/03/09 21:48:46 One drive root 'git-annex-test/70c/e24': Waiting for checks to finish -2017/03/09 21:48:46 One drive root 'git-annex-test/70c/e24': Waiting for transfers to finish -2017/03/09 21:48:49 -Transferred: 1 MBytes (206.541 kBytes/s) -Errors: 0 -Checks: 0 -Transferred: 1 -Elapsed time: 4.9s -OK (4.97s) - present True: Total objects: 1 Total size: 1 MBytes (1048576 Bytes) -OK (2.40s) - storeKey when already present: 2017/03/09 21:48:53 One drive root 'git-annex-test/70c/e24': Waiting for checks to finish -2017/03/09 21:48:53 One drive root 'git-annex-test/70c/e24': Waiting for transfers to finish -2017/03/09 21:48:53 -Transferred: 0 Bytes (0 Bytes/s) -Errors: 0 -Checks: 1 -Transferred: 0 -Elapsed time: 1.1s -OK (1.12s) - present True: Total objects: 1 Total size: 1 MBytes (1048576 Bytes) -OK (2.06s) - retrieveKeyFile: mktemp -d -usage: mktemp [-d] [-q] [-t prefix] [-u] template ... - mktemp [-d] [-q] [-u] -t prefix -FAIL (0.01s) - failed - fsck downloaded object: OK - retrieveKeyFile resume from 33%: FAIL - Exception: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory) - fsck downloaded object: OK - retrieveKeyFile resume from 0: FAIL - Exception: failed to lock content: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: getFileStatus: does not exist (No such file or directory) - fsck downloaded object: OK - retrieveKeyFile resume from end: cp: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: No such file or directory -FAIL - Exception: failed to lock content: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: getFileStatus: does not exist (No such file or directory) - fsck downloaded object: OK - removeKey when present: OK (2.78s) - present False: ^C - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Just starting but have high hopes :-) - -> [[done]] per my comment --[[Joey]] diff --git a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work/comment_1_66f4f2e9e674b02b2a7dee77690d26fd._comment b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work/comment_1_66f4f2e9e674b02b2a7dee77690d26fd._comment deleted file mode 100644 index 67c339b408..0000000000 --- a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work/comment_1_66f4f2e9e674b02b2a7dee77690d26fd._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-03-13T20:29:21Z" - content=""" -git-annex does not contain any calls to the "mktemp" command. - -So, it must be your external special remote that uses that command. -It's up to the authors of external special remotes to make them run -portably on whatever OS's they want to support. Probably if you mention -this to the author of whatever external special remote you're using (you -neglected to say what one it is in your bug report!), they will easily be -able to fix it. - -git-annex is not going to get in the business of bundling a bunch of stuff -that it does not depend on, sorry. -"""]] diff --git a/doc/bugs/git_annex_uninit_breaks_the_underlying_git_repo.mdwn b/doc/bugs/git_annex_uninit_breaks_the_underlying_git_repo.mdwn deleted file mode 100644 index db9d855dc8..0000000000 --- a/doc/bugs/git_annex_uninit_breaks_the_underlying_git_repo.mdwn +++ /dev/null @@ -1,51 +0,0 @@ -### Please describe the problem. - -Git-annex-uninit leaves the underlying git-repo in an unusable state because it does not revert whatever modifications the current git-annex version does to git-add. - -### What steps will reproduce the problem? - - git init Test - cd Test - touch test1.txt; git add test1.txt; git commit -m "initial commit" - git annex init - git annex uninit - touch test2.txt - git add test2.txt - -The last command fails with: - - git-annex: First run: git-annex init - error: external filter 'git-annex smudge --clean -- %f' failed 1 - error: external filter 'git-annex smudge --clean -- %f' failed`` - - -### What version of git-annex are you using? On what operating system? - - git-annex version: 7.20190912-gab739242a3 - build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.3 feed-1.2.0.0 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.10.5 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external - operating system: linux x86_64 - supported repository versions: 7 - upgrade supported from repository versions: 0 1 2 3 4 5 6 - local repository version: 7 - - -### Please provide any additional information below. - -I accidentally discovered this after a system upgrade that included the latest version of git-annex. I wasn't aware of git-add's new behaviour, and so my workflow suddenly failed silently: I was used to manually using git-annex for big files, but from day to day, I just used git normally and synced my workstations through a remote that didn't have git-annex. Now the content of my new files didn't propagate any more; I was mystified, since the files that didn't propagate looked normal (they weren't symlinks, as I was used to for annexed files, and at first I couldn't figure out how to know whether they were annexed or not). As I was in a rush and didn't have access to the internet to clear things up, I kind of panicked and tried getting rid of git-annex before it did more damage… - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I love git-annex (a brilliantly designed piece of software in my view) and have been using it a lot for years! - -> Thanks for pointing out this oversight. [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn b/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn deleted file mode 100644 index d76812d730..0000000000 --- a/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -link [gitweb](https://git.kitenet.net/?p=git-annex.git;a=summary) on [http://git-annex.branchable.com/download/](http://git-annex.branchable.com/download/) leads to cgit error Invalid request - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/glacier.mdwn b/doc/bugs/glacier.mdwn deleted file mode 100644 index cca9d3923a..0000000000 --- a/doc/bugs/glacier.mdwn +++ /dev/null @@ -1,103 +0,0 @@ -[[!meta title="glacier-cli fails with backtrace"]] - -### Please describe the problem. - -Amazon Glacier remote doesn't work as expected. It seems like glacier-cli no longer works with git-annex. - -### What steps will reproduce the problem? - -1. use git-annex from archlinux repo -2. download and install this with pip: https://github.com/basak/glacier-cli -3. follow these instructions https://git-annex.branchable.com/tips/using_Amazon_Glacier/ -4. the problems occurs when trying to move or copy content to glacier - -### What version of git-annex are you using? On what operating system? - -version: 6.20160418-geff8673 -on: Linux 4.10.13-1-ARCH #1 SMP PREEMPT Thu Apr 27 12:15:09 CEST 2017 x86_64 GNU/Linux - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -# with python 3.6 -% git annex copy file.mp3 --to glacier -copy file.mp3 (checking glacier...) (to glacier...) -98% 0.0 B/s 0sTraceback (most recent call last): - File "/home/me/.local/bin/glacier", line 736, in - main() - File "/home/me/.local/bin/glacier", line 732, in main - App().main() - File "/home/me/.local/bin/glacier", line 718, in main - self.args.func() - File "/home/me/.local/bin/glacier", line 500, in archive_upload - file_obj=self.args.file, description=name) - File "/usr/lib/python3.6/site-packages/boto/glacier/vault.py", line 178, in create_archive_from_file - writer.close() - File "/usr/lib/python3.6/site-packages/boto/glacier/writer.py", line 231, in close - self.partitioner.flush() - File "/usr/lib/python3.6/site-packages/boto/glacier/writer.py", line 79, in flush - self._send_part() - File "/usr/lib/python3.6/site-packages/boto/glacier/writer.py", line 64, in _send_part - data = b''.join(self._buffer) -TypeError: sequence item 0: expected a bytes-like object, str found -failed -git-annex: copy: 1 failed - -# -------------------------- -# with python2.7 -% git annex copy file.m3 --to glacier -copy file.mp3 (checking glacier...) (to glacier...) -98% 0.0 B/s 0sTraceback (most recent call last): - File "/home/me/.local/bin/glacier", line 736, in - main() - File "/home/me/.local/bin/glacier", line 732, in main - App().main() - File "/home/me/.local/bin/glacier", line 718, in main - self.args.func() - File "/home/me/.local/bin/glacier", line 500, in archive_upload - file_obj=self.args.file, description=name) - File "/usr/lib/python2.7/site-packages/boto/glacier/vault.py", line 178, in create_archive_from_file - writer.close() - File "/usr/lib/python2.7/site-packages/boto/glacier/writer.py", line 228, in close - self.partitioner.flush() - File "/usr/lib/python2.7/site-packages/boto/glacier/writer.py", line 79, in flush - self._send_part() - File "/usr/lib/python2.7/site-packages/boto/glacier/writer.py", line 75, in _send_part - self.send_fn(part) - File "/usr/lib/python2.7/site-packages/boto/glacier/writer.py", line 222, in _upload_part - self.uploader.upload_part(self.next_part_index, part_data) - File "/usr/lib/python2.7/site-packages/boto/glacier/writer.py", line 129, in upload_part - content_range, part_data) - File "/usr/lib/python2.7/site-packages/boto/glacier/layer1.py", line 1279, in upload_part - response_headers=response_headers) - File "/usr/lib/python2.7/site-packages/boto/glacier/layer1.py", line 114, in make_request - data=data) - File "/usr/lib/python2.7/site-packages/boto/connection.py", line 1071, in make_request - retry_handler=retry_handler) - File "/usr/lib/python2.7/site-packages/boto/connection.py", line 943, in _mexe - request.body, request.headers) - File "/usr/lib/python2.7/httplib.py", line 1042, in request - self._send_request(method, url, body, headers) - File "/usr/lib/python2.7/httplib.py", line 1082, in _send_request - self.endheaders(body) - File "/usr/lib/python2.7/httplib.py", line 1038, in endheaders - self._send_output(message_body) - File "/usr/lib/python2.7/httplib.py", line 880, in _send_output - msg += message_body -UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128) -failed -git-annex: copy: 1 failed - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) -Yes it's a great tool :). Thanks! -AWS Glacier integration would be a perfect addition and I could employ git-annex at my company. - -> Closing as it's not a bug in git-annex, but glacier-cli. [[done]] -> --[[Joey]] diff --git a/doc/bugs/glacier/comment_1_257c401ee74fd48f0b2930f18b82c8c9._comment b/doc/bugs/glacier/comment_1_257c401ee74fd48f0b2930f18b82c8c9._comment deleted file mode 100644 index ad6c3e9f67..0000000000 --- a/doc/bugs/glacier/comment_1_257c401ee74fd48f0b2930f18b82c8c9._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2017-05-16T18:19:13Z" - content=""" -That looks rather more like a bug in glacier-cli than a bug in git-annex to -me. - -"expected a bytes-like object, str found" has a ton of google hits, -and looks to be breakage related to python 3's changes to string handling. - -Please file a bug on glacier-cli, and consider making it use python 2 until -it can be fixed. I'll bet python 2 will avoid this problem. -"""]] diff --git a/doc/bugs/glacier/comment_2_5475986eed257c535c21833c23b7661c._comment b/doc/bugs/glacier/comment_2_5475986eed257c535c21833c23b7661c._comment deleted file mode 100644 index a6223338b0..0000000000 --- a/doc/bugs/glacier/comment_2_5475986eed257c535c21833c23b7661c._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="namsgorf@6b5ce57fbe9dc2a2c65d6817151f107dc22f438c" - nickname="namsgorf" - avatar="http://cdn.libravatar.org/avatar/b85cacece5b347853dc35d97371b9e0c" - subject="comment 2" - date="2017-05-21T13:40:07Z" - content=""" -IIRC, at the time I wrote glacier-cli, boto (the Python AWS library it uses) had no Python 3 support, so I targeted Python 2 only. I see that boto supports Python 3 now. Patches to glacier-cli for Python 3 support welcome. - -Your Python 2 error looks like https://bugs.python.org/issue11898 to me. I know that others have hit the same error in the past. It's a problem between boto and httplib and Python, not a bug in glacier-cli. I don't think it affects Debian or Ubuntu, so you may need to take it up with Arch developers (perhaps Debian or Ubuntu carries a patch?) -"""]] diff --git a/doc/bugs/googlemail.mdwn b/doc/bugs/googlemail.mdwn deleted file mode 100644 index 2fdf6c2da1..0000000000 --- a/doc/bugs/googlemail.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -### Please describe the problem. -Git-Annex crashes when configuring jabber account with foo.bar@googlemail.com - -### What steps will reproduce the problem? -Configure the Jabber Account with foo.bar@googlemail.com instead of foo.bar@gmail.com. The domain googlemail was used for a long time in germany because of a license issue. - -### What version of git-annex are you using? On what operating system? -Mac OS X - 10.8.3 Mountain Lion - -Version: 4.20130709-g18e5f43 - -Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS - - -[[!meta title="xmpp fails to work with googlemail domain"]] -[[!tag design/assistant]] - -> git-annex no longer contains XMPP support, so this bug is "fixed". -> [[done]] --[[Joey]] diff --git a/doc/bugs/googlemail/comment_1_5614fa85029f9f97be03cb74899a7099._comment b/doc/bugs/googlemail/comment_1_5614fa85029f9f97be03cb74899a7099._comment deleted file mode 100644 index eb3c388118..0000000000 --- a/doc/bugs/googlemail/comment_1_5614fa85029f9f97be03cb74899a7099._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm8BAEUyzYhORZmMuocRTk4M-3IumDm5VU" - nickname="luciusf0" - subject="Bug still valid" - date="2014-07-31T08:35:29Z" - content=""" -The bug is still valid. A lot of german users had to use the @googlemail.com extension as google couldn't get the gmail domain in Germany. -So it might be bothering not just a few people, but a whole country! Now, if that doesn't count ... - - Mac OSX 10.9.4 - Version: 5.20140717-g5a7d4ff - Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash - -This is the message I get - - Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: host xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt2.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt1.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt4.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt3.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]})) - - -"""]] diff --git a/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment b/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment deleted file mode 100644 index 1303a2077b..0000000000 --- a/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 2" - date="2014-08-12T17:39:09Z" - content=""" -AFAICS, xmpp.l.google.com is the correct XMPP server; it's what the SRV record for googlemail.com says to use. - -Since it fails with an authentication error, I wonder if google's XMPP is rejecting a user@googlemail.com jid and expects the domain to be @gmail.com or something else. Would that be allowed by the XMPP spec? I don't know. - - -"""]] diff --git a/doc/bugs/http_git_remote_uuid_discovery_repeated.mdwn b/doc/bugs/http_git_remote_uuid_discovery_repeated.mdwn deleted file mode 100644 index 7b3aa03c44..0000000000 --- a/doc/bugs/http_git_remote_uuid_discovery_repeated.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -When cloning eg , each time git-annex -is run, it tries to get the uuid, fails, prints a warning. It should set -annex-ignore instead, so that only happens once. --[[Joey]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/i386ancient_tarball_git_too_old_error.mdwn b/doc/bugs/i386ancient_tarball_git_too_old_error.mdwn deleted file mode 100644 index fc12e94acb..0000000000 --- a/doc/bugs/i386ancient_tarball_git_too_old_error.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -Installing 7.20190912 from the \"ancient\" tarball at https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386-ancient.tar.gz on an x86 Synology NAS, I get - -$ git annex merge - - Git is older than version 2.22 and so it has a memory leak that affects using unlocked files. Recommend you upgrade git before unlocking any files in your repository. -merge git-annex ok -git-annex: thread blocked indefinitely in an MVar operation - -> It seems I messed something up, that build is supposed to have an old git -> that's patched to work, and with a special version number that git-annex -> understands will work. --[[Joey]] - -> > I don't know what went wrong, other than it was surely several layers -> > of human error. I've updated the tarball, and confirmed it's good now. -> > [[done]] --[[Joey]] diff --git a/doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add.mdwn b/doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add.mdwn deleted file mode 100644 index f8a77f32dc..0000000000 --- a/doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -### Please describe the problem. -I've enabled annex.genmetadata to track file modification time. When I unlock, edit and re-add a file, annex imports the modification data from its previous life instead of using the edited (or unedited) file's. - -Annex should always use the added file's mtime as modification time, even if there is conflicting pre-existing metadata. Even better would be if it stored modification time per-object, not worktree file. - -### What steps will reproduce the problem? -```git init testannex; -cd testannex; -git annex init; -git config annex.genmetadata true; -touch bar; -git annex add bar; -git annex sync; -git annex unlock bar; -vim bar; -git annex add bar``` - -output: `Copied metadata from old version of bar to new version. If you don't want this copied metadata, run: git annex metadata --remove-all bar` - -### What version of git-annex are you using? On what operating system? -6.20180227, various Linuxes. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add/comment_1_b215c8ce0f2094a116672572951b19fc._comment b/doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add/comment_1_b215c8ce0f2094a116672572951b19fc._comment deleted file mode 100644 index d598c7afcb..0000000000 --- a/doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add/comment_1_b215c8ce0f2094a116672572951b19fc._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-04-04T16:51:36Z" - content=""" -This happens in Annex.MetaData.genMetaData. First it copies -metadata from the oldkey to the new key. Then it -calls addMetaData on the dateMetaData of the file's mtime. - -In dateMetaData, there's a `filter isnew`, which makes -it filter out any of the date fields that already exist -in the metadata of the new key. - -This was done intentionally, see -[[!commit 8d5158fa3151be4c7fc698b96ed887b43ac48769]] -But that's lacking an explanation of why it was done. - -Note that dateMetaData is also used in Command.ImportFeed -to convert a itempubdate into year and month metadata. -But changing its behavior to override old dates -would not change that code path. - -So, I don't see a problem with making this change, and have gone ahead and -done it. -"""]] diff --git a/doc/bugs/import_--force_does_not_operate_on_locked_files.mdwn b/doc/bugs/import_--force_does_not_operate_on_locked_files.mdwn deleted file mode 100644 index b0ba103622..0000000000 --- a/doc/bugs/import_--force_does_not_operate_on_locked_files.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -`git-annex import --force` does not work on locked files (only unlocked files). Running `7.20181106-g352f88226` on macOS 10.12.6 - -> Nicely spotted! [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/import_tree_should_skip_.git.mdwn b/doc/bugs/import_tree_should_skip_.git.mdwn deleted file mode 100644 index 8ef9df8ee9..0000000000 --- a/doc/bugs/import_tree_should_skip_.git.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -If the remote being imported from has a .git directory, -the import of it fails, because git does not allow adding .git -to a repo. - -But, git *does* allow creating a tree object containing .git, it just can't -check it out. So what happens is that the remote tracking branch contains -.git, but when git is asked to merge that into master, it skips checking -out those files. - -An export back to the remote will then delete the .git directory from it. - -But note that there is *not* data loss! git-annex keeps all the files -in its object store, and the remote tracking branch contains a tree with -the .git in it, so if necessary it could be reconstructed. But with some -difficulty. - -The solution is certianly to - -1. filter out .git when importing -2. avoid deleting .git when exporting - - As long as the export tracking branch did not contain .git, - an export will harm no .git directories, because an exporttree - remote uses removeExportDirectoryWhenEmpty, not removeExportDirectory, - so will not delete non-empty directories. And other than deleting - directories, exporting only deletes files that are removed in the git - diff between two trees; if neither tree contained .git, the diff won't - contain it either, and so if importing skips .git, this will be ok. - ---[[Joey]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info.mdwn b/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info.mdwn deleted file mode 100644 index 937ec5a9e3..0000000000 --- a/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info.mdwn +++ /dev/null @@ -1,53 +0,0 @@ -### Please describe the problem. - -git-annex fails to parse the "Dlf - Der Tag" RSS feed. It doesn't give me helpful info with debug and verbose flags either. In other RSS reader (tested Akregator), the feed is working. - -### What steps will reproduce the problem? - -``` -cd ~/podcasts # into any annexed dir -git annex importfeed https://www.deutschlandfunk.de/podcast-deutschlandfunk-der-tag.3417.de.podcast.xml -``` - -### What version of git-annex are you using? On what operating system? - -- git-annex version: 7.20190507-g6eaa0af42f -- Archlinux (Linux 5.1.11-arch1-1-ARCH) - -### Please provide any additional information below. - -[[!format sh """ -importfeed checking known urls [2019-06-20 11:01:31.01738567] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2019-06-20 11:01:31.018774597] process done ExitSuccess -[2019-06-20 11:01:31.018844437] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2019-06-20 11:01:31.019935278] process done ExitSuccess -[2019-06-20 11:01:31.020116376] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..776b1321007e3f2570b7bfdff9ac2f6a03f9b3f7","--pretty=%H","-n1"] -[2019-06-20 11:01:31.021636336] process done ExitSuccess -[2019-06-20 11:01:31.02184214] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."] -[2019-06-20 11:01:31.023188187] process done ExitSuccess -ok -importfeed https://www.deutschlandfunk.de/podcast-deutschlandfunk-der-tag.3417.de.podcast.xml [2019-06-20 11:01:31.04530659] Request { - host = "www.deutschlandfunk.de" - port = 443 - secure = True - requestHeaders = [("Range","bytes=0-"),("Accept-Encoding","identity"),("User-Agent","git-annex/7.20190507-g6eaa0af42f")] - path = "/podcast-deutschlandfunk-der-tag.3417.de.podcast.xml" - queryString = "" - method = "GET" - proxy = Nothing - rawBody = False - redirectCount = 10 - responseTimeout = ResponseTimeoutDefault - requestVersion = HTTP/1.1 -} - - - warning: parsing the feed failed -ok -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -<3 - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info/comment_1_25df292c558fb470b5db4a67461ce788._comment b/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info/comment_1_25df292c558fb470b5db4a67461ce788._comment deleted file mode 100644 index e0f053330d..0000000000 --- a/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info/comment_1_25df292c558fb470b5db4a67461ce788._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2019-06-20T15:18:49Z" - content=""" -Somehow git-annex receives a truncated file from the web server, -so it is unable to parse it. - -That only happens when using the haskell http library to download. -When git-annex is configured to use curl, it works. - -So, workaround: - - git -c annex.security.allowed-http-addresses=all -c annex.web-options=-4 annex importfeed \ - https://www.deutschlandfunk.de/podcast-deutschlandfunk-der-tag.3417.de.podcast.xml - -git-annex addurl downloads the complete file, so the problem does not -seem to be with the haskell http library, but something to do with how -importfeed is using it that causes a truncation. - -Aha, importfeed uses withTmpFile, so the destination file exists with 0 -size. This triggers a resume code path. And it looks to me like this web -server may not handle resume very well, it appears to send ~32kb -of data and not the whole file in that case. - -So, the obvious fix is to not resume when the destination file is empty, -and I've done that. -"""]] diff --git a/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info/comment_2_ae30337dc8683117cd8afc8fb3dcfde0._comment b/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info/comment_2_ae30337dc8683117cd8afc8fb3dcfde0._comment deleted file mode 100644 index 1abefe1cde..0000000000 --- a/doc/bugs/importfeed___34__parsing_the_feed_failed__34___without_further_info/comment_2_ae30337dc8683117cd8afc8fb3dcfde0._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="grmat@f46c69b114fc77408ff25d75efa4c7dc10b4c0b1" - nickname="grmat" - subject="Thank you very much!" - date="2019-06-20T22:54:49Z" - content=""" -Thanks for the quick response and fix! -"""]] diff --git a/doc/bugs/importfeed_bad_request_without_User-Agent__58__.mdwn b/doc/bugs/importfeed_bad_request_without_User-Agent__58__.mdwn deleted file mode 100644 index 5c9b31713e..0000000000 --- a/doc/bugs/importfeed_bad_request_without_User-Agent__58__.mdwn +++ /dev/null @@ -1,228 +0,0 @@ -### Please describe the problem. - -Since upgrading to `6.20180626-gdf91a5cff` (pre-built OS X binary on OS X 10.11) it appears `git annex importfeed` is unable to properly download a RSS feed from one particular site -- it gets back `400 Bad Request` from the website, and then unsurprisingly reports `warning: bad feed content; no enclosures to download`. The relevant RSS feed appears sane when downloaded from the same URL with `wget` or `curl`. The previous `git-annex` version I was using on this machine (before the security update), `6.20170320-g41c5d9d` was able to download this RSS feed (I realise that's a rather large window of changes!). - -It appears the older version (`6.20170320-g41c5d9d`) used `wget` to download the podcast RSS, and the newer version (`6.20180626-gdf91a5cff`) seems to fetch the RSS internally in a way that does not work with this RSS feed (nor does the newer version appear to provide debug output of what it is doing at that step that goes wrong, unlike the previous version which shows the explicit `wget` command run, even if multiple `--debug` and/or `--verbose` options are provided). - -All other podcast RSS feeds work on both versions. - -As best I can tell from packet captures and `telnet` debugging, the issue is that the new `git annex importfeed` does not send a `User-Agent:` header. Possibly some anti-DoS/anti-spam front end is rejecting it as a result? - -Can a suitable `User-Agent:` header be added to the `git annex importfeed` HTTP requests? - -### What steps will reproduce the problem? - -Attempt to `git annex importfeed` the feed `'https://theythempodcast.com/episodes?format=RSS'`. The problem also appears reproducible with `'http://theythempodcast.com/episodes?format=RSS'` (ie, unencrypted), which makes debugging a wee bit simpler (ie, packet captures can help). - -Failing, on `6.20180626-gdf91a5cff`: - - ewen@ashram:~/Music/podcasts$ git annex --debug importfeed --template="${TEMPLATE}" 'https://theythempodcast.com/episodes?format=RSS' 2>&1 - importfeed checking known urls [2018-07-15 13:36:53.298188] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] - [2018-07-15 13:36:53.306676] process done ExitSuccess - [2018-07-15 13:36:53.306768] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] - [2018-07-15 13:36:53.314672] process done ExitSuccess - [2018-07-15 13:36:53.315353] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."] - [2018-07-15 13:36:53.325249] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] - [2018-07-15 13:36:53.32666] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"] - [2018-07-15 13:36:53.768979] process done ExitSuccess - ok - importfeed https://theythempodcast.com/episodes?format=RSS download failed: - - 400 Bad Request - - - -

400 Bad Request

- 

e64OsAKG/PqPs52sZ @ Sun, 15 Jul 2018 01:36:57 GMT
- 

SEC-43
- 


-    
-    
-
-      warning: bad feed content; no enclosures to download
-    ok
-    [2018-07-15 13:36:58.076606] process done ExitSuccess
-    [2018-07-15 13:36:58.077183] process done ExitSuccess
-    ewen@ashram:~/Music/podcasts$ 
-
-Working, on `6.20170320-g41c5d9d`:
-
-
-ewen@ashram:~/Music/podcasts$ /Applications/OpenSource/git-annex-2017-03-20.app/Contents/MacOS/git-annex importfeed --template="${TEMPLATE}" 'https://theythempodcast.com/episodes?format=RSS'
-importfeed checking known urls ok
-importfeed https://theythempodcast.com/episodes?format=RSS 
-/var/folders/p1/gpj 100%[===================>]  32.62K  61.4KB/s    in 0.5s    
-2018-07-15 13:31:17 URL:https://theythempodcast.com/episodes?format=RSS [33404/33404] -> "/var/folders/p1/gpjb1g7s00zgp64p87w19pgm0000gn/T/feed16807282475249" [1]
-ok
-ewen@ashram:~/Music/podcasts$ /Applications/OpenSource/git-annex-2017-03-20.app/Contents/MacOS/git-annex --debug importfeed --template="${TEMPLATE}" 'https://theythempodcast.com/episodes?format=RSS' 2>&1 | grep -A 1 "format=RSS"
-importfeed https://theythempodcast.com/episodes?format=RSS 
-[2018-07-15 13:33:05.367548] call: wget ["-nv","--show-progress","--clobber","-c","-O","/var/folders/p1/gpjb1g7s00zgp64p87w19pgm0000gn/T/feed16807282475249","https://theythempodcast.com/episodes?format=RSS","--user-agent","git-annex/6.20170320-g41c5d9d"]
-
-     0K .......... .......... .......... ..                   100%  121K=0.3s2018-07-15 13:33:07 URL:https://theythempodcast.com/episodes?format=RSS [33404/33404] -> "/var/folders/p1/gpjb1g7s00zgp64p87w19pgm0000gn/T/feed16807282475249" [1]
-[2018-07-15 13:33:07.050443] process done ExitSuccess
-ewen@ashram:~/Music/podcasts$ 
-

-
-In both cases the `TEMPLATE` value is the same one I've used for years, and works with all the other podcast feeds:
-
-    ewen@ashram:~/Music/podcasts$ set | grep TEMPLATE
-    TEMPLATE='archive/${feedtitle}/${itemtitle}${extension}'
-    ewen@ashram:~/Music/podcasts$ 
-
-### What version of git-annex are you using? On what operating system?
-
-OS X 10.11 (El Capitan), using the pre-built OS X binaries downloaded just after the security release came out.
-
-
-ewen@ashram:~/Music/podcasts$ git annex version
-git-annex version: 6.20180626-gdf91a5cff
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: darwin x86_64
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-local repository version: 5
-ewen@ashram:~/Music/podcasts$ 
-

-
-
-
-### Please provide any additional information below.
-
-Working request (created with `wget`, then replicated with `telnet`):
-
-
-ewen@ashram:~$ telnet 198.185.159.144 80
-Trying 198.185.159.144...
-Connected to 198.185.159.144.
-Escape character is '^]'.
-GET /episodes?format=RSS HTTP/1.1
-User-Agent: Wget/1.19.5 (darwin15.6.0)
-Accept: */*
-Accept-Encoding: identity
-Host: theythempodcast.com
-Connection: Keep-Alive
-Range: bytes=0-
-
-HTTP/1.1 301 Moved Permanently
-Date: Sun, 15 Jul 2018 02:02:53 GMT
-X-ServedBy: web012
-Location: https://theythempodcast.com/episodes?format=RSS
-Transfer-Encoding: chunked
-x-contextid: ZBu72tcg/OJSeq1q9
-x-via: 1.1 echo017
-
-0
-
-^]
-telnet> quit
-Connection closed.
-ewen@ashram:~$ 
-

-
-Failing request (as sent by `git-annex importfeed`):
-
-    ewen@ashram:~$ telnet 198.185.159.144 80
-    Trying 198.185.159.144...
-    Connected to 198.185.159.144.
-    Escape character is '^]'.
-    GET /episodes?format=RSS HTTP/1.1
-    Host: theytheypodcast.com
-    Range: bytes=0-
-    Accept-Encoding: identity
-
-    HTTP/1.1 400 Bad Request
-    content-length: 378
-    x-synthetic: true
-    expires: Thu, 01 Jan 1970 00:00:00 UTC
-    pragma: no-cache
-    cache-control: no-cache, must-revalidate
-    content-type: text/html; charset=UTF-8
-    connection: close
-    date: Sun, 15 Jul 2018 02:01:14 UTC
-    x-contextid: 1WIJdGgE/Y1Tq8lJu
-    x-via: 1.1 echo008
-
-    
-    
-    400 Bad Request
-    
-    
-    
-    
400 Bad Request

-    
1WIJdGgE/Y1Tq8lJu @ Sun, 15 Jul 2018 02:01:14 GMT

-    
SEC-43

-    

-    
-    Connection closed by foreign host.
-    ewen@ashram:~$ 
-
-Also failing request, with minimal HTTP/1.1 headers:
-
-    ewen@ashram:~$ telnet 198.185.159.144 80
-    Trying 198.185.159.144...
-    Connected to 198.185.159.144.
-    Escape character is '^]'.
-    GET /episodes?format=RSS HTTP/1.1
-    Host: theythempodcast.com
-
-    HTTP/1.1 400 Bad Request
-    content-length: 378
-    x-synthetic: true
-    expires: Thu, 01 Jan 1970 00:00:00 UTC
-    pragma: no-cache
-    cache-control: no-cache, must-revalidate
-    content-type: text/html; charset=UTF-8
-    connection: close
-    date: Sun, 15 Jul 2018 02:07:14 UTC
-    x-contextid: c05RnFlG/h78z0OqB
-    x-via: 1.1 echo034
-
-    
-    
-    400 Bad Request
-    
-    
-    
-    
400 Bad Request

-    
c05RnFlG/h78z0OqB @ Sun, 15 Jul 2018 02:07:14 GMT

-    
SEC-43

-    

-    
-    Connection closed by foreign host.
-    ewen@ashram:~$ 
-
-Apparently minimal working request:
-
-    ewen@ashram:~$ telnet 198.185.159.144 80
-    Trying 198.185.159.144...
-    Connected to 198.185.159.144.
-    Escape character is '^]'.
-    GET /episodes?format=RSS HTTP/1.1
-    User-Agent: Wget/1.19.5 (darwin15.6.0)
-    Host: theythempodcast.com
-
-    HTTP/1.1 301 Moved Permanently
-    Date: Sun, 15 Jul 2018 02:09:09 GMT
-    X-ServedBy: web025
-    Location: https://theythempodcast.com/episodes?format=RSS
-    Transfer-Encoding: chunked
-    x-contextid: veJm4JC0/sT3ENh27
-    x-via: 1.1 echo017
-
-    0
-
-    ^]
-    telnet> quit
-    Connection closed.
-    ewen@ashram:~$ 
-
-Note that the only addition was adding a `User-Agent:` header (copied from the `wget` request).  The redirect to HTTPS is expected here, as we are initially requesting via HTTP for `telnet`s benefit (I did try to get `openssl s_client` working, but it appeared the TLS connection timed out before I could manually complete a request, and I had no luck piping the request into `openssl s_client`).
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Absolutely :-)  `git annex` has been my podcatcher, and media management tool for years.  Thanks for writing it!
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/importfeed_bad_request_without_User-Agent__58__/comment_1_4412b2d9f4ed59ff078c8efd9ae6e13f._comment b/doc/bugs/importfeed_bad_request_without_User-Agent__58__/comment_1_4412b2d9f4ed59ff078c8efd9ae6e13f._comment
deleted file mode 100644
index 322506b8a4..0000000000
--- a/doc/bugs/importfeed_bad_request_without_User-Agent__58__/comment_1_4412b2d9f4ed59ff078c8efd9ae6e13f._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="ewen"
- avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
- subject="User-Agent"
- date="2018-07-15T02:21:47Z"
- content="""
-In theory `User-Agent:` is \"optional\", but [clients `SHOULD` send it](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43).  Looks like some servers are particularly fussy about it being sent... and off the top of my head I can't think of a reason *not* to send a `User-Agent:` header of some sort, as it is *very* widely sent.
-
-Ewen
-"""]]
diff --git a/doc/bugs/importfeed_bad_request_without_User-Agent__58__/comment_2_ae6eee51655aa6b1152ade3bdf7f700f._comment b/doc/bugs/importfeed_bad_request_without_User-Agent__58__/comment_2_ae6eee51655aa6b1152ade3bdf7f700f._comment
deleted file mode 100644
index eb9d012eed..0000000000
--- a/doc/bugs/importfeed_bad_request_without_User-Agent__58__/comment_2_ae6eee51655aa6b1152ade3bdf7f700f._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-07-16T15:48:08Z"
- content="""
-Hmm, it should be sending a user agent. 
-
-Wow, it's not sending a user agent!!!
-
-Thank you very much for noticing this glaring omission.
-"""]]
diff --git a/doc/bugs/importfeed_does_not_work_with_socks_proxy.mdwn b/doc/bugs/importfeed_does_not_work_with_socks_proxy.mdwn
deleted file mode 100644
index 4f892469dc..0000000000
--- a/doc/bugs/importfeed_does_not_work_with_socks_proxy.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-It appears that `git annex importfeed` can not be used in with socks proxies because it uses wget unconditionally (at least in the Debian build).
-
-For `addurl`, I could configure the system to use a socks proxy by setting `git config annex.web-download-command "curl --silent --preproxy socks4a://localhost:1080 %url -o %file"`; for `importfeed`, I found no option to override the command used to fetch the URL, and `wget` [lacks SOCKS support](https://savannah.gnu.org/bugs/?func=detailitem&item_id=43576).
-
-Please consider using `web-download-command` for `importfeed` too, introducing a dedicated option `web-get-command` (that would output to stdout rather than %file), or otherwise supporting operation behind a SOCKS proxy.
-
-> Closing this, since the http library git-annex uses supports socks
-> proxies via environment settings, as far as I know. [[done]] --[[Joey]] 
diff --git a/doc/bugs/importfeed_does_not_work_with_socks_proxy/comment_1_9797d8de55cf91288ecfc64a7e96645d._comment b/doc/bugs/importfeed_does_not_work_with_socks_proxy/comment_1_9797d8de55cf91288ecfc64a7e96645d._comment
deleted file mode 100644
index 3db7a070da..0000000000
--- a/doc/bugs/importfeed_does_not_work_with_socks_proxy/comment_1_9797d8de55cf91288ecfc64a7e96645d._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-02-22T16:32:33Z"
- content="""
-It's true that importfeed calls Url.download to download the feed file, 
-without bothering to support annex.web-download-command. That could easily
-be changed.
-
-However, it also uses Url.getUrlInfo, which does not and cannot use the
-annex.web-download-command interface, and which is too complicated an
-interface to make into a hook.
-
-Indeed, annex.web-download-command was never intended to cover all
-the ways git-annex uses http, but only uses of http to download
-large file contents. And importfeed does use it for such downloads,
-but not for its other http needs.
-
-To configure use of a proxy, you would probably be best served by using
-the `http_proxy` and `https_proxy` environment variables, which are
-supported by wget, curl, and by the haskell http library that git-annex
-also uses.
-"""]]
diff --git a/doc/bugs/importtree_not_supported_in_adb_remote.mdwn b/doc/bugs/importtree_not_supported_in_adb_remote.mdwn
deleted file mode 100644
index d6393015e0..0000000000
--- a/doc/bugs/importtree_not_supported_in_adb_remote.mdwn
+++ /dev/null
@@ -1,45 +0,0 @@
-### Please describe the problem.
-I am following these instructions:
-
-but encouter this issue:
-
-```
-$ git annex initremote android type=adb androiddirectory=/sdcard/DCIM encryption=none exporttree=yes importtree=yes
-initremote android 
-git-annex: importtree is not supported by this special remote
-failed
-git-annex: initremote: 1 failed
-```
-
-### What steps will reproduce the problem?
-```
-mkdir testAdbRemote
-cd testAdbRemote
-git init
-git annex init
-git annex initremote android type=adb androiddirectory=/sdcard/DCIM encryption=none exporttree=yes importtree=yes
-```
-
-### What version of git-annex are you using? On what operating system?
-Latest conda one in Ubuntu 18.04 LTS
-
-```
-$ git annex version
-git-annex version: 7.20190322-g7e5502b
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.4.2 http-client-0.5.14 persistent-sqlite-2.9.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-local repository version: 5
-```
-
-### Please provide any additional information below.
-Not needed
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-git-annex has worked wonderfully well for me in the past two years of use and having the described workflow to sync with my Android would be icing on the cake! Moreover, Joey is an awesome dev!
-
-> [[done]] --[[Joey]]
diff --git a/doc/bugs/importtree_not_supported_in_adb_remote/comment_1_8efcccf29a648aa8ecbc9ef0274d9bff._comment b/doc/bugs/importtree_not_supported_in_adb_remote/comment_1_8efcccf29a648aa8ecbc9ef0274d9bff._comment
deleted file mode 100644
index d11393acd0..0000000000
--- a/doc/bugs/importtree_not_supported_in_adb_remote/comment_1_8efcccf29a648aa8ecbc9ef0274d9bff._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-04-23T16:41:43Z"
- content="""
-This feature is new and has not been in a release of git-annex yet.
-"""]]
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6.mdwn b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6.mdwn
deleted file mode 100644
index 00c12567b3..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6.mdwn
+++ /dev/null
@@ -1,66 +0,0 @@
-In a v6 repository, `git annex get` of a particular file re-downloaded it
-each time it was run. `git annex whereis` said the content was locally
-present. But, `git annex fsck` of the file said the content was
-missing, and removed it from the location log.
-
-The file was locked, and the repository was on ext4.
-
-Reported by gleachkr on IRC. Don't have enough information to reproduce
-the problem yet. --[[Joey]]
-
-> My initial analysis is that this must be a problem with
-> `Annex.Content.inAnnex`. Note that checks the cached inode for the
-> content and if it finds a mismatch, it behaves as if the content is not
-> present. That would be consistent with the problem as reported.
-> 
-> When I init a v6 repository and add some locked files, no inode cache is
-> recorded, which makes sense as they're locked.
-> 
-> Hypothesis: A cached inode for the key got into the keys database,
-> despite the file being locked, and that is messing up inAnnex.
-> 
-> Should inAnnex even be checking the inode cache for locked content?
-> This seems unncessary, and note that it's done for v4 mode as well as v6.
-> 
-> How could a cached inode for a locked file leak in? Perhaps the file
-> was earlier unlocked. Or perhaps another, unlocked file, had the same
-> content. I tried both these scenarios, and was able to get a cached
-> inode to be listed for a file, but in my tests at least, it also cached
-> the inode of the locked file, and I did not replicate the problem.
-> 
-> --[[Joey]]
-
-> > When annex.thin is not set, inAnnex does not need to check the inode
-> > cache, and not checking it will avoid this problem.
-> > 
-> > It is necessary for inAnnex to check the inode cache when annex.thin
-> > is set, because then the object file can be a hard link to the working
-> > tree and so modifiable.
-> > 
-> > Checking for link count of 2 and only then checking the inode cache
-> > won't suffice though, because the object file could be modified and then the
-> > worktree file deleted, and then the object file would be modified with
-> > a link count of 1. So with annex.thin, have to always check the inode
-> > cache.
-> > 
-> > So, it seems what has to be done is, when annex.thin is set, check the
-> > inode cache first, if it's unchanged great, but if not, inAnnex would
-> > need to checksum the object file to determine if it's been modified.
-> > So inAnnex gets potentially very much slower for annex.thin, but I can't
-> > see a way around that. --[[Joey]]
-
-> > > Also, I was able to reproduce the repeated get, after unlock; lock;
-> > > touch; fsck and the above change did fix that.
-> > > 
-> > > So, all [[done]]! --[[Joey]]
-
-## more information needed
-
-If gleachkr comes back to IRC, it would be good to find out:
-
-* Was this file previously unlocked? `git log` on the file would probably
-  tell, unless it was briefly unlocked in between commits.
-* Run `git annex info` on the file to see what its key is.  
-  Then, run `sqlite3 .git/annex/keys/db` and .dump and see
-  what is recorded for that key, in both the "content" and "associated"
-  tables.
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_1_fa6b924d792613b60979a87deea2a66f._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_1_fa6b924d792613b60979a87deea2a66f._comment
deleted file mode 100644
index 6ace37334d..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_1_fa6b924d792613b60979a87deea2a66f._comment
+++ /dev/null
@@ -1,67 +0,0 @@
-[[!comment format=mdwn
- username="gleachkr@7c488e398809299a1100b93f8884de43dee83674"
- nickname="gleachkr"
- avatar="http://cdn.libravatar.org/avatar/c7ce6b5eae91547b25e9a05fc7c8cf22"
- subject="More data points"
- date="2017-09-16T01:16:59Z"
- content="""
-the results of `git log` on one affected file are (the last commit being after I noticed the problem and tried to fix it)
-
-    commit 0e93d1c9c18cf7aead978e0ae453e66991d6e500
-    Author: Graham 
-    Date:   Tue Sep 12 19:20:33 2017 +0000
-
-        attempt to fix references for Whitney
-
-    commit 02bf95566eb2dd6947f417019e1d601abcfb55c1
-    Author: Graham 
-    Date:   Tue Aug 8 18:45:06 2017 -0500
-    
-        cleanup
-    
-    commit 655b0fd419945d0ea32d9d178c551af0a64e6afd
-    Author: Graham 
-    Date:   Sat Nov 19 19:21:10 2016 +0000
-    
-        database cleanup
-    
-    commit 54fa420bcaf33847eee77a30fbd9556beea28f77
-    Author: gleachkr 
-    Date:   Fri Sep 9 17:48:48 2016 -0500
-    
-        git-annex in graham@Descartes:~/music
-
-running `.dump` in sqlite3 yields the following two lines containing the key associated with one file suffering from the problem, with no lines containing both \"associated\" and the key (sorry, not a db expert):
-
-    INSERT INTO content VALUES(171,'SHA256E-s8350646--d9bbbd67402a1b7560ebc47bc7bafaf74115a99c628e7458ba4754d8a355908a.m4a','I \"237 8350646 1473527901\"');
-    INSERT INTO content VALUES(172,'SHA256E-s8350646--d9bbbd67402a1b7560ebc47bc7bafaf74115a99c628e7458ba4754d8a355908a.m4a','I \"1711652 8350646 1473527901\"');
-
-another affected file shows up on lines:
-
-    INSERT INTO associated VALUES(3,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','Car Seat Headrest/Teens of Denial/01 Fill in the Blank.m4a');
-    INSERT INTO content VALUES(31,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','I \"135750 8789357 1473525850\"');
-    INSERT INTO content VALUES(32,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','I \"1711014 8789357 1473525850\"');
-    INSERT INTO content VALUES(296,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','I \"1050021 8789357 1498915821\"');
-
-This second file has slightly different deviant behavior. It still registers as not present to `annex find` and `annex info`, is redownloaded by `annex get`, and shows up in `annex list`. But unlike the first, it does not register as not present when `annex fsck` is run. It just checks out, apparently.
-
-The second file gives `git log` results as follows:
-
-    commit 02bf95566eb2dd6947f417019e1d601abcfb55c1
-    Author: Graham 
-    Date:   Tue Aug 8 18:45:06 2017 -0500
-    
-        cleanup
-    
-    commit 655b0fd419945d0ea32d9d178c551af0a64e6afd
-    Author: Graham 
-    Date:   Sat Nov 19 19:21:10 2016 +0000
-    
-        database cleanup
-    
-    commit 54fa420bcaf33847eee77a30fbd9556beea28f77
-    Author: gleachkr 
-    Date:   Fri Sep 9 17:48:48 2016 -0500
-    
-        git-annex in graham@Descartes:~/music
-"""]]
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_2_5e37bcb145880fe6074995f17c5aa7c3._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_2_5e37bcb145880fe6074995f17c5aa7c3._comment
deleted file mode 100644
index 94bada5999..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_2_5e37bcb145880fe6074995f17c5aa7c3._comment
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-09-16T14:54:49Z"
- content="""
-The .dump that shows the file is in the "content" table but
-not the "associated" table seems to confirm my hypothesis.
-
-Aha -- I was able to replicate having "content" but no "associated" in the
-keys database, by first using `git annex add` on a file, then `git annex
-unlock`, then `git annex lock`. Any chance this is what you did? (Perhaps
-some of those commits that git log shows were the locking/unlocking; if you
-`git show` the commits and see that the mode of the file has changed, that
-would confirm it.)
-
-I've still not quite managed to replicate the problem, because the cached
-inodes were still right. Tried moving the file away to another repo, but
-it then removed the cached inodes and so avoided the problem.
-
-Very interesting about the second file with `git annex get` and `git annex
-fsck` behaving differently. Does the file 'Car Seat Headrest/Teens of Denial/01 Fill in the Blank.m4a'
-still exist in your git repository?
-
-Is annex.thin set in .git/config?
-
-----
-
-I probably have enough information to move on to getting your repository
-fixed so you can stop being bothered by the problem at least. I think you
-could probably move .git/annex/keys/db out of the way, and run `git annex
-lock` followed by `git annex fsck` to get into a non-broken state.
-"""]]
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_3_9efad60d2c43a902c7a0e2d6225be1c5._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_3_9efad60d2c43a902c7a0e2d6225be1c5._comment
deleted file mode 100644
index 20d8320071..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_3_9efad60d2c43a902c7a0e2d6225be1c5._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="gleachkr@7c488e398809299a1100b93f8884de43dee83674"
- nickname="gleachkr"
- avatar="http://cdn.libravatar.org/avatar/c7ce6b5eae91547b25e9a05fc7c8cf22"
- subject="comment 3"
- date="2017-09-16T16:02:41Z"
- content="""
-The second file (`01 Fill in the Blank.m4a`) does still exist, although `annex get` always re-retrieves it. annx.thin is not set. Here's the git config, minus remotes:
-
-    [core]
-        repositoryformatversion = 0
-        filemode = true
-        bare = false
-        logallrefupdates = true
-    [annex]
-        uuid = e9731ab7-6a76-4eef-b337-2b8573380014
-        version = 6
-    [filter \"annex\"]
-        smudge = git-annex smudge %f
-        clean = git-annex smudge --clean %f
-
-Thanks for the fix. Just to make sure I understand before breaking anything futher, the idea would be to move `.git/annex/keys/db` somewhere safe, `git annex lock` all the affected files, and then `git annex fsck` the whole repository? or just the affected files?
-"""]]
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_4_90062420b67a7f364f5ece947408798f._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_4_90062420b67a7f364f5ece947408798f._comment
deleted file mode 100644
index af86bec35e..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_4_90062420b67a7f364f5ece947408798f._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2017-09-16T16:04:24Z"
- content="""
-Right, just back up the keys/db just in case, and you need to fsck at least
-any files that are not locked (to repopulate the keys/db for those), 
-so safest is to fsck the whole repository..
-
-Is it possible that you've run `git annex unlock` / `git annex lock` on
-some of the affected files in the past?
-"""]]
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_5_5f2e03340fb98bd146c4563e8e57dd30._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_5_5f2e03340fb98bd146c4563e8e57dd30._comment
deleted file mode 100644
index 811e604271..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_5_5f2e03340fb98bd146c4563e8e57dd30._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2017-09-16T16:07:38Z"
- content="""
-Actually, you should `git annex lock` before moving the database out of
-the way, otherwise it might be confused. So:
-
-1. git annex lock
-2. move keys/db to a safe backup location
-3. git annex fsck
-"""]]
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_6_fce1ef0377e00fb9431d4c8b0215387b._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_6_fce1ef0377e00fb9431d4c8b0215387b._comment
deleted file mode 100644
index 5cd5cbf454..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_6_fce1ef0377e00fb9431d4c8b0215387b._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="gleachkr@7c488e398809299a1100b93f8884de43dee83674"
- nickname="gleachkr"
- avatar="http://cdn.libravatar.org/avatar/c7ce6b5eae91547b25e9a05fc7c8cf22"
- subject="Thanks!"
- date="2017-09-16T16:46:48Z"
- content="""
-Removing the db and running `fsck` seems to have fixed the problem. I really appreciate it. I do think that I unlocked and then re-locked some of the affected files, but I think only after I noticed that they were behaving strangely---in particular, I think I only did this with the affected files that were not `fsck`ing correctly (and this was before I realized they were not `fsck`ing correctly), not with e.g. the Car Seat Headrest song.
-
-I didn't get the chance to fill in the \"Have you had any luck using git-annex before\" part of the standard bug report, so I thought I should add that here: Yes, I've used git-annex regularly for quite a while now. It's an inspiring piece of open-source software. I'm always finding new things it can do. Thank you for creating it, and thanks for your help with this issue!
-"""]]
diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_7_448fddcc8f489030d92cfe9dbba1f07f._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_7_448fddcc8f489030d92cfe9dbba1f07f._comment
deleted file mode 100644
index 6fab59e156..0000000000
--- a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_7_448fddcc8f489030d92cfe9dbba1f07f._comment
+++ /dev/null
@@ -1,53 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 7"""
- date="2018-08-27T16:27:47Z"
- content="""
-I was able to reproduce what I described in comment #2 with current
-git-annex.
-
-Also, I was able to reproduce the fsck failure, by touching the
-.git/annex/objects file. Even though the file is not modifiable, touching
-it updates its mtime, and so the inode cache is considered stale.
-This makes inAnnex think it's not present.
-
-And another way is, when annex.thin is enabled, to touch the unlocked file,
-which also touched the .git/annex/objects it's hardlinked to.
-git-annex lock then checksums it (because the inode cache is stale),
-concludes it's still good, and so proceeds to lock it, but the stale inode
-cache again causes inAnnex to think it's not present.
-
-I still don't know how to reproduce git-annex get redownloading a file that
-git-annex find lists.
-
-> Should inAnnex even be checking the inode cache for locked content? This seems unncessary, and note that it's done for v4 mode as well as v6.
-
-Unnecessary for v4 certianly, but in v6 with annex.thin,
-unlocked content is hard linked and could be modified, 
-so it does need to check that the inode cache is valid.
-
-Could remove the inode cache when locking a file, as long as there
-are no other associated files that are unlocked. That solves the problem
-for that case, and makes inAnnex avoid some unncessary work too.
-
-When the same content has a mix of locked and unlocked associated files,
-the inode cache needs to remain populated (to support annex.thin and so
-git-annex drop will drop the copies of the content from the locked files).
-But then if the inode cache for the locked content becomes stale, and
-the unlocked files get modified, inAnnex will again be wrong.
-
-So, it seems that inAnnex also needs to check if the annex object 
-has no hard links, and if so, treat it as present even when the inode cache
-does not match. That's cheaper than checking the inode cache, so it ought
-to be done first.
-
-Conclusion: Only check the inode cache for the annex object
-when annex.thin has made a hard link to it. If its link count is 1,
-inAnnex knows it's present and locked, so it can assume it's good.
-
-(Also, it's possible there could be a race when locking a file
-where the file gets modified after the inode cache is checked,
-so it's treated as unmodified but is really modified and as a hard link to
-the object file, the object file has the wrong content. Need to make sure
-this race can't occur.)
-"""]]
diff --git a/doc/bugs/install-completions_target_has_missing_dependency.mdwn b/doc/bugs/install-completions_target_has_missing_dependency.mdwn
deleted file mode 100644
index 101cafd67d..0000000000
--- a/doc/bugs/install-completions_target_has_missing_dependency.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-### Please describe the problem.
-
-When running `make install-desktop install-completions`, the git-annex binary may not exist yet. Depending on the order in which Make runs the requested targets, the git-annex target (install-desktop -> build -> $(all) -> git-annex) may or may not have run, to a) check that dist/build/git-annex/git-annex is up to date, b) create the symlink in the root directory, by the time the install-completions target gets run.
-
-### What steps will reproduce the problem?
-
-`make install-completions` without the git-annex binary having been built already.
-
-### What version of git-annex are you using? On what operating system?
-
-Trying to package git-annex for Arch Linux, using the following build recipe:
-
-https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/git-annex#n34
-
-reference downstream bug: https://bugs.archlinux.org/task/62775
-
-(This is building the binary via runhaskell Setup configure/build instead of using the Makefile -- I don't know exactly why, but I suspect it was originally packaged that way due to needing custom options for Arch's ghc.)
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/interoperability_issue_between_buster_and_stretch.mdwn b/doc/bugs/interoperability_issue_between_buster_and_stretch.mdwn
deleted file mode 100644
index 7010e47051..0000000000
--- a/doc/bugs/interoperability_issue_between_buster_and_stretch.mdwn
+++ /dev/null
@@ -1,174 +0,0 @@
-### Please describe the problem.
-
-If a git-annex client from Debian buster (currently 6.20180913-1) tries to talk with a server running Debian stretch (currently 6.20170101-1+deb9u2), it will fail mysteriously:
-
-    copy bar (fd:18: hClose: resource vanished (Broken pipe)) failed
-
-### What steps will reproduce the problem?
-
-On the stretch machine, setup a test git-annex repository.
-
-On the buster machine, setup a test repository, add the stretch
-machine as a remote, then add a file in git-annex, and
-git-annex-sync-content to the stretch machine.
-
-### What version of git-annex are you using? On what operating system?
-
-Debian buster and stretch standard Debian packages.
-
-### Please provide any additional information below.
-
-On the buster machine:
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-(test) [1265]anarcat@curie:test130$ git init test
-Dépôt Git vide initialisé dans /home/anarcat/test/test/.git/
-(test) [1266]anarcat@curie:test$ cd test
-(test) [1267]anarcat@curie:test$ git annex init 
-init  ok
-(recording state in git...)
-(test) [1268]anarcat@curie:test$ echo foo > bar
-(test) [1269]anarcat@curie:test$ git annex add bar
-add bar ok
-(recording state in git...)
-(test) [1270]anarcat@curie:test$ git remote add sal sal:test
-(test) [1271]anarcat@curie:test$ git annex sync sal 
-commit 
-[master (commit racine) 05b6d24] git-annex in anarcat@curie:~/test/test
- 1 file changed, 1 insertion(+)
- create mode 120000 bar
-ok
-pull sal 
-warning: pas de commit commun
-remote: Counting objects: 5, done.
-remote: Compressing objects: 100% (3/3), done.
-remote: Total 5 (delta 0), reused 0 (delta 0)
-Dépaquetage des objets: 100% (5/5), fait.
-Depuis sal:test
- * [nouvelle branche] git-annex  -> sal/git-annex
-ok
-(merging sal/git-annex into git-annex...)
-(recording state in git...)
-push sal 
-Énumération des objets: 18, fait.
-Décompte des objets: 100% (18/18), fait.
-Compression par delta en utilisant jusqu'à 4 fils d'exécution
-Compression des objets: 100% (12/12), fait.
-Écriture des objets: 100% (16/16), 1.92 KiB | 654.00 KiB/s, fait.
-Total 16 (delta 1), réutilisés 0 (delta 0)
-To sal:test
- * [new branch]      git-annex -> synced/git-annex
- * [new branch]      master -> synced/master
-ok
-(test) [1272]anarcat@curie:test$ git annex sync --content sal
-commit 
-Sur la branche master
-rien à valider, la copie de travail est propre
-ok
-pull sal 
-ok
-copy bar (fd:18: hClose: resource vanished (Broken pipe)) failed
-git-annex: sync: 1 failed
-
-# End of transcript or log.
-"""]]
-
-The stretch repo is just `git init test && git -C test annex
-init`. SSH communication is setup with a passwordless SSH key in
-both. Debugging shows us the problem is with the p2pstdio command:
-
-[[!format sh """
-$ git annex sync --content sal --debug
-[2018-11-03 15:25:35.018955156] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
-[2018-11-03 15:25:35.022443588] process done ExitSuccess
-[2018-11-03 15:25:35.022611687] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
-[2018-11-03 15:25:35.02578792] process done ExitSuccess
-[2018-11-03 15:25:35.026234842] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..24d62bcb5e253326bde98283338a855c9bfbe983","--pretty=%H","-n1"]
-[2018-11-03 15:25:35.030089742] process done ExitSuccess
-[2018-11-03 15:25:35.041384604] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
-[2018-11-03 15:25:35.042220799] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
-commit 
-[2018-11-03 15:25:35.045907106] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit","-a","-m","git-annex in anarcat@curie:~/test/test"]
-Sur la branche master
-rien à valider, la copie de travail est propre
-[2018-11-03 15:25:35.077421642] process done ExitFailure 1
-ok
-[2018-11-03 15:25:35.077523489] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
-[2018-11-03 15:25:35.079008549] process done ExitSuccess
-[2018-11-03 15:25:35.079088278] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
-[2018-11-03 15:25:35.080639101] process done ExitSuccess
-[2018-11-03 15:25:35.080766018] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/heads/synced/master"]
-[2018-11-03 15:25:35.08225223] process done ExitSuccess
-[2018-11-03 15:25:35.082343323] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
-[2018-11-03 15:25:35.084234147] process done ExitSuccess
-pull sal 
-[2018-11-03 15:25:35.084663095] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","fetch","sal"]
-[2018-11-03 15:25:37.678014829] process done ExitSuccess
-[2018-11-03 15:25:37.678131075] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
-[2018-11-03 15:25:37.68042014] process done ExitSuccess
-[2018-11-03 15:25:37.680521541] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/sal/master"]
-[2018-11-03 15:25:37.682164837] process done ExitFailure 1
-[2018-11-03 15:25:37.682259432] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/sal/synced/master"]
-[2018-11-03 15:25:37.683835717] process done ExitSuccess
-[2018-11-03 15:25:37.683934116] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/synced/master..refs/remotes/sal/synced/master","--pretty=%H","-n1"]
-[2018-11-03 15:25:37.686212308] process done ExitSuccess
-ok
-[2018-11-03 15:25:37.686343742] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
-[2018-11-03 15:25:37.688215586] process done ExitSuccess
-[2018-11-03 15:25:37.688305585] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
-[2018-11-03 15:25:37.6901916] process done ExitSuccess
-[2018-11-03 15:25:37.690393283] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..24d62bcb5e253326bde98283338a855c9bfbe983","--pretty=%H","-n1"]
-[2018-11-03 15:25:37.692726875] process done ExitSuccess
-[2018-11-03 15:25:37.692906438] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"]
-copy bar [2018-11-03 15:25:37.696621566] chat: ssh ["sal","-S",".git/annex/ssh/sal","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/~/test' '--debug' 'f73778b3-17a4-4fee-9890-402bedf02456' --uuid 02ef3aa6-34d9-42b9-814e-f9ebc47c59e1"]
-[2018-11-03 15:25:37.96931512] P2P > ERROR auth failed
-(fd:18: hClose: resource vanished (Broken pipe)) failed
-[2018-11-03 15:25:37.96973331] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
-[2018-11-03 15:25:37.970341712] read: git ["--version"]
-[2018-11-03 15:25:37.97296492] process done ExitSuccess
-[2018-11-03 15:25:37.974463782] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
-[2018-11-03 15:25:37.978567382] process done ExitSuccess
-[2018-11-03 15:25:37.979111982] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/sal/synced/master"]
-[2018-11-03 15:25:37.982068735] process done ExitSuccess
-[2018-11-03 15:25:37.982213309] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/remotes/sal/synced/master..refs/heads/synced/master","--pretty=%H","-n1"]
-[2018-11-03 15:25:37.986086966] process done ExitSuccess
-[2018-11-03 15:25:37.986239042] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/sal/git-annex"]
-[2018-11-03 15:25:37.988954838] process done ExitSuccess
-[2018-11-03 15:25:37.989110109] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/remotes/sal/git-annex..git-annex","--pretty=%H","-n1"]
-[2018-11-03 15:25:37.993956367] process done ExitSuccess
-[2018-11-03 15:25:37.994340874] read: ssh ["-O","stop","-S","sal","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
-[2018-11-03 15:25:38.00909442] process done ExitSuccess
-[2018-11-03 15:25:38.009887194] process done ExitSuccess
-[2018-11-03 15:25:38.010571056] process done ExitSuccess
-[2018-11-03 15:25:38.011368991] process done ExitSuccess
-git-annex: sync: 1 failed
-"""]]
-
-A manual invocation confirms the [[design/p2p_protocol]] not supported
-by the remote, probably because it's too old:
-
-[[!format sh """
-$ ssh sal git-annex-shell p2pstdio
-fatal: unrecognized command 'p2pstdio'
-git-annex-shell: git-shell failed
-"""]]
-
-I understand the need for this command (which has no manpage, for what
-that's worth ;), but we should be able to fallback gracefully here. In
-the worst case, just treat this as a remote without git-annex-shell
-and revert to rsync to transfer files...
-
-The workaround is to install the (working) backport in stretch, of course.
-
-I wonder if this could be related to
-[[bugs/new_git-annex-shell_protocol_hides_remote_error_messages/]]. 
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Yes! I'm using git-annex like a maniac and I'm using it to archive
-Brazil right now. -- [[anarcat]]
-
-> presumed [[done]] --[[Joey]]
diff --git a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_1_4e7d50e097418290b185f43e05ddd86b._comment b/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_1_4e7d50e097418290b185f43e05ddd86b._comment
deleted file mode 100644
index 9341320db1..0000000000
--- a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_1_4e7d50e097418290b185f43e05ddd86b._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 1"
- date="2018-11-03T19:41:32Z"
- content="""
-Looking at the error message alone, I am pretty sure this is fixed in recent git-annex; I am just waiting on the Haskell transition in Debian to be able to build the package.
-"""]]
diff --git a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_2_768f116e98a3cef3285ef941464c0880._comment b/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_2_768f116e98a3cef3285ef941464c0880._comment
deleted file mode 100644
index 5c21266f12..0000000000
--- a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_2_768f116e98a3cef3285ef941464c0880._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="oops"
- date="2018-11-03T19:52:48Z"
- content="""
-oh. oops. sorry for the noise then... maybe i should have filed this against the BTS first? :)
-"""]]
diff --git a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_3_49bb5da51295072f20e21bb1510eb468._comment b/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_3_49bb5da51295072f20e21bb1510eb468._comment
deleted file mode 100644
index aebb2f5fca..0000000000
--- a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_3_49bb5da51295072f20e21bb1510eb468._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-11-12T20:11:17Z"
- content="""
-This is a duplicate of
-[[todo/Error_when_using_6.20180913_with_6.20170101-1+deb9u2]]
-which was fixed in 6.20180926:
-
-  * Fixes a reversion in the last release that broke interoperation with
-    older versions of git-annex-shell.
-
-I'm going to assume your version didn't include that fix yet, since you did not
-specify the version and I'm offline and can't look up what version of git-annex
-was in Debian at the time you filed the bug report.
-(Please always include actual version numbers in bug reports.
-It always saves me time.)
-"""]]
diff --git a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_4_1e954af67be1ac42ef31292db8a661d2._comment b/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_4_1e954af67be1ac42ef31292db8a661d2._comment
deleted file mode 100644
index 91e84e0129..0000000000
--- a/doc/bugs/interoperability_issue_between_buster_and_stretch/comment_4_1e954af67be1ac42ef31292db8a661d2._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="probably fixed indeed"
- date="2018-11-12T20:54:05Z"
- content="""
-Yes, you're right it's probably fixed. But just for the record, i did mention both version numbers in the bug report (6.20180913-1 and 6.20170101-1+deb9u2). It's the second line of the bug report.
-"""]]
diff --git a/doc/bugs/issue_with_syncing_between_v5_and_v6_repos.mdwn b/doc/bugs/issue_with_syncing_between_v5_and_v6_repos.mdwn
deleted file mode 100644
index f0ee4ba58c..0000000000
--- a/doc/bugs/issue_with_syncing_between_v5_and_v6_repos.mdwn
+++ /dev/null
@@ -1,112 +0,0 @@
-### Please describe the problem.
-I was accidentally syncing between repos at v5 and v6, I didn't realize they were different versions until I started digging into this issue.
-
-I have two repos, one at v5 and one at v6. I add a file to v6 annex, unlock, then sync to my v5 repo. From my v5 repo, I then move the file into a sub-directory, in my v5 repo, and accidentally commit with git add; git commit, instead of git annex add; git commit, since with my v6 repo I am used to using git add for everything. The file content is now missing from annex on my v5 repo. I then sync from both repos. Now the file in v5 repo is broken and the content is not present in annex. The content is fine on the v6 repo. The only way to actually get annex to see the content, from my v5 repo, though is to do git annex upgrade, git annex sync, fsck repair don't help.
-
-### What steps will reproduce the problem?
-
-### What version of git-annex are you using? On what operating system?
-
-    $ git annex version
-    git-annex version: 6.20171128-g58b04cd2e
-    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi
-    dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
-    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1         MD5E MD5 WORM URL
-    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-    local repository version: 6
-    supported repository versions: 3 5 6
-    upgrade supported from repository versions: 0 1 2 3 4 5
-    operating system: darwin x86_64
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-
-#
-# Create a V6 repo and add an image to it
-#
-$ mkdir /tmp/repov6
-$ cd /tmp/repov6
-$ git init
-$ git annex init
-$ /tmp/repov6$ git annex upgrade
-upgrade . (v5 to v6...) ok
-
-$ git add image1.png 
-$ git commit -m "added image 1 to annex"
-$ /tmp/repov6$ git annex info image1.png 
-file: image1.png
-size: 17.69 kilobytes
-key: SHA256E-s17691--c98e6eae515fec6a094e2b4bdcd221ba089a5e6073f6c365f6d4c829243c8aa5.png
-present: true
-$ git annex unlock image1.png
-$ git commit -m "unlocked the image"
-
-#
-# Create a V5 repo
-# and sync with first repo
-#
-$ cd /tmp
-$ git clone /tmp/repov6/ repov5
-Cloning into 'repov5'...
-done.
-$ cd repov5
-$ git annex init "repo v5"
-$ git remote add repov6 /tmp/repov6
-$ git annex sync
-andrew@bumblebee /tmp/repov5$ ls -l image1.png 
-… image1.png -> .git/annex/objects/zJ/7J/SHA256E-s17691--c98e6eae515fec6a094e2b4bdcd221ba089a5e6073f6c365f6d4c829243c8aa5.png/SHA256E-s17691--c98e6eae515fec6a094e2b4bdcd221ba089a5e6073f6c365f6d4c829243c8aa5.png
-
-# this repo is still at version 5
-$ git annex version
-…
-local repository version: 5
-…
-
-# now lets move the unlocked not present image file
-$ mkdir imagesFolder
-$ mv image1.png imagesFolder/
-$ git add -A .
-$ git commit -m "moved file"
-
-## oops I accidentally committed my annexed file using git add from a v5 repo…
-## since I am used to using git add commands in my v6 repos
-
-#
-# Now lets sync
-#
-$ cd /tmp/repov6
-$ git remote add repov5 /tmp/repov5
-$ git annex sync
-$ ls -laL imagesFolder/image1.png 
-…  17691 Dec 10 21:26 imagesFolder/image1.png
-
-# 
-# Now lets try to get this to our V5 repo
-#
-$ cd /tmp/repov5
-$ git annex sync
-$ git annex info imagesFolder2/image1.png
-fatal: Not a valid object name imagesFolder2/image1.png
-info imagesFolder2/image1.png (not a directory or an annexed file or a treeish or a remote or a uuid) failed
-a
-
-# the following does not help
-$ git annex fsck
-$ git annex repair
-
-# the following resolves the issue
-$ git annex upgrade	
-
-
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-Yes
-
-> I don't consider this a bug, so [[done]] --[[Joey]]
diff --git a/doc/bugs/issue_with_syncing_between_v5_and_v6_repos/comment_1_4c3468a17c454cb344b3a944c0f71889._comment b/doc/bugs/issue_with_syncing_between_v5_and_v6_repos/comment_1_4c3468a17c454cb344b3a944c0f71889._comment
deleted file mode 100644
index 9db9c27c4c..0000000000
--- a/doc/bugs/issue_with_syncing_between_v5_and_v6_repos/comment_1_4c3468a17c454cb344b3a944c0f71889._comment
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-12-11T16:59:52Z"
- content="""
-The problem is much simpler than that: Files that are unlocked in v6
-repositories are not treated as annexed files at all in v5 repositories.
-You cannot `git annex get` them or anything. 
-
-So, the simpler reproduction recipe is to `git add` a file to a v6
-repository and then in a v5 clone, `git annex get` and it won't say
-anything, because that's not an annexed file as far as it's concerned.
-
-It's also very easy to deal with this situation if you've gotten into it --
-all you need to do is `git annex lock` the files in a v6 repository and
-commit it, and then the v5 repository will be able to access them.
-
-A good way to avoid the problem while still using the features of v6
-in your v6 repository is to run `git annex adjust --unlock` in there.
-Then commits of unlocked files will automatically be translated to locked
-files that are compatible with v5.
-
-git-annex v5 can't possibly treat v6 unlocked files as annexed files.
-It could warn about the problem, but this would complicate it with needing
-to check if every non-symlink file is a v6 unlocked file. I don't feel
-this problem warrants that complication.
-"""]]
diff --git a/doc/bugs/issue_with_syncing_between_v5_and_v6_repos/comment_2_88a25974db9d544e10e6977056f49555._comment b/doc/bugs/issue_with_syncing_between_v5_and_v6_repos/comment_2_88a25974db9d544e10e6977056f49555._comment
deleted file mode 100644
index 03d1214f14..0000000000
--- a/doc/bugs/issue_with_syncing_between_v5_and_v6_repos/comment_2_88a25974db9d544e10e6977056f49555._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="makes sense"
- date="2017-12-12T00:01:37Z"
- content="""
-Thanks. Seems reasonable.
-
-Andrew
-"""]]
diff --git a/doc/bugs/jobs.mdwn b/doc/bugs/jobs.mdwn
deleted file mode 100644
index e32af703e9..0000000000
--- a/doc/bugs/jobs.mdwn
+++ /dev/null
@@ -1,83 +0,0 @@
-### Please describe the problem.
-
-After many addeded files, a have error:
-Another git process seems to be running in this repository, e.g.
-an editor opened by 'git commit'. Please make sure all processes
-are terminated then try again. If it still fails, a git process
-may have crashed in this repository earlier:
-remove the file manually to continue.
-fatal: Unable to create '/home/syncer/updates/.git/index.lock': File exists.
-
-Another git process seems to be running in this repository, e.g.
-an editor opened by 'git commit'. Please make sure all processes
-are terminated then try again. If it still fails, a git process
-may have crashed in this repository earlier:
-remove the file manually to continue.
-fatal: Unable to create '/home/syncer/updates/.git/index.lock': File exists.
-
-Another git process seems to be running in this repository, e.g.
-an editor opened by 'git commit'. Please make sure all processes
-are terminated then try again. If it still fails, a git process
-may have crashed in this repository earlier:
-remove the file manually to continue.
-fatal: Unable to create '/home/syncer/updates/.git/index.lock': File exists.
-
-Another git process seems to be running in this repository, e.g.
-an editor opened by 'git commit'. Please make sure all processes
-are terminated then try again. If it still fails, a git process
-may have crashed in this repository earlier:
-remove the file manually to continue.
-
-git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] exited 123)
-failed
-fatal: Unable to create '/home/syncer/updates/.git/index.lock': File exists.
-
-
-### What steps will reproduce the problem?
-cd /home/syncer/updates
-
-git init
-
-git annex init --version=6
-
-git clone ssh://git-annex.drweb.loc/home/syncer/updates
-
-echo "* annex.backend=WORM" > .gitattributes
-
-git add .gitattributes
-
-git commit -m "set attributes"
-
-git annex initremote myrsync type=rsync rsyncurl=git-annex.drweb.loc:/home/syncer/rsync_remote encryption=none
-
-git annex copy --all --to myrsync
-
-add and modify files
-
-git annex add -J8 .
-
-### What version of git-annex are you using? On what operating system?
-git-annex version: 6.20170101.1
-build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-local repository version: 6
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-operating system: linux x86_64
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-[[!meta title="git annex add -J crash due to index somehow getting locked"]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/jobs/comment_1_2f37448b1ab618cf485d5335d3b2977d._comment b/doc/bugs/jobs/comment_1_2f37448b1ab618cf485d5335d3b2977d._comment
deleted file mode 100644
index 8f90a0bec9..0000000000
--- a/doc/bugs/jobs/comment_1_2f37448b1ab618cf485d5335d3b2977d._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-08-28T16:16:03Z"
- content="""
-Reproduced by creating 10000 files and running 
-`git -c annex.queuesize=100 annex add -J8`
-
-Apparently it runs two concurrent git adds
-when flushing the queue in some circumstances.
-The smaller queue size must make it easier to reproduce;
-without it all 10000 files get added ok here.
-
-It's not specific to v6 at all.
-
-Two worker threads are flushing their queues at the same time.
-"""]]
diff --git a/doc/bugs/json_should_be_utf8_regardless_of_locale.mdwn b/doc/bugs/json_should_be_utf8_regardless_of_locale.mdwn
deleted file mode 100644
index ac7275a77a..0000000000
--- a/doc/bugs/json_should_be_utf8_regardless_of_locale.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-json is defined as always utf-8. However, when LANG=C,
-git-annex --json currently outputs "file":"���������"
-instead of "file":"äöü東" for that utf-8 filename. --[[Joey]]
-
-This can also affect keys when they contain some non-utf8 from eg the
-extension. And metadata keys and values can contain non-utf8 and also get
-converted to json with similar results.
-
-Note that git-annex can operate on non-utf8 filenames and keys; 
-it's not defined what the json contains then, and it currently contains
-similar garbage.
-
-This happens because aeson's instance of ToJSON for Char uses
-Text.singleton, and Text does not handle ghc's filesystem encoding
-for String. Instead it defaults to `\65533` for each byte encoded with the
-filesystem encoding.
-
-So, git-annex will need to convert filenames and keys and anything else
-that might use the filesystem encoding to Text itself in some
-way that does respect the filesystem encoding. Ie, use encodeBS to convert
-it to a ByteString and then Data.Text.Encoding.decodeUtf8. 
-
-> [[done]] that. --[[Joey]]
-
-What about git-annex commands that take json as input,
-when run in a non-utf8 locale? Tested that, it is handled ok. --[[Joey]]
diff --git a/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected.mdwn b/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected.mdwn
deleted file mode 100644
index b3e8a3a64e..0000000000
--- a/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-### Please describe the problem.
- *As of filing:*
-
-* [downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg.info](https://downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg.info) contains: `distributionVersion = "7.20190913", distributionReleasedate = 2019-10-09 16:52:40.56036784 UTC`
-* when installed `git-annex version` fails with `** bundle directory /Applications/git-annex.app/Contents/MacOS/bundle does not contain git`
-
-*Expected behavior:*
-
-* `distributionVersion` and included `git-annex version` report the most recent announced version:
-  * [git-annex 7.20191009](https://git-annex.branchable.com/news/version_7.20191009/)
-* `git-annex/OSX/current` on downloads.kitenet.net points to a stable, release version
-
-### What steps will reproduce the problem?
-
-1. On macOS, download and deploy the current [git-annex.dmg](https://downloads.kitenet.net/git-annex/OSX/current/10.11_El_Capitan/git-annex.dmg)
-2. Open a terminal session and enter `git-annex version`
-
-### What version of git-annex are you using? On what operating system?
-
-    /Volumes/git-annex/git-annex.app/Contents/Info.plist
- 
-    CFBundleShortVersionString
-    7.20190913-gdf42fc998
-    CFBundleSignature
-    git-annex
-    CFBundleVersion
-    7.20190913-gdf42fc998
-
-    sw_vers
-    ProductName:	Mac OS X
-    ProductVersion:	10.12.6
-    BuildVersion:	16G1917
-
-### Please provide any additional information below.
-
-*Note:*
-
-* Our download and deployment is automated using  [Autopkg](http://autopkg.github.io/autopkg) and [Munki](https://www.munki.org) and has been very stable.
-* `which git` reports `/opt/local/bin/git`   
-
-*See Also:*
-
-* [Currently, 7.20190730 is expected but 7.20190709-gee3885d15 present on OSX/current](https://git-annex.branchable.com/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/)
-
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Fabulous technology, and we really depend upon it to version and move large files (software packages, OS images, multimedia files) and associated git versioned meta-data. Thank you!
-
-> [[fixed|done]] (in the daily build) --[[Joey]]
diff --git a/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected/comment_1_b5c5a87f408a6f1a23e47c19f2c6c90d._comment b/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected/comment_1_b5c5a87f408a6f1a23e47c19f2c6c90d._comment
deleted file mode 100644
index 80d7df27ba..0000000000
--- a/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected/comment_1_b5c5a87f408a6f1a23e47c19f2c6c90d._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="leej"
- avatar="http://cdn.libravatar.org/avatar/eb1c6bd57680f694fb4658388e6de4ed"
- subject="version error also reproduces on 7.20190912 from kitenet.net (downloaded 8/20/2019)"
- date="2019-10-15T23:31:39Z"
- content="""
- `git-annex version` reports the same error on the kitenet.net OSX release 7.20190912 as 7.20190913's described above.  The last known good version we have is 7.20190731-gf845636e3.
-"""]]
diff --git a/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected/comment_2_0b117c980194d5b3e9e31348b696688b._comment b/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected/comment_2_0b117c980194d5b3e9e31348b696688b._comment
deleted file mode 100644
index c1431cf916..0000000000
--- a/doc/bugs/kite_net_OSX__47__current__47___distribution_is_7.20190913_but_7.20191009_expected/comment_2_0b117c980194d5b3e9e31348b696688b._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-10-16T14:26:35Z"
- content="""
-This is two unrelated bugs.
-
-The problem with git is apparently due to homebrew having changed,
-`ls -l /Users/joey/homebrew/Cellar/git/2.23.0/libexec/git-core`
-shows a bunch of symlinks to ../bin/git and a few other binaries; 
-Makefile copies the symlinks into the bundle but does not install the
-binaries they link to.
-
-The build version being a little behind is not uncommon when the
-autobuilder has not been keeping up for whatever reason. I generally don't
-block releases on autobuilds if it's the fault of the autobuilder and not
-a bug in git-annex's build process or test suite, and just ship the latest
-available build.
-
-The autobuilder has since caught up again, so the daily
-build is current but still suffers from the other problem.
-"""]]
diff --git a/doc/bugs/lineageOS_android_install_fail__58___incorrect_arch_test.mdwn b/doc/bugs/lineageOS_android_install_fail__58___incorrect_arch_test.mdwn
deleted file mode 100644
index dc53b15462..0000000000
--- a/doc/bugs/lineageOS_android_install_fail__58___incorrect_arch_test.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-### Please describe the problem.
-Install recent lineageOS Android on Samsung Galaxy S devices (tested with SGS4, SGS5, SGS9) fails due to incorrect arch string test in 'git-annex-install'.
-
-### What steps will reproduce the problem?
-Try to install git-annex, Android version.
-
-### What version of git-annex are you using? On what operating system?
-Recent git-annex-install pulled with wget as detailed here: 
-
-
-### Please provide any additional information below.
-Patch below:
-[[!format sh """
---- git-annex-install_org       2019-03-20 17:51:58.216525055 +0100
-+++ git-annex-install   2019-03-20 17:52:06.224653964 +0100
-@@ -18,7 +18,7 @@
-        arm)
-                arch=armel
-                ;;
--       armv71)
-+       armv7l)
-                arch=armel
-                ;;
-        x86_64)
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-Sure, love it! :)
-
-> Lo1! Thanks for the patch. [[done]] --[[Joey]]
diff --git a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn
deleted file mode 100644
index c660f065b8..0000000000
--- a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn
+++ /dev/null
@@ -1,48 +0,0 @@
-### Please describe the problem.
-
-The shim for the standalone version of git annex invokes the dynamic linker with --library-path set appropriately.  glibc's parsing of library-path treats : and ; as separators and has no quoting syntax for those characters.  Also path items have to be absolute paths so you can't avoid having the whole path.
-
-As a result if you install the standalone version in a directory whose path includes either of those characters it will produce a library-path that's interpreted incorrectly leading to it looking for the libraries in the wrong place and potentially eventually using the system's installed versions if they are available.
-
-### What steps will reproduce the problem?
-
-1. Find a system with as few libraries installed as possible.  libnettle.so.6 is an easy one to avoid.
-2. create a directory called 'test;test'
-3. install git annex standalone in 'test;test'
-4. use the standalone git annex to do a 'git annex get'
-5. there will be an error saying it can't find libnettle.so.6
-
-### What version of git-annex are you using? On what operating system?
-
-This bug applies to any version.  with a ':' it will probably occur on any unix, with a ';' it will occur on at least Linux and Solaris.
-
-### Please provide any additional information below.
-
-This bug can't be fixed.  It's unlikely to trip people up but might with a bad combination of label-based drive mounting and odd drive labels.  The worst case would be incompatible libraries on the system install which could lead to data corruption.
-
-I recommend that the git annex shim should check for ':' or ';' in the path and exit non-zero if they are found.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-jdamery-iabak@oklina:/mnt/iabak-ext;/IA.BAK/shard9$ PATH=../git-annex.linux/:$PATH git annex get prelinger_library/11annualreport00unitrich/11annualreport00unitrich_raw_jp2.zip
-get prelinger_library/11annualreport00unitrich/11annualreport00unitrich_raw_jp2.zip (from web...)
-/mnt/iabak-ext;/IA.BAK/git-annex.linux/shimmed/wget/wget: error while loading shared libraries: libnettle.so.6: cannot open shared object file: No such file or directory
-
-  Unable to access these remotes: web
-
-  Try making some of these repositories available:
-        00000000-0000-0000-0000-000000000001 -- web
-failed
-git-annex: get: 1 failed
-
-# End of transcript or log.
-"""]]
-
-> Actually, this bug is fixable. And I have! I made it detect the problem
-> path, and then fall back to making a directory in /tmp, symlinking the
-> git-annex.linux directory into it, and using that as its base directory.
-> 
-> Of course, that's a suboptimal configuration, but better than having some
-> configurations where it doesn't work. [[done]] --[[Joey]]
diff --git a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__/comment_1_a98072047799a0c9ba8c5589471f6a7b._comment b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__/comment_1_a98072047799a0c9ba8c5589471f6a7b._comment
deleted file mode 100644
index 297a815213..0000000000
--- a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__/comment_1_a98072047799a0c9ba8c5589471f6a7b._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-08-04T19:34:34Z"
- content="""
-Nice analysis.
-
-I can't see any way to avoid this problem. So, seems like a "don't do that
-then" situation. And indeed, it makes sense to detect it and fail in a
-comprehansible way.
-"""]]
diff --git a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why.mdwn b/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why.mdwn
deleted file mode 100644
index adaccd54a2..0000000000
--- a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why.mdwn
+++ /dev/null
@@ -1,68 +0,0 @@
-We have found a strange file which for some reason gets added to annex instead of git, although `file --mime` reports it to be a text file.  Somehow the possible culprit (we also achieved changed in behavior via different means) is the `{}`
-
-Here is the sample of a BADFILE: http://www.onerussian.com/tmp/BADFILE.txt which gets added to annex instead of git:
-
-[[!format sh """
-$> wget http://www.onerussian.com/tmp/BADFILE.txt ; cat .gitattributes; file --mime BAD
-...
-BADFILE.txt                      100%[=======================================================>]     289  --.-KB/s    in 0s      
-
-
-* annex.backend=MD5E
-* annex.largefiles=(not(mimetype=text/*))
-**/.git* annex.largefiles=nothingBADFILE.txt: text/plain; charset=utf-8
-add BADFILE.txt ok
-(recording state in git...)
-
-$> ls -l BADFILE.txt 
-lrwxrwxrwx 1 yoh yoh 120 Apr 26 09:43 BADFILE.txt -> .git/annex/objects/xw/3W/MD5E-s289--2aae5dfcc232055ba6c06270b6c6daf0.txt/MD5E-s289--2aae5dfcc232055ba6c06270b6c6daf0.txt
-
-"""]]
-
-so we tried to troubleshoot a bit and here is attempt with removing `{}` chars vs without removing which shows differing behavior:
-
-[[!format sh """
-(git)smaug:/mnt/btrfs/scrap/tmp/SIMON[master]data_BIDS
-$> cat ../.gitattributes 
-
-* annex.backend=MD5E
-* annex.largefiles=(not(mimetype=text/*))
-**/.git* annex.largefiles=nothing% 
-
-$> git reset --hard; rm -f TEST.txt; sed -e 's,[{}],,g' BADFILE.txt >| TEST.txt; file --mime TEST.txt; git annex add TEST.txt
-HEAD is now at f97185f badfile into git
-TEST.txt: text/plain; charset=utf-8
-add TEST.txt (non-large file; adding content to git repository) ok
-(recording state in git...)
-
-$> git reset --hard; rm -f TEST.txt; cat BADFILE.txt >| TEST.txt; file --mime TEST.txt; git annex add TEST.txt
-HEAD is now at f97185f badfile into git
-TEST.txt: text/plain; charset=utf-8
-add TEST.txt ok
-(recording state in git...)
-
-$> git annex version 
-git-annex version: 7.20190219+git191-g2d6a364d4-1~ndall+1
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-local repository version: 5
-
-$> apt-cache policy git-annex-standalone
-git-annex-standalone:
-  Installed: 7.20190219+git191-g2d6a364d4-1~ndall+1
-  Candidate: 7.20190219+git191-g2d6a364d4-1~ndall+1
-  Version table:
- *** 7.20190219+git191-g2d6a364d4-1~ndall+1 500
-        500 http://neuro.debian.net/debian stretch/main amd64 Packages
-        500 http://neurodebian.ovgu.de/debian stretch/main amd64 Packages
-        100 /var/lib/dpkg/status
-
-"""]]
-
-> [[done]], the magic database changing behavior is not a bug in git-annex
-> --[[Joey]]
diff --git a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_1_d01e15fe5f35a75bb8414ad87c487466._comment b/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_1_d01e15fe5f35a75bb8414ad87c487466._comment
deleted file mode 100644
index e5e7193068..0000000000
--- a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_1_d01e15fe5f35a75bb8414ad87c487466._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-04-26T14:21:31Z"
- content="""
-On Debian unstable, file --mime says it's application/json.
-
-Since git-annex-standalone bundles the magic database, when it's built on
-unstable, it may not match the magic database of the OS, which seems to
-explain it.
-
-So I don't think this is a bug?
-"""]]
diff --git a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_2_1514545a5faaef0a427c1a8f762e8c9d._comment b/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_2_1514545a5faaef0a427c1a8f762e8c9d._comment
deleted file mode 100644
index 087f0aee1d..0000000000
--- a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_2_1514545a5faaef0a427c1a8f762e8c9d._comment
+++ /dev/null
@@ -1,61 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="change in libmagic behavior"
- date="2019-04-26T15:20:22Z"
- content="""
-Hi Joey, thanks for the quick reply. After I filed an issue I did realize as well that it must be difference in libmagic1 library version and change in its behavior (!) and indeed it is the case here:
-
-[[!format sh \"\"\"
-$> apt-cache policy libmagic1                                                                           
-libmagic1:
-  Installed: 1:5.30-1+deb9u2
-  Candidate: 1:5.30-1+deb9u2
-  Version table:
- *** 1:5.30-1+deb9u2 100
-        100 http://debian.csail.mit.edu/debian stretch/main amd64 Packages
-        100 /var/lib/dpkg/status
-     1:5.30-1+deb9u1 100
-        100 http://security.debian.org stretch/updates/main amd64 Packages
-
-$> file -L --mime BADFILE.txt                                                                           
-BADFILE.txt: text/plain; charset=utf-8
-
-$> LD_PRELOAD=/usr/lib/git-annex.linux/usr/lib/x86_64-linux-gnu/libmagic.so.1 file -L --mime BADFILE.txt
-file: compiled magic version [530] does not match with shared library magic version [535]
-BADFILE.txt: application/json; charset=utf-8
-
-\"\"\"]]
-
-Standalone I believe was built on buster. 
-I am not sure how I didn't run into this change of behavior before!
-
-Possibly interesting observation: making it a not kosher json (adding trailing , into one field etc) makes it being detected as text again
-
-But altogether, with this new behavior of libmagic, it begs a new question:
-
-**how (without listing all possible text based file formats) we could instruct annex to treat them as text files?**
-
-There is an `-e` option to `file` to exclude some tests, and I thought excluding `apptype` would help, but it does not
-[[!format sh \"\"\"
-  -e, --exclude TEST         exclude TEST from the list of test to be
-                               performed for file. Valid tests are:
-                               apptype, ascii, cdf, compress, elf, encoding,
-                               soft, tar, json, text, tokens
-
-$> file  -e apptype --mime BADFILE.txt    
-BADFILE.txt: application/json; charset=utf-8
-\"\"\"]]
-
-There is also `-k, --keep-going           don't stop at the first match` so I thought it might list some `text/` but I am not sure what it does:
-
-[[!format sh \"\"\"
-$> file -k --mime BADFILE.txt
-BADFILE.txt: application/json\012- \012- ; charset=utf-8
-
-$> python -c 'import magic; m=magic.Magic(mime=True, keep_going=True); print(m.from_file(\"BADFILE.txt\"))'
-application/json\012- \012-
-\"\"\"]]
-
-but this might be just a bug in libmagic...?
-"""]]
diff --git a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_3_94e62b80e9cdc4fa5aa92e85c29e2a0d._comment b/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_3_94e62b80e9cdc4fa5aa92e85c29e2a0d._comment
deleted file mode 100644
index 85dc89af6a..0000000000
--- a/doc/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/comment_3_94e62b80e9cdc4fa5aa92e85c29e2a0d._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="update"
- date="2019-04-29T13:41:31Z"
- content="""
-[I have asked on the file/libmagic mailing list](https://mailman.astron.com/pipermail/file/2019-April/000106.html) and filed a [bug report for -k bug](https://bugs.astron.com/view.php?id=77)
-"""]]
diff --git a/doc/bugs/migrating_to_non-E_backend_still_adds_extensions.mdwn b/doc/bugs/migrating_to_non-E_backend_still_adds_extensions.mdwn
deleted file mode 100644
index cfe85cbfd5..0000000000
--- a/doc/bugs/migrating_to_non-E_backend_still_adds_extensions.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-### Please describe the problem.
-
-I'm migrating certain files from SHA256E to SHA256, to avoid problems caused by inconsistent-case extensions, and by weird filenames which git-annex misdetects as part of the extension. The obvious approach, `annex migrate --to SHA256`, does not work as expected – the new keys _still_ have the same extension appended. This kinda defeats the point.
-
-I can work around this by migrating to another hash first (e.g. to SHA1), then back.
-
-### What steps will reproduce the problem?
-
-1. Have a SHA256E or SHA1E file
-2. git annex migrate --backend=SHA256
-
-### What version of git-annex are you using? On what operating system?
-
-6.20180509-g0632c49c22, Linux
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-$ ls -l
-lrwxrwxrwx 1 grawity grawity 211 May  2 07:58 EN_EXCH2003_ENT.ISO -> ../../../.git/annex/objects/41/Fq/SHA256E-s391118848--3b0a03ce8a821c98de7d3e67f9664f55b4bb7e13855721db993881bad501caf3.ISO/SHA256E-s391118848--3b0a03ce8a821c98de7d3e67f9664f55b4bb7e13855721db993881bad501caf3.ISO
-
-$ git annex migrate --backend=SHA256 --force
-migrate EN_EXCH2003_ENT.ISO (checksum...) ok
-(recording state in git...)
-
-$ ls -l
-lrwxrwxrwx 1 grawity grawity 209 May 22 08:15 EN_EXCH2003_ENT.ISO -> ../../../.git/annex/objects/09/3P/SHA256-s391118848--3b0a03ce8a821c98de7d3e67f9664f55b4bb7e13855721db993881bad501caf3.ISO/SHA256-s391118848--3b0a03ce8a821c98de7d3e67f9664f55b4bb7e13855721db993881bad501caf3.ISO
-
-$ git annex migrate --backend=SHA1
-migrate EN_EXCH2003_ENT.ISO (checksum...) (checksum...) ok
-(recording state in git...)
-
-$ git annex migrate --backend=SHA256
-migrate EN_EXCH2003_ENT.ISO (checksum...) (checksum...) ok
-(recording state in git...)
-
-$ ls -l
-lrwxrwxrwx 1 grawity grawity 201 May 22 08:17 EN_EXCH2003_ENT.ISO -> ../../../.git/annex/objects/xX/GW/SHA256-s391118848--3b0a03ce8a821c98de7d3e67f9664f55b4bb7e13855721db993881bad501caf3/SHA256-s391118848--3b0a03ce8a821c98de7d3e67f9664f55b4bb7e13855721db993881bad501caf3
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/migrating_to_non-E_backend_still_adds_extensions/comment_1_9fbdd6e150df22f26729b867ea3bd0bf._comment b/doc/bugs/migrating_to_non-E_backend_still_adds_extensions/comment_1_9fbdd6e150df22f26729b867ea3bd0bf._comment
deleted file mode 100644
index a3ab0e372f..0000000000
--- a/doc/bugs/migrating_to_non-E_backend_still_adds_extensions/comment_1_9fbdd6e150df22f26729b867ea3bd0bf._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-05-23T17:07:27Z"
- content="""
-I suspect this is a bug in the fastMigrate code.
-
-Interestingly, the SHA256 key with an exctension works ok, eg fsck can
-verify the checksum.
-
-Also, a subsequent `git annex migrate --backend=SHA256E`
-results in a SHA256E key with no extension.
-"""]]
diff --git a/doc/bugs/migrating_to_non-E_backend_still_adds_extensions/comment_2_f9b73dc8344b5ca98257a0024e097535._comment b/doc/bugs/migrating_to_non-E_backend_still_adds_extensions/comment_2_f9b73dc8344b5ca98257a0024e097535._comment
deleted file mode 100644
index be48f61e40..0000000000
--- a/doc/bugs/migrating_to_non-E_backend_still_adds_extensions/comment_2_f9b73dc8344b5ca98257a0024e097535._comment
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-05-23T17:18:35Z"
- content="""
-The bug was that it got the test backwards for whether 
-it was supposed to be adding or removing the extension!
-
-Bug was introduced in [[!commit 9c4650358ca85a298b747bb897dbf4f8f891fa22]]
-over a year ago.
-
-The bogus SHA256 key with an extension tacked on at the end
-passes fsck because the code happens to always strip extensions from
-hashes, even if the key type is not supposed to include an extension.
-
-Fixed the bug. But this leaves the potential for these badly formed
-SHA256 keys with an extension on the end being in a repository and
-needing to keep code working for them. (The SHA256E keys without an
-extension that also result from the bug are technically not badly formed.)
-
-So, I also made migrate fix those badly formed keys. You have to specify
---backend=SHA256, and then it will migrate the badly formed SHA256 key to
-a correctly formed SHA256 key.
-
-Also, git-annex fsck will now warn when it detects a key needing such a
-migration.
-"""]]
diff --git a/doc/bugs/minor_display_glitch_with_ssh_password_prompting_and_-J.mdwn b/doc/bugs/minor_display_glitch_with_ssh_password_prompting_and_-J.mdwn
deleted file mode 100644
index a8e0871a14..0000000000
--- a/doc/bugs/minor_display_glitch_with_ssh_password_prompting_and_-J.mdwn
+++ /dev/null
@@ -1,51 +0,0 @@
-When using -J and there's a ssh password prompt (or other prompt eg ssh
-host key), the region-based display gets messed up by the ssh output. This
-is a minor display glitch; it's still fairly clear what git-annex is doing.
-
-The root problem is that the regional display code does not know the
-absolute cursor position. All cursor movement is relative. So when ssh
-display moves the cursor, all subsequent output goes to the wrong place.
-
-ansi-terminal has absolute cursor movement, but no way to query position.
-
-Some approaches to fix it:
-
-1. Allocate a slave pty and run ssh in there, forwarding IO from the slave
-   pty to the master pty. The ssh output is then added to the region that
-   it's prompting for the password for.
-   
-   Unix-specific and somewhat heavyweight solution.
-
-2. Set position to eg 0,0 when starting git-annex, and then the
-   absolute position can be calculated, and after ssh runs it can reset the
-   cursor to the previous position. 
-   
-   Would make -J take over the whole screen even if it's only transferring
-   1 file.
-
-3. Clear all regions before running the ssh command that can prompt,
-   (moving the cursor to the start of the first region),
-   and redraw them when it's done. So the ssh output would appear above the
-   redrawn regions.
-
-   This would cause some flicker in the common case where ssh does not have
-   any output. The N regions would display briefly, then be cleared, then
-   be redrawn. It might flicker multiple times, when multiple different
-   hosts are being accessed. 
-   
-   One way to avoid the flicker would be to first
-   try to ssh with password prompting disabled, and only if that fails do
-   regions need to be cleared for the ssh that will prompt. Also, since
-   we then know ssh will prompt, we can display the hostname as context for
-   the "Password:" prompt it uses.
-
-   Needs concurrent-output 1.8.0
-
-4. Find a way to add cursor position querying to ansi-terminal. Can it be
-   done portably?
-
-   See 
-
---[[Joey]]
-
-> [[fixed|done]] using option #3. --[[Joey]]
diff --git a/doc/bugs/move_violates_numcopies.mdwn b/doc/bugs/move_violates_numcopies.mdwn
deleted file mode 100644
index 96598a7885..0000000000
--- a/doc/bugs/move_violates_numcopies.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-`git annex move` does not honor numcopies. It is the only
-git-annex command to not honor numcopies by default.
-
-This can be surprising, and it complicates git-annex's story about
-attempting to preserve numcopies since there's this exception on the side.
-
-Also, `git annex move --to untrusted-repo` drops the local copy even if the
-untrusted copy is the only remaining copy, which is another unique thing
-about move.
-
-Should `git annex move --safe` become the default, and `git annex move
---unsafe` be needed to get the current behavior? 
-
-(Note that the `-u` short option makes that easy enough to type for those
-of us who have workflows using the current behavior.)
-
-Such a change would break workflows, and potentially quite a lot of
-examples in the documentation might need to be updated. Although with the
-default numcopies=1, the move behavior would not change (except when moving
-onto an untrusted repository, ), which will limit the imact some.
-
-There could be a transition period where move warns when run w/o
---safe/--unsafe.
-
---[[Joey]]
-
-> [[done]], using the "don't make it worse" approach. --[[Joey]]
diff --git a/doc/bugs/move_violates_numcopies/comment_1_36e22ecc569f097e4cc58c20d0fa4876._comment b/doc/bugs/move_violates_numcopies/comment_1_36e22ecc569f097e4cc58c20d0fa4876._comment
deleted file mode 100644
index d59c6ead8a..0000000000
--- a/doc/bugs/move_violates_numcopies/comment_1_36e22ecc569f097e4cc58c20d0fa4876._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
- subject="comment 1"
- date="2018-04-10T10:39:23Z"
- content="""
-If git-annex knows it isn't going to do what I've instructed (move the file), I think it should just fail the command immediately, rather than copying but not dropping.
-
-You could make *--safe* fallback to copy (for those that want that behaviour) and *--unsafe* has the risky behaviour, but *move* should either do just that, move the file, or do nothing.
-"""]]
diff --git a/doc/bugs/move_violates_numcopies/comment_2_57299719a6e8f3615819da4fbc460da5._comment b/doc/bugs/move_violates_numcopies/comment_2_57299719a6e8f3615819da4fbc460da5._comment
deleted file mode 100644
index 178164c811..0000000000
--- a/doc/bugs/move_violates_numcopies/comment_2_57299719a6e8f3615819da4fbc460da5._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="force?"
- date="2018-04-10T14:20:08Z"
- content="""
-This definitely seems strange to me. i've been using git-annex for a long time, and I have never known `move` was unsafe by default. so I think that `--safe` should definitely be made defautl.
-
-but beyond that, I wouldn't use `--unsafe` as a new flag: we already have `--force` for `--drop` for example, shouldn't we reuse that here as well?
-"""]]
diff --git a/doc/bugs/move_violates_numcopies/comment_3_491d81f636a4da1deefd2d82063e2f05._comment b/doc/bugs/move_violates_numcopies/comment_3_491d81f636a4da1deefd2d82063e2f05._comment
deleted file mode 100644
index 34abb9ff8b..0000000000
--- a/doc/bugs/move_violates_numcopies/comment_3_491d81f636a4da1deefd2d82063e2f05._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="richih@50508f31e0ee95720acd0120e16d6bdcad9d104b"
- nickname="richih"
- avatar="http://cdn.libravatar.org/avatar/499771047201f3eb29a462897b50a5f3"
- subject="comment 3"
- date="2018-04-10T15:49:35Z"
- content="""
-I agree with anarcat.
-
-The core use case of git-annex is to maintain sets of known-good data. This function mainly relies on a directory structure, checksums, a defined minimum of copies, and tracking where they are. I would never have assumed that I would be able to get git-annex to go below the mincopies, at least not unless I was deep into the innards of git-annex and/or abusing --force or the like.
-
--- RichiH
-"""]]
diff --git a/doc/bugs/move_violates_numcopies/comment_4_370ab3e7adbe6f1888eb5ebe542d18ad._comment b/doc/bugs/move_violates_numcopies/comment_4_370ab3e7adbe6f1888eb5ebe542d18ad._comment
deleted file mode 100644
index 68fda3b6a9..0000000000
--- a/doc/bugs/move_violates_numcopies/comment_4_370ab3e7adbe6f1888eb5ebe542d18ad._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2018-04-10T17:04:14Z"
- content="""
-Candyangel, thanks, failing is indeed the better thing to do
-than copying when it's not safe to move. That makes sense.
-
-Also, `git annex move` should honor required contents, and refuse to move
-content away from a repository that requires it.
-
-It would be ok to use --force instead of --unsafe, but it doesn't allow for
-a staged transition from --unsafe by default to --safe by default. But, if
-we decide a stanged transition is not needed, I would be inclined to use
-the --force.
-
-Move failing in these situations seems less likely to badly break existing
-workflows than move leaving both copies would; the caller will see
-that git-annex errored, rather than it silently leaving extra copies.
-So perhaps a staged transition could be skipped.
-"""]]
diff --git a/doc/bugs/move_violates_numcopies/comment_5_4ef4c6180c71326faa814bb096dab500._comment b/doc/bugs/move_violates_numcopies/comment_5_4ef4c6180c71326faa814bb096dab500._comment
deleted file mode 100644
index c60f554586..0000000000
--- a/doc/bugs/move_violates_numcopies/comment_5_4ef4c6180c71326faa814bb096dab500._comment
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2018-04-10T22:39:30Z"
- content="""
-Another way to approach this is: `move` should not make
-a situation worse, but is not required to make it better.
-
-That would allow moving a file from A to B when numcopies wants 2 copies
-but only one copy exists, because the file being on B is no worse than it
-being on A.
-
-But, if B already has a copy of the file, move would error rather than the
-current behavior of removing from A, when numcopies wants two copies.
-
-And, if B is untrusted (and A is not), or A has the file as required
-content, moving to B would also error, as in both situations it makes
-things worse.
-
-This seems better than the ideas above, because it keeps move a somewhat
-lowlevel operation, like it always has been, but no longer an unsafe one.
-It matches many of my uses of move, when perhaps I want more copies than I
-have, but can't currently spare the space (or am moving the file to a repo
-that will later let it get replicated elsewhere).
-
-It also means that after `git annex move --from`, the local repository will 
-always have the file present, rather than move sometimes failing before
-getting it due to numcopies. (And the converse with `--to`.)
-
-I think this is a small enough change from the current behavior of move
-that it can get away with not having a transition plan.
-"""]]
diff --git a/doc/bugs/move_violates_numcopies/comment_6_2ffb920ae8e5ebfacf9230a1a7c0c7c3._comment b/doc/bugs/move_violates_numcopies/comment_6_2ffb920ae8e5ebfacf9230a1a7c0c7c3._comment
deleted file mode 100644
index 6bee1db8d1..0000000000
--- a/doc/bugs/move_violates_numcopies/comment_6_2ffb920ae8e5ebfacf9230a1a7c0c7c3._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="richih@50508f31e0ee95720acd0120e16d6bdcad9d104b"
- nickname="richih"
- avatar="http://cdn.libravatar.org/avatar/499771047201f3eb29a462897b50a5f3"
- subject="comment 6"
- date="2018-04-11T07:34:43Z"
- content="""
-\"not making it worse\" sounds like acceptable middle ground to me. If you are not erroring out, at least printing a warning would be good. OTOH, this easily gets hidden in a flood of message if you're moving more than just a few files.
-
-Still, principle of least surprise would point towards not going against basic safety measures in any case.
-"""]]
diff --git a/doc/bugs/new_git-annex-shell_protocol_hides_remote_error_messages.mdwn b/doc/bugs/new_git-annex-shell_protocol_hides_remote_error_messages.mdwn
deleted file mode 100644
index 8c27d42961..0000000000
--- a/doc/bugs/new_git-annex-shell_protocol_hides_remote_error_messages.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-`git-annex-shell p2pstdio` hides error messages that were transported over
-ssh to display to the user before. For example, diskreserve problems or IO
-errors. --[[Joey]]
-
-git-annex discards stderr from the command because old
-versions of git-annex-shell don't support the command and error out.
-
-Simply letting stderr through seems like the best solution though,
-if a way can be found to do it.
-Otherwise, all errors would have to be trapped (easy), and all stderr
-output also trapped (hard!), to be sent over the protocol using ERROR.
-And, there'd be a problem with sending messages atomically; if a message is
-being sent and an exception is thrown, that message needs to somehow be
-ended before an ERROR message can be sent.
-
-Hmm, it negotiates the protocol version after opening the connection.
-Any error at that point would make it not use the p2p protocol, 
-so can be excluded. Then, after version negotiation is complete, it
-could start displaying stderr.
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/no_prebuilt_package_for_intel_64_architecture.mdwn b/doc/bugs/no_prebuilt_package_for_intel_64_architecture.mdwn
deleted file mode 100644
index 9b3a8af24c..0000000000
--- a/doc/bugs/no_prebuilt_package_for_intel_64_architecture.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-### Please describe the problem.
-On the download page for linux, https://downloads.kitenet.net/git-annex/linux/current/ (from http://git-annex.branchable.com/install/) there are links to amd64 and Intel 386 versions, but no package for Intel 64 bit version.
-
-### What steps will reproduce the problem?
-Visit the site.
-
-### What version of git-annex are you using? On what operating system?
-
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
->  uses
-> "x86-64" to refer to those. The "amd64" in the name of the file is
-> basically an internal detail, I hope people reading the page will find it
-> clear enough. [[done]] --[[Joey]]
diff --git a/doc/bugs/no_prebuilt_package_for_intel_64_architecture/comment_1_366f4c56248099105f411c1df9b57733._comment b/doc/bugs/no_prebuilt_package_for_intel_64_architecture/comment_1_366f4c56248099105f411c1df9b57733._comment
deleted file mode 100644
index 6ccdf20b02..0000000000
--- a/doc/bugs/no_prebuilt_package_for_intel_64_architecture/comment_1_366f4c56248099105f411c1df9b57733._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="olaf"
- avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
- subject="comment 1"
- date="2017-08-16T01:01:02Z"
- content="""
-They're the same thing.
-
-For a much better explanation than I could write, see: [https://askubuntu.com/a/54298](https://askubuntu.com/a/54298)
-"""]]
diff --git a/doc/bugs/no_prebuilt_package_for_intel_64_architecture/comment_2_9255ebaad5239202c57d86467929321d._comment b/doc/bugs/no_prebuilt_package_for_intel_64_architecture/comment_2_9255ebaad5239202c57d86467929321d._comment
deleted file mode 100644
index 5305ba4cae..0000000000
--- a/doc/bugs/no_prebuilt_package_for_intel_64_architecture/comment_2_9255ebaad5239202c57d86467929321d._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="metst13@1d16544ec52801db7efb2895d3dc7a4458b8eb45"
- nickname="metst13"
- avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
- subject="links on page"
- date="2017-08-22T05:10:11Z"
- content="""
-Thanks, Olaf, for the link with some enlightenment. 
-
-Thanks, Joey. Maybe it would be better to leave only one link to the download place of sources? 
-
-I did't press \"Linux\", but the link on the right to that (which leads to a directory on server, not to the link you gave here).
-"""]]
diff --git a/doc/bugs/no_progress_display_for_transfer_to_or_from_export_remote.mdwn b/doc/bugs/no_progress_display_for_transfer_to_or_from_export_remote.mdwn
deleted file mode 100644
index aaa65a87bb..0000000000
--- a/doc/bugs/no_progress_display_for_transfer_to_or_from_export_remote.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-Seems that progress displays are not set up for storage and 
-retrieval for export remotes.
-
-Probably Remote.Helper.Special ought to do this, since it already deals
-with setting up progress displays for normal storage and retrieval when
-requested by the remote. --[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/occasional_hang_with_p2pstdio.mdwn b/doc/bugs/occasional_hang_with_p2pstdio.mdwn
deleted file mode 100644
index ed7c4decd7..0000000000
--- a/doc/bugs/occasional_hang_with_p2pstdio.mdwn
+++ /dev/null
@@ -1,66 +0,0 @@
-Using git annex get -J20 of 1000 files from ssh remote on localhost,
-I've thrice observed it to hang.
-
-	get 99 (from origin...) (checksum...) ok
-	get 992 (from origin...) (checksum...) ok
-	get 991 (from origin...) (checksum...) ok
-	get 993 (from origin...) (checksum...) ok
-	get 995 (from origin...) (checksum...) ok
-	get 1000 (from origin...) 
-	get 1 (from origin...) 
-	get 10 (from origin...) 
-	get 108 (from origin...) 
-	get 105 (from origin...) 
-	[some more]
-
-It seems it's trying to receive content of the last files listed, but has
-hung somehow in the P2P protocol and not received the data. 
-Those are the only files not present. --[[Joey]]
-
-The particular set of files it stalls on seems somewhat deterministic;
-the sets have been the same at least twice.
-
-Looking at --debug, it does not seem to get to the point of sending a P2P
-request for the keys of the files that it stalls on.
-
-So, a bug setting up the P2P ssh connection, it seems.
-
-Interestingly, the debug log shows it only ran git-annex-shell p2pstdio 
-6 times, despite the concurrency of 20. So, the other 14 must have stalled
-setting up the connection. Suggests the bug is in the connection pool
-code.
-
-> The hang does not involve the connection pool code itself; a call to
-> Annex.Ssh.sshCommand is hanging. So, this likely affected git-annex
-> before p2pstdio, although its timings of calls to sshCommand may be
-> exposing the problem.
-> 
-> The hang is in prepSocket; all the threads enter makeconnection near the
-> same time, and so all of them try to warm up the ssh connection at the
-> same time. And somehow many of those executions of ssh hang.
-> (Arguably there should be locking to prevent multiple threads doing
-> this, but the actual overhead of multiple threads doing it may be
-> smaller than the overhead of such added locking.)
-> 
-> Converted makeconnection to not use processTranscript,
-> and that does seem to avoid the hang.
->
-> Why is makeconnection's use of processTranscript hanging?
-> processTranscriot tries to read the process's output (ssh has none),
-> and waiting for the output to get read is for some reason hanging
-> forever, despite the ssh process becoming a zombie. I actually
-> rewrote the part of processtranscript that reads the process's input,
-> to be a much simpler use of async, and that new implementation has the
-> same problem. It's hanging, not throwing an exception. Most puzzling!
-> 
-> Hmm.. Perhaps the write handle is staying open even after ssh exits?
-> processTranscript sets up a pipe for the process to write to, and
-> the ssh process may inherit the FDs for that pipe (other than as stdout and
-> stderr). If the write handle
-> remains open, reading from it would block. Since the ssh mux server is
-> involved, and the handle might be passed to it or something, that seems
-> at least possible as the cause. The windows version of createProcess
-> does not use that pipe, and switching to use it does avoid the hang.
-> Yep! Setting the pipe's FDs to close on exec did avoid the hang.
->
-> [[done]] --[[Joey]]
diff --git a/doc/bugs/post-receive.mdwn b/doc/bugs/post-receive.mdwn
deleted file mode 100644
index e9422ce212..0000000000
--- a/doc/bugs/post-receive.mdwn
+++ /dev/null
@@ -1,69 +0,0 @@
-### Please describe the problem.
-
-This is actually two (related) bugs.
-I discovered the second by means of troubleshooting the first.
-
-One issue I've had with a portable repo is when I init it from my arch machine it sets up everything as expected.
-When I try to use that drive with my raspberry pi, however, there are some new git hooks (or at least one) that the older version of git annex (still the latest available in the Pi's repos, 2016, which is really old :/) does not support. 
-
-What is necessary to get a newer version of git-annex available in the Raspbian repos for default users? I know I can just install the tarball (and I'm considering it) but for everyone else coming upon this issue...
-
-### What steps will reproduce the problem?
-See above. git-annex init on a newer system, then mount it as a drive on a Raspberry pi (with the older git-annex installed) and set up the pi as a remote. Then git-annex sync.
-
-Note: this is fixable by deleting the post-receive hook in the .git/hooks folder. I'm just not sure that's a great idea.
-
-### What version of git-annex are you using? On what operating system?
-Arch linux: 
-
-git-annex version: 6.20180913-g547d01fd0
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.4.3 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-local repository version: 5
-
-
-Raspberry Pi:
-
-git-annex version: 6.20160923
-build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-local repository version: 5
-supported repository versions: 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-operating system: linux arm
-
-
-
-
-### Please provide any additional information below.
-
-I've also noticed a bug with tab complete on the latest git-annex when in a folder that is not git-annexed. I was looking into git-annex post-receive, and typed git-annex pos to get a listing of possible outputs. This was the result:
-
-
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-tai@trasa:~$ git-annex post-receive git-annex: Not in a git repository.
-git-annex: Not in a git repository.
-
-Display all 105 possibilities? (y or n)^C
-tai@trasa:~$
-
-
-
-# End of transcript or log.
-"""]]
-
-I did not hit enter, the script just failed on me during tab-complete and exited.
-
-Thanks, I look forward to any response from the community this might get.
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/post-receive/comment_1_80c2251beb6a434b364346abc1b2fc02._comment b/doc/bugs/post-receive/comment_1_80c2251beb6a434b364346abc1b2fc02._comment
deleted file mode 100644
index 589bee8067..0000000000
--- a/doc/bugs/post-receive/comment_1_80c2251beb6a434b364346abc1b2fc02._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-09-25T18:17:59Z"
- content="""
-> When I try to use that drive with my raspberry pi, however, there are some new git hooks (or at least one) that the older version of git annex (still the latest available in the Pi's repos, 2016, which is really old :/).
-
-Ok, that sentance no verb. But I'll make a guess what you meant to say..
-The old post-receive hook installed by the new version of git-annex runs
-"git-annex post-receive", which fails on the old version of git-annex.
-
-Yes, it's fine to delete the hook in this situation.
-
-The fist version of git-annex to support that is 6.20170228.
-The latest raspbian release is tracking debian stable AFAICS, which has
-6.20170101, just slightly too old.
-
-I agree this is a backwards compatability problem that should have been avoided.
-I've made `git annex init` generate a better hook script that won't fail
-with an older git-annex version. You can re-run `git annex init` in
-your repository and it will update the hook script.
-"""]]
diff --git a/doc/bugs/post-receive/comment_2_1f4930040f00ecc021ad5d6a67f041d9._comment b/doc/bugs/post-receive/comment_2_1f4930040f00ecc021ad5d6a67f041d9._comment
deleted file mode 100644
index dc815dbf5c..0000000000
--- a/doc/bugs/post-receive/comment_2_1f4930040f00ecc021ad5d6a67f041d9._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="tai@83c0edf140a3f133031751b49c7131d9535a3fcc"
- nickname="tai"
- avatar="http://cdn.libravatar.org/avatar/443f3677ce7e3cabbe09cdb8ad648915"
- subject="Thanks"
- date="2018-09-25T19:52:03Z"
- content="""
-Awesome, thanks so much. 
-
-Note: I the grammar in my sentence so it makes more sense now, but yes you guessed right.
-"""]]
diff --git a/doc/bugs/potential_data_loss_after_late_enabling_of_S3_versioning.mdwn b/doc/bugs/potential_data_loss_after_late_enabling_of_S3_versioning.mdwn
deleted file mode 100644
index be83852b91..0000000000
--- a/doc/bugs/potential_data_loss_after_late_enabling_of_S3_versioning.mdwn
+++ /dev/null
@@ -1,45 +0,0 @@
-If a S3 remote is set up with exporttree=yes, and some files are stored on
-it, and then it's later changed to also have versioning=yes, an exporttree
-that removes some of the original files can lose the only remaining copy of
-them.
-
-An appendonly remote, such as S3 with exporttree=yes, is supposed to not
-let git-annex remove content from it. So such a remote can be not
-untrusted, and exporttree can remove content from its exported tree without
-violating numcopies since the content is still supposed to be available in
-the remote.
-
-The S3 remote that gets versioning=yes enabled *after* some content has
-been stored on it without versioning violates the requirements for an
-appendonly remote. When exporttree removes a file from that S3 remote,
-it could have contained the only copy of the file, and it may not have
-versioning info for that file, so the only copy is lost.
-
-## Migration advice for users affected by this bug
-
-If you think your S3 remote may be affected by this problem, you should
-immediately set it to untrusted to avoid data loss: 
-`git annex untrust $mys3remotename`
-
-If you see a warning message "Remote is configured to use versioning, but no S3 version ID is recorded for this key", 
-your S3 remote is affected.
-
-Also, the fixed git-annex (version 7.20190129) will detect the problem,
-and refuse to delete unversioned files from your versioned S3 bucket.
-
-This will leave you with a S3 remote containing some versioned and some
-unversioned files. Kind of a mess. Best thing to do is to make a new
-S3 remote, with versioning=yes exporttree=yes set from the beginning,
-and copy all the content that was in the old S3 remote over to it.
-Then you can delete the old S3 bucket, and use `git annex dead` to
-make git-annex stop using it.
-
-## Fix
-
-* Auto-enable versioning during initremote (and not enableremote)
-  when versioning=yes. (Or prompt user to do it when aws is too old.)
-* Do not allow changing versioning= during enableremote.
-* Make removeExport and renameExport check that
-  there is a S3 version ID known, and fail if not.
-
-[[done]] --[[Joey]]
diff --git a/doc/bugs/problems_with_android_and_gpg.mdwn b/doc/bugs/problems_with_android_and_gpg.mdwn
deleted file mode 100644
index 86eb783632..0000000000
--- a/doc/bugs/problems_with_android_and_gpg.mdwn
+++ /dev/null
@@ -1,75 +0,0 @@
-### Please describe the problem.
-When my android phone tries to decode files downloaded from a ssh remote using shared encryption, gpg errors occur.
-
-### What steps will reproduce the problem?
-Setup is very similar to my other bug report in .
-Only difference is the location of the annex on the android side.
-I have put it on the /data mount which uses ext4 to avoid the /sdcard fuse mount, which does not handle symlinks.
-
-1) setup git annex via webapp on laptop:
-
-* local annex
-
-* remote annex via ssh with shared encryption (tried two different servers, one with and one without git-annex installed)
-
-* share with my devices using jabber.me account
-
-2) setup git annex via webapp on android:
-
-* local annex in /data/data/ga.androidterm/annex (ext filesystem)
-
-* share with my devices using jabber.me account
-
-* ssh remote is automatically added via XMPP
-
-3) add file to annex on linux, which gets uploaded to the ssh remote
-
-4) symlink for file is created on phone and data downloaded, but never decrypted (see logs below)
-
-### What version of git-annex are you using? On what operating system?
-Ubunut Linux 12.04 with git-annex version:
-
-* 5.20140127.1 (from PPA)
-
-Android 4.2 (rooted) with git-annex version:
-
-* 5.20140211-g556cfeb (from autobuilds)
-
-### Please provide any additional information below.
-full logs:
-
-* linux: 
-
-* android: 
-
-most interesting parts:
-[[!format sh """
-#
-# android:
-#
-gpg: can't open `/usr/local/share/gnupg/options.skel': No such file or directory
-gpg: DBG: locking for `/sdcard/git-annex.home/.gnupg/secring.gpg.lock' done via O_EXCL
-gpg: DBG: locking for `/sdcard/git-annex.home/.gnupg/pubring.gpg.lock' done via O_EXCL
-gpg: decryption failed: bad key
-
-# followed by just the last line for all further attemps
-gpg: decryption failed: bad key
-
-# gpg it self seems to be fine
-root@android:/data/data/ga.androidterm # ./bin/gpg --version -v                
-gpg (GnuPG) 1.4.15
-Copyright (C) 2013 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later 
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law.
-
-Home: ~/.gnupg
-Supported algorithms:
-Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
-Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
-        CAMELLIA128, CAMELLIA192, CAMELLIA256
-Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
-Compression: Uncompressed, ZIP, ZLIB
-"""]]
-
-> Closing as this was a bug in the deprecated Android app. [[done]] --[[Joey]]
diff --git a/doc/bugs/problems_with_android_and_gpg/comment_1_526d8805cb1ae896e8b1920ac2aecc17._comment b/doc/bugs/problems_with_android_and_gpg/comment_1_526d8805cb1ae896e8b1920ac2aecc17._comment
deleted file mode 100644
index 308d7ed8d7..0000000000
--- a/doc/bugs/problems_with_android_and_gpg/comment_1_526d8805cb1ae896e8b1920ac2aecc17._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://openid.stackexchange.com/user/3f8a1927-744c-4409-8425-48fb3c86672f"
- nickname="kim"
- subject="comment 1"
- date="2014-02-14T19:16:02Z"
- content="""
-I am experiencing the exaxact same issue on android 4.3 with the current git-annex version (5.20140211)
-"""]]
diff --git a/doc/bugs/problems_with_android_and_gpg/comment_2_2e1ae66bac4f55b74074b09e22ab270d._comment b/doc/bugs/problems_with_android_and_gpg/comment_2_2e1ae66bac4f55b74074b09e22ab270d._comment
deleted file mode 100644
index c7709f0fc9..0000000000
--- a/doc/bugs/problems_with_android_and_gpg/comment_2_2e1ae66bac4f55b74074b09e22ab270d._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm78jq1Uo-ZbyOPG3diJUWVvEiM0kyAcvk"
- nickname="Dorian"
- subject="any ideas or questions?"
- date="2014-02-25T13:41:16Z"
- content="""
-Hey Joey,
-
-I was wondering if you had any idea how we could fix this problem or if you need further information on this.
-Any response would be appreciated.
-
-Thanks for your great work on git-annex!
-
-Cheers,
-Dorian
-"""]]
diff --git a/doc/bugs/problems_with_android_and_gpg/comment_3_47510400e8e45a71a1581aed99a157a1._comment b/doc/bugs/problems_with_android_and_gpg/comment_3_47510400e8e45a71a1581aed99a157a1._comment
deleted file mode 100644
index 2f663d9439..0000000000
--- a/doc/bugs/problems_with_android_and_gpg/comment_3_47510400e8e45a71a1581aed99a157a1._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.146"
- subject="comment 3"
- date="2014-02-26T18:34:18Z"
- content="""
-AFAICS, the messages about locking are a red herring, since shared encryption is being used, the public and secret key rings are not used.
-
-This problem seems to be explained here: 
-
-It seems there must be a problem with the symmetric key used for shared encryption. Either the repository somehow has the wrong key in it, or the key is not extracted from the repository correctly somehow, or it's not fed into gpg correctly somehow.
-"""]]
diff --git a/doc/bugs/problems_with_android_and_gpg/comment_4_d28d773450d09e03160548d99f12256d._comment b/doc/bugs/problems_with_android_and_gpg/comment_4_d28d773450d09e03160548d99f12256d._comment
deleted file mode 100644
index 8815f03c96..0000000000
--- a/doc/bugs/problems_with_android_and_gpg/comment_4_d28d773450d09e03160548d99f12256d._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm78jq1Uo-ZbyOPG3diJUWVvEiM0kyAcvk"
- nickname="Dorian"
- subject="comment 4"
- date="2014-03-03T14:05:35Z"
- content="""
-Is it correct, that the shared key is transfered through the git repo, meaning in this case XMPP?
-
-Then I guess this might simply be the problem of unreliable XMPP.
-Same problem as here: 
-
-"""]]
diff --git a/doc/bugs/problems_with_android_and_gpg/comment_5_74f1177d6dd42bab5ddfc040cbfb035e._comment b/doc/bugs/problems_with_android_and_gpg/comment_5_74f1177d6dd42bab5ddfc040cbfb035e._comment
deleted file mode 100644
index a9d24b97d0..0000000000
--- a/doc/bugs/problems_with_android_and_gpg/comment_5_74f1177d6dd42bab5ddfc040cbfb035e._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.146"
- subject="comment 5"
- date="2014-03-05T20:49:20Z"
- content="""
-Yes, the key is in the git repository.
-
-While XMPP is an unreliable transport, it either manages to git pull over it, or it fails, git does not allow partial or corrupt pulls.
-"""]]
diff --git a/doc/bugs/problems_with_android_and_gpg/comment_6_8d5549e3facc6245ad09cc591ba83a4c._comment b/doc/bugs/problems_with_android_and_gpg/comment_6_8d5549e3facc6245ad09cc591ba83a4c._comment
deleted file mode 100644
index 94b5056613..0000000000
--- a/doc/bugs/problems_with_android_and_gpg/comment_6_8d5549e3facc6245ad09cc591ba83a4c._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2018-05-08T18:57:20Z"
- content="""
-I'm closing this bug report because the git-annex Android app that it
-was reported on is now deprecated. Instead, we have
-a way to run the regular git-annex build for linux on Android in termux:
-
-
-There were a lot of problems with the way the git-annex Android app was
-put together, and I hope this new approach avoids them. If you try it and
-still have the bug you reported, please followup and I'll reopen it.
-
-"""]]
diff --git a/doc/bugs/remote_tracking_exporttree_importtree_directory.mdwn b/doc/bugs/remote_tracking_exporttree_importtree_directory.mdwn
deleted file mode 100644
index 9af13f2818..0000000000
--- a/doc/bugs/remote_tracking_exporttree_importtree_directory.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-### Please describe the problem.
-The subdirectory sync mechanism for import/export of a directory remote does not work.
-
-### What steps will reproduce the problem?
-Setup a directory-type remote with exporttree and importtree set to yes.
-After the third time of syncing, the content of subdir gets synced into the top-level directory.
-
-(I tried repository versions 5 and 7)
-
-### What version of git-annex are you using? On what operating system?
-OS: Fedora 29 x86_64
-[[!format sh """
-git-annex version: 7.20190503-gfd57780d0
-build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-local repository version: 7
-"""]]
-
-### Please provide any additional information below.
-
-[[!format sh """
-mkdir importexport
-echo > importexport/should_be_in_subdir.txt
-mkdir annex-test
-cd annex-test
-git init
-git annex init --version=7
-echo > in_top.txt
-git add in_top.txt
-git commit -m "top"
-git-annex initremote imexremote type=directory directory=../importexport encryption=none exporttree=yes importtree=yes
-git config remote.imexremote.annex-tracking-branch master:imexremote
-git annex sync --content imexremote
-echo Files after first sync:
-ls
-git annex sync --content imexremote
-echo Files after second sync:
-ls
-git annex sync --content imexremote
-echo After third sync, the files from the subdir show up in the top-level dir
-ls
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-git-annex does a great job in managing my distributed backups. Thanks!
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/remote_tracking_exporttree_importtree_directory/comment_1_514a5235f236494349feff7761973b8d._comment b/doc/bugs/remote_tracking_exporttree_importtree_directory/comment_1_514a5235f236494349feff7761973b8d._comment
deleted file mode 100644
index 45a819abde..0000000000
--- a/doc/bugs/remote_tracking_exporttree_importtree_directory/comment_1_514a5235f236494349feff7761973b8d._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-05-06T16:42:56Z"
- content="""
-Thanks for a very good test case, I have been able to reproduce the bug.
-"""]]
diff --git a/doc/bugs/remote_tracking_exporttree_importtree_directory/comment_2_894698b0136c3bad155109577848c52f._comment b/doc/bugs/remote_tracking_exporttree_importtree_directory/comment_2_894698b0136c3bad155109577848c52f._comment
deleted file mode 100644
index a6cc7dbf5f..0000000000
--- a/doc/bugs/remote_tracking_exporttree_importtree_directory/comment_2_894698b0136c3bad155109577848c52f._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-05-06T16:47:49Z"
- content="""
-It's not limited to git-annex sync, running import followed by merge and
-then export shows the same behavior on the 3rd run. Without the export step, 
-the bug doesn't happen.
-
-The problem actually is in the second pass, the import is ok, but then the
-export sets the remote tracking branch to only contain the subdirectory.
-Then in the third pass that bad basis is used by the import (which does
-nothing) and gets merged.
-
-Why does only the second export trigger the bug, not the first?
-Has to do with makeRemoteTrackingBranchMergeCommit and the shape of the
-commit history.
-
-Indeed, 7.20190322 doesn't have this bug, it was introduced in
-the newest release which added makeRemoteTrackingBranchMergeCommit.
-The export code accidentially passed a tree to that.
-"""]]
diff --git a/doc/bugs/remotedaemon_--stop_doesn__39__t_work.mdwn b/doc/bugs/remotedaemon_--stop_doesn__39__t_work.mdwn
deleted file mode 100644
index 90e137a9bd..0000000000
--- a/doc/bugs/remotedaemon_--stop_doesn__39__t_work.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-### Please describe the problem.
-
-`git annex remotedaemon --help` claims that `--stop` is a valid option for stopping the remote daemon, but it results in:
-
-```
-git annex remotedaemon --stop
-git-annex: --stop not implemented for remotedaemon
-CallStack (from HasCallStack):
-  error, called at ./Command/RemoteDaemon.hs:24:32 in main:Command.RemoteDaemon
-```
-
-### What steps will reproduce the problem?
-
-`git annex remotedaemon --stop`
-
-Just `kill`ing it seems to do the job, however :-)
-
-### What version of git-annex are you using? On what operating system?
-
-7.20190912-g05bc37910 on openSUSE Tumbleweed and Leap 15.0.
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Yes for many years, just finally getting round to exploring the more advanced features :-)
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/remotedaemon_--stop_doesn__39__t_work/comment_1_db0406f22cc140f9726bc9988d567c77._comment b/doc/bugs/remotedaemon_--stop_doesn__39__t_work/comment_1_db0406f22cc140f9726bc9988d567c77._comment
deleted file mode 100644
index bf2cd05946..0000000000
--- a/doc/bugs/remotedaemon_--stop_doesn__39__t_work/comment_1_db0406f22cc140f9726bc9988d567c77._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-09-30T18:31:55Z"
- content="""
-It's fine to just kill it. It doesn't write a pid file and so --stop
-can't work, and my inclination is that there's no point in complicating it
-with that. I've removed the --stop option.
-"""]]
diff --git a/doc/bugs/remotedaemon_--stop_doesn__39__t_work/comment_2_a50a5c1337f204d889a6f50631691d1a._comment b/doc/bugs/remotedaemon_--stop_doesn__39__t_work/comment_2_a50a5c1337f204d889a6f50631691d1a._comment
deleted file mode 100644
index e768cc0441..0000000000
--- a/doc/bugs/remotedaemon_--stop_doesn__39__t_work/comment_2_a50a5c1337f204d889a6f50631691d1a._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
- nickname="branchable"
- avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
- subject="comment 2"
- date="2019-09-30T22:25:11Z"
- content="""
-Given that there is one remotedaemon process per repository, if a user has (say) 10 of them running and wants to stop a particular one, what is the expectation of how they would do this?  Presumably it would involve something like searching the process table for a remotedaemon process whose cwd is the repository in question.  I can't think of any trivial one-liner to do this, since the usual suspects like `pkill` / `ps` / `pidof` etc. do not support filtering by cwd. 
-
-So an advantage of implementing pidfiles and `--stop` would be that each user doesn't have to worry about such details.
-"""]]
diff --git a/doc/bugs/repeated_import_of_same_content_files_from_remote.mdwn b/doc/bugs/repeated_import_of_same_content_files_from_remote.mdwn
deleted file mode 100644
index 083898f4c5..0000000000
--- a/doc/bugs/repeated_import_of_same_content_files_from_remote.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-`git-annex import master --from phone` imports the same files over and
-over from my phone. Not all files, just a few of them. The affected
-files all seem to have multiple copies in the imported tree, with different
-ContentIdentifiers for each. Seems the import code is getting confused and
-unncessarly importing in that case. --[[Joey]]
-
-Seems that the ContentIdentifier database can actually only store one cid
-for a given key at a time, not multiples needed by this. This needs a
-change to the db schema to fix, unfortunately.
-
-> [[done]] --[[Joey]]
diff --git a/doc/bugs/rsync_and_gcrypt_special_remotes_make_-J_slow.mdwn b/doc/bugs/rsync_and_gcrypt_special_remotes_make_-J_slow.mdwn
deleted file mode 100644
index f2c8b3b20a..0000000000
--- a/doc/bugs/rsync_and_gcrypt_special_remotes_make_-J_slow.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-When a rsync or gcrypt special remote is enabled, all git-annex commands
-with -J become slow, even those that don't access the remote.
-
-The problem is that Remote.Rsync.gen and Remote.Gcrypt.gen 
-call rsyncTransport which calls sshOptions. 
-When concurrency is enabled, that blocks for a ssh connection to be set up.
-Even though the ssh connection will often not be used.
-
-It should be possible for it not to block until the ssh connection is used.
---[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error.mdwn b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error.mdwn
deleted file mode 100644
index bc458ee2b8..0000000000
--- a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error.mdwn
+++ /dev/null
@@ -1,113 +0,0 @@
-### Please describe the problem.
-get annex sync fails with rsync error saying that the remote is not accessible.
-
-(root cause git annex did not work on my storage machine which causes the client to complain that it can not download objects but I couldn't figure out how to change the title.)
-
-rerunning the rsync command gives
-[[!format sh """
-rsync -vvv "--progress" "--inplace" "--perms" "-e" "'ssh' 'jwiklund@born' '-S' '.git/annex/ssh/jwiklund@born' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'git-annex-shell ''sendkey'' ''/store/backup/Documents.annex.1'' ''--debug'' ''SHA256E-xxx.org'' --uuid xxx ''--'' ''remoteuuid=xxx'' ''unlocked='' ''direct='' ''associatedfile=tools.org'' ''--'''" "--" "dummy:" ".git/annex/tmp/SHA256E-xxx.org"
-opening connection using: ssh x@y -S .git/annex/ssh/x@y -o ControlMaster=auto -o ControlPersist=yes -T "git-annex-shell 'sendkey' '/path' '--debug' 'SHA256E-xxx.org' --uuid 36c1cd35-bac3-485f-bfaa-e2bb29e25957 '--' 'remoteuuid=yyy' 'unlocked=' 'direct=' 'associatedfile=tools.org' '--'" dummy rsync --server --sender -vvvpe.Lsfx --inplace . .  (18 args)
-protocol version mismatch -- is your shell clean?
-(see the rsync man page for an explanation)
-rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1]
-[Receiver] _exit_cleanup(code=2, file=compat.c, line=176): about to call exit(2)
-"""]]
-
-which seems to tell me something is wrong with rsync (the man page references invalid .bashrc but that was not it).
-
-trying to run the command git-annex-shell on that host gives
-
-[[!format sh """
-git-annex-shell
-rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
-Aborted (core dumped)
-rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
-Aborted (core dumped)
-"""]]
-
-Seems to indicate something is wrong with the locale (on that machine), setting it to c fixes the problem.
-
-[[!format sh """
-echo $LANG
-en_US.UTF-8
-set LANG=c
-git-annex-shell
-"""]]
-
-Actually investigating this shows that git annex it self crashes with this locale for some reason
-
-[[!format sh """
-git-annex version
-rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
-Aborted (core dumped)
-rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
-Aborted (core dumped)
-"""]]
-
-I made it work by adding `status --is-interactive; or set -x LANG c` to my `.config/fish/config.fish` but maybe someone else runs into this.
-
-### What steps will reproduce the problem?
-git-annex sync with against a remote host with a broken LANG git-annex combination.
-actually `git-annex` breaks on that host.
-
-
-### What version of git-annex are you using? On what operating system?
-
-Breaking on OS is Ubuntu 14.04.5 LTS
-It works on Ubuntu 16.04.5 LTS
-
-[[!format sh """
-git-annex version: 7.20181106-g6ba6c6b53
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-"""]]
-
-
-### Please provide any additional information below.
-
-(I installed the latest release while writing this report, and it worked the first time, then it started crashing again):
-
-[[!format sh """
-$ echo $LANG
-en_US.UTF-8
-
-$ git-annex version
-git-annex version: 7.20181106-g6ba6c6b53
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-
-$ git-annex version
-rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
-Aborted (core dumped)
-rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
-Aborted (core dumped)
-rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
-Aborted (core dumped)
-
-$ set -x LANG c
-$ git-annex version
-git-annex version: 7.20181106-g6ba6c6b53
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-git annex has worked well for more than a year now :) happy user.
-
-> closing as a duplicate bug report [[done]] --[[Joey]]
diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error/comment_1_ebf78424a6dc1a886bd9286daedd71ce._comment b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error/comment_1_ebf78424a6dc1a886bd9286daedd71ce._comment
deleted file mode 100644
index 63041aba2a..0000000000
--- a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error/comment_1_ebf78424a6dc1a886bd9286daedd71ce._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-03T17:40:15Z"
- content="""
-This is the same problem as
-
-and I'll bet your git-annex on the remote machine was installed from the
-standalone tarball too?
-"""]]
diff --git a/doc/bugs/same_uuid_for_remotes_with_same_path_but_different_name.mdwn b/doc/bugs/same_uuid_for_remotes_with_same_path_but_different_name.mdwn
deleted file mode 100644
index 3a01d3a698..0000000000
--- a/doc/bugs/same_uuid_for_remotes_with_same_path_but_different_name.mdwn
+++ /dev/null
@@ -1,190 +0,0 @@
-### Please describe the problem.
-As a result of the steps below git-annex end up in a state with multiple remotes (pointing to a USB). The crux is that each has a different name, but same UUID and same path. 
-
-All, except one of the remotes is marked as dead. During sync git-annex tries to sync to all of them, and quite surprisingly appears to be successfull. 
-
-The core problem I guess is that git-annex mistakes one remote for another.
-
-I was just experimenting with git-annex, but I think this could happen for real. You put stuff on a usb, you loose the usb, you mark the usb remote as dead, time passes, you put stuff on a different usb and type the same remote name. Bang, it gets the same UUID.
-
-Not knowing much about git-annex it seems that it generates the UUID before checking for name clash and renaming?
-
-### What steps will reproduce the problem?
-Init ~/annex with CLI. (I had version 7, but probably bug on 5 too). Then add an example file, in my case "The Rust Programming Language.pdf". Finally mount usb drive at /mnt/usb.
-
-    - 1) Start git-annex-webapp.
-    - 2) Create an unencrypted usb remote using the webapp. In my case its name was "smallusb".
-    - 3) Sync files to the drive. Verify all is ok.
-    - 4) Imitate drive loss. Delete annex folder on usb drive: rm -rf /mnt/usb/annex
-    - 5) Imitate drive loss. Change to ~/annex and mark smallusb (or smallusb1, smallusb2) as dead.
-    - 6) Stop git-annex-webapp.
-
-Repeat the steps 1-6 at least 2 times in a loop :)
-git-annex appends a number to smallusb, hence the "(or smallusb1, smallusb2)".
-
-### What version of git-annex are you using? On what operating system?
-Arch Linux, version 7.20190504-gf98e97669 downloaded as a binary from git-annex website.
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
--- .git/annex/daemon.log
-[2019-06-14 06:02:25.999232228] main: starting assistant version 7.20190504-gf98e97669
-[2019-06-14 06:02:26.023575476] Cronner: You should enable consistency checking to protect your data. 
-[2019-06-14 06:02:26.058871795] read: git ["config","--null","--list"]
-[2019-06-14 06:02:26.064856922] process done ExitSuccess
-[2019-06-14 06:02:26.065157988] Tor hidden service not enabled
-(scanning...) [2019-06-14 06:02:26.136886408] Watcher: Performing startup scan
-(started...) 
-gpg: assuming signed data in '/tmp/git-annex.tmpxo2fXm/info'
-gpg: Signature made Wed 08 May 2019 01:26:23 AM MSK
-gpg:                using DSA key 40055C6AFD2D526B2961E78F5EE1DBA789C809CB
-gpg: /tmp/git-annex-gpg.tmp28lKKy/trustdb.gpg: trustdb created
-gpg: Good signature from "git-annex distribution signing key (for Joey Hess) " [unknown]
-gpg: WARNING: This key is not certified with a trusted signature!
-gpg:          There is no indication that the signature belongs to the owner.
-Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
-gcrypt: Repository not found: /mnt/usb/annex7
-(recording state in git...)
-warning: no common commits
-From /mnt/usb/annex7
- * [new branch]      git-annex  -> usb/git-annex
-(merging usb/git-annex into git-annex...)
-(recording state in git...)
-[2019-06-14 06:02:45.460756129] main: Syncing with usb 
-To /mnt/usb/annex7
- * [new branch]      git-annex -> synced/git-annex
- * [new branch]      master -> synced/master
-[2019-06-14 06:02:45.731237811] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
-[2019-06-14 06:02:45.736487217] process done ExitSuccess
-[2019-06-14 06:02:45.736545194] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
-[2019-06-14 06:02:45.741412826] process done ExitSuccess
-[2019-06-14 06:02:45.741780286] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..c19630d0a5366076f7da95a2a5fa2e3cfc51445e","--pretty=%H","-n1"]
-[2019-06-14 06:02:45.74683984] process done ExitSuccess
-[2019-06-14 06:02:45.746899694] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..874014cc02ad2383e612a5a200691adfb279fab6","--pretty=%H","-n1"]
-[2019-06-14 06:02:45.751857523] process done ExitSuccess
-[2019-06-14 06:02:45.752059154] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
-[2019-06-14 06:02:45.755772389] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
-[2019-06-14 06:02:45.760705559] read: git ["config","--null","--list"]
-[2019-06-14 06:02:45.766315456] process done ExitSuccess
-[2019-06-14 06:02:45.766455838] read: git ["config","--null","--list"]
-[2019-06-14 06:02:45.771340045] process done ExitSuccess
-[2019-06-14 06:02:45.77170679] read: git ["config","--null","--list"]
-[2019-06-14 06:02:45.776625026] process done ExitSuccess
-[2019-06-14 06:02:45.776753592] read: git ["config","--null","--list"]
-[2019-06-14 06:02:45.782541882] process done ExitSuccess
-
-[2019-06-14 06:02:45.784051825] read: rsync ["--progress","--inplace","--perms",".git/annex/objects/XV/v2/SHA256E-s11122109--bbf1b9a6d9bc3be5515e3114aea5a7cf7a93ea406bbe53cf37eef81ba578b73f.pdf/SHA256E-s11122109--bbf1b9a6d9bc3be5515e3114aea5a7cf7a93ea406bbe53cf37eef81ba578b73f.pdf","../../../mnt/usb/annex7/annex/tmp/SHA256E-s11122109--bbf1b9a6d9bc3be5515e3114aea5a7cf7a93ea406bbe53cf37eef81ba578b73f.pdf"]
-SHA256E-s11122109--bbf1b9a6d9bc3be5515e3114aea5a7cf7a93ea406bbe53cf37eef81ba578b73f.pdf
-     11,122,109 100%  480.71MB/s    0:00:00 (xfr#1, to-chk=0/1)
-[2019-06-14 06:02:46.647226687] process done ExitSuccess
-(checksum...) [2019-06-14 06:02:46.732000864] chat: git ["--git-dir=../../../mnt/usb/annex7","--literal-pathspecs","--literal-pathspecs","cat-file","--batch"]
-[2019-06-14 06:02:46.732316108] chat: git ["--git-dir=../../../mnt/usb/annex7","--literal-pathspecs","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
-[2019-06-14 06:02:46.737658146] process done ExitSuccess
-[2019-06-14 06:02:46.737894862] process done ExitSuccess
-[2019-06-14 06:02:46.738498152] Transferrer: Uploaded The Rust ..guage.pdf
-[2019-06-14 06:02:46.739276009] Pusher: Syncing with usb, smallusb2, smallusb1, smallusb 
-(recording state in git...)
-remote: error: cannot lock ref 'refs/heads/synced/git-annex': is at bb6dbcca16e11c47a129063b29fc26e1af0b6529 but expected c19630d0a5366076f7da95a2a5fa2e3cfc51445e        
-remote: error: cannot lock ref 'refs/heads/synced/git-annex': is at bb6dbcca16e11c47a129063b29fc26e1af0b6529 but expected c19630d0a5366076f7da95a2a5fa2e3cfc51445e        
-remote: error: cannot lock ref 'refs/heads/synced/git-annex': is at bb6dbcca16e11c47a129063b29fc26e1af0b6529 but expected c19630d0a5366076f7da95a2a5fa2e3cfc51445e        
-To /mnt/usb/annex7
-   c19630d..bb6dbcc  git-annex -> synced/git-annex
-To /mnt/usb/annex7
- ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
-error: failed to push some refs to '/mnt/usb/annex7'
-To /mnt/usb/annex7
- ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
-error: failed to push some refs to '/mnt/usb/annex7'
-To /mnt/usb/annex7
- ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
-error: failed to push some refs to '/mnt/usb/annex7'
-From /mnt/usb/annex7
-   874014c..bb6dbcc  synced/git-annex -> smallusb2/synced/git-annex
-From /mnt/usb/annex7
-   874014c..bb6dbcc  git-annex        -> smallusb1/git-annex
-   874014c..bb6dbcc  synced/git-annex -> smallusb1/synced/git-annex
-From /mnt/usb/annex7
-   874014c..bb6dbcc  git-annex        -> smallusb/git-annex
-   874014c..bb6dbcc  synced/git-annex -> smallusb/synced/git-annex
-Everything up-to-date
-Everything up-to-date
-Everything up-to-date
-[2019-06-14 06:03:26.105979618] Pusher: Syncing with smallusb3, smallusb2, smallusb1, smallusb 
-(recording state in git...)
-remote: error: cannot lock ref 'refs/heads/synced/git-annex': is at 63d983955552f44ad51550dd017da9d3e089bb37 but expected bb6dbcca16e11c47a129063b29fc26e1af0b6529        
-remote: error: cannot lock ref 'refs/heads/synced/git-annex': is at 63d983955552f44ad51550dd017da9d3e089bb37 but expected bb6dbcca16e11c47a129063b29fc26e1af0b6529        
-remote: error: cannot lock ref 'refs/heads/synced/git-annex': is at 63d983955552f44ad51550dd017da9d3e089bb37 but expected bb6dbcca16e11c47a129063b29fc26e1af0b6529        
-To /mnt/usb/annex7
-   bb6dbcc..63d9839  git-annex -> synced/git-annex
-To /mnt/usb/annex7
- ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
-error: failed to push some refs to '/mnt/usb/annex7'
-To /mnt/usb/annex7
- ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
-error: failed to push some refs to '/mnt/usb/annex7'
-To /mnt/usb/annex7
- ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
-error: failed to push some refs to '/mnt/usb/annex7'
-From /mnt/usb/annex7
-   c19630d..63d9839  git-annex        -> smallusb3/git-annex
-   bb6dbcc..63d9839  synced/git-annex -> smallusb3/synced/git-annex
-From /mnt/usb/annex7
-   bb6dbcc..63d9839  git-annex        -> smallusb2/git-annex
-   bb6dbcc..63d9839  synced/git-annex -> smallusb2/synced/git-annex
-From /mnt/usb/annex7
-   bb6dbcc..63d9839  git-annex        -> smallusb1/git-annex
-   bb6dbcc..63d9839  synced/git-annex -> smallusb1/synced/git-annex
-Everything up-to-date
-Everything up-to-date
-Everything up-to-date
-[2019-06-14 06:04:26.120035368] Pusher: Syncing with smallusb3, smallusb2, smallusb1, smallusb 
-Everything up-to-date
-Everything up-to-date
-Everything up-to-date
-Everything up-to-date
-
-
--- .git/config
-
-[core]
-	repositoryformatversion = 0
-	filemode = true
-	bare = false
-	logallrefupdates = true
-[annex]
-	uuid = 2517eda3-c212-486e-a3a8-ffc085b842ba
-	version = 7
-	diskreserve = 1 megabyte
-	autoupgrade = ask
-	debug = true
-[filter "annex"]
-	smudge = git-annex smudge -- %f
-	clean = git-annex smudge --clean -- %f
-[remote "smallusb"]
-	url = /mnt/usb/annex7
-	annex-uuid = c52d9a9f-9362-4698-bb1b-fee40779de4c
-	fetch = +refs/heads/*:refs/remotes/smallusb/*
-[remote "smallusb1"]
-	url = /mnt/usb/annex7
-	annex-uuid = c52d9a9f-9362-4698-bb1b-fee40779de4c
-	fetch = +refs/heads/*:refs/remotes/smallusb1/*
-[remote "smallusb2"]
-	url = /mnt/usb/annex7
-	annex-uuid = c52d9a9f-9362-4698-bb1b-fee40779de4c
-	fetch = +refs/heads/*:refs/remotes/smallusb2/*
-[remote "smallusb3"]
-	url = /mnt/usb/annex7
-	annex-uuid = c52d9a9f-9362-4698-bb1b-fee40779de4c
-	fetch = +refs/heads/*:refs/remotes/smallusb3/*
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-I think this is genius software and just love the docs, the effort put into it shines through! :)
-
-> [[done]]; not a bug --[[Joey]]
diff --git a/doc/bugs/same_uuid_for_remotes_with_same_path_but_different_name/comment_1_eae356cfc2c39967c3975c12e8f6646f._comment b/doc/bugs/same_uuid_for_remotes_with_same_path_but_different_name/comment_1_eae356cfc2c39967c3975c12e8f6646f._comment
deleted file mode 100644
index 1c93de8447..0000000000
--- a/doc/bugs/same_uuid_for_remotes_with_same_path_but_different_name/comment_1_eae356cfc2c39967c3975c12e8f6646f._comment
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-06-26T16:11:23Z"
- content="""
-If the remotes have the same UUID, then one of them cannot be marked dead
-unless all of them are, because git-annex stores all such information under
-the UUID.
-
-git-annex checks before accessing a remote that it has the UUID
-it expects it to have. When the remote is on local media, the locally
-cached UUID is simply invalidated if a new repository with a different UUID
-appears there. Many of us git-annex users swap drives all the time on the
-same mount point. git-annex deals with this just fine.
-
-In your scenario, smallusb and smallusb2 etc
-all point to the same path. For smallusb git-annex had cached a UUID that 
-is marked dead. When a new git-annex repository appeared
-there, git-annex automatically changed the UUID that it had cached for
-smallusb to the new UUID. It then proceeds to work entirely as it's
-supposed to.
-
-I don't see a bug here. If you disagree please show how git-annex does
-something wrong in this situation.
-"""]]
diff --git a/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn b/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn
deleted file mode 100644
index 1452415da3..0000000000
--- a/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn
+++ /dev/null
@@ -1,214 +0,0 @@
-CVE-2018-10857
-
-This is a security hole that allows exposure of
-private data in files located outside the git-annex repository.
-
-The attacker needs to have control over one of the remotes of the git-annex
-repository. For example, they may provide a public git-annex repository
-that the victim clones. Or the victim may have paired repositories with
-them. Or, equivilantly, the attacker could have read access to the victim's
-git-annex repository (eg on a server somewhere), and some channel to get
-commits into it (eg a pull requests).
-
-The attacker does `git-annex addurl --relaxed file:///etc/passwd` and commits
-this to the repository in some out of the way place. Then they wait for the
-victim to pull the change.
-
-The easiest exploit is when the victim is running the assistant, or is
-periodically doing `git annex sync --content`. The victim may also perform
-the equivilant actions manually, not noticing they're operating on the
-file. 
-
-In either case, git-annex gets the content of the annexed file, following
-the file:// url. Then git-annex transfers the content back to the
-attacker's repository.
-
-It may also be possible to exploit scp:// sftp:// smb:// etc urls to get at
-files on other computers that the user has access to as well as localhost.
-I was not able to get curl to download from scp:// or sftp:// on debian
-(unstable) but there may be configurations that allow it.
-
-If the url is attached to a key using a cryptographic hash, then the
-attacker would need to already know at least the hash of the content
-to exploit this.
-
-Sending that content back to them could be considered not a security
-hole. Except, I can guess what content some file on your system might have,
-and use this attack as an oracle to determine if I guessed right, and work
-toward penetrating your system using that information.
-
-So, best to not treat addurl with a hash any differently than 
---relaxed and --fast when addressing this hole.
-
-----
-
-The fix must involve locking down the set of allowed in url schemes.
-Better to have a whitelist than a blacklist. http and https seems like the
-right default.
-
-Some users do rely on file:// urls, and this is fine in some use cases,
-eg when you're not merging changes from anyone else. 
-
-So this probably needs to be a git config of allowed url schemes,
-with an appropriatly scary name, like `annex.security.allowed-url-schemes`.
-
-Redirects from one url scheme to another could be usd to bypass such a
-whitelist. curl's `--proto` also affects redirects. http-conduit 
-is limited to only http and will probably remain that way.
-
-> done in [[!commit 28720c795ff57a55b48e56d15f9b6bcb977f48d9]] --[[Joey]]
-
-----
-
-The same kind of attack can be used to see the content of
-localhost urls and other non-globally-available urls.
-
-Redirects and DNS rebinding attacks mean that checking the IP address
-of the hostname in the url is not good enough. It needs to check the IP
-address that is actually connected to, for each http connection made,
-including redirects.
-
-There will need to be a config to relax checks, like
-with an appropriatly scary name, like
-`annex.security.allowed-http-addresses`. Users will want to enable
-support for specific subnets, or perhaps allow all addresses.
-
-When git-annex is configured to use curl, there seems to be no way
-to prevent curl from following urls that redirect to localhost, other than
-disabling redirections. And unless git-annex also pre-resolves the IP
-address and rewrites it into the url passed to curl, DNS rebinding attacks
-would still be possible. Also, one of the remaining reasons people enable
-curl is to use a netrc file with passwords, and the content of
-urls on those sites could also be exposed by this attack. So, it seems curl
-should not be enabled by default and should have a big security warning if
-it's supported at all. Probably ought to only enable it 
-when `annex.security.allowed-http-addresses=all`
-
-http-client does not have hooks that can be used to find out what IP
-address it's connecting to in a secure enough way.
-See 
-
-Seems that building my own http Manager is the only way to go. By building
-my own, I can do the IP address checks inside it when it's setting up
-connections. And, the same manager can be passed to the S3 and WebDav libraries.
-(The url scheme checks could also be moved into that Manager, to prevent
-S3 redirect to file: url scenarios..)
-
-> restricted http manager done and used in
-> [[!commit b54b2cdc0ef1373fc200c0d28fded3c04fd57212]];
-> curl also disabled by default
-
-http proxies are another problem. They could be on the local network,
-or even on localhost, and http-client does not provide a way to force
-a http proxy to connect to an particular IP address (is that even possible?)
-May have to disable use of http proxies unless
-`annex.security.allowed-http-addresses=all`
-Or better, find what http proxy is enabled and prevent using it if it's on
-an IP not allowed there.
-
-> done in [[!commit cc08135e659d3ca9ea157246433d8aa90de3baf7]]
-
-----
-
-The external special remote interface is another way to exploit this.
-Since it bypasses git-annex's usual url download code, whatever fixes are
-put in place there won't help external special remotes.
-
-External special remotes that use GETURLS, typically in conjunction with 
-CLAIMURL and CHECKURL, and then themselves download the content of urls
-in response to a TRANSFER RETRIEVE will have the same problems as
-git-annex's url downloading. 
-
-An external special remote might also make a simple http request to a
-key/value API to download a key, and follow a redirect to file:///
-or http://localhost/.
-
-If the key uses a cryptographic hash, git-annex verifies the content. 
-But, the attacker could have committed a key that doesn't
-use a hash. Also, the attacker could use the hash check as an oracle,
-to guess at the content of files.
-
-If the external special remote is encrypted, the http content is passed
-though gpg. So, whatever location an attacker redirects it to would also
-have to be encrypted. gpg is not told what encryption key the content is
-expected to be encrypted with. (Could it be told somehow for hybrid and
-shared encryption which key to use? pubkey encryption of course uses
-the regular gpg public key). 
-
-So if the attacker knows a file that the user has encrypted with any of
-their gpg keys, they can provide that file, and hope it will be decrypted.
-Note that this does not need a redirect to a local file or web server; the
-attacker can make their web server serve up a gpg encrypted file.
-This is a separate vulnerability and was assigned CVE-2018-10859.
-
-So, content downloaded from encrypted special remotes (both internal and
-external) must be rejected unless it can be verified with a hash. Then
-content using WORM and URL keys would not be able to be downloaded from
-them. Might as well also require a hash check for non-encrypted external
-special remotes, to block the redirection attack. There could be a config
-setting to say that the git-annex repository is not being shared with
-untrusted third parties, and relax that check.
-
-> done in [[!commit b657242f5d946efae4cc77e8aef95dd2a306cd6b]]
-
-Could also tighten down the gpg decryption to only allow decrypting with
-the provided symmetric key, as a further protection against CVE-2018-10859.
-If this can be done, then only remotes with encryption=pubkey will
-really need to reject WORM and URL keys, since encryption=shared
-and encryption=hybrid use a symetric key that's only used to encrypt data
-for that remote. Although opening those back up to WORM and URL would
-allow the remote sending other content stored on it, to get the wrong
-content decrypted. This seems unlikely to be a useful exploit in most
-cases, but perhaps not all cases, so probably best to not relax the
-rejection aven when doing this. It's still worth doing as a belt and braces
-fix.
-
-> AFAICS, gpg does not have a way to specify to decrypt with only a
-> symmetric encryption key. It could be done by running gpg in an
-> environment with an empty keyring, but gpg agent makes that difficult and
-> it would be added complexity. Decided not to do it.
-
-----
-
-Built-in special remotes that use protocols on top of http, eg S3 and WebDAV,
-don't use Utility.Url, could also be exploited, and will need to be fixed
-separately.
-
-> not affected for url schemes, because http-client only supports http,
-> not file:/
-
-> done for localhost/lan in [[!commit b54b2cdc0ef1373fc200c0d28fded3c04fd57212]]
-
-youtube-dl
-
-> already disabled file:/. Added a scheme check, but it won't block
-> redirects to other schemes. But youtube-dl goes off and does its own thing with other
-> protocols anyway, so that's fine.
-> 
-> The youtube-dl generic extractor will download media files (including 
-> videos and photos) if passed an direct url to them. It does not seem to
-> extract video etc from tags on html pages.
-
-> git-annex first checks if a web page
-> is html before pointing youtube-dl at it, to avoid using it to download
-> direct urls to media files. But that would not prevent a DNS rebinding
-> attack which made git-annex see the html page, and youtube-dl then see
-> a media file on localhost.
-> 
-> Also, the current code in htmlOnly
-> runs youtube-dl if the html page download test fails to download
-> anything.
-> 
-> Also, in the course of a download, youtube-dl could chain to other urls,
-> depending on how its extractor works. Those urls could redirect to
-> a localhost/lan web server.
-> 
-> So, youtube-dl needs to be disabled unless http address security checks
-> are turned off.
-> 
-> > done in [[!commit e62c4543c31a61186ebf2e4e0412df59fc8630c8]]
-
-
-----
-
-Both security holes are now fixed. [[done]] --[[Joey]]
diff --git a/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared.mdwn b/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared.mdwn
deleted file mode 100644
index 24f535d238..0000000000
--- a/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared.mdwn
+++ /dev/null
@@ -1,67 +0,0 @@
-### Please describe the problem.
-I am looking into [decrypting files in special remotes without git-annex](https://git-annex.branchable.com/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/) also with comments in [disaster_recovery_with_an_encrypted_special_remote](http://git-annex.branchable.com/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/). User is trying to figure out filename encryption scheme on special remotes for sharedpubkey encryption scheme.
-
-`sharedpubkey` is using a different filename encryption method than `shared` on special remotes but [encryption](https://git-annex.branchable.com/encryption/) page implies they should be using the same method: “regular public key encryption with shared filename encryption (encryption=sharedpubkey)”.
-
-### What steps will reproduce the problem?
-	andrew@bumblebee /tmp$ mkdir repo1
-	andrew@bumblebee /tmp$ cd repo1/
-	andrew@bumblebee /tmp/repo1$ git init
-	Initialized empty Git repository in /private/tmp/repo1/.git/
-	andrew@bumblebee /tmp/repo1$ git annex init
-	init  ok
-	(recording state in git...)
-	andrew@bumblebee /tmp/repo1$ echo "hello a" > a.txt
-	andrew@bumblebee /tmp/repo1$ git annex add a.txt 
-	add a.txt ok
-	(recording state in git...)
-	andrew@bumblebee /tmp/repo1$ mkdir /tmp/remote1
-	andrew@bumblebee /tmp/repo1$ git annex initremote remote1 type=directory directory=/tmp/remote1 encryption=sharedpubkey keyid=0C5C0618
-	initremote remote1 (encryption setup) (to gpg keys: 222365310C5C0618) ok
-	(recording state in git...)
-	andrew@bumblebee /tmp/repo1$ git annex copy a.txt --to=remote1
-	copy a.txt (to remote1...) 
-	ok                              
-	(recording state in git...)
-	andrew@bumblebee /tmp/repo1$ mkdir /tmp/remote2
-	andrew@bumblebee /tmp/repo1$ git annex initremote remote2 type=directory directory=/tmp/remote2 encryption=shared
-	initremote remote2 (encryption setup) (encryption key stored in git repository) ok
-	(recording state in git...)
-	andrew@bumblebee /tmp/repo1$ git annex copy a.txt --to=remote2
-	copy a.txt (to remote2...) 
-	ok                              
-	(recording state in git...)
-	andrew@bumblebee /tmp/repo1$ ls -la /tmp/remote1/
-	432/ tmp/ 
-	andrew@bumblebee /tmp/repo1$ ls -la /tmp/remote1/432/d7f/GPGHMACSHA1--6e830539e4aac12d435b2abc1f693e0dfacf5e89/GPGHMACSHA1--6e830539e4aac12d435b2abc1f693e0dfacf5e89 
-	-r--r--r--  1 andrew  wheel  340 Jul 19 13:40 /tmp/remote1/432/d7f/GPGHMACSHA1--6e830539e4aac12d435b2abc1f693e0dfacf5e89/GPGHMACSHA1--6e830539e4aac12d435b2abc1f693e0dfacf5e89
-	andrew@bumblebee /tmp/repo1$ ls -la /tmp/remote2/
-	411/ tmp/ 
-	andrew@bumblebee /tmp/repo1$ ls -la /tmp/remote2/411/ad6/GPGHMACSHA1--0332a66cded87db8ec8427280c171133c958754f/GPGHMACSHA1--0332a66cded87db8ec8427280c171133c958754f 
-	-r--r--r--  1 andrew  wheel  78 Jul 19 13:40 /tmp/remote2/411/ad6/GPGHMACSHA1--0332a66cded87db8ec8427280c171133c958754f/GPGHMACSHA1--0332a66cded87db8ec8427280c171133c958754f
-	andrew@bumblebee /tmp/repo1$ ls -la a.txt 
-	lrwxr-xr-x  1 andrew  wheel  186 Jul 19 13:37 a.txt -> .git/annex/objects/8k/z6/SHA256E-s8--448a19594af45f888493a4cb8b6e12ed42fc773dab6db35a299370ebfc805270.txt/SHA256E-s8--448a19594af45f888493a4cb8b6e12ed42fc773dab6db35a299370ebfc805270.txt
-	andrew@bumblebee /tmp/repo1$ echo -n "SHA256E-s8--448a19594af45f888493a4cb8b6e12ed42fc773dab6db35a299370ebfc805270.txt" | openssl dgst -SHA1 -hmac "$(git show git-annex:remote.log | grep 'name='"remote2 " | sed -E 's/.*cipher=([^ ]+) .*/\1/' | base64 -D | tr -d '\n' | head  -c 256)"
-	0332a66cded87db8ec8427280c171133c958754f
-	andrew@bumblebee /tmp/repo1$ echo -n "SHA256E-s8--448a19594af45f888493a4cb8b6e12ed42fc773dab6db35a299370ebfc805270.txt" | openssl dgst -SHA1 -hmac "$(git show git-annex:remote.log | grep 'name='"remote1 " | sed -E 's/.*cipher=([^ ]+) .*/\1/' | base64 -D | tr -d '\n' | head  -c 256)"
-	bb3b1f4b27164c2edc81da32c43c64e8a4be75d8
-	andrew@bumblebee /tmp/repo1$ 
-
-### What version of git-annex are you using? On what operating system?
-	git-annex version: 6.20180626-gdf91a5cff
-	build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
-	dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
-	key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-	remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-	operating system: darwin x86_64
-	supported repository versions: 3 5 6
-	upgrade supported from repository versions: 0 1 2 3 4 5
-	local repository version: 5
-
-
-You can see that I am able to generate correctly the special remote key used by `remote2` the `shared` remote, `0332a66cded87db8ec8427280c171133c958754f`. But using the same method for `remote1` the `sharedpubkey` remote does not yield a meaningful key `bb3b1f4b27164c2edc81da32c43c64e8a4be75d8`
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-Yes. —[andrew](https://git-annex.branchable.com/users/andrew/)
-
-[[done]]
diff --git a/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared/comment_1_72dbc03edbd8559527968c504c4fe7af._comment b/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared/comment_1_72dbc03edbd8559527968c504c4fe7af._comment
deleted file mode 100644
index 0164038c2b..0000000000
--- a/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared/comment_1_72dbc03edbd8559527968c504c4fe7af._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-07-19T20:38:12Z"
- content="""
-Shared only uses the first 256 bytes of the cipher to
-encrypt filenames, while sharedpubkey uses the entire cipher.
-
-That difference makes sense, since shared uses the second half of the cipher to
-encrypt file contents, while sharedpubkey encrypts that to the gpg key(s).
-
-You are truncating the sharedpubkey cipher to 256 bytes; I suspect if you
-don't, it will work. If it still doesn't work, refer to the working code
-that I posted in the forum thread earlier.
-
-I don't think that doc/encryption.mdwn needs to go into detailed specifics.
-If someone would like to write a fully detailed explanation of how the
-encryption works it could go in doc/internals.mdwn or someplace like that.
-
-(Crypto.hs is also not hard to follow if you look at the types:
-cipherMac of a MacOnlyCipher uses the whole cipher, while
-cipherMac of a Cipher uses only the beginning of the cipher.
-And decryptCipher of a SharedPubKeyCipher creates a MacOnlyCipher.)
-
-This bug certianly does not warrent changing the behavior of git-annex,
-which would in any case only complicate the situation since it would still
-need to support the current data.
-"""]]
diff --git a/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared/comment_2_a327ce6e5fe169a3042e207ae7306245._comment b/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared/comment_2_a327ce6e5fe169a3042e207ae7306245._comment
deleted file mode 100644
index 20a11e8b14..0000000000
--- a/doc/bugs/sharedpubkey_is_using_a_different_filename_encryption_method_than_shared/comment_2_a327ce6e5fe169a3042e207ae7306245._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="comment 2"
- date="2018-07-23T22:35:48Z"
- content="""
-Thanks! That makes sense. Marking as done.
-"""]]
diff --git a/doc/bugs/smudge_errors_on_os-x.mdwn b/doc/bugs/smudge_errors_on_os-x.mdwn
deleted file mode 100644
index e05e3e7379..0000000000
--- a/doc/bugs/smudge_errors_on_os-x.mdwn
+++ /dev/null
@@ -1,56 +0,0 @@
-### Please describe the problem.
-
-When following the instructions in [[tips/unlocked files]] on Mac, I am seeing an error message when smudge is run.
-
-This causes the file to end up in git's object database (`.git/objects`) instead of git annex's (`.git/annex/objects`).
-
-I tried the same steps on linux with the autobuilder version (7.20190508) and got no error and the data ended up in git annex correctly.
-
-### What steps will reproduce the problem?
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-$ mkdir test-7-annex
-$ cd test-7-annex
-$ git init
-Initialized empty Git repository in /Users/jones/test-7-annex/.git/
-$ git ci -m 'init' --allow-empty                                                                                                                              
-[master (root-commit) 006a611] init
-$ git annex init mini --version=7                                                                                                                             
-init mini (scanning for unlocked files...)
-ok
-(recording state in git...)
-$ cp ../file.mp3 .
-$ git add file.mp3
-error: cannot feed the input to external filter git-annex smudge --clean -- %f
-error: external filter git-annex smudge --clean -- %f failed
-$ git annex sync
-commit (recording state in git...)
-
-[master 48b44eb] git-annex in mini
- 1 file changed, 0 insertions(+), 0 deletions(-)
- create mode 100755 file.mp3
-ok
-$ du -sh .git/objects/
-3.9M    .git/objects/
-$ du -sh .git/annex/objects
-du: .git/annex/objects: No such file or directory
-
-# End of transcript or log.
-"""]]
-
-### What version of git-annex are you using? On what operating system?
-
-On Mac, versions 7.20190220 (latest download) or 7.20190508 (latest autobuild)
-
-### Please provide any additional information below.
-
-
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-YES! Git annex is an amazing tool and it's the backbone of my long term archiving workflow. I also use it for archive management at work and it's proven to be incredibly useful. Thank you for continuing to maintain and innovate with git annex!
-
-[[done]]
diff --git a/doc/bugs/smudge_errors_on_os-x/comment_1_71a3a522b80617d7afc0f4af7f547c67._comment b/doc/bugs/smudge_errors_on_os-x/comment_1_71a3a522b80617d7afc0f4af7f547c67._comment
deleted file mode 100644
index 9d6cf19af3..0000000000
--- a/doc/bugs/smudge_errors_on_os-x/comment_1_71a3a522b80617d7afc0f4af7f547c67._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="comment 1"
- date="2019-05-21T23:33:57Z"
- content="""
-I am not able to reproduce this bug on MacOS 10.12.6, using git-annex 7.20190508-g06bc46eaa with the git-annex bundled git version 2.18.0. Also, I don't have \"ci\" options on my git so I did `git commit -m 'init' --allow-empty`.
-
-What is your output of `git-annex version`? What version of `git` and `MacOS` are you using?
-
-—Andrew
-"""]]
diff --git a/doc/bugs/smudge_errors_on_os-x/comment_2_fe5919747887d3afda8bf2b77a3ab944._comment b/doc/bugs/smudge_errors_on_os-x/comment_2_fe5919747887d3afda8bf2b77a3ab944._comment
deleted file mode 100644
index 77cff33ae0..0000000000
--- a/doc/bugs/smudge_errors_on_os-x/comment_2_fe5919747887d3afda8bf2b77a3ab944._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-05-23T16:09:38Z"
- content="""
-Could it be that git is not finding git-annex in PATH to run it, or that
-the binary in PATH is somehow broken?
-
-I'm leaning toward the problem being something like that, because if git
-was able to run git-annex and git-annex somehow failed, it would display an
-error message. It seems as if git-annex is not being run.
-"""]]
diff --git a/doc/bugs/smudge_errors_on_os-x/comment_3_ee9dd8af508516ee8a1622efbd10642e._comment b/doc/bugs/smudge_errors_on_os-x/comment_3_ee9dd8af508516ee8a1622efbd10642e._comment
deleted file mode 100644
index 1bcbab308a..0000000000
--- a/doc/bugs/smudge_errors_on_os-x/comment_3_ee9dd8af508516ee8a1622efbd10642e._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="ndj"
- avatar="http://cdn.libravatar.org/avatar/0e1938953fb670f94a4e65b81a3cc58d"
- subject="comment 3"
- date="2019-05-28T03:36:52Z"
- content="""
-I did more digging and I it looks like the issue is that I have a very old version of git (2.2.1) installed via brew that was taking precedence over the system git (2.11.0). Taking that out of the mix made everything work.
-
-Also, by just using `runshell`, it worked as well. I may switch to using that method of adding git-annex to my path, rather than just manually tacking it on the end.
-
-This is on MacOS 10.12.6 and git annex version 7.20190220-g1812ec5da.
-
-Thank you both for your help.
-"""]]
diff --git a/doc/bugs/standalone_debian_pkg_build_fails_in_sid.mdwn b/doc/bugs/standalone_debian_pkg_build_fails_in_sid.mdwn
deleted file mode 100644
index 8bcd1d2f31..0000000000
--- a/doc/bugs/standalone_debian_pkg_build_fails_in_sid.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-### Please describe the problem.
-
-Trying to build debian pkg from current master in sid which has newer ghc (8.4.3+dfsg1-4) to see if it would somehow affect [multiple ssh prompt/locking](http://git-annex.branchable.com/bugs/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/) issue.  But build fails with unclear to me
-
-[[!format sh """
-OK (0.68s)
-    addurl:                                               On branch master
-nothing to commit, working tree clean
-Configuration does not allow accessing file:///build/git-annex-7.20181105+git134-gf39db41d2/.t/tmprepo388/myurl
-download failed: Configuration does not allow accessing file:///build/git-annex-7.20181105+git134-gf39db41d2/.t/tmprepo388/myurl
-OK (0.33s)
-
-All 293 tests passed (264.37s)
-
-git-annex: ExitSuccess
-failed
-git-annex: test: 1 failed
-
-git-annex: ExitFailure 1
-failed
-git-annex: test: 1 failed
-make[1]: *** [Makefile:78: test] Error 1
-make[1]: Leaving directory '/build/git-annex-7.20181105+git134-gf39db41d2'
-dh_auto_test: make V=1 -j1 test returned exit code 2
-make: *** [debian/rules:15: build-arch] Error 2
-
-"""]]
-
-So it is `All 293 tests passed (264.37s)` but then some additional test fails
-
-Note that was 7.20181105+git134-gf39db41d2 and i386
-
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/standalone_debian_pkg_build_fails_in_sid/comment_1_a159b01bd28fde7544343ef2fcfbea56._comment b/doc/bugs/standalone_debian_pkg_build_fails_in_sid/comment_1_a159b01bd28fde7544343ef2fcfbea56._comment
deleted file mode 100644
index b0efdeeeb7..0000000000
--- a/doc/bugs/standalone_debian_pkg_build_fails_in_sid/comment_1_a159b01bd28fde7544343ef2fcfbea56._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 1"
- date="2018-11-19T03:18:23Z"
- content="""
-apparently doesn't build in buster either -- so it is the problem of the 7.20181105+git134-gf39db41d2 not the environment
-"""]]
diff --git a/doc/bugs/standalone_debian_pkg_build_fails_in_sid/comment_2_640cb84ba5ea82254f0571784046fa99._comment b/doc/bugs/standalone_debian_pkg_build_fails_in_sid/comment_2_640cb84ba5ea82254f0571784046fa99._comment
deleted file mode 100644
index e3c2000e54..0000000000
--- a/doc/bugs/standalone_debian_pkg_build_fails_in_sid/comment_2_640cb84ba5ea82254f0571784046fa99._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-11-19T16:40:27Z"
- content="""
-This is a reversion due to [[!commit 39fbaa0682198ba0fd8aa437b8382b13fb71e66f]]
-that breaks any part of a git-annex command that uses exitWith since that
-is actually implemented as an exception which now gets caught.
-
-(Seems that when I tried the test suite after that commit I stopped reading
-at the "All 293 tests passed" because it does always go on to fail.)
-"""]]
diff --git a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file.mdwn b/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file.mdwn
deleted file mode 100644
index 0da5c98e45..0000000000
--- a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file.mdwn
+++ /dev/null
@@ -1,42 +0,0 @@
-### Please describe the problem.
-
-Originally spotted in 
-https://neurostars.org/t/updating-datalad-datasets/1154/11 and thought that the
-guy is just offline and that is why can't get those "web" links, but apparently
-there were no web links for that file, so the message like
-
-[[!format sh """
-Try making some of these repositories available:
-    00000000-0000-0000-0000-000000000001 -- web
-...
-"""]]
-
-was a bit misleading.  Here is the full whereis  for that file (since
-then I've populated git-annex with urls, so if you would clone it you would get
-some http urls for web remote):
-
-[[!format sh """
-                              
-$> git annex whereis sub-10159/anat/sub-10159_T1w.nii.gz
-whereis sub-10159/anat/sub-10159_T1w.nii.gz (3 copies)
-    00000000-0000-0000-0000-000000000001 -- web
-    09ede57e-5ec2-484b-b6fb-8a632e5c7a4e -- [datalad-archives]
-    41f07c30-3cfc-4de3-9fbc-84383f5156e6 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/openfmri/ds000030
-                              
-  datalad-archives: dl+archive:MD5E-s3920586194--f5ecaf1365ea031dd6c20d0f958ed69b.tgz#path=ds030_R1.0.0/sub-10159/anat/sub-10159_T1w.nii.gz&size=11637742
-  datalad-archives: dl+archive:MD5E-s3920586194--f5ecaf1365ea031dd6c20d0f958ed69b.tgz/ds030_R1.0.0/sub-10159/anat/sub-10159_T1w.nii.gz#size=11637742
-  datalad-archives: dl+archive:MD5E-s4347673658--836cb09310fa22f7d2112c7f81e6258b.tgz#path=ds000030/sub-10159/anat/sub-10159_T1w.nii.gz&size=11637742
-  datalad-archives: dl+archive:MD5E-s4349211504--2fe25908e474d782e8963fd31d6fe4b5.zip#path=ds000030/sub-10159/anat/sub-10159_T1w.nii.gz&size=11637742
-  datalad-archives: dl+archive:MD5E-s4802398120--ce2d215f336e6dfa282d69cc35beb80d.tgz#path=sub-10159/anat/sub-10159_T1w.nii.gz&size=11637742
-ok
-"""]]
-
-
-### What version of git-annex are you using? On what operating system?
-
-6.20180807+git63-gbafc55c4a-1~ndall+1
-
-
-[[!meta name=yoh]]
-
-> I think I've now understood and fixed this, so [[done]] --[[Joey]]
diff --git a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_1_fd32c6a7e5ac6b0ac721dd9edd824c29._comment b/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_1_fd32c6a7e5ac6b0ac721dd9edd824c29._comment
deleted file mode 100644
index 6c1a22ad35..0000000000
--- a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_1_fd32c6a7e5ac6b0ac721dd9edd824c29._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-08-21T15:38:51Z"
- content="""
-Note that git-annex get from the web remote in this sitation says
-"no known url" before the message you quoted.
-
-Since location tracking and urls are separate peices of information, it's
-certianly possible for them to be inconsistent like this.
-
-It doesn't normally happen though. Eg, `git annex rmurl` of the last url
-of a remote will update location tracking to say it's missing.
-(Special remote SETURLMISSING does the same thing.)
-
-One way it can happen is using `git-annex setpresentkey` 
-to say a key is present in the web, and not setting an url.
-But that's plumbing and it's up the user to use it consistently.
-
-If you have some other way to get into this state that doesn't involve
-plumbing commands, that could be a bug.
-
-It might be possible to add something linking the data so that
-location tracking for the web is ignored if it doesn't have urls, which
-would also need to apply to some other special remotes that use urls, but
-not others that only might have an associated url. I'm doubtful of this
-idea tho.
-"""]]
diff --git a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_2_20e02b8cc70c602069b80086544a9fea._comment b/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_2_20e02b8cc70c602069b80086544a9fea._comment
deleted file mode 100644
index ab8537d7a4..0000000000
--- a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_2_20e02b8cc70c602069b80086544a9fea._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 2"
- date="2018-08-21T16:23:05Z"
- content="""
-Thanks for the analysis!
-Apparently we did have some web URLs available for that key awhile back, then bucket was redone so they were marked not available.  I wonder if may be for that batch fixup I just did it \"manually\" instead of using `rmurl` which would have taken care about it.  So I guess nothing to fix ;-)
-"""]]
diff --git a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_3_fdf3149137da1c5c61b1dc72089adb1a._comment b/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_3_fdf3149137da1c5c61b1dc72089adb1a._comment
deleted file mode 100644
index fcdfaf8d57..0000000000
--- a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_3_fdf3149137da1c5c61b1dc72089adb1a._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-10-04T19:41:50Z"
- content="""
-Well, it could be a rmurl bug.
-
-        whenM (null <$> getUrls key) $
-                logChange key uuid InfoMissing
-
-I think that might behave wrongly if an uri 
-has been registered by a special remote, since the
-list of urls would then not be empty. So it ought to filter out uris
-that have an OtherDownloader.
-
-And hmm, SETURLPRESENT adds an url to the list, doesn't mark it as present
-in the web, but if you then did a `git annex addurl` to add an url to the web,
-there would be two urls listed, so `git annex rmurl` of the url addurl added would
-leave it marked present in the web because of the other url. Given the data
-that's stored, that can't be handled any better. Fixing this would need to
-add the uuid of the remote next to the url in the log file.
-"""]]
diff --git a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_4_6dff7befbaacbff573c5f72688966af5._comment b/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_4_6dff7befbaacbff573c5f72688966af5._comment
deleted file mode 100644
index c636b09291..0000000000
--- a/doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_4_6dff7befbaacbff573c5f72688966af5._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2018-10-04T20:20:43Z"
- content="""
-I think that making rmurl filter out urls with an OtherDownloader
-when removing an url claimed by the web is sufficient.
-Then SETURIPRESENT won't confuse rmurl from the web.
-
-But what about SETURLPRESENT? Well, that url ought to be a url that can be
-downloaded by the web special remote. And if the web special remote is marked
-as present, it will try to download from that url along with whatever other urls
-are recorded. So, it makes sense for rmurl to treat that url as an indication
-that the web still has content, when removing some other url.
-
-But then if an url is added to the web, and then an external special remote
-uses SETURLPRESENT with another url, and then rmurl removes the first url,
-and then SETURLMISSING removes the other url, the content will still be marked
-as present in the web. So it seem that SETURLMISSING should mark the
-content as not present in the web if that was the last url. (So should other
-special remotes that remove regular urls, like bittorrent.)
-
-Currently the content is marked as not present in the remote making the change,
-which is the wrong thing! (And SETURLPRESENT/SETURIPRESENT mark content
-as present in the external remote, which also seems unncessary.)
-
-The remaining case is an rmurl on an url with an OtherDownloader,
-which is being removed from some other special remote than web, when there are
-some more urls with OtherDownloader that were set by other special remotes.
-
-I think that it doesn't actually make sense for rmurl of such an url to 
-mark the content as not being present in the special remote. The user should
-drop it if they want to remove it from the special remote. It's ok for it to
-remove the url but not update the presence information.
-"""]]
diff --git a/doc/bugs/sync_does_not_drop_local_content_present_in_exporttree_remote.mdwn b/doc/bugs/sync_does_not_drop_local_content_present_in_exporttree_remote.mdwn
deleted file mode 100644
index 91929df397..0000000000
--- a/doc/bugs/sync_does_not_drop_local_content_present_in_exporttree_remote.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-`git annex sync --content` does not drop local unwanted content that
-has been transferred to an exporttree remote.
-
-This normally doesn't matter since exporttree remotes are untrusted, but
-S3 with versioning enabled is not untrusted and once a file reaches such a
-remote it should be able to be dropped locally. --[[Joey]]
-
-Actually, there are two bugs here, because sync --content also fails to
-drop local unwanted content that's got only 1 copy on another remote.
-It forgot to include the local copy as a currently present copy, throwing
-off the numcopies counting. --[[Joey]]
-
-Both [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/sync_with_clone_protocol_error.mdwn b/doc/bugs/sync_with_clone_protocol_error.mdwn
deleted file mode 100644
index 2ae0cab420..0000000000
--- a/doc/bugs/sync_with_clone_protocol_error.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-	Failed to get annex.uuid configuration of repository clam
-
-	Instead, got: "(merging origin/git-annex origin/synced/git-annex into git-annex...)\n(recording state in git...)\nannex.uuid=$obscured\ncore.gcrypt-id=\n"
-
-Seen after cloning the repository to clam, not running git-annex init
-in it, adding clam as a remote, and git annex sync clam.
-Apparently git-annex-shell outputs some merging messages in this 
-case, which breaks the protocol. 
-
-Next git-annex sync clam worked ok and got the UUID.
-
-clam has git-annex 6.20170101 installed.
---[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/test_suite_fails_on_windows.mdwn b/doc/bugs/test_suite_fails_on_windows.mdwn
deleted file mode 100644
index 8de92cf7c4..0000000000
--- a/doc/bugs/test_suite_fails_on_windows.mdwn
+++ /dev/null
@@ -1,688 +0,0 @@
-### Please describe the problem.
-Running the test suite on windows gives test failures.
-
-### What steps will reproduce the problem?
-Install Git for Windows (64-bit), install git-annex into the Git installation dir, open Git bash, run git-annex-test .
-
-### What version of git-annex are you using? On what operating system?
-7.20190730-ga63bf35dc on Windows 10
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-MINGW64_NT-10.0-17763 WPAE9-305 3.0.7-338.x86_64 2019-04-30 21:52 UTC x86_64 Msys
-git-annex version: 7.20190730-ga63bf35dc
-build flags: Assistant Webapp Pairing S3 WebDAV TorrentParser Feeds Testsuite
-dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: mingw32 x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 2 3 4 5 6
-Tests
-  QuickCheck
-    prop_encode_decode_roundtrip:                         OK (0.11s)
-      +++ OK, passed 1000 tests.
-    prop_encode_c_decode_c_roundtrip:                     OK (0.09s)
-      +++ OK, passed 1000 tests.
-    prop_isomorphic_key_encode:                           OK (0.04s)
-      +++ OK, passed 1000 tests.
-    prop_isomorphic_shellEscape:                          OK (0.02s)
-      +++ OK, passed 1000 tests.
-    prop_isomorphic_shellEscape_multiword:                OK (0.85s)
-      +++ OK, passed 1000 tests.
-    prop_isomorphic_configEscape:                         OK (0.02s)
-      +++ OK, passed 1000 tests.
-    prop_parse_show_Config:                               OK (0.05s)
-      +++ OK, passed 1000 tests.
-    prop_upFrom_basics:                                   OK (0.02s)
-      +++ OK, passed 1000 tests.
-    prop_relPathDirToFile_basics:                         OK (0.02s)
-      +++ OK, passed 1000 tests.
-    prop_relPathDirToFile_regressionTest:                 OK
-      +++ OK, passed 1 test.
-    prop_cost_sane:                                       OK
-      +++ OK, passed 1 test.
-    prop_matcher_sane:                                    OK
-      +++ OK, passed 1 test.
-    prop_HmacSha1WithCipher_sane:                         OK
-      +++ OK, passed 1 test.
-    prop_VectorClock_sane:                                OK
-      +++ OK, passed 1 test.
-    prop_addMapLog_sane:                                  OK
-      +++ OK, passed 1 test.
-    prop_verifiable_sane:                                 OK (0.08s)
-      +++ OK, passed 1000 tests.
-    prop_segment_regressionTest:                          OK
-      +++ OK, passed 1 test.
-    prop_read_write_transferinfo:                         OK (0.04s)
-      +++ OK, passed 1000 tests.
-    prop_read_show_inodecache:                            OK (0.02s)
-      +++ OK, passed 1000 tests.
-    prop_parse_build_presence_log:                        OK (1.43s)
-      +++ OK, passed 1000 tests.
-    prop_parse_build_contentidentifier_log:               OK (1.43s)
-      +++ OK, passed 1000 tests.
-    prop_read_show_TrustLevel:                            OK
-      +++ OK, passed 1 test.
-    prop_parse_build_TrustLevelLog:                       OK
-      +++ OK, passed 1 test.
-    prop_hashes_stable:                                   OK
-      +++ OK, passed 1 test.
-    prop_mac_stable:                                      OK
-      +++ OK, passed 1 test.
-    prop_schedule_roundtrips:                             OK
-      +++ OK, passed 1000 tests.
-    prop_past_sane:                                       OK
-      +++ OK, passed 1 test.
-    prop_duration_roundtrips:                             OK
-      +++ OK, passed 1000 tests.
-    prop_metadata_sane:                                   OK (0.87s)
-      +++ OK, passed 1000 tests.
-    prop_metadata_serialize:                              OK (1.09s)
-      +++ OK, passed 1000 tests.
-    prop_branchView_legal:                                OK (0.72s)
-      +++ OK, passed 1000 tests.
-    prop_viewPath_roundtrips:                             OK (0.04s)
-      +++ OK, passed 1000 tests.
-    prop_view_roundtrips:                                 OK (0.48s)
-      +++ OK, passed 1000 tests.
-    prop_viewedFile_rountrips:                            OK (0.02s)
-      +++ OK, passed 1000 tests.
-    prop_b64_roundtrips:                                  OK
-      +++ OK, passed 1000 tests.
-    prop_standardGroups_parse:                            OK
-      +++ OK, passed 1 test.
-  Unit Tests v7 unlocked
-    add dup:                                              Init Tests
-  init: init test repo 
-  Detected a filesystem without fifo support.
-
-  Disabling ssh connection caching.
-
-  Detected a crippled filesystem.
-
-  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
-ok
-(recording state in git...)
-OK (2.25s)
-  add:  git-annex.exe: NUL: openFile: does not exist (No such file or directory)
-error: external filter 'git-annex smudge --clean -- %f' failed 1
-error: external filter 'git-annex smudge --clean -- %f' failed
-FAIL (0.52s)
-    .\Test\Framework.hs:347:
-    foo failed to look up key
-
-1 out of 2 tests failed (2.78s)
-FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    add extras:                                           FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    export_import:                                        FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    export_import_subdir:                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    shared clone:                                         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    log:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    import:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    reinject:                                             FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    unannex (no copy):                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    unannex (with copy):                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    drop (no remote):                                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    drop (with remote):                                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    drop (untrusted remote):                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    get:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    get (ssh remote):                                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    move:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    move (ssh remote):                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    copy:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    lock:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    lock (v7 --force):                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    edit (no pre-commit):                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-Init Tests
-    edit (pre-commit):                                      init: FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    partial commit:                                       FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fix:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    direct:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    trust:                                                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (basics):                                        FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (bare):                                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (local untrusted):                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (remote untrusted):                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck --from remote:                                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    migrate:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    migrate (via gitattributes):                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    unused:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    describe:                                             FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    find:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    merge:                                                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    info:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    version:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    sync:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    union merge regression:                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    adjusted branch merge regression:                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    adjusted branch subtree regression:                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution:                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (adjusted branch):                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution movein regression:                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (mixed directory and file):       FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution symlink bit:                      FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (uncommitted local file):         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (removed file):                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (nonannexed file):                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (nonannexed symlink):             FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (mixed locked and unlocked file): FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    map:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    uninit:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    uninit (in git-annex branch):                         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    upgrade:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    whereis:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    hook remote:                                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    directory remote:                                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    rsync remote:                                         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    bup remote:                                           FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    crypto:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    preferred content:                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    add subdirs:                                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    addurl:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-  Unit Tests v5 direct
-    add dup:                                              init test repo 
-  Detected a filesystem without fifo support.
-
-  Disabling ssh connection caching.
-
-  Detected a crippled filesystem.
-
-  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
-ok
-(recording state in git...)
-Direct mode is not supported by this repository version. Use git-annex unlock instead.
-FAIL (2.28s)
-    .\Test\Framework.hs:474:
-    git annex direct failed
-  add:  git-annex.exe: NUL: openFile: does not exist (No such file or directory)
-error: external filter 'git-annex smudge --clean -- %f' failed 1
-error: external filter 'git-annex smudge --clean -- %f' failed
-FAIL (0.78s)
-    .\Test\Framework.hs:283:
-    foo is not a (crippled) symlink
-
-2 out of 2 tests failed (3.06s)
-FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    add extras:                                           FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    export_import:                                        FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    export_import_subdir:                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    shared clone:                                         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    log:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    import:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    reinject:                                             FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    unannex (no copy):                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    unannex (with copy):                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    drop (no remote):                                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    drop (with remote):                                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    drop (untrusted remote):                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    get:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    get (ssh remote):                                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    move:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    move (ssh remote):                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    copy:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    lock:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    lock (v7 --force):                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    edit (no pre-commit):                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    edit (pre-commit):                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    partial commit:                                       FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fix:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    direct:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    trust:                                                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (basics):                                        FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (bare):                                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (local untrusted):                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck (remote untrusted):                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    fsck --from remote:                                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    migrate:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    migrate (via gitattributes):                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    unused:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    describe:                                             FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    find:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    merge:                                                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    info:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    version:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    sync:                                                 FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    union merge regression:                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    adjusted branch merge regression:                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    adjusted branch subtree regression:                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution:                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (adjusted branch):                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution movein regression:                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (mixed directory and file):       FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution symlink bit:                      FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (uncommitted local file):         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (removed file):                   FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (nonannexed file):                FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (nonannexed symlink):             FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    conflict resolution (mixed locked and unlocked file): FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    map:                                                  FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    uninit:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    uninit (in git-annex branch):                         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    upgrade:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    whereis:                                              FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    hook remote:                                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    directory remote:                                     FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    rsync remote:                                         FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    bup remote:                                           FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    crypto:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    preferred content:                                    FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    add subdirs:                                          FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-    addurl:                                               FAIL
-      Exception: init tests failed! cannot continue
-      CallStack (from HasCallStack):
-        error, called at .\Test\Framework.hs:431:33 in main:Test.Framework
-
-132 out of 168 tests failed (13.35s)
-  (Failures above could be due to a bug in git-annex, or an incompatibility
-   with utilities, such as git, installed on this system.)
-.t\repo\.git\objects\f9\b6e5e36be4911f475c5a96dbc0c2c5d4b256af: removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:DeleteFile "\\\\?\\C:\\Users\\ilya\\.t\\repo\\.git\\objects\\f9\\b6e5e36be4911f475c5a96dbc0c2c5d4b256af": permission denied (Access is denied.)
-sleeping 10 seconds and will retry directory cleanup
-git-annex: .t\repo\.git\objects\f9\b6e5e36be4911f475c5a96dbc0c2c5d4b256af: removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:DeleteFile "\\\\?\\C:\\Users\\ilya\\.t\\repo\\.git\\objects\\f9\\b6e5e36be4911f475c5a96dbc0c2c5d4b256af": permission denied (Access is denied.)
-
-
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-
-> Confirmed that my silently fix fixed it, [[done]] --[[Joey]]
diff --git a/doc/bugs/test_suite_fails_on_windows/comment_1_1fcc64cfab4a9d9d215c85788db0e1db._comment b/doc/bugs/test_suite_fails_on_windows/comment_1_1fcc64cfab4a9d9d215c85788db0e1db._comment
deleted file mode 100644
index 169d47c2d2..0000000000
--- a/doc/bugs/test_suite_fails_on_windows/comment_1_1fcc64cfab4a9d9d215c85788db0e1db._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-08-07T17:14:22Z"
- content="""
-Just running "git-annex add" on a file on windows is enough to reproduce
-the bug.
-
-This must be related to ghc 8.6.1's change to Windows paths that made "NUL"
-not work, but git-annex has been using the device namespace workaround for
-nearly a year now.
-
-Presumably the recent upgrade of the windows autobuilder's toolchain
-exposed the problem. Maybe something had a reversion?
-
-In ghci 8.6.5, this works fine, no error:
-
-	withFile "\\\\.\\NUL" ReadMode (\h -> print "opened NUL ok")
-
-Need to try ghci Utility/Process.hs on windows and see if running
-`withNullHandle (const noop)` works.
-"""]]
diff --git a/doc/bugs/test_suite_fails_on_windows/comment_2_4e8d054e01ec9678d90e90f15b1da8a6._comment b/doc/bugs/test_suite_fails_on_windows/comment_2_4e8d054e01ec9678d90e90f15b1da8a6._comment
deleted file mode 100644
index 1bf02ba58b..0000000000
--- a/doc/bugs/test_suite_fails_on_windows/comment_2_4e8d054e01ec9678d90e90f15b1da8a6._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-08-07T21:20:58Z"
- content="""
-Tracked it back to runSqliteInfo. Both that and runSqlite use NUL
-somewhere.
-
-So the bug is in persistent-sqlite, or one of its dependencies.
-
-Aha! silently-1.2.5, used by persistent in runMigrationSilent,
-and it's already been fixed in a point release. I've bumped the dependency,
-hopefully that will fix this.
-"""]]
diff --git a/doc/bugs/test_suite_fails_on_windows/comment_3_e8ea2d2b744d1322ec8fa88af9a645c3._comment b/doc/bugs/test_suite_fails_on_windows/comment_3_e8ea2d2b744d1322ec8fa88af9a645c3._comment
deleted file mode 100644
index f9719cf413..0000000000
--- a/doc/bugs/test_suite_fails_on_windows/comment_3_e8ea2d2b744d1322ec8fa88af9a645c3._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 3"
- date="2019-08-12T20:15:01Z"
- content="""
-Could there be some point release to facilitate Windows getting a version with not broken dependency?  We are still experiencing tests failures while installing/using [https://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe](https://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe) which reports git annex 
-7.20190709-g15a972dd3.  Ref: https://ci.appveyor.com/project/mih/datalad/builds/26646252/job/yvrb8hxqjo4ly6v1
-
-"""]]
diff --git a/doc/bugs/the_assistant_fail_to_correctly_add_or_sync_ssh_remote_with_non_ascii_letter_in_the_directory.mdwn b/doc/bugs/the_assistant_fail_to_correctly_add_or_sync_ssh_remote_with_non_ascii_letter_in_the_directory.mdwn
deleted file mode 100644
index 12c8dc6c3a..0000000000
--- a/doc/bugs/the_assistant_fail_to_correctly_add_or_sync_ssh_remote_with_non_ascii_letter_in_the_directory.mdwn
+++ /dev/null
@@ -1,46 +0,0 @@
-### Please describe the problem.
-I've tried to setup a remote using assistant, but it failed to correctly sync apparently because there is a "è" in the directory
-
-### What steps will reproduce the problem?
-run the webapp
-use "Add another directory"
-then Remote Server
-add host name, user name password and directory as "Bibliothèque calibre" (to a repository that already exists)
-
-the remote is added as metadata only and the assistant will try to upload every file to it every time it is restarted.
-
-if a symlink is created named "calibre library", and is used instead, there is no problem.
-
-### What version of git-annex are you using? On what operating system?
-it is git-annex version: 5.20150916-1 on debian/sid
-
-### Please provide any additional information below.
-
-the log is full of:
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-ssh: Could not resolve hostname git-annex-toubib.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-volesprit.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-toubib.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-volesprit.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-toubib.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-sssh: Could not resolve hostname git-annex-toubib.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-volesprit.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-toubib.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-volesprit.lot-of-stuff.info-moi_22_biblioth%c3%a8que.20calibre: Name or service not known
-ssh: Could not resolve hostname git-annex-toubib.lot-of-stuff.info-moi_22_biblioth%c3%a8que.2ssh: Could not resolve hostname git-annex-volesprit.lot-of-stuff.info-m
-
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Adding remote that use only ascii letter work realy well with the webapp. 
-
-> I tried to reproduce this, but could now. (I made sure to try with LANG=C
-> as well as a unicode locale.
->
-> So, I think this must have been fixed in the 4 years since the bug was
-> filed. [[done]] --[[Joey]]
diff --git a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn
deleted file mode 100644
index 962466392b..0000000000
--- a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-### Please describe the problem.
-
-The new "tor onion server" setup function uses magic-wormhole to transfer the necessary keys and addresses (yay!). However it should really be using a distinct "app id". Magic-wormhole codes are scoped to a specific APPID, which means that someone using the normal CLI client (`wormhole send foo.jpg`) can get a wormhole code like "1-purple-kumquat", and someone doing a git-annex setup process can get a code like "1-green-mushroom", and they won't be competing with each other for the numeric channel-id.
-
-If magic-wormhole's file-transfer application got really popular, and there were thousands of simultaneous users, the file-transfer wormhole codes would grow to require three or four digits (e.g. "9134-purple-kumquat"), making them harder to type. But if git-annex uses a different APPID, then git-annex codes could continue to be short and easy, independent of contention for channel-ids on other applications.
-
-To tell magic-wormhole to use a different APPID, just do `wormhole --appid=$APPID send ...` or `wormhole --appid=$APPID receive ...`. APPIDs should be unique and scoped to an owner of some sort, so I'd recommend a DNS name or URL-shaped identifier, something like "git-annex.branchable.com/onion-setup". If you add a new distinct mode, one which doesn't interoperate with the current onion-setup mode, you can allocate a new APPID for that mode too (e.g. "git-annex.branchable.com/new-thing-setup").
-
-You'll have a compatibility hit when you land this: two applications using different APPIDs won't communicate, so e.g. git-annex before the patch won't do wormhole setups with git-annex after the patch.
-
-The --appid= feature was added in magic-wormhole 0.9.0, released 24-Dec-2016.
-
-### What steps will reproduce the problem?
-
-
-### What version of git-annex are you using? On what operating system?
-
-I haven't run git-annex's onion setup feature directly, but I'm reading through the source code from current git, cd8d905f3418b9c6a6c658a0c7256ae6f5066310, Utility/MagicWormhole.hs, and I don't see anything that adds an --appid argument. (I don't know Haskell at all, so I apologize if it's already doing --appid and I'm just not looking in the right place).
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-It looks pretty amazing! Looking forward to using it in a Dropbox-like synchronization context soon.
-
-> I've gone with the 2021-12-31 flag day approach. [[done]] --[[Joey]]
diff --git a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_1_d3b23b5bba991ea7b9b7c24f812a9018._comment b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_1_d3b23b5bba991ea7b9b7c24f812a9018._comment
deleted file mode 100644
index 46a54fb9f7..0000000000
--- a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_1_d3b23b5bba991ea7b9b7c24f812a9018._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-01-31T17:04:26Z"
- content="""
-Werner, I appreciate you filing this bug report. And I see magic-wormhole
-0.9.1 is now available in testing so it will be in the next debian stable
-release probably.
-
-If I'm going to make this change, I need to do it ASAP. If git-annex
-ships in Debian stable not using a wormhole app-id, then it pretty
-much is going to need to continue not using an app-id forever.
-(Which might not be a total disaster really; I don't know that a ton
-of users are using this feature..)
-
-The timeline for this is very tight now, unfortunately. (Pity that I have
-been traveling and missed this until now.) I'm not sure
-if, I released a git-annex today with this change, it would reach testing
-in time for the freeze. I've pinged Richih to try to figure that out.
-"""]]
diff --git a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_2_3f4693f6d877e2fcf4e62bd2b38a4472._comment b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_2_3f4693f6d877e2fcf4e62bd2b38a4472._comment
deleted file mode 100644
index 6c426001ef..0000000000
--- a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_2_3f4693f6d877e2fcf4e62bd2b38a4472._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-01-31T17:20:56Z"
- content="""
-
-based on this, we may have missed the window; there are 5 days until
-Debian freezes, and it takes 10 days to get a change into testing.
-
-It's still probably possible to get a change in, but it would need manual
-approval. Guess it would come down to whether I could get the change
-pre-approved for migration into Debian before releasing a git-annex
-with that change.
-
-(AFAIK Debian is the only distribution containing git-annex that's getting
-ready to freeze it.)
-"""]]
diff --git a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_3_882d915354ccd653f784499662544f31._comment b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_3_882d915354ccd653f784499662544f31._comment
deleted file mode 100644
index bbe424cb8d..0000000000
--- a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid/comment_3_882d915354ccd653f784499662544f31._comment
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2017-02-02T17:46:05Z"
- content="""
-After talking it over with the Debian maintainer, conclusion is
-we unfortunately missed the window to make this change.
-
-One way to still make the change would be to modify git-annex now to use an
-appid, but only once the date is after 31 Dec 2021 or so. So the change
-then has plenty of time to get into the subseqent Debian stable release
-(assuming the current release happens sometime in the next 1.5 years, and
-the one after that takes around the current average of 2 years), and also
-plenty of time to get into other faster moving distributions.
-
-That leaves a few years in which there's a risk that popularity of tor
-wormhole pairing snowballs. Currently I do think that's a low risk. 
-Most users of git-annex with tor will likely only pair with well under 10
-other repositories (it's too tedious to pair with more, and it starts
-not scaling well to have links to too many repositories). Pairing takes
-maybe 10 minutes max to do. So, each user will run wormhole for 100
-minutes max. For there to be a constant load of 100 users running wormhole,
-needs 3600 new users every day, or 1.3 million per year.
-"""]]
diff --git a/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem.mdwn b/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem.mdwn
deleted file mode 100644
index 3105f3aeff..0000000000
--- a/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-### Please describe the problem.
-
-Running `git annex init` on an [unRAID server](https://lime-technology.com/what-is-unraid/) results in an annex created with `crippledfilesystem = true` and `direct = true`. I understand from reading [this](https://git-annex.branchable.com/design/assistant/blog/day_188__crippled_filesystem_support/) that it occurs when `git annex init` performs a probe to determine if all of the following are supported:
-
-1. symlinks
-2. hard links
-3. unix permissions
-
-Although unRAID disks are formatted with xfs, and therefore support all three of the above, I'm assuming that unRAID's method of combining multiple disks into one "share" is the cause of the problem (hardlinks still work on a single disk, but not on shares that span multiple disks). Symlinks and unix permissions work normally in the unRAID-created shares.
-
-Is there any way to allow the use of 'indirect' mode with multi-disk shares? As I mentioned, symlinks and unix permissions work normally--it's only the hardlinks that won't work across the multi-disk shares.
-
-I can create a 'normal' annex as long as I `cd` to a single disk drive first--what would happen if the annex was later moved onto a multi-disk share? Would it still work? Would it fail gracefully? Would it cause data loss?
-
-### What steps will reproduce the problem?
-
-    cd /mnt/user/NameOfShare
-    git init
-    git annex init
-
-The following will result in the creation of a 'normal' indirect share:
-
-    cd /mnt/disk1
-    git init
-    git annex init
-
-### What version of git-annex are you using? On what operating system?
-
-    git-annex version: 6.20161211-gc3ab3c668
-    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
-    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
-    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Has been working great, so far, except for the above.
-
-> [[done]]; I think this just doesn't support permissions correcectly, and
-> there does not appear to be a git-annex bug. --[[Joey]]
diff --git a/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem/comment_1_3698dfec0b4b566b240da53d5e20ae5f._comment b/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem/comment_1_3698dfec0b4b566b240da53d5e20ae5f._comment
deleted file mode 100644
index 723bde6bf3..0000000000
--- a/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem/comment_1_3698dfec0b4b566b240da53d5e20ae5f._comment
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-06-06T19:28:18Z"
- content="""
-Lack of support for hard links does not make git-annex enable 
-crippled filesystem mode. Lack of support for either symlinks
-or unix permissions are the only things that cause that.
-
-I assume that you've checked that you can create symlinks on the UnRaid.
-
-Unix permissions may *seem* to work, eg they can be set. However, git-annex
-checks if they *actually* work, by creating a file, removing the write bit,
-and trying to write to it. If the write succeeds, the filesystem is not
-actually honoring permissions.
-
-Using git-annex in indirect mode with such a filesystem can
-result in data loss. For example:
-
-	git annex add foo
-	git commit foo -m added
-	echo corrupt > foo
-
-Here the echo follows the symlink to the single copy of the file in
-.git/annex/objects/ and ignoring the permissions that don't allow writing
-it it, overwrites it with other data. `git annex fsck` will then tell you
-that you've lost the old content of the file.
-
-So, I don't recommend trying to bypass git-annex's check for crippled
-filesystems.
-"""]]
diff --git a/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__.mdwn b/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__.mdwn
deleted file mode 100644
index 59cdc56fc8..0000000000
--- a/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__.mdwn
+++ /dev/null
@@ -1,121 +0,0 @@
-### Please describe the problem.
-
-Our http://datasets.datalad.org has been providing git annex repos, some of which with the content, via a "dummy" HTTP support of git.  For various reasons (performance, progress reporting by git upon clone) we want to switch to use [Smart HTTP](https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP) git-http-backend  backend.  Sample deployment is at http://datasets-dev.datalad.org/.
-I followed the docs to set it up and only added one more configuration tune up
-
-
-```
- RewriteEngine On
-
- RewriteCond  "%{HTTP_USER_AGENT}"  "(git)"
-
- RewriteRule ^(.*)$ "/git/$1" [PT]
-```
-
-so that people could still browse the website in the browser, but whenever `git` tries to access it, we direct to the `git-http-backend` CGI serving under `/git/` prefix (`ScriptAlias /git/ /usr/lib/git-core/git-http-backend/`).
-
-Everything seems to work nicely on git side, BUT I am having difficulty to make git-annex being able to serve annexed files from it:
- 
-### What version of git-annex are you using? On what operating system?
-
-6.20180913+git149-g23bd27773-1~ndall+1
-
-
-### Please provide any additional information below.
-
-[[!format sh """
-$> builtin cd /tmp/; rm -rf raiders; git clone http://datasets-dev.datalad.org/labs/haxby/raiders/ ; cd raiders; git annex get sub-rid000005/anat/sub-rid000005_run-01_T1w_defacemask.nii.gz                                                                                                                          Cloning into 'raiders'...                
-remote: Counting objects: 17926, done.
-remote: Compressing objects: 100% (7203/7203), done.
-remote: Total 17926 (delta 7356), reused 15517 (delta 6237)
-Receiving objects: 100% (17926/17926), 1.23 MiB | 6.53 MiB/s, done.
-Resolving deltas: 100% (7356/7356), done.
-README.md                 masks/       stimulus/       sub-rid000014/  sub-rid000028/  sub-rid000038/  task-raiders_bold.json
-dataset_description.json  scripts/     sub-rid000005/  sub-rid000015/  sub-rid000029/  sub-rid000042/
-derivatives/              sourcedata/  sub-rid000011/  sub-rid000020/  sub-rid000033/  sub-rid000043/
-(merging origin/git-annex into git-annex...)
-(recording state in git...)
-get sub-rid000005/anat/sub-rid000005_run-01_T1w_defacemask.nii.gz download failed: Not Found
-
-  Remote origin not usable by git-annex; setting annex-ignore
-(not available) 
-  Try making some of these repositories available:
-  	41e5039d-1750-43d2-8bea-89897d969326 -- /mnt/datasets/datalad/crawl/labs/haxby/raiders
-   	87d7db62-683d-43b2-b594-baeb420ae7a6 -- .
-   	afde6679-1f2f-41f2-935a-93e7e3d70274 -- nastase@head1:~/BIDS/haxby/raiders
-   	de53ce43-2c07-4971-8de8-0445c596f7dc -- datalad-public-ro
-
-  (Note that these git remotes have annex-ignore set: origin)
-failed
-(recording state in git...)
-git-annex: get: 1 failed
-"""]]
-
-fails because `config` file is under `.git/` subdirectory there and git-annex doesn't try to access it at all to deduce the uuid, thus marking origin as annex-ignore.
-
-But if I add that `.git` suffix to the url, then:
-
-[[!format sh """
-(git)hopa:/tmp/raiders[master]
-$> builtin cd /tmp/; rm -rf raiders; git clone http://datasets-dev.datalad.org/labs/haxby/raiders/.git/ ; cd raiders; git annex get sub-rid000005/anat/sub-rid000005_run-01_T1w_defacemask.nii.gz                                                                 
-Cloning into 'raiders'...
-remote: Counting objects: 17926, done.
-remote: Compressing objects: 100% (7203/7203), done.
-remote: Total 17926 (delta 7356), reused 15517 (delta 6237)
-Receiving objects: 100% (17926/17926), 1.23 MiB | 5.08 MiB/s, done.
-Resolving deltas: 100% (7356/7356), done.
-README.md                 masks/       stimulus/       sub-rid000014/  sub-rid000028/  sub-rid000038/  task-raiders_bold.json
-dataset_description.json  scripts/     sub-rid000005/  sub-rid000015/  sub-rid000029/  sub-rid000042/
-derivatives/              sourcedata/  sub-rid000011/  sub-rid000020/  sub-rid000033/  sub-rid000043/
-(merging origin/git-annex into git-annex...)
-(recording state in git...)
-get sub-rid000005/anat/sub-rid000005_run-01_T1w_defacemask.nii.gz (from origin...) 
-download failed: Not Found
-download failed: Not Found
-
-  Unable to access these remotes: origin
-
-  Try making some of these repositories available:
-  	41e5039d-1750-43d2-8bea-89897d969326 -- /mnt/datasets/datalad/crawl/labs/haxby/raiders
-   	87d7db62-683d-43b2-b594-baeb420ae7a6 -- .
-   	afde6679-1f2f-41f2-935a-93e7e3d70274 -- nastase@head1:~/BIDS/haxby/raiders
-   	de53ce43-2c07-4971-8de8-0445c596f7dc -- datalad-public-ro [origin]
-failed
-(recording state in git...)
-git-annex: get: 1 failed
-"""]]
-because it fails to find those two files under `.git/annex/objects`, here is apache log file
-
-
-```
-10.31.191.134 - - [01/Oct/2018:13:01:58 -0400] "GET /labs/haxby/raiders/.git//config HTTP/1.1" 206 501 "-" "-"
-
-10.31.191.134 - - [01/Oct/2018:13:01:58 -0400] "GET /labs/haxby/raiders/.git//annex/objects/Z8/f1/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz HTTP/1.1" 404 243 "-" "git-annex/6.20180913+git149-g23bd27773-1~ndall+1"
-
-10.31.191.134 - - [01/Oct/2018:13:01:58 -0400] "GET /labs/haxby/raiders/.git//annex/objects/681/5d0/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz HTTP/1.1" 404 243 "-" "git-annex/6.20180913+git149-g23bd27773-1~ndall+1"
-```
-
-where it seems to assume different layout:
-
-[[!format sh """
-$> ls -dl $webroot//labs/haxby/raiders/.git/annex/objects/*/*/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz
-drwxrwsr-x 1 yoh datalad 104 Sep 26  2016 /mnt/btrfs/manual-snapshots/srv-20180928/datasets.datalad.org/www///labs/haxby/raiders/.git/annex/objects/Z8/f1/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz/
-"""]]
-
-
-which git-annex assumes when working with the dummy HTTP:
-
-```
-10.31.191.134 - - [01/Oct/2018:13:09:53 -0400] "GET /labs/haxby/raiders/.git//config HTTP/1.1" 206 501 "-" "-"
-
-10.31.191.134 - - [01/Oct/2018:13:09:53 -0400] "GET /labs/haxby/raiders/.git//annex/objects/Z8/f1/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz/MD5E-s41438--06c245e709e7d40a90ed48c6c3b58295.nii.gz HTTP/1.1" 200 41679 "-" "git-annex/6.20180913+git149-g23bd27773-1~ndall+1"
-```
-
-So I wonder if I need to do something on my end in configuring apache2, or something could/should be done on git-annex side?  Ideally I would like to be able to just clone them without specifying `.git/` suffix to the url.
-
-But also note that `git-annex` seems to not even provide any agent value while trying to access `config` file:
-
-```
-10.31.191.134 - - [01/Oct/2018:13:12:45 -0400] "GET /labs/haxby/raiders/.git//config HTTP/1.1" 206 501 "-" "-"
-```
-[[fixed|done]] --[[Yarik]]
diff --git a/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__/comment_1_38e521eae22d333bd4d68dfcca6c4339._comment b/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__/comment_1_38e521eae22d333bd4d68dfcca6c4339._comment
deleted file mode 100644
index 1274ab8ede..0000000000
--- a/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__/comment_1_38e521eae22d333bd4d68dfcca6c4339._comment
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-10-04T17:52:43Z"
- content="""
-So your web server is behaving differently when the user-agent contains "git"
-than when it does not.
-
-I don't think that git-annex can possibly talk to the git-http-backend
-successfully, since that is only going to support whatever subset of the
-http protocol that git smart http needs, and probably does not serve up the
-annexed files at all. When I force the user agent to not contain "git", it works.
-
-(It does look like git-annex init did not pass a user-agent when getting
-the config file, but with git-annex head I've verified it does pass it.)
-
-That leaves only the difference between http://datasets-dev.datalad.org/labs/haxby/raiders/
-and http://datasets-dev.datalad.org/labs/haxby/raiders/.git/  
-Now, with dumb http the first url would not work; git does not probe for
-$url/.git or $url.git when cloning over dumb http.
-
-I'm not clear if somehing in your rewriting made that url work, or if
-git-http-backend finds the repository.
-"""]]
diff --git a/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__/comment_2_8e63433bee547e21b6f9e1d1932cccba._comment b/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__/comment_2_8e63433bee547e21b6f9e1d1932cccba._comment
deleted file mode 100644
index ece11fa409..0000000000
--- a/doc/bugs/unable_to_access_annexed_files_from_a_git_repo_website_serving_via___34__smart_HTTP__34__/comment_2_8e63433bee547e21b6f9e1d1932cccba._comment
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 2"
- date="2018-10-05T04:30:31Z"
- content="""
-ok... it helps to RTFM so I found the recommended way to host webcgi and the git-http-backend from the same site, just adjusted to not need `/git/` prefix:
-
-[[!format sh \"\"\"
- ScriptAliasMatch \
-        \"(?x)^/(.*/(HEAD | \
-                        info/refs | \
-                        .git/objects/(info/[^/]+ | \
-                                 [0-9a-f]{2}/[0-9a-f]{38} | \
-                                 pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
-                        git-(upload|receive)-pack))$\" \
-        /usr/lib/git-core/git-http-backend/$1
-\"\"\"]]
-
-So it seems that access with explicit `/.git` works now nicely with both git and git-annex.  Without `.git/` - only git works, I guess the same `config` access issue.  I guess `git-http-backend`, as any git command, can determine the root directory of the repository if invoked under .git or not.
-
-I've installed current HEAD of git-annex (6.20180926+git93-gdc47dfe90... you don't have that commit since I am still carrying that LOCPATH patch for neurodebian) - indeed this one has user-agent reflected... probably could craft a rewrite rule for git-annex agent some time
-
-"""]]
diff --git a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn
deleted file mode 100644
index fdb47b1a6c..0000000000
--- a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn
+++ /dev/null
@@ -1,84 +0,0 @@
-### Please describe the problem.
-
-A bup remote has lost its UUID, even though it is defined in git's `config` file.
-
-### What steps will reproduce the problem?
-
-`cat config` gives
-[[!format sh """
-[core]
-        repositoryformatversion = 0
-        filemode = true
-        bare = true
-        logallrefupdates = false
-        preloadIndex = true
-        untrackedCache = true
-[annex]
-        uuid = b67bfb7e-3ae1-4cb5-be1c-44cd07a6724b
-        version = 7
-[filter "annex"]
-        smudge = git-annex smudge %f
-        clean = git-annex smudge --clean %f
-[remote "holy-server-backup"]
-        annex-buprepo = /media/pi/DiStephBackup/backup
-        annex-uuid = 3af6c3c4-973a-481e-82d0-bfc15bff6f30
-        annex-sync = false
-[...]
-"""]]
-
-but `git annex info holy-server-backup` has forgotten the uuid (and the description), giving
-
-[[!format sh """
-uuid: 
-description: 
-remote: holy-server-backup
-trust: semitrusted
-cost: 110.0
-type: bup
-repo: /media/pi/DiStephBackup/backup
-encryption: none
-chunking: none
-[...]
-"""]]
-
-Unsurprisingly, commands such as `git annex get --all --from=holy-server-backup` complain with
-
-`git-annex: cannot determine uuid for holy-server-backup (perhaps you need to run "git annex sync"?)`
-
-This has happened after I started using version 7 upgraded from version 6 (with `git annex upgrade`). Before then it was working like a charm.
-And now I cannot revert to version 6...
-
-I'm not sure where version 7 is trying to get the UUID from, if not from the git config file, and why there started to be a discrepancy.
-
-
-### What version of git-annex are you using? On what operating system?
-
-git-annex version: 7.20181106-g352f88226, standalone
-
-[[!format sh """
-operating system: linux arm
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-"""]]
-
-
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-
-# End of transcript or log.
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Yes, I love git-annex! has been helping me manage my files for years!
-
-> As far as I can see, this is either user error having removed the
-> annex.uuid config from the bup repo somehow, or something other than
-> git-annex did it, or perhaps the bup repo that was initialized for use
-> with this remote has since been replaced by another bup repo. No
-> indication that this is a bug in git-annex so [[done]]. --[[Joey]]
diff --git a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_1_1a26474498c3683c4b1a7d41cd3f7ed2._comment b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_1_1a26474498c3683c4b1a7d41cd3f7ed2._comment
deleted file mode 100644
index fb3473bf7c..0000000000
--- a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_1_1a26474498c3683c4b1a7d41cd3f7ed2._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-04T16:59:53Z"
- content="""
-I doubt this has anything to do with v7, it made no changes in this area.
-I've verified that git-annex's bup support is still working.
-
-git-annex embeds a uuid into a bup repository, so the annex-uuid listed in
-the git-annex repo's .git/config is only a cache of the last seen uuid. So
-it seems that, when git-annex tries to read the uuid from your bup
-repository, it's not finding anything.
-
-In your bup repository's git config file, there should be an annex.uuid
-setting. It seems that you've somehow lost that. There's no way git-annex
-would remove it. You can of course run 
-"git config annex.uuid 3af6c3c4-973a-481e-82d0-bfc15bff6f30" in the bup
-repository to add it back, if you're sure that the bup repository is the
-same one git-annex was using before.
-"""]]
diff --git a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_2_1f876aeaf770e6933f03de60c471eb8c._comment b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_2_1f876aeaf770e6933f03de60c471eb8c._comment
deleted file mode 100644
index 2f23776b1b..0000000000
--- a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_2_1f876aeaf770e6933f03de60c471eb8c._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="StéphaneGL"
- avatar="http://cdn.libravatar.org/avatar/a12e6e0852d5a1985b8684b17202561c"
- subject="comment 2"
- date="2018-12-05T22:58:57Z"
- content="""
-Thanks for the prompt reply! Yes, you're right, it's the config file in the bup repo that was corrupted, for some reason. I hadn't thought running git-annex in the other repo would get the bup UUID from the bup's config file and not the local one. All works like a charm! Thanks again!
-"""]]
diff --git a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size.mdwn b/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size.mdwn
deleted file mode 100644
index 3acf63831f..0000000000
--- a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-### Please describe the problem.
-
-After unlocking a repository, the next git status will take time linear to the file size. It seems to be highly inefficient (the I/O on my SSD is not anywhere near the limit).  
-For a 500Mb flac album it takes ~5–10s, for my 100GB local music archive it took well over 30min.
-
-### What steps will reproduce the problem?
-
-```
-git annex upgrade
-git annex unlock
-git status / git add -A
-```
-
-### What version of git-annex are you using? On what operating system?
-
-6.20160527  
-NixOS (master branch)
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Not yet. :)  
-But will use it to keep my music library and sync a smaller (ogg) version to my various devices (with beets handling metadata and conversion)
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_1_ea798d60cbdfa7534bad0ba47119379d._comment b/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_1_ea798d60cbdfa7534bad0ba47119379d._comment
deleted file mode 100644
index 2ebcf375e3..0000000000
--- a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_1_ea798d60cbdfa7534bad0ba47119379d._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="mail@4e627fd997ef5ca9f75e62ffc0aba5b27bd6aea1"
- nickname="mail"
- subject="comment 1"
- date="2016-06-19T16:27:15Z"
- content="""
-I noticed after filing the bug that the first `git commit` takes as much (or even more!) time as the `git add -A` before it.  
-So you pay overhead twice somehow.
-"""]]
diff --git a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_2_7efc9b056b88fc7a75309a80445b5102._comment b/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_2_7efc9b056b88fc7a75309a80445b5102._comment
deleted file mode 100644
index 43f9b37af5..0000000000
--- a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_2_7efc9b056b88fc7a75309a80445b5102._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2016-07-06T18:56:04Z"
- content="""
-This problem is dicussed in detail in [[todo/smudge]] and is the main
-reason that v6 mode is not production ready.
-
-I have patches to git that avoid this problem.
-"""]]
diff --git a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_3_910399daee8c9ad9909068a23f0eb5c9._comment b/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_3_910399daee8c9ad9909068a23f0eb5c9._comment
deleted file mode 100644
index b98157be16..0000000000
--- a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_3_910399daee8c9ad9909068a23f0eb5c9._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="ynikitenko"
- avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
- subject="same problem"
- date="2017-10-24T09:31:06Z"
- content="""
-When could that be fixed? 
-
-I face the same problem. My repo is only about 2Gb, but it syncs quite slow (like minutes or tens of minutes, but with every smallest change that I want to be synced). I don't want to use other than version 6 and thin to save space, but it takes much time. 
-
-For another repo of 100 thousand files (though 2.6Gb) git-annex commit did not even work (I killed that after about 20 hours of work - it loaded the machine, created a lot of files (twice the size of the repo), but did not stop in that time).
-"""]]
diff --git a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_4_c005382360247da300d5e274d62bf19a._comment b/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_4_c005382360247da300d5e274d62bf19a._comment
deleted file mode 100644
index c81bf7a6c6..0000000000
--- a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_4_c005382360247da300d5e274d62bf19a._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="ynikitenko"
- avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
- subject="not so slow"
- date="2017-10-27T12:29:08Z"
- content="""
-I'd like to add to my previous comment that now git-annex works pretty well with the same repository (I mean the one that I was able to build and which I use). 
-
-I don't know why that happened and why that was slow before. 
-"""]]
diff --git a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_5_7c785f07f73ddbcf316fa6144b727375._comment b/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_5_7c785f07f73ddbcf316fa6144b727375._comment
deleted file mode 100644
index 41c2b7588c..0000000000
--- a/doc/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/comment_5_7c785f07f73ddbcf316fa6144b727375._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2017-10-30T17:12:00Z"
- content="""
-IIRC once git checks the work tree file one time and realizes it's not
-really changed, it then avoids the unncessarily expensive operation
-happening again.
-
-These inneficiencies can't be fixed without changes to git. It's all
-discussed in [[todo/smudge]] in detail.
-"""]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded.mdwn b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded.mdwn
deleted file mode 100644
index a7c01972b2..0000000000
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded.mdwn
+++ /dev/null
@@ -1,35 +0,0 @@
-### Please describe the problem.
-
-With a v6 repo, if I unlock an annex file, change it, and then add it back, the annex object is writeable.
-
-### What steps will reproduce the problem?
-
-    git init tmp-v6 && cd tmp-v6
-    git annex init --version=6
-    echo foo >foo && git annex add foo && git commit -m'add foo'
-    git annex unlock foo
-    echo more >>foo && git annex add foo && git commit -m'modify foo'
-    ls -l $(readlink foo)
-    # -rw-r--r-- 1 kyle kyle 9 Aug 29 17:18 .git/annex/objects/60/QW/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d
-
-### What version of git-annex are you using? On what operating system?
-
-    git annex version
-
-    # git-annex version: 6.20180808-gdad627fa9
-    # build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Testsuite
-    # dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
-    # key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-    # remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-    # operating system: linux x86_64
-    # supported repository versions: 3 5 6
-    # upgrade supported from repository versions: 0 1 2 3 4 5
-    # local repository version: 6
-
-Debian Stretch, but building git-annex from source with `stack build`.
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Yes, everyday.  Thank you for git-annex :-)
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_1_663a9b9a1bd7846d79e35be8fb0be97b._comment b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_1_663a9b9a1bd7846d79e35be8fb0be97b._comment
deleted file mode 100644
index 29ecffdd9e..0000000000
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_1_663a9b9a1bd7846d79e35be8fb0be97b._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-08-30T15:00:39Z"
- content="""
-Hmm, I don't reproduce this here.
-
-Also AFAIK there is no difference in the code path used here
-to move a file into the annex between v5 and v6. Does it happen with v5?
-
-Seems there is either something in your environment (umask, core.sharedRepository
-git config etc though I don't think any of those would explain this
-particular file mode) or the build on stretch is somehow behaving differently.
-"""]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_2_066cc775495fc4eb0b054b3737f20d5a._comment b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_2_066cc775495fc4eb0b054b3737f20d5a._comment
deleted file mode 100644
index 9412b4793d..0000000000
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_2_066cc775495fc4eb0b054b3737f20d5a._comment
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="confirming"
- date="2018-08-30T15:57:39Z"
- content="""
-just wanted to say that I see the same (thanks Kyle for copy/pasteable example):
-
-[[!format sh \"\"\"
-$> git init tmp-v6 && cd tmp-v6
-git annex init --version=6     
-echo foo >foo && git annex add foo && git commit -m'add foo'
-git annex unlock foo                                        
-echo more >>foo && git annex add foo && git commit -m'modify foo'
-ls -l $(readlink foo)                                            
-Initialized empty Git repository in /tmp/tmp-v6/.git/
-init  ok
-(recording state in git...)
-add foo ok
-(recording state in git...)
-[master (root-commit) 19d9427] add foo
- 1 file changed, 1 insertion(+)
- create mode 120000 foo
-unlock foo ok
-(recording state in git...)
-add foo ok
-(recording state in git...)
-[master 9a2a079] modify foo
- 1 file changed, 1 insertion(+), 1 deletion(-)
--rw------- 1 yoh yoh 9 Aug 30 11:52 .git/annex/objects/60/QW/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d
-
-$> umask
-077
-
-$> git annex version  
-git-annex version: 6.20180807+git142-g1a08a8613-1~ndall+1
-
-\"\"\"]]
-
-tried with umask 022 - the same
-"""]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_3_755c9123c3d1c627aca51932c121bdc5._comment b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_3_755c9123c3d1c627aca51932c121bdc5._comment
deleted file mode 100644
index d4f9ac7c68..0000000000
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_3_755c9123c3d1c627aca51932c121bdc5._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="reproduced more"
- date="2018-08-30T16:02:39Z"
- content="""
-tried across a number of boxes, and other users, and older git-annex -- the same effect everywhere.
-The common denominator - I was using neurodebian build (will check next)
-"""]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_4_7e741ba5998cbc707951bf5dfc50479f._comment b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_4_7e741ba5998cbc707951bf5dfc50479f._comment
deleted file mode 100644
index c4ddbfef4a..0000000000
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_4_7e741ba5998cbc707951bf5dfc50479f._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="kyle"
- avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
- subject="v5"
- date="2018-08-30T16:05:01Z"
- content="""
-> Also AFAIK there is no difference in the code path used here to move a file into the annex between v5 and v6. Does it happen with v5?
-
-No, it doesn't: 
-
-    -r--r--r-- 1 kyle kyle 9 Aug 29 17:02 .git/annex/objects/60/QW/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d
-"""]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_5_d40df34ebcb2f3e1610c7b85bd3ef4e3._comment b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_5_d40df34ebcb2f3e1610c7b85bd3ef4e3._comment
deleted file mode 100644
index a7d4f03114..0000000000
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_5_d40df34ebcb2f3e1610c7b85bd3ef4e3._comment
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="clear docker for ubuntu 18:04 - the same"
- date="2018-08-30T16:07:51Z"
- content="""
-[[!format sh \"\"\"
-root@6f7d56840b4b:/tmp/tmp-v6# ls -l $(readlink foo)
--rw-r--r-- 1 root root 9 Aug 30 16:06 .git/annex/objects/60/QW/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d
-root@6f7d56840b4b:/tmp/tmp-v6# history
-    1  apt-get update -qqq
-    2  apt-get install -t eatmydata
-    3  apt-get install -y eatmydata
-    4  eatmydata apt-get install -y git-annex
-    5  cd /tmp
-    6  git init tmp-v6 && cd tmp-v6
-    7  git annex init --version=6
-    8  echo foo >foo && git annex add foo && git commit -m'add foo'
-    9  git annex unlock foo
-   10  echo more >>foo && git annex add foo && git commit -m'modify foo'
-   11  ls -l $(readlink foo)
-   12  history
-root@6f7d56840b4b:/tmp/tmp-v6# git annex version
-git-annex version: 6.20180227
-\"\"\"]]
-"""]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_6_2d3e926459c04c6a9a2c5a43ee9733e4._comment b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_6_2d3e926459c04c6a9a2c5a43ee9733e4._comment
deleted file mode 100644
index 3db37eee6b..0000000000
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_6_2d3e926459c04c6a9a2c5a43ee9733e4._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2018-09-05T18:26:33Z"
- content="""
-Reproduced.
-
-Analysis: In v6, `git annex add` runs `git ls-files --modified`, 
-which runs the clean filter on the unlocked file as git sees it was
-modified. Which in ingests the file with lockingFile = False.
-So, the annex object doesn't get the write bit cleared at that point.
-Then when `git annex add` gets around to ingesting the file
-itself, since the annex object is already present it's used as-is.
-
-`git add` of a new file in v6 also puts content in the annex
-with the write bit set. If a different file with that same content is then passed
-to `git annex add`, the same thing happens with the symlink to unprotected
-content.
-
-So, linkToAnnex should freezeContent. That would solve all cases that lead
-to this. (But not when annex.thin has made the annex object a hard link,
-in that case it being writable is expected.)
-"""]]
diff --git a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning.mdwn b/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning.mdwn
deleted file mode 100644
index c3c0570374..0000000000
--- a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning.mdwn
+++ /dev/null
@@ -1,381 +0,0 @@
-### Please describe the problem.
-
-Can't find an approach to file permissions mode to get thin v6 annex repo to hold no second copies.
-
-I realize that hardlinks work in such a way that all links have same permissions mode. The issue is, which mode for files I should set to always get hardlinks?
-`git-annex` seems to prefer 555 for `.git/annex/objects/` files, but appears it can create e.g. 644 when copying from remote.
-`git` remembers file modes as either 755 or 644, so after `git annex lock; git annex unlock` cycle or `git annex fix` no file is hardlinked if `.git/annex/objects/` file mode is 555.
-
-### What steps will reproduce the problem?
-
-* Create a new git-annex repo. v6, thin.
-* Create few files with same content but different perms (e.g. 555, 755, 644).
-* Add and commit these files to annex.
-* Observe that in this repo, 0555-mode file is hardlinked.
-* Clone this repo
-* Init annex in the second repo to also be v6 thin.
-* Fetch the annex files to second repo.
-* Observe that in the new repo, 0644-mode file is hardlinked.
-* Try to figure out which permissions to use across the repo to always have hardlinks.
-
-### What version of git-annex are you using? On what operating system?
-
-6.20180926. Gentoo Linux. Manually corrected ebuild based on the one in `haskell` overlay.
-
-### Please provide any additional information below.
-
-[[!format sh """
- $ git init annex_perm_issue
-Initialized empty Git repository in /home/j/annex_perm_issue/.git/
-[OK]
-21:44:11 Wed 17 Oct j@undo-autkin ~
- $ cd annex_perm_issue
-[OK]
-21:44:13 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ git annex init --version=6
-init  ok
-(recording state in git...)
-[OK]
-21:45:09 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls
-[OK]
-21:45:12 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ v 755
-[OK]
-21:45:25 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ cp 755 644
-[OK]
-21:45:32 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ cp 755 555
-[OK]
-21:45:36 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ chmod 755 755
-[OK]
-21:45:42 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ chmod 555 555
-[OK]
-21:45:45 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ chmod 644 644
-[OK]
-21:45:50 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--r-xr-xr-x. 1 j j 5 Oct 17 21:45 555
--rw-r--r--. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:45:52 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ md5sum *
-d8e8fca2dc0f896fd7cb4cb0031ba249  555
-d8e8fca2dc0f896fd7cb4cb0031ba249  644
-d8e8fca2dc0f896fd7cb4cb0031ba249  755
-[OK]
-21:46:00 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ git config annex.thin true
-[OK]
-21:47:08 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ g add *
-[OK]
-21:47:17 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--r-xr-xr-x. 2 j j 5 Oct 17 21:45 555
--rw-r--r--. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:47:20 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ g su
-On branch master
-
-No commits yet
-
-Changes to be committed:
-  (use "git rm --cached ..." to unstage)
-
-        new file:   555
-        new file:   644
-        new file:   755
-
-Untracked files not listed (use -u option to show untracked files)
-[OK]
-21:47:23 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ g ci -m 'adding all'
-(recording state in git...)
-[master (root-commit) d03ede4] adding all
- 3 files changed, 3 insertions(+)
- create mode 100755 555
- create mode 100644 644
- create mode 100755 755
-[OK]
-21:48:16 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--r-xr-xr-x. 2 j j 5 Oct 17 21:45 555
--rw-r--r--. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:48:20 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l .git/annex/objects/
-total 4
-drwxr-xr-x. 3 j j 4096 Oct 17 21:47 w8
-[OK]
-21:48:33 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l .git/annex/objects/w8/
-total 4
-drwxr-xr-x. 3 j j 4096 Oct 17 21:47 pv
-[OK]
-21:48:34 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l .git/annex/objects/w8/pv/
-total 4
-dr-xr-xr-x. 2 j j 4096 Oct 17 21:47 SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-[OK]
-21:48:35 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--r-xr-xr-x. 2 j j 5 Oct 17 21:45 555
--rw-r--r--. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:49:41 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ git annex lock .
-lock 555 ok
-lock 644 ok
-lock 755 ok
-(recording state in git...)
-[OK]
-21:49:45 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
-lrwxrwxrwx. 1 j j 178 Oct 17 21:45 555 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-lrwxrwxrwx. 1 j j 178 Oct 17 21:45 644 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-lrwxrwxrwx. 1 j j 178 Oct 17 21:45 755 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-[OK]
-21:49:47 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ git annex unlock .
-unlock 555 ok
-unlock 644 ok
-unlock 755 ok
-(recording state in git...)
-[OK]
-21:49:52 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 555
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:49:53 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ git annex fix .
-fix 555 ok
-fix 644 ok
-fix 755 ok
-[OK]
-21:50:01 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 555
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:50:02 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/
-total 4
--r-xr-xr-x. 1 j j 5 Oct 17 21:45 SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-[OK]
-21:50:08 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ git show | cat
-commit d03ede4f1a8b2ba3967a9aae005030cea408e3a5
-Author: Andrey Utkin 
-Date:   Wed Oct 17 21:48:16 2018 +0100
-
-    adding all
-
-diff --git a/555 b/555
-new file mode 100755
-index 0000000..db80da6
---- /dev/null
-+++ b/555
-@@ -0,0 +1 @@
-+/annex/objects/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-diff --git a/644 b/644
-new file mode 100644
-index 0000000..db80da6
---- /dev/null
-+++ b/644
-@@ -0,0 +1 @@
-+/annex/objects/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-diff --git a/755 b/755
-new file mode 100755
-index 0000000..db80da6
---- /dev/null
-+++ b/755
-@@ -0,0 +1 @@
-+/annex/objects/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-[OK]
-21:50:30 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ cd ..
-[OK]
-21:55:23 Wed 17 Oct j@undo-autkin ~
- $ g clone ~/annex_perm_issue/ ~/annex_perm_issue.clone
-Cloning into '/home/j/annex_perm_issue.clone'...
-done.
-[OK]
-21:55:35 Wed 17 Oct j@undo-autkin ~
- $ cd ~/annex_perm_issue.clone
-[OK]
-21:55:37 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git annex status
-[OK]
-21:55:53 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 555
--rw-r--r--. 1 j j 92 Oct 17 21:55 644
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 755
-[OK]
-21:55:55 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git annex init
-init  ok
-(recording state in git...)
-[OK]
-21:56:07 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 555
--rw-r--r--. 1 j j 92 Oct 17 21:55 644
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 755
-[OK]
-21:56:10 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git annex copy --to=here --all
-copy SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2 (from origin...) (checksum...) ok
-(recording state in git...)
-[OK]
-21:56:40 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 555
--rw-r--r--. 1 j j 92 Oct 17 21:55 644
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 755
-[OK]
-21:56:43 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git annex fix .
-[OK]
-21:56:48 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 555
--rw-r--r--. 1 j j 92 Oct 17 21:55 644
--rwxr-xr-x. 1 j j 92 Oct 17 21:55 755
-[OK]
-21:56:49 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ cat 555
-/annex/objects/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-[OK]
-21:56:56 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git annex version
-git-annex version: 6.20180926
-build flags: Assistant Webapp Pairing WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
-dependency versions: bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.0.1 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.4
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-local repository version: 5
-[OK]
-21:57:42 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git annex upgrade
-upgrade (v5 to v6...) (scanning for unlocked files...)
-ok
-[OK]
-21:57:47 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 555
--rw-r--r--. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:57:50 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git config annex.thin true
-[OK]
-21:57:57 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 555
--rw-r--r--. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:58:03 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ git annex fix .
-fix 555 ok
-fix 644 ok
-[OK]
-21:58:06 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 555
--rw-r--r--. 2 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-21:58:07 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ ls -l .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/
-total 4
--rw-r--r--. 2 j j 5 Oct 17 21:45 SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-[OK]
-21:58:24 Wed 17 Oct j@undo-autkin ~/annex_perm_issue.clone
- $ cd ../annex_perm_issue
-[OK]
-22:00:07 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 555
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-22:00:11 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/
-total 4
--r-xr-xr-x. 1 j j 5 Oct 17 21:45 SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-[OK]
-22:00:18 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ chmod 555 *
-[OK]
-22:00:43 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--r-xr-xr-x. 1 j j 5 Oct 17 21:45 555
--r-xr-xr-x. 1 j j 5 Oct 17 21:45 644
--r-xr-xr-x. 1 j j 5 Oct 17 21:45 755
-[OK]
-22:00:44 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ g su
-On branch master
-Changes to be committed:
-  (use "git reset HEAD ..." to unstage)
-
-        modified:   644
-
-Untracked files not listed (use -u option to show untracked files)
-[OK]
-22:00:46 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ g annex fix .
-fix 555 ok
-fix 644 ok
-fix 755 ok
-[OK]
-22:01:06 Wed 17 Oct j@undo-autkin ~/annex_perm_issue
- $ ls -l
-total 12
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 555
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 644
--rwxr-xr-x. 1 j j 5 Oct 17 21:45 755
-
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-lil' positive end note mode on:
-
-git-annex is the only thing to which I trust my archive of most valuable documents and memories!
-
-> [[done]]; see comments --[[Joey]]
diff --git a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_1_029e49d631afad4e2a76f3082d20f20e._comment b/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_1_029e49d631afad4e2a76f3082d20f20e._comment
deleted file mode 100644
index 5f3ef2c292..0000000000
--- a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_1_029e49d631afad4e2a76f3082d20f20e._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="andrey_utkin@49e37627b3060c40292113d73d7ffbf317233e62"
- nickname="andrey_utkin"
- avatar="http://cdn.libravatar.org/avatar/95bb7f4f7647cc24c1cf635b61578842"
- subject="comment 1"
- date="2018-10-17T22:07:15Z"
- content="""
-Have just repeated same commands in a new release 6.20181011, same behaviour.
-"""]]
diff --git a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_2_6c6ed937660b6f19829362c2c2cb4991._comment b/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_2_6c6ed937660b6f19829362c2c2cb4991._comment
deleted file mode 100644
index dbe7e8921e..0000000000
--- a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_2_6c6ed937660b6f19829362c2c2cb4991._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-10-18T19:45:15Z"
- content="""
-When two files have the same content, annex.thin will only make one of them
-be a hard link to the annex object. The other file will have its own
-redundant copy of the content. This is the only way to prevent an edit to
-one file immediatly changing the other file, which would be very surprising
-behavior.
-
-When the file in git has the executable bit set, annex.thin is not honored
-for that file either. That's a lot simpler than juggling permissions
-around.
-
-Does that explain everything you're seeing, or is there still a bug buried
-in that transcript? I have not had time to read the whole thing.
-"""]]
diff --git a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_3_cbe7f29914091bc9de49dab8f4ed6003._comment b/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_3_cbe7f29914091bc9de49dab8f4ed6003._comment
deleted file mode 100644
index 7c89cfe3dd..0000000000
--- a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_3_cbe7f29914091bc9de49dab8f4ed6003._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="andrey_utkin@49e37627b3060c40292113d73d7ffbf317233e62"
- nickname="andrey_utkin"
- avatar="http://cdn.libravatar.org/avatar/95bb7f4f7647cc24c1cf635b61578842"
- subject="comment 3"
- date="2018-10-18T20:18:01Z"
- content="""
-> When two files have the same content, annex.thin will only make one of them be a hard link to the annex object. The other file will have its own redundant copy of the content. This is the only way to prevent an edit to one file immediatly changing the other file, which would be very surprising behavior.
-
-Ah, that explains my biggest confusion. Thanks!
-
-> When the file in git has the executable bit set, annex.thin is not honored for that file either. That's a lot simpler than juggling permissions around.
-
-Ok, I will take a note. But was it this way from the very beginning, or is this a later-added idea? From my observations, this is not true. I do have a large annex repo, I have done a global `chmod -R u=rwx,g=rx,o=rx *`, all my files have exec bit set and all of them are hardlinked (except for the files which are duplicates of other hardlinked files). I don't remember for sure, it might be that I've chmod-ed files in .git/annex/objects as well :)
-"""]]
diff --git a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_4_41478c52765cf09a94c7137437ad8716._comment b/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_4_41478c52765cf09a94c7137437ad8716._comment
deleted file mode 100644
index 533c94dad4..0000000000
--- a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_4_41478c52765cf09a94c7137437ad8716._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="andrey_utkin@49e37627b3060c40292113d73d7ffbf317233e62"
- nickname="andrey_utkin"
- avatar="http://cdn.libravatar.org/avatar/95bb7f4f7647cc24c1cf635b61578842"
- subject="comment 4"
- date="2018-10-18T23:34:26Z"
- content="""
-
-I am stupid talking about executable files hardlinking. I think I just chmod-ed already hardlinking files, that's how I got it. No surprise.
-
-I am ok with this quirk (executable files are not thinned), but just curious: what exactly influenced such design decision?
-"""]]
diff --git a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_5_2b36163f3c8cca18ce4b05e381bf1795._comment b/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_5_2b36163f3c8cca18ce4b05e381bf1795._comment
deleted file mode 100644
index 5caf7d5038..0000000000
--- a/doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_5_2b36163f3c8cca18ce4b05e381bf1795._comment
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2018-10-26T17:17:35Z"
- content="""
-[[!commit b7c8bf5274a64389ac87d6ce0388b8708c261971]] is where that was
-implemented. Interestingly, its commit message does say that the annex
-object file is made executable when using annex.thin.
-And indeed, git add of an executable file with annex.thin set does
-make the object executable and hard link to it.
-
-But that commit contains this line that avoids hard linking:
-
-	        | maybe False isExecutable destmode = copy =<< getstat
-
-Which is what I based my earlier comment on. But without that line,
-AFAIK it will behave the way you want, with the annex object and
-executable worktree file being hard linked. The code also removes the
-execute bit if the annex object file later ends up getting hard linked
-instead to a non-executable file.
-
-So, based on this analysis, I'm going to remove that line. And improve the
-annex.thin docs slightly, and I think that's sufficient to close this bug.
-"""]]
diff --git a/doc/bugs/v6_smudge_filter_breaks_git_diff_for_files_outside_the_repository.mdwn b/doc/bugs/v6_smudge_filter_breaks_git_diff_for_files_outside_the_repository.mdwn
deleted file mode 100644
index 54e70ea0fb..0000000000
--- a/doc/bugs/v6_smudge_filter_breaks_git_diff_for_files_outside_the_repository.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-### Please describe the problem.
-
-`git annex upgrade` to v6 configures a filter using `git-annex smudge`. With it, `git diff` can't be run on files external to the repository, without getting a lot of stderr output like:
-
-    fatal: '../test.txt' is outside repository
-    error: external filter 'git-annex smudge --clean %f' failed 1
-
-This breaks vim-gitgutter signs, and possibly other tools as well.
-
-
-### What steps will reproduce the problem?
-
-[[!format sh """
-$ git init test
-$ cd test
-$ git annex init
-$ git annex upgrade
-$ git diff ../file1.txt ../file2.txt
-"""]]
-
-
-### What version of git-annex are you using? On what operating system?
-
-6.20180913-1~bpo9+1 on Debian Stretch + backports.
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/v6_smudge_filter_breaks_git_diff_for_files_outside_the_repository/comment_1_b2a895188e4f3e680586289667a6696d._comment b/doc/bugs/v6_smudge_filter_breaks_git_diff_for_files_outside_the_repository/comment_1_b2a895188e4f3e680586289667a6696d._comment
deleted file mode 100644
index 6827b184ad..0000000000
--- a/doc/bugs/v6_smudge_filter_breaks_git_diff_for_files_outside_the_repository/comment_1_b2a895188e4f3e680586289667a6696d._comment
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-11-15T16:50:16Z"
- content="""
-git diff is running the smudge --clean filter, and there are two different
-cases when it comes to git-annex's filter.
-
-If the user is for some reason using git to diff two files that are both
-located outside the repository, the thing to do is clearly to pass them
-both through the clean filter unchanged. That way the actual text of the
-files will be diffed, not the pointer file the clean filter would usually
-provide.
-
-OTOH, the user may be diffing an annexed file located in the git repo
-with a file outside the repo. If the smudge filter generates a pointer for
-the file inside the repo, and not for outside, then the diff between the
-pointer and the actual content of the other file will not be useful.
-
-Unfortunately, the interface doesn't let git-annex distinguish between
-these scenarios, since the filter is run on one file at a time.
-It also doesn't make much sense for the clean filter to actually ingest a
-file located outside the repo into the annex.
-
-So it seems the best that can be done is for the clean filter to
-pass through the content of files located outside the repo. At least
-avoiding error messages and unwanted ingestion, but not generating a useful
-diff in the second case. And this is the approach I've implemented.
-
-Another way to look at it is, git diff displays a diff of the data that
-actually gets checked into git. Diffing two worktree files that are both
-annexed results in a not very useful diff between two pointer files. So
-it's consistent that diffing between a worktree file and an out-of-worktree
-file results in a not very useful diff between a pointer file and the later
-file's content. This is also consitent with how git diff works
-with git-annex symlinks.
-"""]]
diff --git a/doc/bugs/v6_unlock_confused_by_touch.mdwn b/doc/bugs/v6_unlock_confused_by_touch.mdwn
deleted file mode 100644
index d7abddede3..0000000000
--- a/doc/bugs/v6_unlock_confused_by_touch.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-Touching a locked file in a v6 repository follows the symlink and touches
-the object file. This makes inAnnex's sameInodeCache fail because the keys
-database has a different mtime cached, and so `git annex unlock` doesn't
-populate the file with content, but with a pointer file.
-
-Also, `git annex` fsck complains no copies exist even though the symlink is
-pointing at a copy.
-
-This seems another reason to not check sameInodeCache for locked content,
-along with
-
---[[Joey]]
-
-Note that after initial  `git annex add` into a v6 repository, the keys
-database does not have an inode cached. But after an unlock followed by a
-lock, it does. So, here's a complete reproducer:
-
-	git annex init --version=6
-	date > file
-	git annex add file
-	git annex unlock file
-	git annex lock file
-	touch file
-	git annex unlock file
-	cat file
-	/annex/objects/...
-
-> now [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
deleted file mode 100644
index a0fb0f2e5c..0000000000
--- a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
+++ /dev/null
@@ -1,130 +0,0 @@
-### Please describe the problem.
-
-I cannot figure out how to fetch file from a new v7 clone on a FAT
-filesystem.
-
-### What steps will reproduce the problem?
-
- 1. mount external USB drive named `KINGSTON`
- 2. `cd /media/anarcat/KINGSTON`
- 3. `git clone ~/git-annex-repo` `git -C git-annex-repo annex info`
-
-### What version of git-annex are you using? On what operating system?
-
-7.20181121 on Debian buster.
-
-### Please provide any additional information below.
-
-I have a small-ish repository (1.2GB) that I was hoping to more
-naturally clone onto an external USB stick. It took a surprisingly
-long time, so at first I thought it was actually fetching the files as
-well:
-
-    anarcat@curie:KINGSTON$ git clone ~/Pictures/calendes
-    Clonage dans 'calendes'...
-    fait.
-    Extraction des fichiers: 100% (174/174), fait.
-    "git clone ~/Pictures/calendes" took 4 mins 54 secs
-
-But no, the repository is actually quite small:
-
-    $ du -shL calendes
-    47M	calendes
-
-Okay, let's figure out what's on there:
-
-    anarcat@curie:calendes$ git annex info
-
-      Detected a filesystem without fifo support.
-
-      Disabling ssh connection caching.
-
-      Detected a crippled filesystem.
-    (merging origin/git-annex into git-annex...)
-    (recording state in git...)
-
-      Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
-
-    Basculement sur la branche 'adjusted/master(unlocked)'
-    repository mode: indirect
-    trusted repositories: 0
-    semitrusted repositories: 7
-    	00000000-0000-0000-0000-000000000001 -- web
-     	00000000-0000-0000-0000-000000000002 -- bittorrent
-     	012c0223-72a6-4215-92fc-d130420c74b4 -- anarcat@curie:/media/anarcat/KINGSTON/calendes [here]
-     	383d0375-492f-47a3-9ab0-5e98cb8dae7e -- anarcat@angela:~/Pictures/calendes
-     	39538a65-dfdf-461a-80a6-5bba368eac8d -- anarcat@curie:~/Pictures/calendes [origin]
-     	434fe592-63af-4a76-8ee0-25ae70c66dff -- anarcat@marcos:/var/www/calendes
-     	c7cdb1a3-a84f-49b1-a50d-95db16be7313 -- anarcat@marcos:~/Pictures/calendes
-    untrusted repositories: 0
-    transfers in progress: none
-    available local disk space: 15.41 gigabytes (+1 megabyte reserved)
-    local annex keys: 0
-    local annex size: 0 bytes
-    annexed files in working tree: 0
-    size of annexed files in working tree: 0 bytes
-    bloom filter size: 32 mebibytes (0% full)
-    backend usage:
-
-Hmm.. Okay, adjusted branches. Not sure how that works, but let's try
-it out:
-
-    anarcat@curie:calendes$ git annex get
-    anarcat@curie:calendes$ git annex get pictures/2018-01/DSCF1012.RAF
-    anarcat@curie:calendes$
-
-Hmm... That does nothing. Okay, reading back [[git-annex-adjust]], it
-says that `sync --content` should work:
-
-    anarcat@curie:calendes$ git annex sync --content
-    commit 
-    Sur la branche adjusted/master(unlocked)
-    rien à valider, la copie de travail est propre
-    ok
-    pull origin 
-    ok
-    push origin 
-    Énumération des objets: 8, fait.
-    Décompte des objets: 100% (8/8), fait.
-    Compression par delta en utilisant jusqu'à 4 fils d'exécution
-    Compression des objets: 100% (5/5), fait.
-    Écriture des objets: 100% (6/6), 714 bytes | 714.00 KiB/s, fait.
-    Total 6 (delta 2), réutilisés 1 (delta 0)
-    To /home/anarcat/Pictures/calendes
-       a0b9ba9..490f30e  master -> synced/master
-     * [new branch]      git-annex -> synced/git-annex
-    ok
-
-(Ah crap, I forgot `--no-push` and now I need to mark that thing as
-dead.)
-
-Okay, that didn't work either: the files are still missing from the
-USB key. I have also tried to `git annex copy --to KINGSTON` after
-setting up the remote: the copy goes fine, but the file is still
-absent, according to `git annex whereis` from the `KINGSTON` repo's
-perspective, and the file in the worktree is still just the pointer to
-the internal datastructures.
-
-At that point I gave up and copied the files directly using a file
-manager because, thankfully, the new v7 mode seems to work well enough
-for me to be able to just copy files that way now. :)
-
-How do I fetch those files anyways? -- [[anarcat]]
-
-> Ugh. Obviously, problem between keyboard and chair here. :( Turns
-> out the clone didn't create a v7 repository, and a simple `git annex
-> upgrade` on the clone fixed the problem. The `Entering an adjusted
-> branch` warning threw me off - I thought it was an indicator that
-> the `init` stage (correctly?) detected it should be in v7 mode. I
-> would have expected a v5 repo to be in classical `direct` mode here,
-> not this weird state where it's "partly v7". Maybe I misunderstood
-> something?
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-I am a faithful user of git-annex since almost the beginning, and it's
-serving me incredibly well. The new v7 mode seems awesome and I have
-high hopes it will solve a *ton* of workflow issues I have identified
-over time with git-annex. So congratulations on that awesome work! :)
-
-> [[fixed|done]] in master, I think. --[[Joey]]
diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_1_a940e8cfd427eb3396ac327970a93805._comment b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_1_a940e8cfd427eb3396ac327970a93805._comment
deleted file mode 100644
index 43963db978..0000000000
--- a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_1_a940e8cfd427eb3396ac327970a93805._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-04T16:16:42Z"
- content="""
-Thing is, it should have auto-upgraded to v7 in that case, and a bug
-prevented it from doing so. Already fixed in
-[[!commit 865d5561035fec84749f8b2131110fab97cd3aa6]].
-"""]]
diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_2_f2ee808b3ee2631f1a753fe0c8e2a001._comment b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_2_f2ee808b3ee2631f1a753fe0c8e2a001._comment
deleted file mode 100644
index 60007031a1..0000000000
--- a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_2_f2ee808b3ee2631f1a753fe0c8e2a001._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="thanks!"
- date="2018-12-04T17:10:15Z"
- content="""
-well, that was fast! we'll have to invent a new heisenbug-type of bug for you: the bug that's fixed *before* you report it. :) i'm glad I wasn't hallucinating this too...
-"""]]
diff --git a/doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn b/doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn
deleted file mode 100644
index 3ad892906b..0000000000
--- a/doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn
+++ /dev/null
@@ -1,87 +0,0 @@
-### Please describe the problem.
-
-In v7 repos unlocking files larger then RAM, causes out of memory error on subsequent commands.
-
-### What steps will reproduce the problem?
-
-Just create new repository, add big file, unlock it, try to run `git annex status`. See full actions list below.
-
-### What version of git-annex are you using? On what operating system?
-
-Tested on:
-
-- 7.20181206-gc4b6115f7
-- 7.20181212-g7d51b0c10
-
-### Please provide any additional information below.
-
-[[!format sh """
-
-$ git --version
-git version 2.20.1
-
-$ git annex version
-git-annex version: 7.20181212-g7d51b0c10
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-operating system: linux x86_64
-supported repository versions: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-
-$ git init
-Initialized empty Git repository in /home/user/Temp/Annex/bug/.git/
-
-$ git annex init --version=7
-init  ok
-(recording state in git...)
-
-$ ls -lh
-total 16G
--rw-r--r-- 1 user user 16G Jan  9 23:00 big-file
-
-$ git annex status
-? big-file
-
-$ git annex add
-add big-file ok
-(recording state in git...)
-
-$ git annex status
-A big-file
-
-$ git annex sync
-commit 
-[master (root-commit) ef57173] git-annex in user@user-thinkpad:~/Temp/Annex/bug
- 1 file changed, 1 insertion(+)
- create mode 120000 big-file
-ok
-
-$ git annex status
-
-$ git status
-On branch master
-nothing to commit, working tree clean
-
-$ git annex unlock big-file
-unlock big-file ok
-(recording state in git...)
-
-$ git annex status
-fatal: Out of memory, realloc failed
-git-annex: git status failed
-git-annex: status: 1 failed
-
-$ git status
-fatal: Out of memory, realloc failed
-
-"""]]
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-
-Git Annex is unique piece of Art, there is nothing like it.
-
-> This bug got fixed in git. I just tested with 2.23 and verified it's
-> [[done]] --[[Joey]]
diff --git a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_1_b5adba30830051c4ef93e1ea486757f7._comment b/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_1_b5adba30830051c4ef93e1ea486757f7._comment
deleted file mode 100644
index 564b94a847..0000000000
--- a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_1_b5adba30830051c4ef93e1ea486757f7._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-01-22T21:45:10Z"
- content="""
-Yeah, so git status is OOMing, not git-annex. (And git commit OOMs too BTW.)
-
-I think git is just naively trying to malloc enough memory for the
-entire file even though it's configured to use the smudge/clean filter
-and the actual data it needs to deal with is small.
-
-I've mentioned this on the git mailing list, in message-id
-`<20190122220714.GA6176@kitenet.net>`.
-"""]]
diff --git a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_2_3d4672aa2603021e26b21dc72f84c3cb._comment b/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_2_3d4672aa2603021e26b21dc72f84c3cb._comment
deleted file mode 100644
index 89cf8193f0..0000000000
--- a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_2_3d4672aa2603021e26b21dc72f84c3cb._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="gueux"
- avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
- subject="comment 2"
- date="2019-01-24T10:34:08Z"
- content="""
-Is this bug the same as https://git-annex.branchable.com/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/ ?
-
-Here is a pointer to your message: https://public-inbox.org/git/20190122220714.GA6176@kitenet.net/ for those like me who are not subscribed.
-"""]]
diff --git a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_2_9300dfd4ec40742de217897765df2126._comment b/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_2_9300dfd4ec40742de217897765df2126._comment
deleted file mode 100644
index fe67858f1f..0000000000
--- a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_2_9300dfd4ec40742de217897765df2126._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-01-24T20:37:24Z"
- content="""
-A patch to git that avoids this problem has been submitted to the mailing
-list, and hopefully will be in an upcoming release.
-"""]]
diff --git a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_4_b98dea188d5a049d91f4446d966d0a70._comment b/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_4_b98dea188d5a049d91f4446d966d0a70._comment
deleted file mode 100644
index 710eddfabd..0000000000
--- a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_4_b98dea188d5a049d91f4446d966d0a70._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="gueux"
- avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
- subject="comment 4"
- date="2019-02-27T09:34:12Z"
- content="""
-Was the patch forgotten? It does not seem to be part of v2.21.0...
-"""]]
diff --git a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_5_732905e5f901d1cdaf4c6cc743db7e95._comment b/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_5_732905e5f901d1cdaf4c6cc743db7e95._comment
deleted file mode 100644
index 64c97ccb0e..0000000000
--- a/doc/bugs/v7_unlock_big_file__58___out_of_memory/comment_5_732905e5f901d1cdaf4c6cc743db7e95._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2019-03-18T15:18:06Z"
- content="""
-The patch got into git's pu branch on March 7th, and seems to be wending
-its way to master (made it into Junio's branch today).
-"""]]
diff --git a/doc/bugs/versioned_S3_generates_invalid_encoded_url.mdwn b/doc/bugs/versioned_S3_generates_invalid_encoded_url.mdwn
deleted file mode 100644
index 250512fbbe..0000000000
--- a/doc/bugs/versioned_S3_generates_invalid_encoded_url.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-See https://github.com/OpenNeuroOrg/datalad-service/issues/99
-where the url generated by a versioned S3 export remote did not url-encode
-the "+" in the S3 object ID.
-
-This breaks git-annex info's display of urls for a file.
-It also breaks git-annex get from a public S3 remote. While the object
-in that issue is versioned, other code paths for non-versioned objects
-have the same problem.
-
-https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html
-describes an URI encoding that appears non-standard;
-Aws.S3.Core.s3UriEncode implements that. But is S3 using the same
-non-standard URI encoding for URLs to objects?
-https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html
-documents a need to url-encode a few punctuation characters, but is
-frustratingly vague.
-
-Experimentally, even url-encoding alphanumerics works in these urls.
-So it would be ok to use a standard URI encoder.
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/webdav_remote_fails_on_pound_signs.mdwn b/doc/bugs/webdav_remote_fails_on_pound_signs.mdwn
deleted file mode 100644
index 35455023d3..0000000000
--- a/doc/bugs/webdav_remote_fails_on_pound_signs.mdwn
+++ /dev/null
@@ -1,61 +0,0 @@
-### Please describe the problem.
-
-When doing an `export` to a WebDAV remote, git-annex chokes on directory that have the `#` character in it, presumably because it has special meaning in HTTP.
-
-### What steps will reproduce the problem?
-
-Roughly, setup a WebDAV remote:
-
-    WEBDAV_USERNAME=anarcat WEBDAV_PASSWORD=REDACTED git annex initremote webdav type=webdav url=https://example.net/nextcloud/remote.php/webdav/Photos/ encryption=none exporttree=yes
-
-Create a directory with a pound sign in it, and export it:
-
-    mkdir -p pictures/foo#1 ; touch pictures/foo#1/test; git annex add pictures ; git commit -myolo
-    git annex export master:pictures --to webdav
-
-### What version of git-annex are you using? On what operating system?
-
-7.20181211-2 on Debian buster, from Debian packages.
-
-### Please provide any additional information below.
-
-Here's part of the output from the of the original export command:
-
-    [...]
-    export lib3.net documentation/photo/IMG_0636.JPG 
-    ok                                
-    export lib3.net documentation/radio/Antenna #1/20101107_002.jpg 
-    failed                            
-    [...]
-
-Trying to export again retries only those but still fails:
-
-    $ git annex export master:pictures --to webdav
-    export lib3.net documentation/radio/Antenna #1/20101107_002.jpg 
-    failed                            
-    [...]
-
-I have since then renamed the evil directory to remove the pound sign. But then export tries to rename it and still fails:
-
-
-    $ git annex export master:pictures --to lib3.net
-    rename lib3.net documentation/radio/Antenna #1/20101107_005.jpg -> .git-annex-tmp-content-SHA256E-s53186--07c80575cc0fa2b902fd0828f4b4ce0b12af7be94721a1e50134ec78bb67bc2e.jpg 
-      rename failed; deleting instead
-    [...]
-
-... and it then proceeds to upload the renamed files correctly:
-
-    [...]
-    export lib3.net documentation/radio/antenna-1/20101107_002.jpg 
-    ok                                
-    [...]
-
-The log doesn't show it, but delete also fails, as a new export run will try to rename the old files again, and fail.
-
-It wouldn't be so bad if git-annex would fail to upload to a webdav repo and just force the user to use sane filenames. The problem is it doesn't recover when the user does fix its shit... ;)
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-I'm running out of ideas here, to be honest. I've certainly had a lot of "luck" running git-annex before, but as others have said, "there's no such thing as luck" and the reason this whole thing works at all is because you work so hard on making it. So: thanks again! --[[anarcat]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/webdav_remote_fails_on_pound_signs/comment_1_b6b1cff5972a655d14b592652ae8d1a8._comment b/doc/bugs/webdav_remote_fails_on_pound_signs/comment_1_b6b1cff5972a655d14b592652ae8d1a8._comment
deleted file mode 100644
index a4695178ae..0000000000
--- a/doc/bugs/webdav_remote_fails_on_pound_signs/comment_1_b6b1cff5972a655d14b592652ae8d1a8._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-02-07T17:11:22Z"
- content="""
-I guess that "#" and "?" in a webdav path is just not possible, since
-the path becomes part of the url that is used. It might even be legal for a
-webdav server to cut those off the url and store data to the basename,
-which could overwrite another file that shared that basename.
-
-I don't like escaping those somehow, because the user should expect to see
-the same filenames in the export that they have in their tree. So exporting
-should fail. And removal should can succeed without doing anything, to
-let it recover, which is ok since the file content is certianly not located
-at an url containing either of those characters.
-
-I think that S3 might have the same problem, have not tried it yet.
-"""]]
diff --git a/doc/bugs/webdav_remote_fails_on_pound_signs/comment_2_a88aa0458413481787b4a59990a210df._comment b/doc/bugs/webdav_remote_fails_on_pound_signs/comment_2_a88aa0458413481787b4a59990a210df._comment
deleted file mode 100644
index 9413e7b5f0..0000000000
--- a/doc/bugs/webdav_remote_fails_on_pound_signs/comment_2_a88aa0458413481787b4a59990a210df._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-02-07T17:47:06Z"
- content="""
-Fixed for webdav, still need to check S3.
-
-Update: S3 does not have the problem, because the path to a S3 object is
-also part of the url, and yet S3 doesn't special case '#' and '?'.
-
-Kind of makes me wonder if all webdav servers have the problem either.
-"""]]
diff --git a/doc/bugs/why_are_all_those_files_modified.mdwn b/doc/bugs/why_are_all_those_files_modified.mdwn
deleted file mode 100644
index fefeeebb10..0000000000
--- a/doc/bugs/why_are_all_those_files_modified.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-Following up on [[todo/clarify_that_v7_applies_to_all_clones]], the
-next step was to fetch all content from the central, still v5
-repository, which worked fine.
-
-But weirdly, some files showed up as modified:
-
-    $ git annex get
-    [...]
-    $ git status
-    ## master...origin/master
-     M calendrier/photos/DSCF0879.jpg
-     M calendrier/photos/DSCF1191.jpg
-
-Strangely, git doesn't see which changes are present here:
-
-    $ git diff
-    [... takes some time, but no output ...]
-    $ 
-
-Workaround: `git checkout .` - but I don't understand why that is happening in the first place... Is that a bug? -- [[anarcat]]
-
-> update: yes, and it was [[fixed|done]] by joeyh.
diff --git a/doc/bugs/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment b/doc/bugs/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment
deleted file mode 100644
index ccb11e5d1f..0000000000
--- a/doc/bugs/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-04T21:27:30Z"
- content="""
-If the file is locked, git-annex get has to modify it when it populates it.
-
-git-annex is supposed to restage the file in order to update git's index.
-In a few cases where the index file is locked by something else, it is 
-unable to do so and displays a warning, so perhaps that's what happened here.
-"""]]
diff --git a/doc/bugs/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment b/doc/bugs/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment
deleted file mode 100644
index 9e8ec3a09e..0000000000
--- a/doc/bugs/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="comment 2"
- date="2018-12-04T21:37:54Z"
- content="""
-> If the file is locked, git-annex get has to modify it when it populates it.
-> 
-> git-annex is supposed to restage the file in order to update git's index. In a few cases where the index file is locked by something else, it is unable to do so and displays a warning, so perhaps that's what happened here.
-
-Hmm... I *think* I ran `git annex unlock` on `curie` here, so all files should be unlocked. I don't know what else could be locking the index file and didn't see a warning about it. I've seen a similar situation when upgrading other repositories in the past as well... 
-"""]]
diff --git a/doc/bugs/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment b/doc/bugs/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment
deleted file mode 100644
index db0b615173..0000000000
--- a/doc/bugs/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="happened again"
- date="2018-12-04T22:08:36Z"
- content="""
-I just did a `git annex upgrade` with (again) 6.20180913-1~bpo9+1 and I am again seeing all files as modified (but diff is empty). No other command was running on the repository that I know of.
-"""]]
diff --git a/doc/bugs/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment b/doc/bugs/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment
deleted file mode 100644
index 247a5a25d8..0000000000
--- a/doc/bugs/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2018-12-11T16:27:27Z"
- content="""
-I reproduced as follows:
-
-* Have a v7 repository, and unlock a couple of files.
-* Clone to a v5 repository.
-* Get the files into the v5 repository. (git annex get won't work on the
-  unlocked files, but you can get --all or copy from the v7 to the v5 or
-  whatever)
-* Upgrade the v5 repository to v7.
-
-Does that sequence match what you were doing? I didn't reproduce the
-problem when just upgrading the v5 and then getting the unlocked files into it.
-
-Seems that the upgrade to v7 process, after scanning for and populating
-unlocked files, needs to update git's index. I thought it did, but perhaps
-I forgot or that is not working.
-"""]]
diff --git a/doc/bugs/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment b/doc/bugs/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment
deleted file mode 100644
index 7c4ef13055..0000000000
--- a/doc/bugs/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2018-12-11T17:03:38Z"
- content="""
-Fixed the problem I described.
-"""]]
diff --git a/doc/bugs/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment b/doc/bugs/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment
deleted file mode 100644
index 165556cabb..0000000000
--- a/doc/bugs/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="possibly"
- date="2018-12-11T17:06:19Z"
- content="""
-> Does that sequence match what you were doing? I didn't reproduce the problem when just upgrading the v5 and then getting the unlocked files into it.
-
-I don't *exactly* remember, unfortunately, but that seems likely. It matches my previous comment, which indicates I upgraded to the backport *after* filing the bug report anyways.
-
-> Seems that the upgrade to v7 process, after scanning for and populating unlocked files, needs to update git's index. I thought it did, but perhaps I forgot or that is not working.
-
-Makes sense! :)
-"""]]
diff --git a/doc/bugs/windows_annex_link_wrong.mdwn b/doc/bugs/windows_annex_link_wrong.mdwn
deleted file mode 100644
index 8a1b29280b..0000000000
--- a/doc/bugs/windows_annex_link_wrong.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-On windows, the links to .git/annex/objects are no longer relative; include
-drive letter and full path.
-
-This used to not be the case; it must have gotten broken. --[[Joey]]
-
-> [[fixed|done]]
diff --git a/doc/bugs/windows_export_tree_exports_empty_tree.mdwn b/doc/bugs/windows_export_tree_exports_empty_tree.mdwn
deleted file mode 100644
index 37523c71c7..0000000000
--- a/doc/bugs/windows_export_tree_exports_empty_tree.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-The test suite's `test_export_import` fails on Windows.
-It seems that exporting a tree that contains annexed files
-somehow ends up exporting an empty tree.
-
-The test is running in an adjusted unlocked branch. But it exports
-the master branch. The master branch indeed contains an empty tree.
-
-The origin repo is also using an adjusted unlocked branch. Some changes
-have been committed there, but not synced back to the master branch.
-
-On clone from that, git-annex sets up an adjusted unlocked branch,
-and it merges origin's adjusted unlocked branch in. So the annexed files
-are present in that branch, but still not in master.
-
-This is not really a windows-specific problem. Only on windows or perhaps
-on a crippled FS does the test suite actually test opeation in an unlocked
-adjusted branch, because it enters that mode only on demand. Arguably
-the test suite should run all the tests separately on an adjusted branch,
-but that would add a lot of extra time to the test suite and very few
-tests are likely to behave any differently there.
-
-On balance, I think that making the test case run a git-annex sync
-before exporting is good enough.
-
-[[done]] --[[Joey]]
diff --git a/doc/bugs/windows_fails_import_export_tests.mdwn b/doc/bugs/windows_fails_import_export_tests.mdwn
deleted file mode 100644
index d8861fa33d..0000000000
--- a/doc/bugs/windows_fails_import_export_tests.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-Windows test suite fails the import/export tests.
-
-It imports a file, but the worktree file remains a unlocked pointer
-file. So the test fails. Running `git annex smudge--update` fixed the
-file content. 
-
-Reproduced outside the test suite, and tried with GIT_TRACE=1.
-When `git-annex merge remote/master``runs git merge, it does then smudge
---clean the imported files. But smudge --update does not get run. The
-post-merge hook should run it.
-
-Ahh -- on windows, hooks are not written, because the code skips that
-for a crippled filesystem, assuming it has no execute bit.
-
-So, this is both a problem on windows and on crippled filesystems.
-The user needs to run smudge --update themselves, or maybe git-annex
-can do it sometimes. Eg, `git annex merge` (and sync) could certianly
-smudge --update when on a crippled filesystem. And that would be
-enough to fix the test suite.
-
-But if a user is on a crippled filesystem with an adjusted branch, and
-they do some other operation that would be covered by post-merge or
-post-checkout hook, they will be surprised to find unpopulated pointer
-files in the working tree.
-
-I think this can be avoided. On eg fat on linux, all files are executable,
-so the hook can be installed and will work. On Windows, a hook can start
-with #!/bin/sh and not be executable, and will be run by the bash bundled
-with git for windows.
---[[Joey]]
-
-> [[fixed|done]]; 100% test pass on windows now --[[Joey]]
diff --git a/doc/bugs/windows_support_totally_bitrotted.mdwn b/doc/bugs/windows_support_totally_bitrotted.mdwn
deleted file mode 100644
index bb2a075de5..0000000000
--- a/doc/bugs/windows_support_totally_bitrotted.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-Unfortunately, git-annex is completely broken in Windows right now:
-
-* In a direct mode repository, `git annex add` stages the git-annex link,
-  but then `git annex sync` stages the file content into git, so the file
-  content gets committed to git.
-* In a v7 repository (with or without adjusted branches), `git annex add`
-  stages the git-annex link, but `git status` then shows the file as
-  modified from what was staged, and `git diff --cached` shows a diff
-  from the git-annex link to the file content. And `git commit -a`
-  commits the file content to git, not to git-annex.
-
-Something has bitrotted. Note that git-annex in Windows Subsystem for Linux
-does not have these problems and seemed to work fairly well last time I
-tried it. --[[Joey]]
-
-These seem surprisingly related in some way, given that direct mode is only
-being maintained and should not have changed its behavior at all.
-Perhaps there has been some change that is causing both problems?
-
-In direct mode, `git annex sync --content` is running "git add -f" on each
-file in the work tree, including unmodified files and files that `git annex
-add` has staged annex links for already. That's `stageDirect`, apparently
-it falls through to the `addgit` action, that is supposed to only happen for
-not yet staged files that are dummy symlinks or something (this code is
-untouched since 2013). That suggests that `catKey` or `toInodeCache`
-returned Nothing which should not happen in this case.
-
-So, the next step will be to build git-annex on Windows and instrument
-`stageDirect` to work out which thing it depends on has broken..
-
-> [[fixed|done]] --[[Joey]] 
diff --git a/doc/bugs/windows_support_totally_bitrotted/comment_1_e6e629e4b6cbaf51b9b6ed88a6713afd._comment b/doc/bugs/windows_support_totally_bitrotted/comment_1_e6e629e4b6cbaf51b9b6ed88a6713afd._comment
deleted file mode 100644
index 21ff276723..0000000000
--- a/doc/bugs/windows_support_totally_bitrotted/comment_1_e6e629e4b6cbaf51b9b6ed88a6713afd._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-02-18T15:15:49Z"
- content="""
-After a windows-appropriate amount of sturm und drang I have windows dev
-environment set up.
-
-Both `catKey` and `fileKey` are returning Nothing in a situation where at
-least `catKey` should find a key.
-"""]]
diff --git a/doc/bugs/windows_support_totally_bitrotted/comment_2_4a37c0d8abbc64abd383d0d306be31f6._comment b/doc/bugs/windows_support_totally_bitrotted/comment_2_4a37c0d8abbc64abd383d0d306be31f6._comment
deleted file mode 100644
index 1dd76847b6..0000000000
--- a/doc/bugs/windows_support_totally_bitrotted/comment_2_4a37c0d8abbc64abd383d0d306be31f6._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-02-18T21:03:54Z"
- content="""
-isLinkToAnnex failing on windows because of mixed path separator issues
-caused by [[!commit 5d98cba923e541be4dc9fd36f5f3c4a37b465bf1]].
-
-Verified it's working in both direct and v7 unlocked with that fixed.
-"""]]
diff --git a/doc/bugs/windows_test_suite_fails_to_init_direct_mode_repo.mdwn b/doc/bugs/windows_test_suite_fails_to_init_direct_mode_repo.mdwn
deleted file mode 100644
index 599da46d5e..0000000000
--- a/doc/bugs/windows_test_suite_fails_to_init_direct_mode_repo.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-For some reason the test suite on windows is failing to set up the direct
-mode repo; git-annex direct fails because the repo is a v7 repo in adjusted
-unlocked mode.
-
-I have not managed to reproduce this outside of the test suite.
-
-Hmm, I reordered the direct mode tests to come first, and the failure went
-away. Think that .t/repo gets reused somehow, and being already a v7 repo, 
-git annex init --version=7 silently did not change it. (Now it will error
-out instead.)
-
-.t/repo is supposed to be deleted between each pass, but deleting
-directories on Windows is a fairly probabalistic venture. It would be
-better to use a different repo path for each pass. [[done]] --[[Joey]]
diff --git a/doc/bugs/withOtherTmp_file_escapes.mdwn b/doc/bugs/withOtherTmp_file_escapes.mdwn
deleted file mode 100644
index 04f1481e25..0000000000
--- a/doc/bugs/withOtherTmp_file_escapes.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-This was reported with concurrent processes, I think probably during a `git
-annex add` but not sure:
-
-	git-annex: .git/annex/othertmp/inge59014-3: getFileStatus: does not exist (No such file or directory)
-	failed
- 
-	git-annex: .git/annex/othertmp/ingest-assemble_den59014-8: removeLink: does not exist (No such file or directory)
-	failed
-
-From the "ingest" in the name, these files are from
-`Annex.Ingest.lockDown'`, which uses `withOtherTmp`, hard links the file
-into the temp directory, and then returns a LockedDown that includes the
-temp filepath. So, it's escaped the locking that `withOtherTmp` does, and
-another process can clean up the temp files at the wrong point in time.
-This will need some significant code reworking to fix.
-
-> [[fixed|done]] --[[Joey]]
-
-This is a fairly new problem because the code to have other processes
-cleanup stale othertmp files was only added a couple months back.
-
-I audited other uses of withOtherTmp, and the only other problem I found is
-similar, in Annex.Branch.stageJournal. Fixed that one.
---[[Joey]]
diff --git a/doc/bugs/withOtherTmp_file_escapes/comment_1_b5f54c5908d209433628b81f5c147cd5._comment b/doc/bugs/withOtherTmp_file_escapes/comment_1_b5f54c5908d209433628b81f5c147cd5._comment
deleted file mode 100644
index f49889c2e4..0000000000
--- a/doc/bugs/withOtherTmp_file_escapes/comment_1_b5f54c5908d209433628b81f5c147cd5._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 1"
- date="2019-05-07T16:04:58Z"
- content="""
-Yes, this was during a `git annex add`, with several of these commands running in parallel on the same repo.  Thanks for looking into it.
-
-Can this occur when running a single git-annex command with -J?
-
-"""]]
diff --git a/doc/bugs/withOtherTmp_file_escapes/comment_2_637818a2288e7e6fb60b3003c16b7fc7._comment b/doc/bugs/withOtherTmp_file_escapes/comment_2_637818a2288e7e6fb60b3003c16b7fc7._comment
deleted file mode 100644
index 5b3be5f0b6..0000000000
--- a/doc/bugs/withOtherTmp_file_escapes/comment_2_637818a2288e7e6fb60b3003c16b7fc7._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-05-07T16:08:58Z"
- content="""
-It can occur whenever another git-annex process shuts down and tries to
-clean up the temp direcotry while the earlier process is still using it to
-ingest a file.
-"""]]
diff --git a/doc/bugs/withOtherTmp_file_escapes/comment_3_5a14bfeb539e4d2749539256722c2219._comment b/doc/bugs/withOtherTmp_file_escapes/comment_3_5a14bfeb539e4d2749539256722c2219._comment
deleted file mode 100644
index 6f6e5c122a..0000000000
--- a/doc/bugs/withOtherTmp_file_escapes/comment_3_5a14bfeb539e4d2749539256722c2219._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 3"
- date="2019-05-07T16:53:10Z"
- content="""
-As a quick fix, would it be possible to make each git-annex process create its own temp subdir under `.git/annex/othertmp/`, e.g. based on process ID, and use (and at the end clean up) only that?
-
-Or, if that's not simple to do, add a config option to disable cleaning up `.git/annex/othertmp/` at shutdown?  I can clean it myself after all git-annex processes have finished.
-
-"""]]
diff --git a/doc/bugs/withOtherTmp_file_escapes/comment_4_cbbb3fad74d51c8dc053dbae25f3f68b._comment b/doc/bugs/withOtherTmp_file_escapes/comment_4_cbbb3fad74d51c8dc053dbae25f3f68b._comment
deleted file mode 100644
index a8a0bf3065..0000000000
--- a/doc/bugs/withOtherTmp_file_escapes/comment_4_cbbb3fad74d51c8dc053dbae25f3f68b._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2019-05-07T17:19:54Z"
- content="""
-Oh, but I already fixed it..
-"""]]
diff --git a/doc/bugs/withOtherTmp_file_escapes/comment_5_27bd997dc7839c4a151ef06b68423007._comment b/doc/bugs/withOtherTmp_file_escapes/comment_5_27bd997dc7839c4a151ef06b68423007._comment
deleted file mode 100644
index 9fdc8bec06..0000000000
--- a/doc/bugs/withOtherTmp_file_escapes/comment_5_27bd997dc7839c4a151ef06b68423007._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 5"
- date="2019-05-14T19:23:33Z"
- content="""
-Still seeing this bug with the latest git-annex, during a parallel git-annex-add:
-
-add pipelines/cromwell-executions/assemble_denovo/ffcbdd7a-f4b2-427f-9aee-b286ff66e42c/call-refine_2x_and_plot/execution/gatk/resource\
-s/exampleBAM.bam.bai ok
-add pipelines/cromwell-executions/assemble_denovo/ffcbdd7a-f4b2-427f-9aee-b286ff66e42c/call-refine_2x_and_plot/execution/script ok
-(recording state in git...)
-add pipelines/cromwell-executions/assemble_denovo/3cbe618f-fcb6-4afd-8342-cec631894c66/call-scaffold/execution/stderr
-git-annex: .git/annex/othertmp/ingest-stderr61432-7295: rename: permission denied (Permission denied)
-failed
-add pipelines/cromwell-executions/assemble_denovo/3f716be9-b496-4f08-9bc9-5dc5e65e0111/call-assemble/execution/stderr
-git-annex: .git/annex/othertmp/ingest-stderr61432-7830: rename: permission denied (Permission denied)
-failed
-add pipelines/cromwell-executions/assemble_denovo/4099e3b6-30e8-47cd-8daf-f178cf15bbc2/call-scaffold/execution/stderr.background
-git-annex: .git/annex/othertmp/inge61432-8197: rename: permission denied (Permission denied)
-failed
-add pipelines/cromwell-executions/assemble_denovo/4794a803-878a-4d8b-8ef1-ffff68278d74/call-scaffold/execution/LASV_NGA_2018_1286.lLAS\
-V_pool1.7.assembly1-trinity-spades.intermediate_gapfill.fasta
-git-annex: .git/annex/othertmp/ingest-LASV_NGA_2018_1286.lLASV_pool1.7.assembly1-trinity-spades61432-8746.interm: rename: permission d\
-enied (Permission denied)
-failed
-
-"""]]
diff --git a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__.mdwn b/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__.mdwn
deleted file mode 100644
index e03ea396a8..0000000000
--- a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__.mdwn
+++ /dev/null
@@ -1,73 +0,0 @@
-The files `unused`, `badunused` and `tmpunused` in `.git/annex/` do not have the correct permissions when the git repository is set to `--shared=group`. Such files are `600`, while they should be `660`, as other files in `.git/annex`.
-
-For this reason, when those files are created, they are accessibile only to one user (the owner), triggering errors when other users in the group attempt things like `git annex unused` or `git annex dropunused`. At least this occurs with git-annex 6.20171018+gitgbb20b1ed3-1~ndall+1 .
-
-To reproduce the problem:
-
-    git init --shared=group
-    git annex init
-    echo test > test
-    git annex add test
-    git commit -m test
-    git rm test
-    git commit -m removed
-    git annex unused
-
-you get:
-
-    unused . (checking for unused data...) (checking master...) 
-      Some annexed data is no longer used by any files:
-        NUMBER  KEY
-        1       SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-      (To see where data was previously used, try: git log --stat -S'KEY')
-      
-      To remove unwanted data: git-annex dropunused NUMBER
-      
-    ok
-
-
-Conversely, from another user of the group you get:
-
-    > git annex unused
-    unused . (checking for unused data...) (checking master...) 
-      Some annexed data is no longer used by any files:
-        NUMBER  KEY
-        1       SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
-      (To see where data was previously used, try: git log --stat -S'KEY')
-      
-      To remove unwanted data: git-annex dropunused NUMBER
-      
-    
-    git-annex: .git/annex/unused: openFile: permission denied (Permission denied)
-    failed
-    git-annex: unused: 1 failed
-
-Moreover:
-
-    > git annex dropunused 1
-    git-annex: .git/annex/misctmp/mergedrefs.0: createDirectory: permission denied (Permission denied)
-
-
-This is somewhat expected, because the permissions of `unused`, `badunused` and `tmpunused` are `600`:
-
-    > ll .git/annex/
-    total 40
-    drwxrwsr-x 5 ele testgroup 4096 dic 19 14:50 ./
-    drwxrwsr-x 9 ele testgroup 4096 dic 19 14:50 ../
-    -rw------- 1 ele testgroup    0 dic 19 14:50 badunused
-    -rw-rw-r-- 1 ele testgroup  345 dic 19 14:49 index
-    -rw-rw-r-- 1 ele testgroup   41 dic 19 14:49 index.lck
-    drwxrwsr-x 2 ele testgroup 4096 dic 19 14:49 journal/
-    -rw-rw---- 1 ele testgroup    0 dic 19 14:49 journal.lck
-    -rw-rw-r-- 1 ele testgroup   62 dic 19 14:49 mergedrefs
-    drwxrwsr-x 2 ele testgroup 4096 dic 19 14:49 misctmp/
-    drwxrwsr-x 3 ele testgroup 4096 dic 19 14:49 objects/
-    -rw-rw---- 1 ele testgroup    0 dic 19 14:49 precommit.lck
-    -rw-rw-r-- 1 ele testgroup    0 dic 19 14:49 sentinal
-    -rw-rw-r-- 1 ele testgroup   21 dic 19 14:49 sentinal.cache
-    -rw------- 1 ele testgroup    0 dic 19 14:50 tmpunused
-    -rw------- 1 ele testgroup  101 dic 19 14:50 unused
-
-If this is the intended behavior, could you please explain me how to use `git annex unused` and `dropunused` in a shared repository?
-
-> Fixed all of this I was able to reproduce. [[done]] --[[Joey]]
diff --git a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_1_ca6b7e3d5d83d2dd6532533ecdb965c3._comment b/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_1_ca6b7e3d5d83d2dd6532533ecdb965c3._comment
deleted file mode 100644
index c573945075..0000000000
--- a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_1_ca6b7e3d5d83d2dd6532533ecdb965c3._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="emanuele"
- nickname="emanuele.olivetti"
- avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce"
- subject="comment 1"
- date="2017-12-19T14:19:14Z"
- content="""
-Notice that, if I manually change the permsissions of `unused`, `badunused` and `tmpunused` to `660`, then other another user of the group can do `git annex unused` and `git annex dropunused 1` without errors. Unfortunately, after `git annex unused`, the ownership of `unused`, `badunused` and `tmpunused` changes from the initial user to the new user, and permissions are reset to `600`, which re-creates the initial problem.
-"""]]
diff --git a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_2_252800c3f4df5a5219e7f13c2b6ef841._comment b/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_2_252800c3f4df5a5219e7f13c2b6ef841._comment
deleted file mode 100644
index ef6ede63ed..0000000000
--- a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_2_252800c3f4df5a5219e7f13c2b6ef841._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-01-02T20:17:03Z"
- content="""
-Fixed, but I was not able to reproduce the part where dropunused failed
-with a permissions error involving .git/annex/misctmp, despite having it
-set up the same as you did.
-"""]]
diff --git a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_3_608fc6f82962c70e55259923c0522f6f._comment b/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_3_608fc6f82962c70e55259923c0522f6f._comment
deleted file mode 100644
index edc531049c..0000000000
--- a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_3_608fc6f82962c70e55259923c0522f6f._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="emanuele"
- avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce"
- subject="Thanks!"
- date="2018-01-03T10:51:45Z"
- content="""
-Joey, thanks for fixing the bug and for the larger commit (24df95f0f6ab474119aff3bbd942251373754ab2) to properly handle core.sharedRepository!
-
-I see you couldn't reproduce the permissions error involving .git/annex/misctmp. Just to clarify: it occurs to me only with the user for which `git annex unused` fails, and not to the initial user that did `git rm`, for which `git annex unused` works. I can still reproduce the issue in this very moment with git-annex 6.20171211+gitgba511f4de-1~ndall+1. Nevertheless, I'll try the updated code as soon as possible.
-
-And thanks to the anonymous bitcoin donor for supporting the fix of this bug!
-"""]]
diff --git a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_4_bb6c06fb6d0fb7053c4e3ade80b5f9da._comment b/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_4_bb6c06fb6d0fb7053c4e3ade80b5f9da._comment
deleted file mode 100644
index c6f4e7338b..0000000000
--- a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_4_bb6c06fb6d0fb7053c4e3ade80b5f9da._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2018-01-04T18:28:20Z"
- content="""
-Yes, I was running dropunused as other user, and still see no permissions
-problem there. .git/annex/misctmp is writable by the group.
-"""]]
diff --git a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_5_4fdbb304d67b198f32aa55b1672b0c78._comment b/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_5_4fdbb304d67b198f32aa55b1672b0c78._comment
deleted file mode 100644
index 77d25eaa27..0000000000
--- a/doc/bugs/wrong_permissions_of_unused__44___badunused_and_tmpunused__63__/comment_5_4fdbb304d67b198f32aa55b1672b0c78._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="emanuele"
- avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce"
- subject="comment 5"
- date="2018-01-09T08:46:44Z"
- content="""
-I can confirm that the permissions I see are set as you say: .git/annex/misctmp is writable by the group. Still, the error message appears here, using git-annex 6.20171211. I will look more in detail into this one. If something interesting pops out, I'll write here.
-
-Thanks again for your work.
-"""]]
diff --git a/doc/bugs/yesod-default_appears_no_longer_necessary.mdwn b/doc/bugs/yesod-default_appears_no_longer_necessary.mdwn
deleted file mode 100644
index 50c439ef82..0000000000
--- a/doc/bugs/yesod-default_appears_no_longer_necessary.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-### Please describe the problem.
-
-The description for yesod-default is:
-
-> Since version 1.2 of Yesod, this functionality is provided by the yesod package. This package is no longer needed.
-
-git-annex depends on yesod-default >=1.2.0 and yesod >=1.2.6 (and many other yesod-*>1.2).
-
-Thus git-annex should be able to drop yesod-default from the cabal file.
-
-### What steps will reproduce the problem?
-
-Just build from source.
-
-### What version of git-annex are you using? On what operating system?
-
-6.20171109, source tarball.
-
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-
-Sure, this is not really a "problem" anyway.
-
-> Thanks for noticing this, I've made the changes. [[done]] --[[Joey]]
diff --git a/doc/bugs/zsh_completions_installed_to_location_not_in_fpath.mdwn b/doc/bugs/zsh_completions_installed_to_location_not_in_fpath.mdwn
deleted file mode 100644
index 1a80aa227e..0000000000
--- a/doc/bugs/zsh_completions_installed_to_location_not_in_fpath.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-### Please describe the problem.
-
-Installing git-annex via the Makefile results in a zsh completion installed to `$(PREFIX)/$(SHAREDIR)/zsh/vendor-completions`
-
-This is not used by zsh, since the builtin zsh fpath is `$(PREFIX)/$(SHAREDIR)/zsh/site-functions` -- as a result, zsh completions do not work.
-
-Some system distributions of zsh may change the builtin fpath, in which case git-annex may have working zsh completions out of the box -- I believe the current installation method is designed based on Debian's preferred layout.
-
-### What steps will reproduce the problem?
-
-Install git-annex on a non-Debian system
-
-### What version of git-annex are you using? On what operating system?
-
-version 7.20190730 on an Arch Linux system.
-
-### Recommended fix
-
-Make the installation directory configurable. Use /etc/os-release to check if the system is a Debian-based system, and if so, continue to use vendor-completions, if not, use site-functions.
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/zsh_completions_installed_to_location_not_in_fpath/comment_1_82e2d63c92276bb71891f3d8cc8dc9dd._comment b/doc/bugs/zsh_completions_installed_to_location_not_in_fpath/comment_1_82e2d63c92276bb71891f3d8cc8dc9dd._comment
deleted file mode 100644
index 20aba16f22..0000000000
--- a/doc/bugs/zsh_completions_installed_to_location_not_in_fpath/comment_1_82e2d63c92276bb71891f3d8cc8dc9dd._comment
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-08-15T18:52:51Z"
- content="""
-Debian also supports /usr/local/share/zsh/site-functions/,
-it's just that it's for local sysadmin use and not a place that
-packages should install files, so they added /usr/share/zsh/vendor-completions/
-for that.
-
-However, checking `/etc/os_release` probably entails keeping track of the
-name of every debian derivative, so I'd really rather not do that.
-
-Also, even if the Makefile were changed to use
-/usr/local/share/zsh/site-functions/, it sounds as if that might not be a
-path that works universally either.
-
-Surely there must be a way to ask zsh where to install completions to?
-But short of taking the first item from $fpath, which doesn't seem robust,
-I don't know how to. And zsh may not even be installed when building a
-package that should later integrate with zsh.
-
-FWIW, I checked half a dozen packages like curl that include zsh
-completions, and none of them installed them with `make install`,
-they were just there to be installed manually. It seems zsh is making this
-too hard for software to bother integrating with it.
-"""]]
diff --git a/doc/bugs/zsh_completions_installed_to_location_not_in_fpath/comment_2_184598bf13c232c1e8934180bf79d364._comment b/doc/bugs/zsh_completions_installed_to_location_not_in_fpath/comment_2_184598bf13c232c1e8934180bf79d364._comment
deleted file mode 100644
index 6850184cdd..0000000000
--- a/doc/bugs/zsh_completions_installed_to_location_not_in_fpath/comment_2_184598bf13c232c1e8934180bf79d364._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="eschwartz@5abb721e66990e478c7d1caf96beb4f9794eb168"
- nickname="eschwartz"
- avatar="http://cdn.libravatar.org/avatar/16ec8475b4e3507f8d1a71101c16b208"
- subject="comment 2"
- date="2019-08-15T21:15:09Z"
- content="""
-The greatness of os-release (dash, not underscore) is that you can use the ID_LIKE field. From the os-release(5) man page:
-
-\"A space-separated list of operating system identifiers in the same syntax as the ID= setting. It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces [...]\". If \"debian\" is the value of ID, or is contained in the space-separated value of ID_LIKE, then you don't need to know what the specific OS is.
-
-Before os-release, it was common to check if the file /etc/debian_version existed, and if not, check for other distros using /etc/arch-release, /etc/fedora-release, and so on. Ubuntu historically included /etc/debian_version just so tools could identify the distro as debian-compatible, while identifying as Ubuntu only if you used lsb-release...
-
-...
-
-The site-functions directory should work everywhere, I think, since both the /usr/share and /usr/local/share equivalents are defined by the zsh build system (and I'm not aware of any distributors other than Debian which override the former). On my Arch system:
-
-```
-echo $fpath
-/usr/local/share/zsh/site-functions /usr/share/zsh/site-functions /usr/share/zsh/functions/Calendar /usr/share/zsh/functions/Chpwd /usr/share/zsh/functions/Completion /usr/share/zsh/functions/Completion/Base /usr/share/zsh/functions/Completion/Linux /usr/share/zsh/functions/Completion/Unix /usr/share/zsh/functions/Completion/X /usr/share/zsh/functions/Completion/Zsh /usr/share/zsh/functions/Exceptions /usr/share/zsh/functions/Math /usr/share/zsh/functions/MIME /usr/share/zsh/functions/Misc /usr/share/zsh/functions/Newuser /usr/share/zsh/functions/Prompts /usr/share/zsh/functions/TCP /usr/share/zsh/functions/VCS_Info /usr/share/zsh/functions/VCS_Info/Backends /usr/share/zsh/functions/Zftp /usr/share/zsh/functions/Zle
-```
-Specifically, if you look at the configure.ac, it will:
-
-- take a configurable --enable-site-fndir (the packaging location), which defaults to /usr/share/zsh/site-functions but which Debian overrides (this is SITEFPATH_DIR in Src/init.c)
-- if enable-site-fndir did not already get defined to /usr/local/share/zsh/site-functions (the local sysadmin location), then guarantee it is included by defining it as $fixed_sitefndir and embedding it in the binary as FIXED_FPATH_DIR (Src/init.c)
-- additionally include anything configured via --enable-additional-fpath, because enable-site-fndir is a string rather than an array, and the additional-fpath can be a comma-separated array (ADDITIONAL_FPATH in Src/init.c)
-
-It's regrettable that unlike bash-completion, there is no pkg-config file for this. :( That would at least allow the build system to build-depend on zsh in order to automatically grab this information. But ultimately, the only thing you need to worry about is which distribution-modified value to use for/instead of /usr/share/zsh/site-functions
-
-In the case of curl, the make install only installs to site-functions, but provides an option --with-zsh-functions-dir=/usr/share/zsh/vendor-completions used at https://salsa.debian.org/debian/curl/blob/27e07a35cb9c727d6005c0afa291e2a3dc3bc5af/debian/rules#L20
-
-Various other programs I have seen will often install to site-functions and let debian's packaging move it if needed, or try to check whether any of several known directories exist. Here is an elaborate detection mechanism which works for a proliferation of possible locations, and can be successfully packaged in a distro build recipe if you first mkdir -p \"$DESTDIR/usr/share/zsh/site-functions\" (or vendor-completions, depending): https://github.com/kovidgoyal/calibre/blob/7460a12a4bcd05efc822f7fe421626772e2f6575/src/calibre/linux.py#L192-L210
-
-The downside of that is that the packager needs to know they should do this first. :(
-"""]]
diff --git a/doc/devblog/day_499__security_hole.mdwn b/doc/devblog/day_499__security_hole.mdwn
index 635dc3f073..d110f0c31b 100644
--- a/doc/devblog/day_499__security_hole.mdwn
+++ b/doc/devblog/day_499__security_hole.mdwn
@@ -4,7 +4,7 @@ now when the security hole is disclosed.
 Security is not compositional. You can have one good feature, and add
 another good feature, and the result is not two good features, but a new
 security hole. In this case
-[[bugs/security_hole_private_data_exposure_via_addurl]] (CVE-2018-10857). 
+[[security/CVE-2018-10857_and_CVE-2018-10859|CVE-2018-10857]]. 
 And it can be hard to spot this kind of security hole, but then once it's
 known it seems blindly obvious.
 
diff --git a/doc/todo/--batch_for_copy.mdwn b/doc/todo/--batch_for_copy.mdwn
deleted file mode 100644
index 0db9656771..0000000000
--- a/doc/todo/--batch_for_copy.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-apparently not in 6.20170525+gitge1cf095ae-1~ndall+1  yet
-
-[[!format sh """
-$> git annex copy --help | grep -q batch || echo nothing
-nothing
-
-"""]]
-
-[!meta author=yoh]
-
-> [[done]] for copy and move --[[Joey]]
diff --git a/doc/todo/Add_a_way_to_mark_exporttree_remotes_dead.mdwn b/doc/todo/Add_a_way_to_mark_exporttree_remotes_dead.mdwn
deleted file mode 100644
index c534f59ba7..0000000000
--- a/doc/todo/Add_a_way_to_mark_exporttree_remotes_dead.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-There is currently no way to get rid of an exporttree remote, because the trust level `untrusted` is enforced.
-
-
-    $ git annex dead exp
-    dead exp
-      This remote's trust level is overridden to untrusted.
-    ok
-    (recording state in git...)
-
-> Fun bug! I've fixed it so that will work. [[done]] --[[Joey]]
diff --git a/doc/todo/Add_confirmation_dialog_to_the_restart_option.mdwn b/doc/todo/Add_confirmation_dialog_to_the_restart_option.mdwn
deleted file mode 100644
index 1ff909b8cf..0000000000
--- a/doc/todo/Add_confirmation_dialog_to_the_restart_option.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-I have four git-annex repositories and I often use the option "Switch repository" in the webapp, but this option is just above the "Restart daemon" option and I have clicked it quite a few time unintentionally.
-Could it be possible to add a confirmation dialog just like in the "Shutdown daemon" option?
-
-> spacer added; [[done]]  --[[Joey]]
diff --git a/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment b/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment
deleted file mode 100644
index 0732b7dde0..0000000000
--- a/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-02-15T16:54:54Z"
- content="""
-Restarting the daemon should just take a second and the web browser should
-redirect to the new instance. I guess it does move away from the current
-page to the dashboard, and in a way that the back button can't undo, but I
-see no other harm in accidentally restarting the daemon.
-
-So, I think I'll just add a spacer to separate the repository part of that
-menu from the daemon part.
-"""]]
diff --git a/doc/todo/Amazon_Cloud_Drive.mdwn b/doc/todo/Amazon_Cloud_Drive.mdwn
deleted file mode 100644
index 7ec91b4d31..0000000000
--- a/doc/todo/Amazon_Cloud_Drive.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-I've released a special remote which uses rclone to enable Amazon Cloud Drive:  -- [[DanielDent]]
-
----
-
-Is there a special remote implementation for Amazon Cloud Drive?
-
-It's just became unlimited for a fair price: $60/year ( https://www.amazon.com/clouddrive/pricing ).
-
-http://techcrunch.com/2015/03/26/amazon-goes-after-dropbox-google-microsoft-with-unlimited-cloud-drive-storage/
-
--- bence aka [[parhuzamos]] 
-
-> Not yet, but I just need to investigate haskell api bindings for it, I
-> suppose. --[[Joey]]
-
-> > Don't know if there's such a thing... there seems to be SDKs for android and IOS, but nothing more. It seems like it's a REST API: https://developer.amazon.com/public/apis/experience/cloud-drive/... --[[anarcat]]
-
->> requested it be added to amazonka  --[[Joey]]
-
->>> In the meantime,  supports Amazon Cloud drive.
->>> I may revisit adding support for it directly to git-annex if amazonka
->>> does get support, but for now, that seems good enough, so [[done]]
->>> --[[Joey]]
diff --git a/doc/todo/Amazon_Cloud_Drive/comment_1_a2fea3eecf0971bf1b9d3c71377d3be9._comment b/doc/todo/Amazon_Cloud_Drive/comment_1_a2fea3eecf0971bf1b9d3c71377d3be9._comment
deleted file mode 100644
index c7db6882c4..0000000000
--- a/doc/todo/Amazon_Cloud_Drive/comment_1_a2fea3eecf0971bf1b9d3c71377d3be9._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="interfect@b151490178830f44348aa57b77ad58c7d18e8fe7"
- nickname="interfect"
- subject="Windows support?"
- date="2016-09-01T03:31:30Z"
- content="""
-The git-annex-remote-rclone solution doesn't seem to work in Windows.
-
-I have the script on my PATH, and I'm doing everything in Git Bash. I can run the script from the shell just fine, but Git Annex itself says it can't execute it.
-
-git-annex: Cannot run git-annex-remote-rclone -- Make sure it's in your PATH and is executable.
-
-Presumably it doesn't know how to talk to bash.exe to get it to run the script.
-"""]]
diff --git a/doc/todo/Amazon_Cloud_Drive/comment_2_9adfd0dc49540a90d8d8a941c9c56fbe._comment b/doc/todo/Amazon_Cloud_Drive/comment_2_9adfd0dc49540a90d8d8a941c9c56fbe._comment
deleted file mode 100644
index 2d50ddaba7..0000000000
--- a/doc/todo/Amazon_Cloud_Drive/comment_2_9adfd0dc49540a90d8d8a941c9c56fbe._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2016-09-05T18:26:03Z"
- content="""
-@interfect probably what was discussed here
-
-
-I've made the necessary change to git-annex this morning so it should be
-able to run external special remote scripts on Windows. Have not tested it.
-"""]]
diff --git a/doc/todo/Amazon_Cloud_Drive/comment_3_6a4833f0c52d3726cd95d0818e0a89bf._comment b/doc/todo/Amazon_Cloud_Drive/comment_3_6a4833f0c52d3726cd95d0818e0a89bf._comment
deleted file mode 100644
index c1fd609194..0000000000
--- a/doc/todo/Amazon_Cloud_Drive/comment_3_6a4833f0c52d3726cd95d0818e0a89bf._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
- nickname="jason.dixon.email"
- avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
- subject="Same issue with rclone on windows."
- date="2017-03-08T08:55:48Z"
- content="""
-Using linux it works perfectly. Really great. But on windows no such luck. Trying many things to get it to function and no success.
-
-Given the thinness of the bash wrapper that binds rclone to annex, and rclones inherent cross platform nature. It would be awesome to have this remote as a first class citizen. Similar to amazon glacier requiring glacier-cli. Simply requiring rclone to open up so many backends is a very light dependency. :)
-"""]]
diff --git a/doc/todo/Amazon_Cloud_Drive/comment_4_7e66da169c3decb5771226cd3d4a905b._comment b/doc/todo/Amazon_Cloud_Drive/comment_4_7e66da169c3decb5771226cd3d4a905b._comment
deleted file mode 100644
index f66db898a2..0000000000
--- a/doc/todo/Amazon_Cloud_Drive/comment_4_7e66da169c3decb5771226cd3d4a905b._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
- nickname="jason.dixon.email"
- avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
- subject="Oh and to be slightly helpful"
- date="2017-03-08T08:57:08Z"
- content="""
-This is with version 6.20170302. So as of this writing, the current version I believe.
-"""]]
diff --git a/doc/todo/Amazon_Cloud_Drive/comment_5_441e2cf615735bc3fc403702edc8a809._comment b/doc/todo/Amazon_Cloud_Drive/comment_5_441e2cf615735bc3fc403702edc8a809._comment
deleted file mode 100644
index 6df8c84411..0000000000
--- a/doc/todo/Amazon_Cloud_Drive/comment_5_441e2cf615735bc3fc403702edc8a809._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="added as a special remote"
- date="2018-09-06T00:58:52Z"
- content="""
-it was not obvious to me at all that rclone was supported by git-annex! that's awesome!
-
-to make it clearer it exists, i've added it it to the list of [[special remotes]] as [[special_remotes/rclone]].
-"""]]
diff --git a/doc/todo/Avoid_repo_fixup_if___34__.noannex__34___is_present.mdwn b/doc/todo/Avoid_repo_fixup_if___34__.noannex__34___is_present.mdwn
deleted file mode 100644
index 5fcfa433a2..0000000000
--- a/doc/todo/Avoid_repo_fixup_if___34__.noannex__34___is_present.mdwn
+++ /dev/null
@@ -1,43 +0,0 @@
-Init.checkCanInitialize aborts if it finds a ".noannex" file, but before doing so Annex.new runs fixupRepo.  This results in the .git file being unnecessarily converted to a symlink.  It's minor, but it'd be nice if git-annex avoided touching the repo in this situation because git treats the symlink differently than the .git file in some ways.  For example, in the case of worktrees, trying to remove a fixed up one will fail:
-
-    % git worktree remove ../wt
-    fatal: validation failed, cannot remove working tree: '/tmp/tmp.Z0NByT6PLO/wt/.git' is not a .git file, error code 2
-
-
-Here's a demo of the issue:
-
-    % git init main
-    % cd main
-    % touch .noannex
-    % git add .noannex
-    % git commit -mnoannex
-    % git worktree add ../wt HEAD
-    % cd ../wt
-
-    % ls -l .git
-    -rw-r--r-- 1 kyle kyle 51 Jan 29 10:58 .git
-    % cat .git
-    gitdir: /tmp/tmp.Z0NByT6PLO/main/.git/worktrees/wt
-
-    % git annex init
-    init  
-      Initialization prevented by .noannex file (use --force to override)
-
-    git-annex: Not initialized.
-    failed
-    git-annex: init: 1 failed
-
-    % ls -l .git
-    lrwxrwxrwx 1 kyle kyle 25 Jan 29 10:58 .git -> ../main/.git/worktrees/wt
-
-    % git annex version
-    git-annex version: 7.20181121+git58-gbc4aa3f0e-1~ndall+1
-    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
-    dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.3 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
-    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
-    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
-    operating system: linux x86_64
-    supported repository versions: 5 7
-    upgrade supported from repository versions: 0 1 2 3 4 5 6
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/Compatibility_with_socks-0.6_and_persistant-template-2.7.mdwn b/doc/todo/Compatibility_with_socks-0.6_and_persistant-template-2.7.mdwn
deleted file mode 100644
index b8b35cefd8..0000000000
--- a/doc/todo/Compatibility_with_socks-0.6_and_persistant-template-2.7.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-The current Hackage version (7.20190615) only compiles with the constraints socks<0.6, persistent-template<2.7.
-
-The compiler errors can be fixed with the attached patches.
-
-In the case of the socks changes (for Tor), I am not sure if it will actually work correctly.
-
-> Found the necessary changes to get it to compile. [[done]] --[[Joey]]
diff --git a/doc/todo/Compatibility_with_socks-0.6_and_persistant-template-2.7/comment_1_94741c386078997f0e8a7d2d8e7af46c._comment b/doc/todo/Compatibility_with_socks-0.6_and_persistant-template-2.7/comment_1_94741c386078997f0e8a7d2d8e7af46c._comment
deleted file mode 100644
index ca20c8822a..0000000000
--- a/doc/todo/Compatibility_with_socks-0.6_and_persistant-template-2.7/comment_1_94741c386078997f0e8a7d2d8e7af46c._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-06-25T15:08:27Z"
- content="""
-I don't see any attached patches, could you send them?
-"""]]
diff --git a/doc/todo/Display_the_version_of_a_library_corresponding_to_a_build_flag.mdwn b/doc/todo/Display_the_version_of_a_library_corresponding_to_a_build_flag.mdwn
deleted file mode 100644
index 42dfce2a9a..0000000000
--- a/doc/todo/Display_the_version_of_a_library_corresponding_to_a_build_flag.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-It would be great when diagnosing issues to know the version of a particular library that git-annex is compiled with.
-
-Because there are so many dependencies though, perhaps only the libraries corresponding to a build flag should be displayed, so instead of
-
-    ~ λ git annex version
-    git-annex version: 6.20170321-g4642912
-    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Quvi
-    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
-    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-
-It would show:
-
-    ~ λ git annex version
-    git-annex version: 6.20170321-g4642912
-    build flags: ...etc... TorrentParser-1.2.1 Feeds-2.3.1 Quvi-1.0.0
-    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
-    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-
-> Well, I think better not to complicate the build flags list, which the
-> user may want to refer to, with this. Also, there should be a way to
-> indicate versions for libraries that don't have a build flag, when the
-> version is a common question. So, let's add it as a separate line of
-> data. [[done]] --[[Joey]] 
diff --git a/doc/todo/Error_when_using_6.20180913_with_6.20170101-1+deb9u2.mdwn b/doc/todo/Error_when_using_6.20180913_with_6.20170101-1+deb9u2.mdwn
deleted file mode 100644
index 36dccb8454..0000000000
--- a/doc/todo/Error_when_using_6.20180913_with_6.20170101-1+deb9u2.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-[A Debian user reports](https://bugs.debian.org/909023) that 6.20180913 cannot be used with a server running the version of git-annex in Debian stretch.  The error is:
-
-    fd:23: hClose: resource vanished (Broken pipe)
-
-Presumably this sudden lack of backwards incompatibility is unintentional.
-
---spwhitton
-
-> Indeed it was, and I'll be making a release in the next couple of days
-> because of the breakage. [[done]] --[[Joey]]
diff --git a/doc/todo/Exporting_with_exporttree_should_sync_files_deleted_from_the_remote.mdwn b/doc/todo/Exporting_with_exporttree_should_sync_files_deleted_from_the_remote.mdwn
deleted file mode 100644
index d31b8a68f6..0000000000
--- a/doc/todo/Exporting_with_exporttree_should_sync_files_deleted_from_the_remote.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-If git-tracked files are removed from the remote, they don't get synced over after a "git annex fsck" and "git annex export".
-
-Is there some way that they could make it to the remote? I'm imagining an rsync-like behavior to copy over files that have different time stamps or file sizes. Would such a feature be welcome in git annex?
-
-> Since git-annex 6.20180626, `git annex fsck --from` an exporttree=yes remote
-> will notice if files on it have been deleted, and then 
-> `git annex sync --content` or `git-annex export` will re-upload them.
-> 
-> But perhaps more interesting, if the remote is also configured with
-> importtree=yes, `git-annex import` from it can now notice deletions
-> as well as other changes to the content on the remote, and make a remote 
-> tracking branch in git reflecting the changes. You can then merge or
-> revert the changes and export or sync can be used to put the deleted 
-> files back on the remote if desired.
->
-> Only a subset of remotes support importree, but the fsck method
-> will work for all. So, this is [[done]]. --[[Joey]] 
diff --git a/doc/todo/Facilitate_public_pretty_S3_URLs.mdwn b/doc/todo/Facilitate_public_pretty_S3_URLs.mdwn
deleted file mode 100644
index 69d09e3fa2..0000000000
--- a/doc/todo/Facilitate_public_pretty_S3_URLs.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-I archive all my photos/video to a bucket CNAMED to http://s.natalian.org/ with a simple YYYY-MM-DD prefix.
-
-E.g. 
-
-I'm not doing a great job of backing up the S3 bucket to another S3 compatible host, since `s3cmd sync`/`aws sync` is so slow, but that's beside the point. Ideally it could be tracked by **git-annex**!
-
-Adding all the objects into git-annex, IIUC currently would require me:
-
-* to download the ~80GB and then add them to git-annex
-* there is no way to keep my current S3 URLs with the [[special_remotes/S3]] since `git-annex` has it's own special way of storing to a bucket, e.g. https://s3-ap-southeast-1.amazonaws.com/s3-10418340-834d-41c2-b38f-7ee84bf6a23a/SHA256E-s1034208123--235e4f288d094c2e1870bc3d9d353abf34542c04c1d26905e882718a7ccf74cf.mp4 - I'd rather not have HTTP redirects
-* AFAICT there is no way currently with git-annex to mark the [[special_remotes/S3]] as public, which is needed for public URLs to work
-* AFAICT there is no current automated method the mapping via `git-annex addurl` with the public URLs of the each file in the bucket
-
-The ideal solution in my mind is for git-annex to track the contents of S3 as they are now, preserving the URLs and tracking the checksums in a separate index file.
-
-Thank you!
-
-> I don't think this is something git-annex can usefully do.
-> Instead, see
-> . --[[Joey]]
-
-> [[done]]; the new `git-annex export` feature allows you to export a tree
-> to a special remote. --[[Joey]]
diff --git a/doc/todo/Facilitate_public_pretty_S3_URLs/comment_1_c803bfef1b881c6f64ed44d49dfb4547._comment b/doc/todo/Facilitate_public_pretty_S3_URLs/comment_1_c803bfef1b881c6f64ed44d49dfb4547._comment
deleted file mode 100644
index 3eb005b945..0000000000
--- a/doc/todo/Facilitate_public_pretty_S3_URLs/comment_1_c803bfef1b881c6f64ed44d49dfb4547._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="similar to a forum question"
- date="2015-03-07T02:05:26Z"
- content="""
-this is similar to a forum question i asked: [[forum/original_filename_on_s3/]]. --[[anarcat]]
-"""]]
diff --git a/doc/todo/Finding_content_in_other_repositories_should_not_need_a_git_remote.mdwn b/doc/todo/Finding_content_in_other_repositories_should_not_need_a_git_remote.mdwn
deleted file mode 100644
index 3025ae7351..0000000000
--- a/doc/todo/Finding_content_in_other_repositories_should_not_need_a_git_remote.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-git annex unused supports an --from option to select a specific remote to find unused data in. When you use that on a repository which is not linked to from the current repository by a git remote, git annex fails:
-
-    $ git annex unused --from somerepository
-    git-annex: there is no available git remote named somerepository
-    $ git annex unused --from repowithremote
-    unused repowithremote (checking for unused data...) 
-    [...]
-
-As git annex at least for newly-deleted files knows when those are stored in the given repository, git annex should at least find those.
-
-> [[done]], made it suppose the uuid or description.
-> 
-> Of course, `dropunused --from` still needs the name of a remote, so this
-> is only useful for querying.. --[[Joey]]
diff --git a/doc/todo/LFS_API_support.mdwn b/doc/todo/LFS_API_support.mdwn
deleted file mode 100644
index 8cb525e940..0000000000
--- a/doc/todo/LFS_API_support.mdwn
+++ /dev/null
@@ -1,101 +0,0 @@
-I was very disappointed to see GitLab [drop support](https://gitlab.com/gitlab-org/gitlab-ee/issues/1648) for git-annex in their 9.0 release in 2017. This makes it impossible to use GitLab to store our blobs. But there is a way out of there.
-
-GitLab, GitHub, Gogs and many other hosting providers actually support the Git LFS API for large file storage. If git-annex would support that API through (say) a special (or builtin) remote, it would be possible to transparently access those contents.
-
-I'm not talking about supporting the *client*-side LFS datastructures. Everything would stay the same from git-annex's point of view. The idea would be to allow pushing/pulling files from Git LFS repositories, quite simply.
-
-Could that work? Would it be possible to just make this into a separate remote without having to hack at git-annex's core?
-
-Thanks for your great work! :) -- [[anarcat]]
-
-> git lfs has some fairly complicated endpoint guessing and discovery;
-> to find the lfs http endpoint for a ssh remote it sshs to the server,
-> runs git-lfs-authenticate there and parses the resulting json. The
-> authentication generates a http basic auth header, which is valid for a
-> few hours or so.
-> 
-> One consequence is that the endpoint can change over time to some other
-> server. It may also be possible for the authentication to return more
-> than one endpoint, not sure. Anyway, I guess that git-annex would need to
-> treat a given lfs remote as a single copy, irrespective of what
-> endpoints discovery finds. So a lfs special remote will get a uuid
-> assigned like any other special remote.
-> 
-> When a git-lfs repo is forked, the fork shares the lfs endpoint of its
-> parent. (And github's lfs bandwidth and storage quotas do too, so it
-> seems it may be possible to fork someone's repo, push big objects to it
-> and eat up *their* quota!) If a special remote is initialized for the
-> parent and another for the clone, git-annex would see two different
-> uuids, and so think there were two copies of objects in them, while
-> there's really just effectively 1 copy.
-> 
-> In the git-lfs protocol, the upload action has an optional "ref"
-> parameter, which is a git ref that the object is associated with.
-> In some cases, a user may only be able to upload objects if the right ref
-> is provided
-> .
-> This could be problimatic because from git-annex's perspective, there's
-> no particular git ref associated with an annex object. I suppose it could
-> always send the current ref. It will need to handle the case where the
-> lfs endpoint rejects a request due to the wrong ref, and communicate this
-> as an error to git-annex, especially in the `checkPresent`
-> implementation.
-> 
-> To implement `checkPresent`, git-annex will need send a "download"
-> request. The response contains a url to use to download the blob;
-> git-annex could either HEAD it to verify it's present, or assume that the
-> lfs endpoint has verified enough that it's present in order to send that
-> response. Since lfs has no way to delete objects, all that `checkPresent`
-> will detect is when the server has lost an object for some reason.
-> 
-> git-lfs has "transfer adapters", but the only important one currently is 
-> the "basic" adaptor, which uses the standard lfs API. The "custom"
-> adapter is equivilant to a git-annex external special remote.
-> 
-> The lfs API is intended to batch together several uploads or downloads
-> into a single response to the endpoint. But git-annex doesn't have a good
-> capacity for batching; for example when git-annex is downloading all 
-> the files in a directory, it goes through them sequentially and expects
-> each download to complete before stating the next.
-> (This limitation also makes Amazon Glacier's
-> batch downloads suboptimal so perhaps git-annex should be improved in
-> some way to support batch requests.) The simple implementation would be
-> to make API requests with a single object in each. Besides being somewhat
-> slower, that risks running into whatever API rate limit the endpoint
-> might have.
-> 
-> > I probed the github lfs endpoint for rate limiting by forcing git-lfs
-> > to re-download a small object repeatedly (deleting the object and running
-> > `git lfs pull`). I tried this with both a http remote with no
-> > authentication (about 1 request per second) and a ssh remote
-> > (one request per 4 seconds). Both successfully got through 1000
-> > requests w/o hitting a rate limit.
-> > 
-> > But, github's rate limiting probably changes dynamically, and google
-> > finds git lfs hitting rate limit when they're having problems in the
-> > past, so this is only a rough idea of the current picture.
-> 
-> That seems to be all the complications involved in implementing this,
-> aside from git-annex needing to know the sha256 and size of an object.
-> --[[Joey]]
-
-> Started some initial work in the `git-lfs` branch. --[[Joey]]
-
-[[done]]! --[[Joey]]
-
----
-
-## related ideas
-
-A couple ideas for possible things that could also be done with git-lfs
-integration. Just to keep in mind while implementing the above.
-
-* git-annex could support git-lfs pointer files. This would let a lfs 
-  repo be cloned and git-annex used to manage the files in it with the
-  finer control it allows compared to git-lfs.
-
-* A lfs API endpoint could serve out of a git-annex repository.
-  One neat thing this would allow is, when git-annex knows an url
-  where an object is located (from the web special remote or another
-  special remote that registers an url), it could direct the lfs
-  client to that url when it requests to download the object.
diff --git a/doc/todo/LFS_API_support/comment_1_24d303ada8bedff1744dc30ad136a265._comment b/doc/todo/LFS_API_support/comment_1_24d303ada8bedff1744dc30ad136a265._comment
deleted file mode 100644
index 20f9a698a4..0000000000
--- a/doc/todo/LFS_API_support/comment_1_24d303ada8bedff1744dc30ad136a265._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-03T17:00:42Z"
- content="""
-I think it's possible to write such an external special remote.
-You would need to generate the hashes that git-lfs uses
-to store files and have git-annex remember them for retrieval, using
-SETSTATE and GETSTATE.
-
-(IIRC git-lfs uses SHA256, so when a git-annex key also does, which is
-common, you could special case it to avoid needing to store state.)
-"""]]
diff --git a/doc/todo/Make_default_annex_version_match___40__clone_or_sync__41___parent.mdwn b/doc/todo/Make_default_annex_version_match___40__clone_or_sync__41___parent.mdwn
deleted file mode 100644
index 723efdea14..0000000000
--- a/doc/todo/Make_default_annex_version_match___40__clone_or_sync__41___parent.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-by default, git-annex will set repo version to v5  
---even if I clone a v6 repo  
---or sync from a v6 repo  
-----(if I sync and there is a git remote in the network which hasn't been git annex initialized yet, it become a v5 repo in its config file)  
-
-so I must always upgrade after creating a new repo, or else specify v6 in the creation command.
-
-Given the potential negative effects of mixed version networks, it is probably best to follow the version of the repo cloned, unless the version is specified in the command.
-
-> [[closing|done]] based on my comment --[[Joey]]
diff --git a/doc/todo/Make_default_annex_version_match___40__clone_or_sync__41___parent/comment_1_ce82ccf68108d47977e32ba005098415._comment b/doc/todo/Make_default_annex_version_match___40__clone_or_sync__41___parent/comment_1_ce82ccf68108d47977e32ba005098415._comment
deleted file mode 100644
index 007a1161cf..0000000000
--- a/doc/todo/Make_default_annex_version_match___40__clone_or_sync__41___parent/comment_1_ce82ccf68108d47977e32ba005098415._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-06-06T17:45:40Z"
- content="""
-I don't feel that the benefits of doing this would be worth the added
-complexity. v6 repositories are still an experimental feature, and just
-because one user is using them does not mean another user necessarily
-will want to. One user might be using a v6 repository with `git annex
-adjust --unlock`, and if so it will remain compatible with v5 clones.
-Only if unlocked files are being committed to a v6 repository is there
-a backwards compatability problem.
-
-And, when there's a central git repository, one clone might be using v6
-mode but clonding from the central repo would still produce a v5 repo,
-so making this change wouldn't help at all with a common case.
-"""]]
diff --git a/doc/todo/Not_working_on_Android-x86.mdwn b/doc/todo/Not_working_on_Android-x86.mdwn
deleted file mode 100644
index 746356cdc9..0000000000
--- a/doc/todo/Not_working_on_Android-x86.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta title="Android is only autobuilt for arm, not x86 or mips"]]
-
-### Please describe the problem.
-
-git-annex doesn't start on [Android-x86](http://www.android-x86.org) in VirtualBox (version 4.1.18-dfsg-2+deb7u1).
-
-On Android 4.2.2 (android-x86-4.2-20130228.iso) it starts the terminal which prints nothing but `[Terminal session finished]`.
-On Android 4.3 (android-x86-4.3-20130725.iso) it starts the terminal and prints:
-
-    In mgmain JNI_OnLoad
-    
-    [Terminal session finished]
-
-The browser/webapp is never started.
-
-### What version of git-annex are you using? On what operating system?
-
-Version 1.0.52 for Android. I made sure to install the correct APK files for each version of Android.
-
-> There is no longer an Android port per se; the Linux port is used in
-> termux. So, many architectures are supported that way. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/Not_working_on_Android-x86/comment_1_5eec4d7530c9df68f1bd1b1ca7021ef5._comment b/doc/todo/Not_working_on_Android-x86/comment_1_5eec4d7530c9df68f1bd1b1ca7021ef5._comment
deleted file mode 100644
index 4bcca0ab4f..0000000000
--- a/doc/todo/Not_working_on_Android-x86/comment_1_5eec4d7530c9df68f1bd1b1ca7021ef5._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.64"
- subject="comment 1"
- date="2013-11-22T16:37:36Z"
- content="""
-git-annex is a native binary, and is currently only being built for arm android.
-
-Is Android on x86 a thing used on real-world hardware? I have only seen it in the context of a developer's test environment.
-
-The instructions for building git-annex from source for Android should work on x86. The ghc-android build would need to be tweaked to build a cross compiler targeting that architecture. This can be done by editing settings near the top of ghc-android's `build.sh`.
-
-I am going to move this from bugs/ to todo/ after posting this comment, because it is certiantly not a bug, but a wishlist item at best.
-"""]]
diff --git a/doc/todo/Not_working_on_Android-x86/comment_2_e5c4c99cb0675ad69bf8d7796be23c8e._comment b/doc/todo/Not_working_on_Android-x86/comment_2_e5c4c99cb0675ad69bf8d7796be23c8e._comment
deleted file mode 100644
index 3f568f5555..0000000000
--- a/doc/todo/Not_working_on_Android-x86/comment_2_e5c4c99cb0675ad69bf8d7796be23c8e._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlYSw35UMlOf9rFlP5EUTBz7is5X09qVXI"
- nickname="Johannes"
- subject="Support on Motorola razr i"
- date="2013-11-28T16:10:38Z"
- content="""
-Hi,
-I'm using the Motorola razr i. So there is a usecase, where a x86 CPU is used in a mobile phone. If it's easy as you described, can you build a Version with x86 support?
-
-Thanks
-Jack
-"""]]
diff --git a/doc/todo/Not_working_on_Android-x86/comment_3_6b609af60bf1c477139e40eba5cb0c4e._comment b/doc/todo/Not_working_on_Android-x86/comment_3_6b609af60bf1c477139e40eba5cb0c4e._comment
deleted file mode 100644
index e4ac8f820d..0000000000
--- a/doc/todo/Not_working_on_Android-x86/comment_3_6b609af60bf1c477139e40eba5cb0c4e._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.191"
- subject="comment 3"
- date="2014-04-20T21:01:50Z"
- content="""
-Samsung Galaxy Tab 3 (GT-P5210)  also needs this.
-
-Each new git-annex builder takes me days to set up, and is an ongoing drain to keep running. I would much rather walk someone else through setting one up, unless this becomes a very common architecture for android.
-"""]]
diff --git a/doc/todo/Retire_Esqueleto_as_a_dependency.mdwn b/doc/todo/Retire_Esqueleto_as_a_dependency.mdwn
deleted file mode 100644
index 87e597414f..0000000000
--- a/doc/todo/Retire_Esqueleto_as_a_dependency.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-Since Esqueleto is seemingly abandoned and it's causing grief with NixOS: [[https://git-annex.branchable.com/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09/]] I did the work to remove it as a dependency in this commit
-[[https://github.com/seanparsons/git-annex/commit/62f291262f37327d9b2a864cd701aacb03766115]]
-
-Alongside that is a bunch of nix specific files that support the building and/or development of git-annex, which is pretty much anything with "nix" in the name in the patch.
-
-> Went ahead and merged it! [[done]] Thank you for your contribution to
-> git-annex. --[[Joey]]
diff --git a/doc/todo/Retire_Esqueleto_as_a_dependency/comment_1_b022e0e0a7711f306036b457a34144e4._comment b/doc/todo/Retire_Esqueleto_as_a_dependency/comment_1_b022e0e0a7711f306036b457a34144e4._comment
deleted file mode 100644
index de962ed37e..0000000000
--- a/doc/todo/Retire_Esqueleto_as_a_dependency/comment_1_b022e0e0a7711f306036b457a34144e4._comment
+++ /dev/null
@@ -1,58 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-11-05T17:34:43Z"
- content="""
-Wow, this is impressive work!
-
-I was aware of the maintenance difficulties, but 
-had not realized it would be feasible to remove Esqueleto.
-
-That said, is it fully abandoned or only hit a rough patch?
-Last I heard there was at least desire to keep it going, and indeed 
-esqueleto's git master will build with the current haskell ecosystem. 
-But they wanted to make some other "correctness" changes before release.
-It felt to me like perhaps tying those changes together with the Persistent
-upgrade was not a great decision, but hard to tell.
-
-
-This seems certianly wrong; it's lost the NOT.
-
-	  addAssociatedFile ik f = queueDb $ do
-	  	-- If the same file was associated with a different key before,
-	  	-- remove that.
-	-	delete $ from $ \r -> do
-	-		where_ (r ^. AssociatedFile ==. val af &&. not_ (r ^. AssociatedKey ==. val ik))
-	+	deleteWhere [AssociatedFile ==. af, AssociatedKey ==. ik]
-
-Otherwise, looking over the patch, it looks like it probably does the same thing,
-but my memory of persistent's SQL DSL is fuzzy and I'm not 100% sure.
-Is there any way to verify the same or equivilant SQL gets generated?
-
-One hunk I'm unsure about:
-
-	- removeExportTree h k loc = queueDb h $ 
-	- 	delete $ from $ \r ->
-	- 		where_ (r ^. ExportTreeKey ==. val ik &&. r ^. ExportTreeFile ==. val ef)
-	+ removeExportTree h k loc = queueDb h $
-	+ 	deleteWhere [ExportTreeKey ==. ik, ExportTreeFile ==. ef]
-
-Not clear from persistent's documentation if deleteWhere with two
-Filters combines them with AND or OR? Looks like there's a FilterAnd
-that would clearly do the same thing as the esquelito version.
-
-Similarly unsure about the removeExportedLocation and removeAssociatedFile
-and addAssociatedFile hunks.
-
-Do we know that an empty Filter list matches everything as used below
-instead of nothing? Not clear to me from the documentation.
-
-	  dropAllAssociatedFiles :: WriteHandle -> IO ()
-	  dropAllAssociatedFiles = queueDb $
-	-  	delete $ from $ \(_r :: SqlExpr (Entity Associated)) -> return ()
-	+ 	deleteWhere ([] :: [Filter Associated])
-
-Of course I can test all of these questions, and it would be good
-to expand the test suite to test the SQL code in isolation, but
-maybe you know the answers already.
-"""]]
diff --git a/doc/todo/Retire_Esqueleto_as_a_dependency/comment_2_3a3143db7124fe8790b23fdc820a7eed._comment b/doc/todo/Retire_Esqueleto_as_a_dependency/comment_2_3a3143db7124fe8790b23fdc820a7eed._comment
deleted file mode 100644
index 5c4b94e0ce..0000000000
--- a/doc/todo/Retire_Esqueleto_as_a_dependency/comment_2_3a3143db7124fe8790b23fdc820a7eed._comment
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!comment format=mdwn
- username="seantparsons"
- avatar="http://cdn.libravatar.org/avatar/616fb81847630239dd1ab099138cb685"
- subject="comment 2"
- date="2018-11-06T22:50:25Z"
- content="""
-I've pushed the fix needed to my branch: [[https://github.com/seanparsons/git-annex/tree/remove-esqueleto]]
-
-    This seems certianly wrong; it's lost the NOT.
-
-Well spotted, I even remember double checking the not equal syntax, that should be fixed now.
-
-    Is there any way to verify the same or equivilant SQL gets generated?
-
-I don't believe so, but I'm not an expert in either project I mostly just turned the \"fix compile errors until there are none\" crank.
-
-    Not clear from persistent's documentation if deleteWhere with two Filters combines them with AND or OR?
-
-From the docs relating to the `Filter` type ([[http://hackage.haskell.org/package/persistent-2.9.0/docs/Database-Persist.html#v:-124--124-.]]):
-
-    If you are looking for an (&&.) operator to do (A AND B AND (C OR D)) you can use the (++) operator instead as there is no (&&.).
-
-That seems pretty conclusive multiple entries in a list are combined with `FilterAnd`.
-
-    Do we know that an empty Filter list matches everything as used below instead of nothing? Not clear to me from the documentation.
-
-Yup, the type hint indicates that it relates to the table: https://www.yesodweb.com/book/persistent#persistent_delete
-
-    it would be good to expand the test suite to test the SQL code in isolation
-
-I can probably look at adding some more tests this weekend.
-"""]]
diff --git a/doc/todo/Retire_Esqueleto_as_a_dependency/comment_3_a07fa20980fe3a41077e83db9c71cc98._comment b/doc/todo/Retire_Esqueleto_as_a_dependency/comment_3_a07fa20980fe3a41077e83db9c71cc98._comment
deleted file mode 100644
index b2192c360a..0000000000
--- a/doc/todo/Retire_Esqueleto_as_a_dependency/comment_3_a07fa20980fe3a41077e83db9c71cc98._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-11-10T16:02:28Z"
- content="""
-Thanks for answering my questions.
-
-I've pulled remove-esqueleto into my repo, and I'm fairly
-ready to merge it. git-annex test passes. It would be good, but not
-mandatory to improve the test suite, so I'll wait and see what you do this
-weekend.
-"""]]
diff --git a/doc/todo/S3_anonymous_exporttree_support.mdwn b/doc/todo/S3_anonymous_exporttree_support.mdwn
deleted file mode 100644
index 681a5943ea..0000000000
--- a/doc/todo/S3_anonymous_exporttree_support.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-S3 remotes using exporttree=yes cannot currently be accessed w/o creds.
-This is possible to support with some work. --[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/S3_fsck_support.mdwn b/doc/todo/S3_fsck_support.mdwn
deleted file mode 100644
index b9ded40952..0000000000
--- a/doc/todo/S3_fsck_support.mdwn
+++ /dev/null
@@ -1,58 +0,0 @@
-I have (i think?) noticed that the s3 remote doesn't really do an fsck:
-
-http://source.git-annex.branchable.com/?p=source.git;a=blob;f=Remote/S3.hs;hb=HEAD#l86
-
-Besides, unless S3 does something magic and amazingly fast, the checksum is just too slow for it to be really operational:
-
-
-$ time git annex fsck -f s3 video/original/quartet_for_deafblind_h264kbs18000_24.mov
-fsck video/original/quartet_for_deafblind_h264kbs18000_24.mov (checking s3...) ok
-(recording state in git...)
-
-real    0m1.188s
-user    0m0.444s
-sys     0m0.324s
-$ time git annex fsck video/original/quartet_for_deafblind_h264kbs18000_24.mov
-fsck video/original/quartet_for_deafblind_h264kbs18000_24.mov (checksum...)
-ok
-(recording state in git...)
-
-real    3m14.478s
-user    1m55.679s
-sys     0m8.325s
-

-
-1s is barely the time for git-annex to do an HTTP request to amazon, and what is returned doesn't seem to have a checksum of any kind:
-
-
-fsck video/original/quartet_for_deafblind_h264kbs18000_24.mov (checking s3...) [2015-06-16 00:31:46 UTC] String to sign: "HEAD\n\n\nTue, 16 Jun 2015 00:31:46 GMT\n/isuma-files/SHA256E-s11855411701--ba268f1c401321db08d4cb149d73a51a10f02968687cb41f06051943b4720465.mov"
-[2015-06-16 00:31:46 UTC] Host: "isuma-files.s3.amazonaws.com"
-[2015-06-16 00:31:46 UTC] Response header 'x-amz-request-id': '9BF7B64EB5A619F3'
-[2015-06-16 00:31:46 UTC] Response header 'x-amz-id-2': '84ZO7IZ0dqJeEghADjt7hTGKGqGAWwbwwaCFVft3ama+oDOVJrvpiFjqn8EY3Z0R'
-[2015-06-16 00:31:46 UTC] Response header 'Content-Type': 'application/xml'
-[2015-06-16 00:31:46 UTC] Response header 'Transfer-Encoding': 'chunked'
-[2015-06-16 00:31:46 UTC] Response header 'Date': 'Tue, 16 Jun 2015 00:32:10 GMT'
-[2015-06-16 00:31:46 UTC] Response header 'Server': 'AmazonS3'
-[2015-06-16 00:31:46 UTC] Response metadata: S3: request ID=, x-amz-id-2=
-ok
-

-
-did i miss something? are there fsck checks for s3 remotes?
-
-if not, i think it would be useful to leverage the "md5summing" functionality that the S3 API provides. there are two relevant stackoverflow responses here:
-
-http://stackoverflow.com/questions/1775816/how-to-get-the-md5sum-of-a-file-on-amazons-s3
-http://stackoverflow.com/questions/8618218/amazon-s3-checksum
-
-... to paraphrase: when a file is `PUT` on S3, one can provide a `Content-MD5` header that S3 will check against the uploaded file content for corruption, when doing the upload. then there is some talk about how the `ETag` header *may* hold the MD5, but that seems inconclusive. There's a specific API call for getting the MD5 sum:
-
-https://docs.aws.amazon.com/AWSAndroidSDK/latest/javadoc/com/amazonaws/services/s3/model/ObjectMetadata.html#getContentMD5()
-
-the android client also happens to check with that API on downloads:
-
-https://github.com/aws/aws-sdk-android/blob/4de3a3146d66d9ab5684eb5e71d5a2cef9f4dec9/aws-android-sdk-s3/src/main/java/com/amazonaws/services/s3/AmazonS3Client.java#L1302
-
-now of course MD5 is a pile of dung nowadays, but having that checksum beats not having any checksum at all. *and* it is at no cost on the client side... --[[anarcat]]
-
-> Don't think there's anything for git-annex to do here, so [[done]]
-> --[[Joey]]
diff --git a/doc/todo/S3_fsck_support/comment_1_9317598723ea38ae9432ad50e0de666d._comment b/doc/todo/S3_fsck_support/comment_1_9317598723ea38ae9432ad50e0de666d._comment
deleted file mode 100644
index 6a66335d74..0000000000
--- a/doc/todo/S3_fsck_support/comment_1_9317598723ea38ae9432ad50e0de666d._comment
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-06-16T17:50:56Z"
- content="""
-You're incorrect; `git-annex fsck --from remote` works to fsck *any*
-remote. For remotes like S3, it has to download the content to check it
-locally, which is why `remoteFsck` is not provided.
-
-Since you passed -f (--fast) to fsck, it avoids checksuming the content,
-so avoids downloading it, and only verifies that S3 still says it has
-the content. As documented on the git-annex fsck man page.
-
-AFAICS, the Content-MD5 is only used by S3 to check that the data uploaded
-to S3 didn't get corrupted over the wire. I assume that S3 implements its
-own checksums to detect when data already stored on it gets corrupted, so
-it seems redundant and complicating for git-annex to query it for md5sums.
-It would work just as well for git-annex to verify a key after downloading
-it, using the key's own hash, per [[todo/ checksum verification on transfer]].
-
-It **might** be worth filling in the `poContentMD5` field with the md5 of
-the file when uploading it to S3. Of course, this requires hashing the file
-locally. And when storing an encrypted object on S3, it would require
-buffering the whole encrypted object to disk first, in order to hash it
-(but that's currently done anyway).
-"""]]
diff --git a/doc/todo/S3_fsck_support/comment_2_7a1ce64d362b8f75adf22709771a7787._comment b/doc/todo/S3_fsck_support/comment_2_7a1ce64d362b8f75adf22709771a7787._comment
deleted file mode 100644
index a27ed8e567..0000000000
--- a/doc/todo/S3_fsck_support/comment_2_7a1ce64d362b8f75adf22709771a7787._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- subject="comment 2"
- date="2015-06-16T20:10:50Z"
- content="""
-understood: i thought `-f` was `--from`... hence my confusion.
-
-as for `remoteFsck`, i guess what i am saying is exactly that: there *does* seem to be a way to do a remote checksum of the file *without* downloading it. it seems to be a critical advantage over having to download the whole repository to check it... maybe `--fast` could use that technique and `non--fast` would download?
-
-as for the on-wire MD5 stuff, that does seem to be overkill...
-"""]]
diff --git a/doc/todo/S3_fsck_support/comment_3_2b96f61188b2ada729a284e95fc89dab._comment b/doc/todo/S3_fsck_support/comment_3_2b96f61188b2ada729a284e95fc89dab._comment
deleted file mode 100644
index fea0477543..0000000000
--- a/doc/todo/S3_fsck_support/comment_3_2b96f61188b2ada729a284e95fc89dab._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-07-02T16:43:03Z"
- content="""
-Not knowing how S3's backend is implemented, I have to assume that, in
-order to get the advertised number of 9's of reliability, it involves some
-replication of data, as well as some method to detect if a bit has flipped
-or a drive has died, and recover.
-
-This is requesting that git-annex ask S3 for a md5sum, and compare it
-against a md5sum that it, presumably, keeps track of locally. If the two
-are different, git-annex could tell that S3 has lost data. But, git-annex is
-in a much worse position to tell if S3 has lost data then S3 itself is.
-It seems very unlikely that this extra checking would ever detect a problem
-that S3 didn't itself detect and fix (or in the 0.00001% case, 
-fail to fix and delete the lost file?)
-
-Bit flips during transfer seem more likely than that. `poContentMD5` could
-help guard against those.
-"""]]
diff --git a/doc/todo/Support_for_include_matching_option_in_findref.mdwn b/doc/todo/Support_for_include_matching_option_in_findref.mdwn
deleted file mode 100644
index 1c36ba3c5d..0000000000
--- a/doc/todo/Support_for_include_matching_option_in_findref.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-The documentation for `findref` says it accepts the same options as `find` but the matching option `--include` isn't supported here.
-
-This leads to the confusing behavior where `findref` is sensitive to the presence of content, but you can't tell it not to be in the same manner as `find`.
-
-Could the difference be removed by adding support for `--include`?
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/Support_for_include_matching_option_in_findref/comment_1_2b113c2ef62ccc473cdeec08e5b7fac1._comment b/doc/todo/Support_for_include_matching_option_in_findref/comment_1_2b113c2ef62ccc473cdeec08e5b7fac1._comment
deleted file mode 100644
index 943cc4aca0..0000000000
--- a/doc/todo/Support_for_include_matching_option_in_findref/comment_1_2b113c2ef62ccc473cdeec08e5b7fac1._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-09T16:27:14Z"
- content="""
-Relatedly, commands that support --branch and file matching options
-silently fail to match the file matching options. Eg, this does not copy
-anything:
-
-	git annex copy --branch master --to origin --include='*'
-"""]]
diff --git a/doc/todo/Test_cases_for_exporttree_special_remotes.mdwn b/doc/todo/Test_cases_for_exporttree_special_remotes.mdwn
deleted file mode 100644
index 3d32b2c710..0000000000
--- a/doc/todo/Test_cases_for_exporttree_special_remotes.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-As far as I can tell, `git annex testremote` doesn't test exporting yet
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/Test_cases_for_exporttree_special_remotes/comment_1_4db9a4b9cb94ba7ee460ee81fe52bf86._comment b/doc/todo/Test_cases_for_exporttree_special_remotes/comment_1_4db9a4b9cb94ba7ee460ee81fe52bf86._comment
deleted file mode 100644
index 18caa43f80..0000000000
--- a/doc/todo/Test_cases_for_exporttree_special_remotes/comment_1_4db9a4b9cb94ba7ee460ee81fe52bf86._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-11-07T21:07:00Z"
- content="""
-That's right, exporttree is not tested yet.
-Thanks for the reminder.
-"""]]
diff --git a/doc/todo/Test_cases_for_exporttree_special_remotes/comment_2_0e280ec5691dbb0eef68f6e6c1424d08._comment b/doc/todo/Test_cases_for_exporttree_special_remotes/comment_2_0e280ec5691dbb0eef68f6e6c1424d08._comment
deleted file mode 100644
index 5cbb24e598..0000000000
--- a/doc/todo/Test_cases_for_exporttree_special_remotes/comment_2_0e280ec5691dbb0eef68f6e6c1424d08._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-11-08T17:38:02Z"
- content="""
-Added some fairly comprehensive tests.
-"""]]
diff --git a/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol.mdwn b/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol.mdwn
deleted file mode 100644
index 25dea6eef5..0000000000
--- a/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-As shown by benchmarks in
-*[[here|todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__]]*,
-there is some overhead for each file transfer to a rsync special remote, to
-set up the connection. Idea is to extend git-annex-shell with a command or
-commands that don't use rsync for transferring objects, and that can handle
-transferring or otherwise operating on multiple objects inside a single tcp
-session.
-
-This might only be used when it doesn't need to resume transfer of a file;
-it could fall back to rsync for resuming.
-
-Of course, when talking with a git-annex-shell that does not support this
-new command, git-annex would still need to fall back to the old commands
-using rsync. And should remember for the session that the remote doesn't
-support the new command.
-
-It could use sftp, but that seems kind of difficult; it would need to lock
-down sftp-server to only write annexed objects to the right repository.
-And, using sftp would mean that git-annex would need to figure out the
-filenames to use for annexed objects in the remote repository, rather than
-letting git-annex-shell on the remote work that out.
-
-So, it seems better to not use sftp, and instead roll our own simple
-file transfer protocol.
-
-So, "git-annex-shell -c p2pstdio" would speak a protocol over stdin/stdout
-that essentially contains the commands inannex, lockcontent, dropkey,
-recvkey, and sendkey.
-
-P2P.Protocol already contains such a similar protocol, used over tor.
-That protocol even supports resuming interrupted transfers.
-It has stuff including auth that this wouldn't need, but it would be
-good to unify with it as much as possible.
-
-----
-
-Benchmarks
-
-Dropping 200 files from a remote over a satellite internet connection,
-speed increased from 364s to 183s.
-
-Dropping 1000 files from a remote over ssh to localhost, with -J4, 
-speed increased from 20s to 6s. Without -J4, speed increased from 41s to
-10s.
-
-(By comparison, dropping 1000 files from a remote on the same filesystem
-took 12s, so remote access over localhost seems faster now! Possibly
-there's a little bit more concurrency when git-annex and git-annex-shell
-are both running?)
-
-Transferring a 30 mb file over ssh to localhost, speed increased from
-3.288s to 3.031s. Due to rsync's several levels of checksumming?
-
-Dropping 1000 files from local, with each being locked on a ssh localhost
-remote, speed increased from 30s to 7s.
-
-[[done]]
diff --git a/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol/comment_1_504f0e728edad9b35cd88e8a657fd5bb._comment b/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol/comment_1_504f0e728edad9b35cd88e8a657fd5bb._comment
deleted file mode 100644
index 2de537d423..0000000000
--- a/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol/comment_1_504f0e728edad9b35cd88e8a657fd5bb._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 1"
- date="2018-03-06T20:33:44Z"
- content="""
-only marginally related since may be the abstraction level is at different level? but thought to add thoughts on \"bundling\" also calls to get stuff from web remote:
-
-although both curl and wget do allow for multiple URLs to be specified within a single invocation (which manual also recommends for download of multiple files since avoids reestablishing the session) I could not find any way to provide those URLs with target filenames as it would be needed for git-annex to store into corresponding target key files. The only way would be to parse wget output (which IIRC git annex already does for progress reporting), get the target filename and move into a proper location
-
-[[!format sh \"\"\"
-$> wget -iwget-links -nv --show-progress --clobber
-highres001.nii.gz?ve 100%[===================>]   5.40M  2.30MB/s    in 2.3s    
-2018-03-06 15:31:49 URL:http://openneuro.s3.amazonaws.com/ds000001/ds000001_R1.1.0/uncompressed/sub001/anatomy/highres001.nii.gz?versionId=8TJ17W9WInNkQPdiQ9vS7wo8ZJ9llF80 [5663237/5663237] -> \"highres001.nii.gz?versionId=8TJ17W9WInNkQPdiQ9vS7wo8ZJ9llF80.2\" [1]
-inplane001.nii.gz?ve 100%[===================>] 653.88K  1.10MB/s    in 0.6s    
-2018-03-06 15:31:50 URL:http://openneuro.s3.amazonaws.com/ds000001/ds000001_R1.1.0/uncompressed/sub001/anatomy/inplane001.nii.gz?versionId=ystKDnaPkdzSwzdRPZH0PtMMknZJCQV4 [669578/669578] -> \"inplane001.nii.gz?versionId=ystKDnaPkdzSwzdRPZH0PtMMknZJCQV4.1\" [1]
-FINISHED --2018-03-06 15:31:50--
-Total wall clock time: 3.2s
-Downloaded: 2 files, 6.0M in 2.9s (2.06 MB/s)
-\"\"\"]]
-"""]]
diff --git a/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol/comment_2_660c9ece3dbfb2eb20b42b71826a4fbc._comment b/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol/comment_2_660c9ece3dbfb2eb20b42b71826a4fbc._comment
deleted file mode 100644
index 7adf5f3a96..0000000000
--- a/doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol/comment_2_660c9ece3dbfb2eb20b42b71826a4fbc._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-03-09T17:50:24Z"
- content="""
-That's the same problem as bundling multiple files with rsync, just a
-different remote with a different program.
-
-If wget/curl invocation speed is actually a bottleneck, it might help to
-have git-annex use native haskell http-conduit for http downloads. That
-would allow for http connection pipelining. Please open a separate todo
-though, this one is only about git-annex-shell speed.
-"""]]
diff --git a/doc/todo/adb_import.mdwn b/doc/todo/adb_import.mdwn
deleted file mode 100644
index dc26dfa9ed..0000000000
--- a/doc/todo/adb_import.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-Make adb special remote support import tree.
-
-This would be very useful for syncing with an android device without
-needing to run git-annex on it. While git-annex works well enough in
-termux, the horribleness of android's /sdcard makes it unappealing to put a
-git annex repository on it (direct mode is still the best option there;
-v7 unlocked works but without hard links has to store two copies of each
-file).
-
-This needs at a minimum a way to list files in a directory via adb,
-in order to find new files. `adb shell find /sdcard/ -type f` seems to work
-across a range of android versions (5.1, 8.1).
-
-To avoid re-downloading each file each import, a way to list files
-along with a good content identifier is needed.
-`adb shell find /sdcard/ -type f -exec stat -c "'%d %i %s %Y %n'" {} +`
-works on (5.1, 8.1) (note the weird quoting that it needs)
-
-To avoid losing modifications to files 
-that the user makes using the android device while the same files are being
-exported to it would need an upload to a temp location followed by a check
-that the original is unmodified before renaming. This needs
-shell scripting in android's limited shell environment, or
-`adb shell stat 'origfile'` followed by `adb shell mv 'tmpfile' 'origfile'`.
-
-That is necessarily racy, although the race window is
-probably not much wider than the similar races when git checkout stats
-work tree files before overwriting them.
-
-Alternatively, the documentation could tell the user to avoid modifying files
-on their android device while git-annex is exporting to it, or to instead
-only ever modify files on the android device, and import from it, but not
-export any changes to it. (Or some combination of those 
-for different subdirectories on it.) But it seems like this won't be
-necessary.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/adb_special_remote.mdwn b/doc/todo/adb_special_remote.mdwn
deleted file mode 100644
index d183511e44..0000000000
--- a/doc/todo/adb_special_remote.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-Make a special remote using adb to send file to an android device.
-
-While there is an android port, a special remote will suffice for many use
-cases, and may work better overall.
-
-It should support exporttree=yes, since most use cases involve exporting a
-tree of files and consuming them on the android device.
-
-Use adb push, adb pull, and use adb shell for checkpresent and remove.
-
-Ought to implement [[import tree]] too, so that changes made
-to files on the android device can be imported back into the git
-repository.
-
-And, [[export preferred content]] would be a useful feature for
-excluding some files from a tree exported to android.
-
-> Status: Remote implemented, but not yet [[import tree]] and
-> [[export preferred content]]. --[[Joey]]
-
-> Update: Import from adb is now implemented. Closing [[done]] --[[Joey]]
diff --git a/doc/todo/add_prefix_option_to_export.mdwn b/doc/todo/add_prefix_option_to_export.mdwn
deleted file mode 100644
index e219e41c69..0000000000
--- a/doc/todo/add_prefix_option_to_export.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-Could we add a prefix option to [git-annex-export](https://git-annex.branchable.com/git-annex-export/)?
-
-Something like `git annex export master:some-videos --to myexport --prefix share-with-john` would create a new subdirectory called `share-with-john` on the `myexport` exporttree remote and copy all files from the local `some-videos` directory into the new `share-with-john` directory.
-
-I could then do another export using the same remote like `git annex export master:some-other-videos --to myexport --prefix share-with-bill` which wouldn't touch any of the videos I previously shared with john but would create a new export into a new `share-with-bill` directory.
-
-My goal with the prefix option is to setup an exporttree remote one time, but then be able to re-use this same remote multiple times to create independent publicly shared folders.
-
-> [[done]], seems we've decided against adding this --[[Joey]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_1_e13e593ba8c62ce630bc3456cb4e0f10._comment b/doc/todo/add_prefix_option_to_export/comment_1_e13e593ba8c62ce630bc3456cb4e0f10._comment
deleted file mode 100644
index 07ef83bd33..0000000000
--- a/doc/todo/add_prefix_option_to_export/comment_1_e13e593ba8c62ce630bc3456cb4e0f10._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-11-19T17:19:54Z"
- content="""
-This would complicate the data structures git-annex needs for an export remote.
-
-Notably, git-annex relies on location tracking information in the git-annex
-branch, which tracks whether or not a remote contains an object. With
-multiple subdirectories in the same remote, one could contain an object and
-another one not. There's no way to record that without some kind of unique
-identifier for each tree in the remote.
-
-So I think this is better handled by initializing one remote per export
-directory, and using something like S3's fileprefix= option. Of the remotes
-supporting exporttree so far, only S3 has such a thing; it would make sense
-to add it to webdav, and perhaps rsync and adb. (Seems that for directory
-it's easier to just make a new directory.) 
-
-Can I ask what type of special remote you were wanting this feature for?
-"""]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_2_c2df40a099db6059b28c79259b689da6._comment b/doc/todo/add_prefix_option_to_export/comment_2_c2df40a099db6059b28c79259b689da6._comment
deleted file mode 100644
index c330aba674..0000000000
--- a/doc/todo/add_prefix_option_to_export/comment_2_c2df40a099db6059b28c79259b689da6._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-11-19T19:40:59Z"
- content="""
-TBH, an exported tree can contain the same content in two files,
-and the export database does contain information to deal with that;
-the location log doesn't really need to be modified to support this.
-
-Another way to look at it is that you want to build a larger tree, that
-contains two or more trees in subdirectories, and export the larger tree
-to the top of the remote. And if you look at this that way, it's
-already possible to do what you want using only git commands like `git mktree`.
-"""]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_3_c76aa611a2b389b9d7a0512a733c0d03._comment b/doc/todo/add_prefix_option_to_export/comment_3_c76aa611a2b389b9d7a0512a733c0d03._comment
deleted file mode 100644
index e3d5bae9af..0000000000
--- a/doc/todo/add_prefix_option_to_export/comment_3_c76aa611a2b389b9d7a0512a733c0d03._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="comment 3"
- date="2018-11-20T17:45:34Z"
- content="""
-OK. Excellent, yes `git mktree` sounds promising, although I might still need an additional option to `export` to achieve my goals (maybe `--append-only` see last paragraph). Here is more detail on my use case:
-
-I am looking to add a `Share` feature to [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle). Often, I have one file, or a few files that I wish to share with people. Typically I will upload these to google drive and then create a public share link from the entire folder they are in, then share that with people over email. With `git-annex-turtle` I would like a user to be able to right-click on a file, a multiple-file selection or a folder, choose `Share` and then have these files shared somewhere publicly, then report back to the user the public URL of this share (via their clipboard or a dialog).
-
-I don't know what remote types would be desirable for `git-annex-turtle` users, but I was hoping that I could find a solution that could work for any remote type that already supports public file downloads and the `exporttree` option. Probably rsync, s3 and google drive would be a good first start. s3 and google drive already support public downloads and a savy user could certainly make their rsync remote support public downloads as well.
-
-The issue with *“initializing one remote per export directory”* is that I would like to minimize effort for my `git-annex-turtle` users. I think it is reasonable to ask them to setup one public remote one time, then they can re-use that remote anytime they want to share something new. But I wouldn't want to have to ask them to create a new remote everytime they click the `Share` button. It is certainly plausible that I could automate this process, but then I would need to investigate storing security credentials and the various authentication mechanism for various supported remotes and write code to auto-generate new remotes of various types on the fly.
-
-Using `git mktree` seems very promising since I could pass it an arbitrary set of 1 or more files or folders that are already present in `git`, create a new tree then share that tree using the export command. One problem with this is that it becomes tricky when I want to share another tree, without deleting previously exported trees (right?). I think, if I could keep track of all trees previously shared I could create a new tree containing all of the old trees and the new tree. But, I don't want to do this, because `git-annex-turtle` is designed to store no critical file or content information that can't be automatically recreated from the git repositories themselves.
-
-I am wondering if adding an option like `--append-only` to the `export` command would resolve this issue? This option would disable the entire merge process, never deleting content from a remote, only ever adding. I could then create new trees using `git mktree` anytime I want to do a new share and just do the export of that new tree with the `--append-only` option and not have to worry about `git annex` trying to merge changes and delete previously exported trees? Or perhaps this isn't any easier than a `--prefix` option since the `export` command needs to locally keep track of what it exported? Perhaps there could be a new command instead of `export`? Some kind of command that supports any remote that already supports the `exporttree` option? Perhaps something like `git annex copy-tree treeish --to the-public-remote` would copy a tree to a remote using something similar to the `export` mechanism but would never attempt to do any merging and would never keep track of what was uploaded. Or perhaps the `--append-only` option to `export` could behave similarly, never keeping track locally of what was uploaded.
-
-
-
-
-
-"""]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_4_441bf863b2d4d418f7d2dbc376428ef6._comment b/doc/todo/add_prefix_option_to_export/comment_4_441bf863b2d4d418f7d2dbc376428ef6._comment
deleted file mode 100644
index 43c7968451..0000000000
--- a/doc/todo/add_prefix_option_to_export/comment_4_441bf863b2d4d418f7d2dbc376428ef6._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="comment 4"
- date="2018-11-26T15:42:36Z"
- content="""
-After thinking about this for a few days I am thinking that the existing `git-annex export` functionality can work well. I think I will have users specify a local directory in their annex called something like `public-share` along with a single public exporttree remote to use with that local share. Whenever the user clicks `Share` on a single file (or folder or multi-selection of files and folders) i'll just create a new sub-directory in `public-share` called something like `public-share/CURRENT_DATETIME/` and place all of the new files to share in there. Then i'll do an export like: `git-annex export master:public-share --to=public-tree-remote`. This takes advantage of the existing export functionality and has the added benefit of giving the user a local record of all files that are currently publicly shared, which seems pretty useful.
-"""]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_5_fe7223a5321b8a4aef723e276513f5be._comment b/doc/todo/add_prefix_option_to_export/comment_5_fe7223a5321b8a4aef723e276513f5be._comment
deleted file mode 100644
index 64a639c6e6..0000000000
--- a/doc/todo/add_prefix_option_to_export/comment_5_fe7223a5321b8a4aef723e276513f5be._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2018-12-03T17:53:59Z"
- content="""
-I wonder if you'd be better off querying `git annex whereis --json` 
-for public urls and providing those to the users. Several special remotes
-provide public urls. (S3 needs a non-default configuration to do it.)
-
-Anyway back to your question, git-annex arranges for the exported tree to
-always be available, including across clones of the repository. So you can
-get the exported tree, graft another file into it, and export the new tree.
-
-So how to look up the previously exported tree? [[/internals]] documents
-how to find it in the export.log, but it seems there ought to be a
-command-line interface to query for it. So I've made `git annex info remote`
-provide that information, as "exportedtree". Note that in an export
-conflict it may have multiple values. You'll want to use --fast with that,
-and probably --json.
-
-Let me know if you need something more, or if this todo can be closed with
-that.
-"""]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_6_e617a4b1d5833daa5287e168f6d41da1._comment b/doc/todo/add_prefix_option_to_export/comment_6_e617a4b1d5833daa5287e168f6d41da1._comment
deleted file mode 100644
index 1de8bccec2..0000000000
--- a/doc/todo/add_prefix_option_to_export/comment_6_e617a4b1d5833daa5287e168f6d41da1._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2018-12-04T16:58:12Z"
- content="""
-I think that's a good, simple plan.
-"""]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_7_5635d23fae7d9464605389b03af11565._comment b/doc/todo/add_prefix_option_to_export/comment_7_5635d23fae7d9464605389b03af11565._comment
deleted file mode 100644
index 1d77457df0..0000000000
--- a/doc/todo/add_prefix_option_to_export/comment_7_5635d23fae7d9464605389b03af11565._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="comment 7"
- date="2018-12-08T16:46:34Z"
- content="""
-Perfect thanks. Yes fine to mark as done.
-
-Thank you for adding additional information about exporttree to `git annex info remote` that will prove useful if I do go done that route at a future date.
-
-Yes, I do plan to lookup public URLs with `git annex whereis --json`.
-"""]]
diff --git a/doc/todo/addurl_should_fail_when_youtube-dl_disabled.mdwn b/doc/todo/addurl_should_fail_when_youtube-dl_disabled.mdwn
deleted file mode 100644
index 1d6cf80778..0000000000
--- a/doc/todo/addurl_should_fail_when_youtube-dl_disabled.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-When using addurl on an url that youtube-dl supports, if it's installed but
-not enabled to be used due to the recent security fix, git-annex will
-download the web page and add it, which is unlikely to be desired behavior.
-Instead, it should check if youtube-dl supports the page, and then error
-out at the download stage, with a message that points at how to enable it.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/amazon_prime_photos.mdwn b/doc/todo/amazon_prime_photos.mdwn
deleted file mode 100644
index 77342e1fe4..0000000000
--- a/doc/todo/amazon_prime_photos.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
- just  thought to check if you anyhow considered it  Joey: https://www.amazon.ca/clouddrive/primephotos ,  which could be a  great  feature for  those with prime,  even if only for photos.  didn't check about any API
-
- cheers
-
-> I don't want to add such a niche special remote to git-annex, but if
-> someone wants to implement it as an external special remote, they could
-> certianly do so. Similar things have been done for using other photo
-> storage services. [[done]] --[[Joey]]
diff --git a/doc/todo/append-only_mode.mdwn b/doc/todo/append-only_mode.mdwn
deleted file mode 100644
index c3b6d621a4..0000000000
--- a/doc/todo/append-only_mode.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-The [[git-annex-shell]] wrapper allows the configuration of a readonly
-repository (through the `GIT_ANNEX_READONLY` environment and friends)
-but that is useful only when we want users to access the data and not
-add to it.
-
-It would be nice to have a *write-only* or "append-only" mode. My use
-case is a backup server that would receive git-annex objects and
-changes, but would forbid the client from deleting content on the
-server. This is to protect contents from being destroyed (or encrypted
-as is a common pattern with ransomware) by a compromised client.
-
-There has been some discussions and work done to protect *branches* in
-such a way, in
-[[todo/git-hook_to_sanity-check_git-annex_branch_pushes]], and that
-could help, but even with git hooks, a malicious client could still
-drop content.
-
-It seems to me this would require modifications to the
-`git-annex-shell` wrapper to forbid certain operations like `dropkey`,
-`lockcontent`, or `p2pstdio` although I'm unfamiliar with the last two
-so I am not certain they could be harmful. Maybe `p2pstdio` itself
-could be somewhat fixed to allow only append commands.
-
-Is it fair to assume that `recvkey` is safe in this context, ie. that
-it wouldn't overwrite an existing bit of content without first doing a
-checksum?
-
-Thanks! -- [[anarcat]]
-
-> Good idea.. Implemented. 
-> 
-> I'm not entirely happy with the name, but could not think of
-> a better one.
-> 
-> Yes, `recvkey` will never overwrite content already in the annex,
-> and unless you turn off annex.verify, hashes will also be checked
-> before letting anything into the annex.
-> 
-> Of course, if non-hashed keys are used, and an object has not
-> reached the repository yet from a trusted source, an attacker
-> could slip in something malicious without being noticed.
-> Setting annex.securehashesonly would be a good idea to prevent this.
-> 
-> p2pstdio implements the same security policies as the rest of
-> git-annex-shell.
-> 
-> --[[Joey]]
-
-> Update: I didn't close this before, but it seems [[done]] --[[Joey]]
diff --git a/doc/todo/append-only_mode/comment_1_eaa7ae80c3758bccd23c4e0a8d1eefc4._comment b/doc/todo/append-only_mode/comment_1_eaa7ae80c3758bccd23c4e0a8d1eefc4._comment
deleted file mode 100644
index fb904da842..0000000000
--- a/doc/todo/append-only_mode/comment_1_eaa7ae80c3758bccd23c4e0a8d1eefc4._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="https://christian.amsuess.com/chrysn"
- nickname="chrysn"
- avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
- subject="append-only and gitolite"
- date="2018-05-28T11:47:13Z"
- content="""
-Thanks, that's a nice feature.
-
-How could this be integrated with gitolite? Should the `if ( can_write($repo) )` branch be amended by a check for the \"+\" flag ([short documentation](http://gitolite.com/gitolite/conf-2/) says that \"RW\" is roughly \"create or fast-forward, no deletes\" while \"RW+\" includes deletes and non-fast-forwards)?
-
-(This might change the user experience on repositories run with \"RW\" permissions currently, but IMO patching a possibly unwanted access that can be easily granted if so desired.)
-"""]]
diff --git a/doc/todo/append-only_mode/comment_2_fd1f869f97e0658ec3986fe05f28345e._comment b/doc/todo/append-only_mode/comment_2_fd1f869f97e0658ec3986fe05f28345e._comment
deleted file mode 100644
index 6bf43ec0a9..0000000000
--- a/doc/todo/append-only_mode/comment_2_fd1f869f97e0658ec3986fe05f28345e._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="some docs"
- date="2018-07-06T01:44:08Z"
- content="""
-I have tried to document this in the [[git-annex-shell]] manpage, see if it works for you... thanks so much for implementing this key feature so quickly!
-"""]]
diff --git a/doc/todo/append-only_mode/comment_3_790ce76fe02ca35b9da7309ee2384c01._comment b/doc/todo/append-only_mode/comment_3_790ce76fe02ca35b9da7309ee2384c01._comment
deleted file mode 100644
index d4eac48cf2..0000000000
--- a/doc/todo/append-only_mode/comment_3_790ce76fe02ca35b9da7309ee2384c01._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-07-06T16:34:02Z"
- content="""
-I think it would go better in a tips page than on the man page.
-Especially since no complete solution is available and it's well beyond the
-scope of a manpage for git-annex-shell to document such a solution.
-
-It seems to me that allowing untrusted people to push to the git-annex
-branch is asking for various mischeif. One that comes to mind is they can
-add a repository, configure it to be trusted, and make git-annex think
-it has a copy of all content. Combined with preferred content settings this
-could make git-annex drop the only actual copy of content.
-"""]]
diff --git a/doc/todo/append-only_mode/comment_4_cb00ed89aa7931fdadbf44355bdc78b2._comment b/doc/todo/append-only_mode/comment_4_cb00ed89aa7931fdadbf44355bdc78b2._comment
deleted file mode 100644
index f961d85e9f..0000000000
--- a/doc/todo/append-only_mode/comment_4_cb00ed89aa7931fdadbf44355bdc78b2._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="comment 4"
- date="2018-07-06T16:48:29Z"
- content="""
-understood, i'll add a tips page as well.. i started some personal notes here:
-
-https://anarc.at/services/backup/#append-only-git-repositories
-
-regarding pushes to the git-annex branch... in my threat model, it is not a real problem. they can drop all the contents locally and destroy everything there anyways. if an attacker adds an extra repo, sure, a \"smart\" git-annex command might mistakenly drop contents in the wrong location, but the attacker could do that anyways, without adding that branch. what is actually precious are the blobs stored on the remote server: if those can't be removed, we are safe, if I understand things correctly.
-"""]]
diff --git a/doc/todo/batch_command_result_status.mdwn b/doc/todo/batch_command_result_status.mdwn
deleted file mode 100644
index b405e7ef62..0000000000
--- a/doc/todo/batch_command_result_status.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-For batch commands like fromkey and setpresentkey, when some operations in a batch succeed and others fail, it's hard to know which ones were done.  It would be good if the operations had an option to output the status to stdout or to a file, maybe in json format.  It would also be good if there was a --keep-going option to try each operation even if some early ones fail.  Currently, when some operations fail, the set of doable operations that gets done depends on the input order, and there is no reliable way to know which ones succeeded.  
-
-> Limiting this to fromkey, [[done]] --[[Joey]] 
diff --git a/doc/todo/batch_command_result_status/comment_1_78290ab147983ab8efdeb21b4ae53832._comment b/doc/todo/batch_command_result_status/comment_1_78290ab147983ab8efdeb21b4ae53832._comment
deleted file mode 100644
index 551bedab05..0000000000
--- a/doc/todo/batch_command_result_status/comment_1_78290ab147983ab8efdeb21b4ae53832._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-02-05T17:20:40Z"
- content="""
-Many commands do have an interface that works like that. For example
-`git annex get --batch --json` has json output and does not stop when a get
-fails.
-
-So this comes down to specific behaviors of specific commands.
-I've added --json to fromkey.
-
-I don't think that setpresentkey can fail, unless there's a disk IO error
-or something?
-
-Any others?
-"""]]
diff --git a/doc/todo/batch_command_result_status/comment_2_c89014d3088aa448f4c980d26ab43104._comment b/doc/todo/batch_command_result_status/comment_2_c89014d3088aa448f4c980d26ab43104._comment
deleted file mode 100644
index fa586cd098..0000000000
--- a/doc/todo/batch_command_result_status/comment_2_c89014d3088aa448f4c980d26ab43104._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 2"
- date="2019-02-05T20:55:59Z"
- content="""
-Thanks a lot!  I mostly use fromkey/setpresentkey/registerurl for now.  registerurl, I guess, also cannot fail?  Though, I think I've seen failures related to git locks being held?
-"""]]
diff --git a/doc/todo/batch_command_result_status/comment_3_4f0b9c3fe9405d9bbb4adee31e2aa36d._comment b/doc/todo/batch_command_result_status/comment_3_4f0b9c3fe9405d9bbb4adee31e2aa36d._comment
deleted file mode 100644
index e03d4bf8da..0000000000
--- a/doc/todo/batch_command_result_status/comment_3_4f0b9c3fe9405d9bbb4adee31e2aa36d._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2019-02-07T20:09:22Z"
- content="""
-Failure is always an option :) but if the failure is due to disk IO error
-or disk full or memory error or whatever, it doesn't much matter which
-particular item in the batch caused the error because you're going to want
-to redo from start anyway.
-
-I'll close this, if you find other commands whose batch interface can be
-improved open more todos.
-"""]]
diff --git a/doc/todo/be_able_to_refer_to_remotes_by_uuid.mdwn b/doc/todo/be_able_to_refer_to_remotes_by_uuid.mdwn
deleted file mode 100644
index df6bac4360..0000000000
--- a/doc/todo/be_able_to_refer_to_remotes_by_uuid.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-in light of https://github.com/datalad/datalad/issues/1259 (conflicting remote names)  I wondered if both initremote and enableremote (and probably others) should acquire ability to set/refer to remotes by their UUIDs instead of relying purely on name which is not guaranteed to be unique.
-
-[[!meta name=yoh]]
-
-> This seems [[done]], at least initremote and enableremote support uuid=.
-> --[[Joey]]
diff --git a/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_1_54585f8fa43b315637af60eaf9d6ad50._comment b/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_1_54585f8fa43b315637af60eaf9d6ad50._comment
deleted file mode 100644
index 926c6f6fc6..0000000000
--- a/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_1_54585f8fa43b315637af60eaf9d6ad50._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-02-07T16:34:57Z"
- content="""
-enableremote can already enable a remote by uuid instead of by name.
-
-It might be useful to let a uuid be provided to initremote. There's also
-some foot shooting potential (reuse the wrong uuid and then the special
-remote has been set up, so how would you change it).
-"""]]
diff --git a/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment b/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment
deleted file mode 100644
index fc22f0c904..0000000000
--- a/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-02-07T18:59:41Z"
- content="""
-I've made `initremote` be able to be provided with a uuid=whatever
-parameter to use whatever UUID you like.
-
-Valid use cases include setting up two special remotes that access the same
-data store through two different interfaces. For example, a rsync special
-remote that is also accessible via a NFS mount as a directory special remote.
-
-It can also be used when two unrelated repositories want to use the same
-data store. Of course, dropping data from the data store then becomes a
-problem, since one of the repositories will know it was dropped, and the
-other one won't. Can get into situations where one of the repositories
-was relying on its remote as the only place a file was stored, and so loses
-the only copy it knows about when the other repository moves the content
-from the remote.
-
-For datalad-archives, I think dropping content from that special remote is
-not supported. Which nearly avoids such problems. If so, it should be fine
-to reuse some UUID for all the datalad-archives special remotes in
-different unrelated datalad repositories.
-"""]]
diff --git a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads.mdwn b/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads.mdwn
deleted file mode 100644
index b0021033be..0000000000
--- a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-"Downloading unverified content from (non-encrypted) external special remotes is prevented, because they could follow http redirects to web servers on localhost or on a private network, or in some cases to a file:/// url" -- it's be good if an exception to this could be configured for a given type of external special remote, and/or for specific special remotes.
-Sometimes I _know_ that a given external special remote doesn't do redirects, or that a given special remote repository won't have bad URLs.  Remembering to do
-git -c annex.security.allow-unverified-downloads=ACKTHPPT annex get myfile
-every time is another thing to think about, when the whole point of git-annex is to not have to think about where things are :)  While configuring 
-annex.security.allow-unverified-downloads=ACKTHPPT permanently opens security holes.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_1_048cdb0a814ec560373d8c5c01663fab._comment b/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_1_048cdb0a814ec560373d8c5c01663fab._comment
deleted file mode 100644
index 22469ad9d9..0000000000
--- a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_1_048cdb0a814ec560373d8c5c01663fab._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-09-25T18:51:11Z"
- content="""
-Added a per-remote configuration of that.
-
-I thought about adding something to the external special remote protocol
-to let them indicate what they are not vulnerable to CVE-2018-10857.
-But it only affects WORM and URL keys, which I'm reluctant to complicate the
-protocol for. (It would be better perhaps to just remove those types of
-keys.) And it's actually rather difficult for external special
-remote authors to guarantee that is the case, since libraries they use may
-change over time.
-"""]]
diff --git a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_2_485e090092e6ccddbe79f59903d493ec._comment b/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_2_485e090092e6ccddbe79f59903d493ec._comment
deleted file mode 100644
index 8f8c26516e..0000000000
--- a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_2_485e090092e6ccddbe79f59903d493ec._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 2"
- date="2018-09-26T00:14:53Z"
- content="""
-per-remote config solves this, thanks.  \"It would be better perhaps to just remove those types of keys\" -- please don't, I've had various uses for both.
-"""]]
diff --git a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_3_f625216ca793d73cb42f70bf8b10a9cc._comment b/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_3_f625216ca793d73cb42f70bf8b10a9cc._comment
deleted file mode 100644
index 24dc81f7dc..0000000000
--- a/doc/todo/better_exceptions_to_annex.security.allow-unverified-downloads/comment_3_f625216ca793d73cb42f70bf8b10a9cc._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 3"
- date="2018-09-26T00:51:29Z"
- content="""
-\"I thought about adding something to the external special remote protocol to let them indicate what they are not vulnerable to CVE-2018-10857\" -- you could instead add a special remote message FETCH_URL_FOR_ME that asks git-annex to fetch the URL, and git-annex can then fetch it with its internal fetcher that does the needed security checks.
-"""]]
diff --git a/doc/todo/checksum_verification_on_transfer.mdwn b/doc/todo/checksum_verification_on_transfer.mdwn
deleted file mode 100644
index 4b0ec364e9..0000000000
--- a/doc/todo/checksum_verification_on_transfer.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-Since most file transfers, particularly to/from encrypted special remotes involve git-annex streaming through the contents of the file anyway, it should be possible to add a verification of the checksum nearly for free. The main thing needed is probably a faster haskell checksum library than Data.Digest.Pure.Sha, which is probably slow enough to be annoying.
-
-I have not verified if an upload could be aborted before sending the data to the remote if a checksum failure is detected. It may be dependent on the individual special remote implementations. Some probably stream the encrypted data directly out the wire, while others need to set up a temp file to run a command on. It would certainly be possible to at least make the upload abort and fail if a bad checksum was detected.
-
-Doing the same for downloads is less useful, because the data is there locally to be fscked. The real advantage would be doing the check for uploads, to ensure that hard-to-detect corrupted files don't reach special remotes.
-
---[[Joey]]
-
-[[!meta title="do checksum verification on upload to special remotes"]]
-
-> [[done]]; I don't see any way to do checksum verification on upload
-> to a special remote, without it somehow having a way to verify an
-> arbitrary checksum method of data stored in it, which nothing supports.
-> --[[Joey]]
diff --git a/doc/todo/checksum_verification_on_transfer/comment_1_30f77e631608b9751f9032f97d58cc30._comment b/doc/todo/checksum_verification_on_transfer/comment_1_30f77e631608b9751f9032f97d58cc30._comment
deleted file mode 100644
index 5de1251da3..0000000000
--- a/doc/todo/checksum_verification_on_transfer/comment_1_30f77e631608b9751f9032f97d58cc30._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
- nickname="Richard"
- subject="comment 1"
- date="2013-09-09T11:50:05Z"
- content="""
-Doing this during downloads would still be nice.
-
-While the files are easier to fsck, users will need to actually do this. If it happenend automatically, it would increase safety and reduce disk i/o.
-
-Of course, this will not detect degradation during/after writing.
-
-If you don't make it the default, please at least make it optional for us bordering on OCD when it comes to data storage.
-
-
-Richard
-"""]]
diff --git a/doc/todo/checksum_verification_on_transfer/comment_2_1267ff79ddc84dad146bdb11a7bdf8b2._comment b/doc/todo/checksum_verification_on_transfer/comment_2_1267ff79ddc84dad146bdb11a7bdf8b2._comment
deleted file mode 100644
index 39f0a9e2c6..0000000000
--- a/doc/todo/checksum_verification_on_transfer/comment_2_1267ff79ddc84dad146bdb11a7bdf8b2._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2015-10-01T15:45:18Z"
- content="""
-My original reasoning makes sense for uploads, I think. 
-
-The checksum library used is a lot faster now, but it would still be best
-to do the checksum as part of the same file read used to transfer the file,
-when possible.
-
-There is a good reason to want to verify checksums when downloading objects
-too: Git does that, and so if git-annex does too, the same reasoning about
-security can be done about git-annex repositories as can be done about git
-repositories. In other words, not verifying checksums when downloading objects
-violates least surprise.
-
-A concrete example: If the user is uploading objects to gitlab, they should
-be able to git pull, and verify their signed commit, and git annex get, and
-not need to worry about whether gitlab (or a MITM) could do something evil
-to the downloaded objects.
-
-Similarly, a S3 special remote does not include the git repo, so users
-should be able to assume that, given their locally trusted git repo, git
-annex get will only ever get verified objects from the S3 remote.
-
-Question: What about local repositories, eg on a removable drive?
-Git does do checksum verification between local repositories, unless
-cloned with --shared. Probably follows git-annex should too.
-
-My current thinking is that this verification should be done by default.
-Security features that are not enabled by default are not very useful.
-It should, however, be able to be turned off, either globally, or on a
-per-remote basis.
-"""]]
diff --git a/doc/todo/checksum_verification_on_transfer/comment_3_2fa9445619032a378264de8b59958c60._comment b/doc/todo/checksum_verification_on_transfer/comment_3_2fa9445619032a378264de8b59958c60._comment
deleted file mode 100644
index b18e7dcb5d..0000000000
--- a/doc/todo/checksum_verification_on_transfer/comment_3_2fa9445619032a378264de8b59958c60._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""status update"""
- date="2015-10-01T19:17:38Z"
- content="""
-Checksum verification is now done for all downloads, unless disabled via
-annex.verify=false.
-
-When an object is uploaded to a regular git remote, checksum verification
-also also done. (For a local directory, git-annex runs a download from the
-perspective of the remote, so we get it for free, and when git-annex-shell
-recvkey is used, it checksums the data it receives and compares it with the
-key.)
-
-For uploads to special remotes, no checksum verification is done yet.
-Leaving this todo item open because of that gap in the coverage.
-"""]]
diff --git a/doc/todo/checksum_verification_on_transfer/comment_4_cd5974b989f0a75a8d441d6c3eff4807._comment b/doc/todo/checksum_verification_on_transfer/comment_4_cd5974b989f0a75a8d441d6c3eff4807._comment
deleted file mode 100644
index 42167f134a..0000000000
--- a/doc/todo/checksum_verification_on_transfer/comment_4_cd5974b989f0a75a8d441d6c3eff4807._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="checksums of remote data"
- date="2019-05-13T22:03:38Z"
- content="""
-\"I don't see any way to do checksum verification on upload to a special remote, without it somehow having a way to verify an arbitrary checksum method of data stored in it, which nothing supports\" -- arbitrary checksum no, but some remotes do support verifying MD5 checksums specifically.  E.g. DNAnexus can tell you the MD5 of each uploaded part of a multi-part file; Google Cloud Storage can tell you the MD5 for a non-composite file, and CRC32 for composite files. Maybe, the [[external special remote protocol|design/external_special_remote_protocol]] could be extended with optional requests/replies to expose these capabilities?
-"""]]
diff --git a/doc/todo/checksum_verification_on_transfer/comment_5_30add692347382aaa718b9b3ee7f116d._comment b/doc/todo/checksum_verification_on_transfer/comment_5_30add692347382aaa718b9b3ee7f116d._comment
deleted file mode 100644
index 27c061eddf..0000000000
--- a/doc/todo/checksum_verification_on_transfer/comment_5_30add692347382aaa718b9b3ee7f116d._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2019-05-23T17:34:40Z"
- content="""
-It seems better to keep checksums specific to a given protocol at the level
-of that protocol. What would be the benefit of pushing that up to
-git-annex's APIs?
-"""]]
diff --git a/doc/todo/cloning_direct_mode_repo_over_http.mdwn b/doc/todo/cloning_direct_mode_repo_over_http.mdwn
deleted file mode 100644
index b5d037e86e..0000000000
--- a/doc/todo/cloning_direct_mode_repo_over_http.mdwn
+++ /dev/null
@@ -1,38 +0,0 @@
-Indirect mode repos can be cloned over http, and just work. But, direct
-mode repos don't currently work; while git can clone them ok, git-annex get
-doesn't know where to get the file contents from.
-
-To support this, git-annex would have to check if the remote is in direct
-mode, and when it is, it would need to download the direct mode mapping
-file, to find out which file has the content of a key. Then, after
-downloading the a file, it would need to make sure to checksum it, since
-nothing prevents a direct mode file from being modified at the same time
-it's downloaded.
-
-All seems doable. However.. [[design/caching_database]] wants to switch the
-direct mode mapping files from simple flat text files to a sqlite database.
-Which would complicate this a lot. Can sqlite databases be accessed over
-http, or would the whole, possibly large database need to be downloaded?
-If so, what to do when the database changes? Re-downloading a possibly
-large db is not good.
-
----
-
-Alternatively, the direct mode mapping files of the remote could be
-bypassed. Instead, look at what the remote HEAD branch is, and look at that
-branch locally. Create local direct mode mappings for the remote HEAD
-branch, and use them when downloading.
-
-This approach would mean that, if the remote's HEAD changes and we haven't
-noticed, we might download the wrong file (that has eg, been moved).
-checksumming would detect this, but it does make it more fragile.
-
-Also, creating the direct mode mappings for a remote HEAD would currently
-be pretty slow. Probably implementing the caching database for direct mode
-mappings would lead to faster code. So, this feature seems best blocked on
-the direct mode database either way!
-
---[[Joey]]
-[[!meta tag=deprecateddirectmode]]
-
-> direct mode has been removed, so [[done]] --[[Joey]]
diff --git a/doc/todo/cloning_direct_mode_repo_over_http/comment_1_36701696af41f8b71bb2fd4829f05b7c._comment b/doc/todo/cloning_direct_mode_repo_over_http/comment_1_36701696af41f8b71bb2fd4829f05b7c._comment
deleted file mode 100644
index a1abe3f2ba..0000000000
--- a/doc/todo/cloning_direct_mode_repo_over_http/comment_1_36701696af41f8b71bb2fd4829f05b7c._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-02-19T19:55:20Z"
- content="""
-v6 unlocked files don't have this problem; a repo containing them can be
-accessed over http.
-
-So, I think that's a better way to go than complicating the http support
-with direct mode stuff. Especially since direct mode is going away.
-
-Won't close this yet, but will when I get around to removing direct mode..
-"""]]
diff --git a/doc/todo/config_option_to_use_all_processors_by_default.mdwn b/doc/todo/config_option_to_use_all_processors_by_default.mdwn
deleted file mode 100644
index 63b9bed3e4..0000000000
--- a/doc/todo/config_option_to_use_all_processors_by_default.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-Can you add a global config flag to tell parallelizable commands to use all available cores?  Often I forget to add -JN when it would have sped things up.
-
-> Added as --jobs=cpus / annex.jobs=cpus. This will allow 
-> later expansion, perhaps `--jobs=cpus-1` to leave a spare core
-> or `--jobs=remotes*2` to run two jobs per remote, or things like that. 
->
-> It's a bit more typing than -J0, but since it can be configured once in
-> annex.jobs, that seemed an acceptable tradeoff to future proof it.
-> 
-> [[done]] --[[Joey]]
diff --git a/doc/todo/config_option_to_use_all_processors_by_default/comment_1_1fa91968840bb25bd09c6dfe64f1f8cd._comment b/doc/todo/config_option_to_use_all_processors_by_default/comment_1_1fa91968840bb25bd09c6dfe64f1f8cd._comment
deleted file mode 100644
index cc79e00c62..0000000000
--- a/doc/todo/config_option_to_use_all_processors_by_default/comment_1_1fa91968840bb25bd09c6dfe64f1f8cd._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-10-04T16:04:57Z"
- content="""
-git-annex is rarely cpu-bound so I don't know how useful that would really
-be in practice.
-
-A git config to set the concurrency level is certianly a good idea,
-implemented as annex.jobs.
-"""]]
diff --git a/doc/todo/config_option_to_use_all_processors_by_default/comment_2_72f1e7c4ac97010be4d8eee7bceb03f2._comment b/doc/todo/config_option_to_use_all_processors_by_default/comment_2_72f1e7c4ac97010be4d8eee7bceb03f2._comment
deleted file mode 100644
index 2601c4b8e1..0000000000
--- a/doc/todo/config_option_to_use_all_processors_by_default/comment_2_72f1e7c4ac97010be4d8eee7bceb03f2._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 2"
- date="2018-10-05T18:24:18Z"
- content="""
-Thanks for adding annex.jobs .  Could you make it so that setting it to 0 means \"use all available processors\"?  I use git-annex on AWS instances, and reserve instances with different processor counts at different times.
-
-\"git-annex is rarely cpu-bound\" -- I though parallelization helps by parallelizing I/O operations such as file transfers?
-
-
-"""]]
diff --git a/doc/todo/config_option_to_use_all_processors_by_default/comment_2_e60a03a8e3225b15424e7e2c505ad133._comment b/doc/todo/config_option_to_use_all_processors_by_default/comment_2_e60a03a8e3225b15424e7e2c505ad133._comment
deleted file mode 100644
index c66182299a..0000000000
--- a/doc/todo/config_option_to_use_all_processors_by_default/comment_2_e60a03a8e3225b15424e7e2c505ad133._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-10-05T15:26:20Z"
- content="""
-Just to be clear, not rejecting the idea of -J ncupus out of hand, but I
-think it needs some UI consideration. If it were implemented as -J0 (or -J
-but I don't think optparse-applicative currently supports -J optionally
-lacking a parameter), we might regret it if a better way to determine
-a good level of concurrency is later found.
-
-Wanting to run one (or two) concurrent operations per remote is something
-that comes to mind as perhaps better in many situations.
-
-Or I can imagine dynamically adjusting concurrency to
-optimise throughput. Although I don't know how I'd implement that.
-"""]]
diff --git a/doc/todo/config_option_to_use_all_processors_by_default/comment_4_3e56a9ccb13ebe7736c56dd472157cbe._comment b/doc/todo/config_option_to_use_all_processors_by_default/comment_4_3e56a9ccb13ebe7736c56dd472157cbe._comment
deleted file mode 100644
index 3cb823f62a..0000000000
--- a/doc/todo/config_option_to_use_all_processors_by_default/comment_4_3e56a9ccb13ebe7736c56dd472157cbe._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2018-10-08T16:22:31Z"
- content="""
-Ilya, my previous comment was talking about the problem with dedicating -J0
-to that.
-
-And yes, parallelization helps with IO, so why run 64 processes on a 64 CPU
-system if it has the same speed bus / same network speed as a 4 CPU system?
-"""]]
diff --git a/doc/todo/config_option_to_use_all_processors_by_default/comment_5_62a0ee0c5b09e6af4a71a8ba55332d00._comment b/doc/todo/config_option_to_use_all_processors_by_default/comment_5_62a0ee0c5b09e6af4a71a8ba55332d00._comment
deleted file mode 100644
index 61b373f520..0000000000
--- a/doc/todo/config_option_to_use_all_processors_by_default/comment_5_62a0ee0c5b09e6af4a71a8ba55332d00._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 5"
- date="2018-10-08T21:48:27Z"
- content="""
-\"why run 64 processes on a 64 CPU system if it has the same speed bus / same network speed as a 4 CPU system\" -- it doesn't always; higher-end AWS instances have 25Gbps networks, and you can buy more throughput as needed.
-"""]]
diff --git a/doc/todo/custom_f-droid_repo.mdwn b/doc/todo/custom_f-droid_repo.mdwn
deleted file mode 100644
index 1403ebe0ca..0000000000
--- a/doc/todo/custom_f-droid_repo.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-It would be great to have a custom f-droid repo "alla guardianproject.info" (before getting git-annex into the main f-droid repo).
-
-See  ().
-
-> I've dropped the git-annex android port, instead there's a way to install
-> the regular linux build into termux. So, this todo is obsolete. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/custom_f-droid_repo/comment_1_d2bdc001584d4b5f925390910ec1ef73._comment b/doc/todo/custom_f-droid_repo/comment_1_d2bdc001584d4b5f925390910ec1ef73._comment
deleted file mode 100644
index f1c682fbc6..0000000000
--- a/doc/todo/custom_f-droid_repo/comment_1_d2bdc001584d4b5f925390910ec1ef73._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.146"
- subject="comment 1"
- date="2014-03-05T20:45:32Z"
- content="""
-The f-droid developers are willing to add git-annex in principle, their build environment just needs to have its build dependencies added to it. I've completely automated (except for occasional breakage due to changes on hackage) to setup of the necessary cross build environment. I have not had time to look into how to integrate that into the f-droid build system, and it would be great if someone with interest could do so.
-
-I suspect that setting up a custom f-droid repo would be just as much work, plus more work on an ongoing basis.
-"""]]
diff --git a/doc/todo/custom_f-droid_repo/comment_2_20eebe13b76d5279a3d09b346b65ff6e._comment b/doc/todo/custom_f-droid_repo/comment_2_20eebe13b76d5279a3d09b346b65ff6e._comment
deleted file mode 100644
index 34aa063f4c..0000000000
--- a/doc/todo/custom_f-droid_repo/comment_2_20eebe13b76d5279a3d09b346b65ff6e._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnR6E5iUghMWdUGlbA9CCs8DKaoigMjJXw"
- nickname="Efraim"
- subject="comment 2"
- date="2014-03-06T10:06:02Z"
- content="""
-I've noticed that fdroidserver is available in the main debian repos, and not having really looked at it too much yet, if it shares similar code to wannabuild then it should be possible to continue everything as you're already doing it, just in addition rsync or git push the code base to a local fdroidserver instance and also copy the binary over once it's set up.
-(if I understood wannabuild correctly, if you upload new source and a prebuilt binary it will mark that architecture as built.)
-"""]]
diff --git a/doc/todo/custom_f-droid_repo/comment_3_5a79abb8b1dd12426e111e733fa6493b._comment b/doc/todo/custom_f-droid_repo/comment_3_5a79abb8b1dd12426e111e733fa6493b._comment
deleted file mode 100644
index dda348874d..0000000000
--- a/doc/todo/custom_f-droid_repo/comment_3_5a79abb8b1dd12426e111e733fa6493b._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
- nickname="Tobias"
- subject="comment 3"
- date="2014-03-06T22:49:22Z"
- content="""
-F-droid compiles all the binaries themselves internally.
-"""]]
diff --git a/doc/todo/custom_f-droid_repo/comment_4_55f05624f0e939f7b8d0c505285e5690._comment b/doc/todo/custom_f-droid_repo/comment_4_55f05624f0e939f7b8d0c505285e5690._comment
deleted file mode 100644
index a122aae927..0000000000
--- a/doc/todo/custom_f-droid_repo/comment_4_55f05624f0e939f7b8d0c505285e5690._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="http://lj.rossia.org/users/imz/"
- ip="79.165.57.121"
- subject="this topic in their Submission Queue"
- date="2014-05-03T14:59:11Z"
- content="""
-I opened [a request to add git-annex](https://f-droid.org/forums/topic/git-annex/) in the F-Droid's submission queue about a year ago.
-
-Just posting here the link, so that all the discussion (not much) can be found by those interested.
-
-"""]]
diff --git a/doc/todo/custom_f-droid_repo/comment_6_de4229f04daf48a153e2f44f57a05a3b._comment b/doc/todo/custom_f-droid_repo/comment_6_de4229f04daf48a153e2f44f57a05a3b._comment
deleted file mode 100644
index 033e35377a..0000000000
--- a/doc/todo/custom_f-droid_repo/comment_6_de4229f04daf48a153e2f44f57a05a3b._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="http://lj.rossia.org/users/imz/"
- ip="79.165.57.121"
- subject=" clarification: a custom F-Droid server just to post your updated apps"
- date="2014-05-03T15:57:55Z"
- content="""
-If I've understood Efraim correctly, he means that someone (perhaps, Joey) can run a custom F-Droid server with Joey's builds of the app **copied to the repo as is (without rebuilding there)**, so that those using an F-Droid client would get the updates through this standard path (for them) instead of manually looking for updates here.
-
-Like from a custom APT repository run not by Debian (in this case -- F-Droid team), but by an independent developer who is providing package builds not avaialble in Debian by building the packages himself, signing them, and putting them into his own APT repo (indexing them).
-
-"""]]
diff --git a/doc/todo/delete_old_misctmp_files.mdwn b/doc/todo/delete_old_misctmp_files.mdwn
deleted file mode 100644
index 81623e19ae..0000000000
--- a/doc/todo/delete_old_misctmp_files.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-Files can be left in .git/annex/misctmp when git-annex is interrupted in
-the middle of an operation that uses it. Especially with `git annex add`
-being interrupted can leave a large file hard linked in there, which can
-become a problem for the user.
-
-While it would be possible to hook SIGINT and clean up the files, that
-wouldn't catch every way git-annex could be interrupted; ie power failure.
-
-The assistant has some code that deletes misctmp files there older than 1
-day. Perhaps when git-annex uses the misctmp directory it should first
-perform such a cleanup pass.
-
-A 1 day timeout is not ideal.. Imagine a git-annex add of a really big file
-where the checksum takes more than 1 day.
-
-Let's use a lock file. There can be a single one for the whole misctmp
-directory. When it's being used, a shared lock is held. Take an exclusive
-lock before cleaning it.
-
-Since old versions of git-annex could still be in use and using the misctmp
-directory, let's rename the directory that new versions of git-annex
-use to .git/annex/othertmp.
-
-[[done]] --[[Joey]]
diff --git a/doc/todo/do_not_allow_using_stop_in_CommandPerform.mdwn b/doc/todo/do_not_allow_using_stop_in_CommandPerform.mdwn
deleted file mode 100644
index 353a273201..0000000000
--- a/doc/todo/do_not_allow_using_stop_in_CommandPerform.mdwn
+++ /dev/null
@@ -1,36 +0,0 @@
-`stop` does different things depending on the stage of a command that it's
-used in.
-
-In CommandStart, it quietly stops any further action.
-
-In CommandPerform, it causes the command to fail,
-which looks like "commandname actionitem failed".
-If no other output is emitted to say why it failed,
-this is not nice.
-
-(It can't be used in CommandCleanup.)
-
-It would be good to get rid of support for running `stop` in
-CommandPerform. Simply change the type:
-
-	- stop :: Annex (Maybe a)
-	+ stop :: CommandStart
-
-And follow the compile errors.
-
-> Hmm, I tried doing this, and I was not finding any other places
-> that stopped without emitting some kind of warning or informational
-> message.
-> 
-> And on second thought, this use of stop behaves the same as
-> `next (return False)`, or as having a CommandCleanup that
-> returns False without displaying any indication why.
-> 
-> So compprehensively fixing it would probably need to involve
-> returning something other than False from CommandCleanup, like a message
-> to display, but with only one case of the problem currently, I don't think it's
-> worth the bother to do that. Also, there are lots of different ways it
-> makes sense to display different messages in different situations and so 
-> returning a message to display feels wrong.
-> 
-> Guess I'm not going to do this. [[done]] --[[Joey]]
diff --git a/doc/todo/do_not_block_on_crypto_key_generation.mdwn b/doc/todo/do_not_block_on_crypto_key_generation.mdwn
deleted file mode 100644
index 90e4e9e58a..0000000000
--- a/doc/todo/do_not_block_on_crypto_key_generation.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-While trying to reproduce a [[problem with the gcrypt remote|bugs/gcrypt_repository_not_found]], I found that the `encryption step` can hand on this gpg command:
-
-    gpg --batch --no-tty --use-agent --quiet --trust-model always --gen-random --armor 2 512
-
-I think that "depletes the entropy pool", as witnessed by the state of the kernel entropy pool in `/proc/sys/kernel/random/entropy_avail`. As it turns out, `--gen-random 2` reads bytes from `/dev/random` and, indeed, by default that pool is 4096 bits large so the above command completely drains that pool to zero because it creates a 4096 bit (512 bytes * 8) key. It can take several minutes to "refill" the pool, which means batch-creating keys like this can take forever and also have an impact on other components of the system which rely on the kernel random number generator.
-
-Using `/dev/random` in that way is a somewhat controversial practice. Indeed, [some people recommend using urandom for all purposes](https://www.2uo.de/myths-about-urandom/), including secret key material generation. 
-
-From what I understand `urandom` and `random` basically use the same entropy source on Linux: the only difference is the latter blocks when it "thinks" it does not have enough entropy. But this (running out of entropy, not "thinking" that we do) basically never happens on Linux systems unless we are on the very first boot after an install. Because it's unlikely that git-annex will run on such an environment, I would discourage the use of `--gen-random 2` in git-annex.
-
-I strangely could not find out *where* exactly gpg is called in that way. All i could find was Util.Gpg.genRandom but that seems to hardcode `--gen-random 1`, not `2`, so I don't exactly know what's going on here. But I'm pretty sure it's git-annex calling it: 
-
-    anarcat  12745  0.3  0.2 1074098148 36304 pts/6 Sl+ 13:34   0:00              \_ /usr/bin/git-annex initremote encrypted type=gcrypt gitrepo=/home/anarcat/tmp/b keyid=8DC901CE64146C048AD50FBB792152527B75921E
-    anarcat  12753  0.0  0.0  16028  3652 pts/6    S+   13:34   0:00                  \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
-    anarcat  12754  0.0  0.0  16028  3308 pts/6    S+   13:34   0:00                  \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
-    anarcat  12756  0.0  0.0  33476  3784 pts/6    SL+  13:34   0:00                  \_ gpg --batch --no-tty --use-agent --quiet --trust-model always --gen-random --armor 2 512
-
-I was hoping this was something git-remote-gcrypt would be doing, but it's not: this is git-annex calling. Maybe some off-by-one conversion error somewhere?
-
-Thank you for your time... -- [[anarcat]]
-
-> [[closing|done]] --[[Joey]]
diff --git a/doc/todo/do_not_block_on_crypto_key_generation/comment_1_339ffe281eb75b70dd7ea8bc5ae55125._comment b/doc/todo/do_not_block_on_crypto_key_generation/comment_1_339ffe281eb75b70dd7ea8bc5ae55125._comment
deleted file mode 100644
index b92ea47447..0000000000
--- a/doc/todo/do_not_block_on_crypto_key_generation/comment_1_339ffe281eb75b70dd7ea8bc5ae55125._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-07-03T16:23:05Z"
- content="""
-This is implemented in Utility.Gpg.genRandom. There is no off-by-one,
-git-annex intentially makes the same default choices that gnupg does
-about random quality.
-
---fast makes it use /dev/urandom for people who lean on that side of the
-entropy controversy. initremote's man page documents this.
-
-("Some people recommend" is often not a good basis for security defaults.
-Some people recommend using RDRAND and trusting Intel...)
-"""]]
diff --git a/doc/todo/do_not_block_on_crypto_key_generation/comment_2_34b1e7f04ca17438e2a3e6209993a3a9._comment b/doc/todo/do_not_block_on_crypto_key_generation/comment_2_34b1e7f04ca17438e2a3e6209993a3a9._comment
deleted file mode 100644
index edb4ca05f2..0000000000
--- a/doc/todo/do_not_block_on_crypto_key_generation/comment_2_34b1e7f04ca17438e2a3e6209993a3a9._comment
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="some further considerations"
- date="2018-07-04T02:17:49Z"
- content="""
-> This is implemented in Utility.Gpg.genRandom. There is no off-by-one, git-annex intentially makes the same default choices that gnupg does about random quality.
-
-Then you'll be happy to know there is a proposal to change those defaults in gnupg as well, for similar reasons:
-
-https://dev.gnupg.org/T3894
-
-Cargo-culting those defaults does not seem like a reasonable way either. ;)
-
-> --fast makes it use /dev/urandom for people who lean on that side of the entropy controversy. initremote's man page documents this.
-
-I did not notice that, thanks. I would still argue it is better to use `/dev/urandom` for cryptoraphic purposes.
-
-> (\"Some people recommend\" is often not a good basis for security defaults. Some people recommend using RDRAND and trusting Intel...)
-
-That's a straw man. I am not recommending RDRAND. I'm recommending `/dev/urandom`. There are drawbacks in using `/dev/random`. To quote from the above URL:
-
-> djb has argued that an attacker capable of controlling the inputs to your seeding algorithm might gain an advantage in a continuous-seeding scenario that they wouldn't get in a seed-once-and-done approach.
-
-There are, as far as I am aware, no drawback to using `/dev/urandom`. I know there is some sort of controversy about this: I'm actually taking a stand here and asking people to justify why they are using `/dev/random`.
-
-I understand you might decide to not justify this directly in git-annex, however, and defer to projects like GnuPG, but I figured you might like to know the issue is not so clear cut there either... Werner Koch, the main author of GnuPG, says this of using `/dev/urandom`:
-
-> I use it for a long time now and it is really helpful. Do this only on Linux with the getrandom system call or if you are sure that Libgcrypt is not used in the early boot stage.
-
-So I think it might be worth reconsidering this here as well.
-"""]]
diff --git a/doc/todo/do_not_block_on_crypto_key_generation/comment_3_6fad0d287d5aaa76ec5a8177f7bec231._comment b/doc/todo/do_not_block_on_crypto_key_generation/comment_3_6fad0d287d5aaa76ec5a8177f7bec231._comment
deleted file mode 100644
index 1df6756597..0000000000
--- a/doc/todo/do_not_block_on_crypto_key_generation/comment_3_6fad0d287d5aaa76ec5a8177f7bec231._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-07-04T16:17:41Z"
- content="""
-git-annex outsources all cryptography (aside from hashes) to gnupg; it is
-not cargo-culting to include cryptographic key generation in that set.
-
-If gnupg changes to use getrandom by default then git-annex will follow suite.
-
-(Also, use of "cargo-culting" "straw man" etc tends to not lead to good
-quality discussions. EOT for me.)
-"""]]
diff --git a/doc/todo/do_not_block_on_crypto_key_generation/comment_4_33d80e721c6a922574ac98dd3075c4d8._comment b/doc/todo/do_not_block_on_crypto_key_generation/comment_4_33d80e721c6a922574ac98dd3075c4d8._comment
deleted file mode 100644
index dbb9c4cc7b..0000000000
--- a/doc/todo/do_not_block_on_crypto_key_generation/comment_4_33d80e721c6a922574ac98dd3075c4d8._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="apologies"
- date="2018-07-05T15:56:27Z"
- content="""
-I'm sorry, I misunderstood this comment:
-
-> git-annex intentially makes the same default choices that gnupg does about random quality
-
-I thought you were saying you replicated gnupg's policy decisions but now I understand you delegate those to GnuPG which seems like a reasonable choice! And hopefully this will all be fixed when GnuPG is fixed.
-
-Sorry for the trouble... :/
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend.mdwn b/doc/todo/dumb__44___unsafe__44___human-readable_backend.mdwn
deleted file mode 100644
index 13e2ffd15b..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-This was already discussed twice previously: [[forum/original_filename_on_s3/]] and [[todo/Facilitate_public_pretty_S3_URLs/]]. Yet I am still constantly having problems with this when trying to use git-annex to do some particular stuff.
-
-My latest example is a friend that wanted to sync files to a remote Webdav server. While I know he can use [[special_remotes/webdav/]] support, the resulting filenames on the webdav server will be basically garbled beyond recognition for any user that will use the Webdav server without git-annex.
-
-I understand the rationale behind the existing [[backends]], but wouldn't it be possible to implement a new backend that would just use the filename as a key?
-
-I know this would have several downsides:
-
-* lack of deduplication
-* much more exposed to corruption (no checksum to check against recorded? or can this be put somewhere else?)
-
-The main advantage, for me, is much better interoperability: any remote becomes usable by other non-git-annex clients... It would also be great as it would allow me to store only a *part* of my git-annex files on a remote without having a forest of empty files (on broken filesystems) or symlinks (on real filesystems) for files that are missing, something that is a massive source of confusion for users I work with. It could, for example, allow me to create thumb drives that would solve the [[hide missing files]] problem. -- [[anarcat]]
-
-> [[done]]; the new `git-annex export` feature allows you to export a tree
-> to a special remote. --[[Joey]]
-
-> > That is not exactly what I was hoping for. It's a little confusing to have a whole other command set for remotes. For example, I stumbled upon a [[bug in the webdav special remote|bugs/cannot_talk_with_nextcloud_server]] which I could work around by using the rclone remote, *except* that remote still doesn't support exporttree, because it's so special. If this would have been implemented through a "dumb" backend the way I proposed, all those special remotes would have worked out of the box without needing to be individually ported. Now I can't use this feature on my WebDAV server because of that bug...
-> > 
-> > I also need to learn yet another command in an already crowded namespace. This makes it harder for new people to get familiar with git-annex.
-> >
-> > I nevertheless thank you for the new feature and hope to use it to publish shiny clean files in remotes in the future! :) -- [[anarcat]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_1_d8db68bd9ebc4447617cfcb5c0c164a0._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_1_d8db68bd9ebc4447617cfcb5c0c164a0._comment
deleted file mode 100644
index b3614e8d15..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_1_d8db68bd9ebc4447617cfcb5c0c164a0._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-02-09T16:37:11Z"
- content="""
-Use what filename? A key can have any number of associated filenames in one
-or several git branches. The filenames can change at any time.
-
-AFAICS, this is a "pony" request. It seems like a good idea, but doesn't
-really work when you look at the details.
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_2_7620c429812d5ea1a649cbfda1cb09bb._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_2_7620c429812d5ea1a649cbfda1cb09bb._comment
deleted file mode 100644
index fce8a7879b..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_2_7620c429812d5ea1a649cbfda1cb09bb._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="konubinix"
- subject="fuser and unison?"
- date="2016-02-10T09:12:52Z"
- content="""
-Dear anarcat, I totally understand your use case since I often get into situations like that. I think that, by design (content addressable storage etc.), git-annex is not at all suited to fulfill this use case.
-
-I managed to use a combination of a fuse mount and unison to reach that use case.
-
-I create a fuse view of the git annex working copy with pyfs (http://pyfilesystem.org/) via a command line like : fsmount -f -a file:///my_git_annex_working_copy my_share_directory
-
-Generally, I share the fuse mount over samba, ftp and http.
-
-In order to synchronize with a distant directory (the use case you mentioned), I use another fuse mount and unison to sync both.
-
-Generally, I share the content on a remote samba server, using: 'smbnetfs ~/Network' and then 'unison my_share_directory ~/Network/PathToTheRemote'
-
-In the case of a s3 drive, I don't know the details since I never went there, but you could try: 'fsmount -f -a s3:///my_s3_remote my_s3_directory', then 'unison my_share_directory my_s3_directory'
-
-You may think that all those mounts are difficult to manage. As a matter of fact, I use supervisord (http://supervisord.org/) that helps making sure that everything is running OK. I have been using that setup for a few years now, without trouble.
-
-I hope that I could help.
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_3_d46183e53b1e6293681efadec9b46c6b._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_3_d46183e53b1e6293681efadec9b46c6b._comment
deleted file mode 100644
index b21e9e21db..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_3_d46183e53b1e6293681efadec9b46c6b._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- subject="""comment 3"""
- date="2016-04-09T04:39:11Z"
- content="""
-What about having a direct more in an external work tree?
-
-I could have my .git directory in some local directory (say
-`~/.git-annex/remote-mp3.git`) and the actual files on the device (say
-`/media/anarcat/mounted/mp3`).
-
-I know that there are many possible names for a single key, but isn't
-that a problem for direct mode as well?
-
-And I know it's a poney... I keep on asking for poneys here, but
-poneys are great, and actually quite useful and even friendly animals
-if you can use and take care of them correctly. :)
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_4_bbee2fa4b4fed1c5117cc4ddb0395278._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_4_bbee2fa4b4fed1c5117cc4ddb0395278._comment
deleted file mode 100644
index 845eb7f169..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_4_bbee2fa4b4fed1c5117cc4ddb0395278._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- subject="dumb external remote implemented"
- date="2016-06-23T00:34:59Z"
- content="""
-so I went ahead and scratched my itch of implementing this dumb special remote. i think it would be better implemented as a backend, but i am not sure how to implement that without going deep into haskell, and it seems like a mad idea anyways, because it would need to modify the hashing structure as well (to keep the directory structure).
-
-the remote is a simple shell script inspired by the example script, but that does some nasty (and slow) `git log -S` stuff to find a matching file path to a given key. ideally, this would be streamlined into a git-annex command that could then be optimized, because as it is now, each call is a separate history search.
-
-the script is here: 
-
-i haven't added it to the [[special_remotes]] list yet, because maybe it warrants a separate [[tips]] page. i also do not want to introduce what can be seen as a \"bad idea\" from git-annex's integrity principles to the list of special remotes before agreement here.
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_5_941b2364433ae42bc67a75f93564331d._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_5_941b2364433ae42bc67a75f93564331d._comment
deleted file mode 100644
index ac2b16ae1e..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_5_941b2364433ae42bc67a75f93564331d._comment
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- subject="related issues and response to problems raised"
- date="2016-06-23T14:44:06Z"
- content="""
-there are two related issues that were closed as wontfix here, which i missed in my original search as well:
-
-* [[todo/clear file names in special remotes]] ([archive](http://web.archive.org/web/20160413162353/http://git-annex.branchable.com/todo/clear_file_names_in_special_remotes/))
-* [[todo/New special remote suggeston - clean directory]] ([archive](http://web.archive.org/web/20160413171909/http://git-annex.branchable.com/todo/New_special_remote_suggeston_-_clean_directory/))
-
-those issues were actually removed, but are still on the internet archive for future reference.
-
-to summarize those issues, the rationale there is that those remotes are potentially destructuve (lack of locking and checks) and have workarounds (`rsync -a` was suggested). it is also clearly stated that this is contrary to the git-annex design and is a \"pony\" feature.
-
-i would counter that this is an often requested feature that seems to be a major usability issue for a lot of people. there are other unsafe remotes out there, like the `bittorrent` special remote, which is explicitely documented as such, and where we recommend users `untrust` the remote when it is setup. yet, those remotes have their uses and the rich diversitry of such remotes makes git-annex one of the most interesting projects out there.
-
-furthermore, `rsync -a` is not the same as git-annex's excellent tracking features. in my use case ([[forum/syncing_music_to_my_android_device]]), there is no git annex repository that has the same set of files which I want present on the android device, so I cannot use `rsync` without incurring a large storage space cost.
-
-as for this being contrary to git-annex design, you obviously know more about this than me, but from the outside it doesn't seem *that* counter-intuitive. it seems that we have go through a lot of hoops to try to make stuff like [[todo/Facilitate_public_pretty_S3_URLs]] work at all. having a different backend for specially crafted remotes would be a huge gain in usability and impact on data security could be limited with the usual trust/untrust mechanisms.
-
-i would be curious to hear more about how such a backend would be contrary to git-annex's design. i am assuming here that my main repo could still have a SHA256E backend and *some* remotes could have *different* backends. Obviously, maybe that's a flawed assumption and I obviously see how such a dumb backend could break way more assumptions git-annex makes about its data, if it *has* to be used on all the remotes. Yet, there *are* backends right now like `URL` and `WORM` that could be considered \"unsafe\", yet do not provide as great usability gains as this dumb backend could provide.
-
-i understand you have been requested this feature often and would understand if this other request would just be closed again. but considering how often it comes up, from different users, i think it should at least be considered as something that should be more explicitely documented (in [[not]], [[backends]] and [[special_remotes]] maybe?) to keep further requests from coming in. keeping an issue like this opened would also help in avoiding duplicate requests.
-
-thank you for your time and efforts on git-annex, i cannot state enough how helpful it is to me. the fact that I could write a special remote to accomplish the above filthy todo is a testament to how flexible and powerful git-annex is. :)
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_6_63b0da8fe5cba74411e16070d4dcf4bb._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_6_63b0da8fe5cba74411e16070d4dcf4bb._comment
deleted file mode 100644
index 859dfb461e..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_6_63b0da8fe5cba74411e16070d4dcf4bb._comment
+++ /dev/null
@@ -1,45 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2016-10-31T19:50:06Z"
- content="""
-So, I tried your git-annex-remote-dumb. After fixing its calckey to work with the current version of git-annex ...
-
-	joey@darkstar:~/tmp/repo>git annex initremote dumb type=external externaltype=dumb  directory=/tmp/dumb encryption=none
-	initremote dumb ok
-	joey@darkstar:~/tmp/repo>echo hello > hello
-	joey@darkstar:~/tmp/repo>git annex add
-	add hello ok
-	joey@darkstar:~/tmp/repo>git commit -m add
-	joey@darkstar:~/tmp/repo>git annex move hello --to dumb
-	move hello (to dumb...) 
-	ok
-	joey@darkstar:~/tmp/repo>cat /tmp/dumb/hello
-	hello
-	joey@darkstar:~/tmp/repo>git mv hello goodbye
-	joey@darkstar:~/tmp/repo>git commit -a -m rename
-	joey@darkstar:~/tmp/repo>echo oh no > hello
-	joey@darkstar:~/tmp/repo>git annex add hello
-	add hello ok
-	joey@darkstar:~/tmp/repo>git commit -a -m foo
-	joey@darkstar:~/tmp/repo>git annex copy hello --to dumb
-	copy hello (to dumb...) 
-	ok                      
-	joey@darkstar:~/tmp/repo>cat /tmp/dumb/hello
-	oh no
-	joey@darkstar:~/tmp/repo>git annex whereis goodbye
-	whereis goodbye (1 copy) 
-	   	3ef932e6-0989-46bd-a4c6-86562ed713f5 -- [dumb]
-	ok
-	joey@darkstar:~/tmp/repo>git annex fsck --from dumb goodbye
-	fsck goodbye (fixing location log) 
-	  ** Based on the location log, goodbye
-	  ** was expected to be present, but its content is missing.
-	failed
-	(recording state in git...)
-
-So yeah, that's data loss, and it's just the first thing I thought of.
-
-Aside from data loss bugs, /tmp/dumb just can't be kept fully up-to-date
-with changes to the working tree. So what's the point of it?
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_7_10086c35bbd54e502303a8763cc06afd._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_7_10086c35bbd54e502303a8763cc06afd._comment
deleted file mode 100644
index 39bac1887d..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_7_10086c35bbd54e502303a8763cc06afd._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="https://anarc.at/openid/"
- nickname="anarcat"
- avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
- subject="re dataloss and point"
- date="2017-01-17T01:34:43Z"
- content="""
-I think you wouldn't have had data loss if you untrusted the repository, am I correct? The remote is explicitly marked as \"unsafe\" (and ideally, it would automatically declare that to git-annex, but maybe there's no way to setup the trust level of remotes automatically like that) so operations that *move* files to it will be denied unless there's another copy somewhere...
-
-As for \"what's the point of it\", I thought I made that pretty clear... It enables use cases like:
-
-* [[forum/syncing_music_to_my_android_device/]]
-* [[forum/original_filename_on_s3/]]
-* [[todo/Facilitate_public_pretty_S3_URLs]]
-* etc
-
-> Aside from data loss bugs, /tmp/dumb just can't be kept fully up-to-date with changes to the working tree. So what's the point of it?
-
-I'm not sure what you mean there, by \"can't be kept fully up up-to-date\", could you clarify?
-
-Do you mean it won't follow renames and such? In my use case, I don't mind: i can just trash the remote and recreate it, if the working tree changes - and it doesn't change often enough for this to be a problem.
-
-> After fixing its calckey to work with the current version of git-annex...
-
-would you mind sharing that fix? :)
-
-thanks for the feedback, and sorry for the delay - for some reason i never got notifications for the reply... :/
-"""]]
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_8_4bc3923e6882f4562f99b56b155c51ba._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_8_4bc3923e6882f4562f99b56b155c51ba._comment
deleted file mode 100644
index 282a48ee68..0000000000
--- a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_8_4bc3923e6882f4562f99b56b155c51ba._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 8"""
- date="2018-10-08T16:10:25Z"
- content="""
-Your suggestion was not practical though, because the regular special
-remote interface does not allow all necessary operations for that. 
-The exporttree interface is the minimal API extension that supports this.
-
-And picking which tree to export and how necessarily involves an additional
-user interface, `git annex exporttree` is that. Once it's set up you can
-use the `git annex sync --content` interface at least.
-"""]]
diff --git a/doc/todo/easy_way_to_reproduce_normal_download_command.mdwn b/doc/todo/easy_way_to_reproduce_normal_download_command.mdwn
deleted file mode 100644
index 5e913a544d..0000000000
--- a/doc/todo/easy_way_to_reproduce_normal_download_command.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-so there's a `annex.web-download-command` settings, great! i have used
-it to do bandwidth limitations with:
-
-    wget --limit-rate=$download -O %file %url
-
-...and it works well.. however, i notice the output is different, and
-that's because once we override that setting, git-annex doesn't add
-other magic settings it uses. so by turning that thing on and off and
-inspecting the process list, i was able to figure out that the command
-is actually:
-
-    wget -q --show-progress --clobber -c --limit-rate=$download -O %file %url
-
-that gets me closer to the command generated by git-annex. however, i
-am not sure the `--clobber` and `-c` flags should always be
-present. furthermore, the `--user-agent
-git-annex/5.20150610+gitg608172f-1~ndall+1` flag is missing.
-
-could there be an (optional) %useragent interpolation to fix that?
-
-what about the other settings, is it okay to hardcode those?
-
-maybe this would be easier if there would be an options override just
-like rsync, but separate ones for curl and wget... --[[anarcat]]
-
-> git-annex now only uses curl, and defaults to a built-in http downloader.
-> The annex.web-download-command is no longer supported. annex.web-options
-> can be used to pass options to curl.
-> 
-> So, I don't think this todo is relevant anymore, closing [[done]].
-> --[[Joey]]
diff --git a/doc/todo/easy_way_to_reproduce_normal_download_command/comment_1_26ddfa03fcf51250b963cb9511a38404._comment b/doc/todo/easy_way_to_reproduce_normal_download_command/comment_1_26ddfa03fcf51250b963cb9511a38404._comment
deleted file mode 100644
index 2c050ffa34..0000000000
--- a/doc/todo/easy_way_to_reproduce_normal_download_command/comment_1_26ddfa03fcf51250b963cb9511a38404._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-07-02T20:36:22Z"
- content="""
-Separate options could be added, but I'm not sure they're needed.
-git-annex only ever runs one of curl or wget on a given system.
-
-Which one varies depending on what is installed (ie, it uses wget when
-available and otherwise uses curl), but as long as that's
-stable, you can just use annex.web-options to pass additional options to
-whichever one it runs.
-
-FWIW, --limit-rate works for both curl and wget, more or less the same.
-"""]]
diff --git a/doc/todo/export.mdwn b/doc/todo/export.mdwn
deleted file mode 100644
index 7c3bf0ee64..0000000000
--- a/doc/todo/export.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-`git annex export` corresponding to import. This might be useful for eg,
-datalad. There are some requests to make eg a S3 bucket mirror the
-filenames in the git annex repository with incremental updates, 
-which seem out of scope (and there are many tools to do stuff like that
-search "deploy files to S3 bucket"), 
-but something simpler like `git annex export` could be worth doing.
-
-`git annex export --to remote files` would copy the files to the remote,
-using the names in the working tree. For remotes like S3, it could add the
-url of the exported file, so that another clone of the repo could use the
-exported data.
-
-Would this be able to reuse the existing `storeKey` interface, or would
-there need to be a new interface in supported remotes?
-
-> [[done]]! --[[Joey]]
-
diff --git a/doc/todo/export/comment_1_cb87f7518da252b950d70c60352e848e._comment b/doc/todo/export/comment_1_cb87f7518da252b950d70c60352e848e._comment
deleted file mode 100644
index c07acc5caa..0000000000
--- a/doc/todo/export/comment_1_cb87f7518da252b950d70c60352e848e._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
- subject="sounds like the dumb backend, except not dumb"
- date="2017-04-08T20:21:41Z"
- content="""
-This sounds a lot like what i was trying to do in
-[[todo/dumb, unsafe, human-readable_backend]], except done properly. :)
-
-I was wondering about that asymmetry recentrly, and it would seem like
-a good idea to fix this. the `--to remote` flag could especially be
-useful for directory, rsync or even webdav remotes. i am not sure how
-this could be implemented, but i would certainly use this.
-
-having addurl work would be an awesome bonus, especially with webdav,
-where the mapping can be easily guessed (like S3). could be trickier
-with rsync/directory because then the user would need to tell
-git-annex what the base url is somewhere, but would fix a ton of use
-cases i had for this, like [[forum/original filename on s3]],
-[[forum/Facilitate public pretty S3 URLs]], [[todo/hide_missing_files]]
-and, my favorite, [[forum/syncing music to my android device]].
-it would also automate, extend and simplify the
-[[tips/publishing_your_files_to_the_public/]] use case.
-
-so thanks for this effort, i think it's a great idea and i'm excited
-to test this! -- [[anarcat]]
-
-"""]]
diff --git a/doc/todo/export/comment_2_b13f12dd00347114f99fd11d85d236a0._comment b/doc/todo/export/comment_2_b13f12dd00347114f99fd11d85d236a0._comment
deleted file mode 100644
index 4e394dd9e9..0000000000
--- a/doc/todo/export/comment_2_b13f12dd00347114f99fd11d85d236a0._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-05-11T17:25:48Z"
- content="""
-Note that making `git annex export` need a remote to export to would be
-somewhat asymmetric compared to `git annex import` which can operate on any
-directory full of files.
-
-Still, if you want to export to a directory full of files, setting up a
-directory special remote before exporting is not too big a pain, probably.
-
-I suppose the question is whether this asymetricity and complication of
-perhaps needing changes to the remote interface for `export` is a price
-worth paying to be able to have export upload to lots of sorts of remotes.
-"""]]
diff --git a/doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment b/doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment
deleted file mode 100644
index 307ff40a76..0000000000
--- a/doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment
+++ /dev/null
@@ -1,42 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2017-05-24T18:59:30Z"
- content="""
-`storeKey` could not be used for this, so it would need a new remote method
-to store a file on the remote under a specified name. Call it `storeFile`.
-
-What should `storeFile` with an encrypted special remote do? Encrypting
-the data does not seem very useful, especially for hybrid and shared
-where the secret key is embedded in the git repo. Not encrypting the data
-is surely a least surprise violation that would be a security hole.
-So probably best to not support exporting to encrypted special remotes.
-
-`git annex export --to specialremote` cannot handle incremental updates,
-resuming uploads etc, because special remotes can be so limited they only
-support putting the whole content of a file. Even resuming interrupted
-uploads is problimatic, because we don't know for sure what key was
-(partially or completely) exported before. The best that seems doable
-is to make `storeFile` avoid resending the file if the remote has the file
-on it already, and move the file into place atomically once it's all sent. 
-
-Then `git annex export --to remote` could be run repeatedly to export files
-until everything gets exported.
-
-But, when a file has been modified, that would prevent the modified version
-being exported. Unless state is stored somewhere to say that the given file
-on a remote is the content of a given key.
-That state could take the form of a .git-annex/filename.exported stored
-on the remote, which contains the name of the key. When exporting a new
-key over an existing file, that would be overwritten. (Really needs to be
-done atomically..)
-
-What about deleted files? Should export somehow notice that a file
-has been deleted locally, and remove it from the remote? How?
-
-----
-
-Alternatively, leave the incremental updating, deletion etc to
-third-party tools, and have `git annex export` simply export the current
-files to a directory.
-"""]]
diff --git a/doc/todo/export/comment_4_da8b5b8c9fc371fe138590744b2adce3._comment b/doc/todo/export/comment_4_da8b5b8c9fc371fe138590744b2adce3._comment
deleted file mode 100644
index 1d694e0e25..0000000000
--- a/doc/todo/export/comment_4_da8b5b8c9fc371fe138590744b2adce3._comment
+++ /dev/null
@@ -1,51 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2017-07-10T17:30:23Z"
- content="""
-Yoh suggested storing a treeish associated with the export to a special
-remote. Pointed out that the diff from that treeish to the next one could
-be used to update the export.
-
-(That does seem very close to [[todo/dumb, unsafe, human-readable_backend]].)
-
-Would need to somehow deal with partial uploads. There are two ways
-an upload can be partial:
-
-* Some of the files in the treeish have been uploaded; others have not.
-* A file has been partially uploaded.
-
-These two cases need to be disentangled somehow in order to handle
-them. It could use the location log, so once a key gets uploaded
-to the special remote, its content is marked present. However, using the
-location log does not seem sufficient to handle all cases (eg two files
-swapping names between two treeishes, where one of the files has been
-uploaded only partially to the special remote).
-
-It seems promosing to keep track of two separate treeishes:
-
-1. The treeish that is the current goal to have exported to the special
-   remote.
-2. The treeish for the current state of the special remote. Note that
-   after even an interrupted transfer, this treeish needs to be updated to
-   contain the current state of the special remote, which would mean
-   constructing a new treeish. (Perhaps a per-remote index file could be
-   used.)
-
-Having these two treeishes allows:
-
-* Detecting renames of exported files, which some special remotes can do
-  more efficiently.
-* Determining the key that a given file on the special remote is
-  storing the content of.
-* Resuming an interrupted export, without re-uploading all the files.
-* Detecting a partially uploaded file, because the current state treeish
-  for the remote should not contain that file.
-* Knowing what key was in the process of being sent to a partially uploaded
-  file, and so resuming that upload. Look at the goal treeish and see what
-  key it has for the file; as long as the goal treeish is the same goal
-  that was used for the interrupted export, that's the key. (This needs a
-  way to track if the goal has changed.)
-* Optionally, making `git annex sync` and the assistant upload as needed
-  to satisfy goal treeishes for special remotes.
-"""]]
diff --git a/doc/todo/export/comment_5_e5ac435b73818d9002f5ada84062e933._comment b/doc/todo/export/comment_5_e5ac435b73818d9002f5ada84062e933._comment
deleted file mode 100644
index 037754881e..0000000000
--- a/doc/todo/export/comment_5_e5ac435b73818d9002f5ada84062e933._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2017-07-10T18:15:02Z"
- content="""
-Using trees like that would not work well in a distributed setting
-where two repositories could be storing content on the same special remote.
-
-The per-remote trees could be stored, by eg grafting them into the
-git-annex branches's tree under the uuid of the special remote.
-
-But, there could then be merge conflicts, when different trees have been
-exported to the same special remote concurrently. And there's no way to
-resolve such a merge: If repo A uploaded F containing K and B uploaded F
-containing L, we don't know which file the special remote ended up with.
-If that happened it would have to delete and re-export from scratch.
-
-I think it's fine for exporting to only be able to be done from one
-repository. But, if a user tries to do the above, it needs to fail in some
-reasonable way, not leave a mess.
-"""]]
diff --git a/doc/todo/export/comment_6_88529583c38bc0c13dbe9a097e97b744._comment b/doc/todo/export/comment_6_88529583c38bc0c13dbe9a097e97b744._comment
deleted file mode 100644
index 376e5ad900..0000000000
--- a/doc/todo/export/comment_6_88529583c38bc0c13dbe9a097e97b744._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2017-07-11T15:32:07Z"
- content="""
-I've started a more detailed/coherent design document at
-[[design/exporting_trees_to_special_remotes]].
-"""]]
diff --git a/doc/todo/export/comment_7_8f1c20d78e3d8e00757a8819045fdcc8._comment b/doc/todo/export/comment_7_8f1c20d78e3d8e00757a8819045fdcc8._comment
deleted file mode 100644
index 3b32fa7b0c..0000000000
--- a/doc/todo/export/comment_7_8f1c20d78e3d8e00757a8819045fdcc8._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="roger.herikstad@ca3b99b0263344ccfd8ec134a12261be25ef3504"
- nickname="roger.herikstad"
- avatar="http://cdn.libravatar.org/avatar/ad4ab4eded6bcd5d60bacc446419a4fd"
- subject="Not working with rsync?"
- date="2018-02-28T02:41:38Z"
- content="""
-I was hoping to use export as a way of exporting my repository to a server where I'd like non-git users to be able to directly access the files. 
-The server is a Synology box, and I would like users to be able to see and download files through File Station. I have successfully set up git-annex on this box, but when I tried navigating to the path of the repository in File Station, it seems that File Station was not able to follow the symbolic links to download file contents. I then thought of using export in combination with an rsync special remote, but git annex returns an error saying that exporttree=yes is not support for this kind of remote. Is this something that could be fixed in future versions, or is there something about rsync special remote that prevents export from working in principle?
-
-"""]]
diff --git a/doc/todo/export/comment_8_3b93389a1f50aad0f759d361f06200e9._comment b/doc/todo/export/comment_8_3b93389a1f50aad0f759d361f06200e9._comment
deleted file mode 100644
index c68f7161ab..0000000000
--- a/doc/todo/export/comment_8_3b93389a1f50aad0f759d361f06200e9._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 8"""
- date="2018-02-28T15:54:06Z"
- content="""
-Remotes need to have a nontrivial amount of code added to them in order to
-support export. That had not been done for rsync yet. I've implemented it
-now.
-"""]]
diff --git a/doc/todo/export_preferred_content.mdwn b/doc/todo/export_preferred_content.mdwn
deleted file mode 100644
index bc82528b31..0000000000
--- a/doc/todo/export_preferred_content.mdwn
+++ /dev/null
@@ -1,240 +0,0 @@
-`git annex export` normally exports all files in the specified tree,
-which is generally what the user wants.
-But, in some situations, the user may want to export a subset of files,
-in a way that can be well expressed by a preferred content expression.
- 
-> started work on this in the `preferred` branch. --[[Joey]]
->
-> > And [[done]]! --[[Joey]]
-
-For example, they may want to export .mp3 files but not the .wav
-files used to produce those.
-
-Or, export podcasts, but not ones in a "old" directory that have already
-been listened to.
-
-It seems doable to make `git annex export` honor whatever
-preferred content settings have been configured for the remote.
-(And `git annex sync --content` too.)  
-> done
-
-Logs.Export already records the tree that the user chose to export
-into the git-annex branch. Should excluded files be present in that
-tree or not? A good reason to do that is that if the preferred content
-settings change, the next export will pick up on the change, since
-the exported tree differs from the tree to be exported.
-So: Make export of a tree filter that tree through the preferred
-content of the remote, and use the new tree as the tree that really
-gets exported, recording it in the git-annex branch. But the remote
-tracking branch will point to the tree that the user chose to export.
-> done
-
-Problem: A preferred content expression include=subdir/foo or
-exclude=subdir/bar matches relative to the top of the repository.
-But `git annex export` may be exporting a sub-tree, and it has no way
-of knowing where a provided sub-tree sha is rooted within the larger tree.
-What it could do is when provided "master:subdir" know that it's operating
-within subdir and prefix that to filenames when matching preferred content.
-But that would be inconsistent behavior and could violate least surprise. 
-It may be better to add a note that preferred content expressions include=
-exclude= etc match relative to the top of the exported tree when exporting
-a subtree.
-> done
-
-Note: Each `git-annex sync --content` re-filters the exported tree.
-Unnecessary work. If there were a way to look up the original tree that
-corresponds with the filtered exported tree, that could be avoided.
-
-----
-
-> `git annex import` of a tree from a special remote would also be
-> influenced by this.
-> 
-> It would make sense for the ImportableContents to have files
-> that are not preferred content filtered out of it. Eg, if a .wav file
-> is added to the remote, it shouldn't be downloaded. Or a better example,
-> if directory Music is excluded from an android remote, importing from
-> it should exclude that directory.
-> > done
-
-## import after limited export
-
-> Problem: If a tree is exported with eg, no .wav files, and then an import
-> is made from the remote, and necessarily lacks .wav files, the remote
-> tracking branch will be updated with a tree with no .wav
-> files. Merging that into master will delete all the .wav files.
-> 
-> So it seems that, when updating the remote tracking branch for an import,
-> the files that were excluded from being exported to it need to be added
-> back in. So that tree of excluded files needs to somehow be kept track of
-> when exporting.
->
-> Complication: The export might happen from one clone and then another
-> clone imports. The clones might not sync in between. Seems all that
-> the importing clone can rely on is its local state.
-> 
-> If importing with no remote tracking branch existing yet, the import will
-> create one with a disconnected history, and so it's ok to import a tree
-> missing excluded files; merging a disconnected history won't delete 
-> those files from master.
-> 
-> In the multiple clone case, the importing clone can't rely on information
-> from the exporting clone, but if the importing clone only ever imports
-> it's fine; if it exports it needs to take that into account for
-> subsequent imports.
-> 
-> So, the only case where the excluded files
-> need to be added back is when there was a previous export done from
-> the current repo. The list of excluded files in the export can 
-> be recorded locally and added back to the import.
-> 
-> > done
-
-## matching preferred content expressions on import
-
-> Matching a preferred content expression at import time before the content
-> is downloaded means that the imported key may not yet be known. (Only
-> when the ContentIdentifier is known can it can be mapped back to an
-> already known key.) This is a problem for every preferred content term
-> that relates to a key. 
-> 
-> Maybe the problem expressions can be guessed:
->
-> * For copies, lackingcopies, and approxlackingcopies, inallgroup, 
->   the number of copies could be assumed to be 1 (the remote being
->   imported from). But if it turns out to hash to a known key,
->   they would have matched wrong.
-> 
-> * For inbackend and securehash, the backend that will be used for the
->   import is probably known. But if annex.largefiles becomes
->   supported for imports, it would not be any longer.
-> 
-> * For metadata, if we assume the imported file is new content, 
->   is has no metadata attached. But if it turns out to hash
->   to a known key, this would have matched wrong.
-> 
-> * For present, the content is in the remote, so it's definitely present.
-> 
-> * For unused, the file is going to be added to the tree, its key
->   will definitely not be unused.
-> 
-> So in some cases the guess is wrong and a problem expression
-> matches when it should not. This either results in a file being imported
-> that should not, or a file not being imported that should be.
-> In the former case, when the file reaches the master branch and
-> a later export is done, the file may or may not be preferred content
-> for the special remote then, and when it's not it will get removed from
-> the special remote.
-> 
-> So for example: The user sets a preferred content expression of
-> "metadata=notforexport=true" and has some files with that set.
-> Then they import from a remote, and it downloads a new file that happens
-> to have the same content as one of those files.  The new file gets
-> added to their master branch, and they export to the remote and the
-> new file is then removed from the remote. Seems fairly ok?
-> 
-> Another example: The user sets a preferred content expression of "not
-> inallgroup=backup". The import/export remote is not in that group.
-> They import from it, and find that no new files that are added to the
-> remote ever get imported. That seems to be what they asked for.
-> 
-> Another example: The user sets a preferred content expression of "not
-> inallgroup=exports". The import/export remote *is* in that group,
-> and so are several other import/export remotes.
-> They import from it, and find that no new files that are added to the
-> remote ever get imported. Even if the same file got added to all other
-> remote in that group. This seems surprising!
-> 
-> Maybe better than guessing would be to limit preferred content
-> expression matching for importing to terms that don't require the key.
-> If an expression is found to require the key, display a warning and 
-> don't import. 
-> 
-> OR download the content
-> from the remote, generate a key from it, and re-match the preferred
-> content expression. That avoids any surprises and supports all
-> expressions at the expense of an unnessary download. As long as the
-> ContentIdentifier to Key mapping gets updated, it will only download
-> a given file unncessarily one time.
-> 
-> Which approach is better? Note that almost all of the standard groups
-> do depend on the key. But it seems very likely that most actual
-> uses of this feature would involve the name or size of a file that's
-> being imported, and nothing else.
-> 
-> Imagine an import of all non-mp3s from the phone, and the phone has
-> a 20 gb mp3 collection. Downloading them all just to check the preferred
-> content expression would be an enormous amount of unnecessary work.
-> If the user started with `exclude=*.mp3`, they'd expect it to be fast,
-> and if they changed to `exclude=*.mp3 or metadata=tag=podcast`
-> and it did all that extra work, that would be surprising.
-
-> > done; it seemed to make sense at least at first to make import
-> > fail when the preferred content dependened on a key.
-
-## different preferred content for export and import?
-
-May be cases where this makes sense. For example, I might make my phone
-prefer all content that has some metadata set, but want to import all files
-from my phone (or all files except those in the music directory).
-
-OTOH, that config would cause files imported from the phone to be removed
-from it on the next export, unless the necessary metadata got set; git
-annex sync --content would not work well.
-
-Better example: Make the phone want all content that is in the laptop
-group, so all files on my laptop export to the phone but not others that I
-have archived. But want to import all files from the phone except for mp3s.
-
-One way would be new preferred content terminals that match when importing
-and exporting:
-
-	(exporting and copies=laptop:1) or (importing and exclude=*.mp3)
-
-This needs preferred content expressions for import to be able to
-support things like copies= that need to know the key, as discussed above.
-
-If the import preferred content expression is limited to not include those
-terms, the above example can't be used at import time. Unless it can be
-simplified before being checked for those terms:
-
-	(false and copies=laptop:1) or (true and exclude=*.mp3)
-
-	false or (true and exclude=*.mp3)
-
-Or there could be separate expressions for import and export.
-And this kind of makes sense; the normal preferred content expression
-controls what is stored on a remote, so affects export, and the import
-preferred content expression is only used to fine-tune which files get
-imported from it.
-
-Problem: Suppose a tree is exported to a special remote, and the tree includes some
-mp3 files. And then an import is done, excluding mp3 files. That will
-create a remote tracking branch that lacks the mp3 files; merging it will
-delete them from master. That could be surprising! This is the inverse of
-the "import after limited export" problem, but it seems it 
-can't be solved in a similar way.
-
-That problem might be a fatal blow to this idea of separate expressions
-for import and export. But it's worse than that! -- 
-
-Problem: Suppose a tree is exported to a special remote and the tree
-includes mp3 files. Then the remote's preferred content is set to exclude
-mp3 files. Then on import from the remote, a tree will be constructed that
-lacks the mp3 files that were exported before; merging it will delete them
-from master.
-
-That could be avoided by making the import notice that the preferred
-content expression has changed, and so throw away the old remote tracking
-branch history and import a commit with no parent, avoiding the deletion.
-But, if some other file got deleted from the special remote after the
-export, the import would then not delete it.
-
-Alternatively, when a preferred content expression doesn't match a file at
-import, could check if the same file is known to be present on the remote
-as of the last import or export. (With same or different content.) If so,
-assume the preferred content has changed and that the user does not want to
-delete this file, so keep it in the import anyway. This way the import does
-not delete files from master, and when the next export removes it from
-the remote it will still not get deleted from master.
-> done
diff --git a/doc/todo/feature_request__58___pubkey-only_encryption_mode.mdwn b/doc/todo/feature_request__58___pubkey-only_encryption_mode.mdwn
deleted file mode 100644
index 5a3c108856..0000000000
--- a/doc/todo/feature_request__58___pubkey-only_encryption_mode.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-### Feature request
-
-It is not possible to put encrypted content in place on remotes with just a
-public GPG key. You always need the private key, even for encryption. I
-guess this is because how the cipher HMAC is used for replacing file names
-with their hashes. However, if that requirement (having secret file names)
-was dropped, I assume a pubkey-only mode could be implemented?
-
-My specific use case is backup archiving. I have my backups packed in
-archive files and want to use git-annex to copy the archives to offsite
-remotes (S3). In that case, I don't care much about hiding file names, but
-would appreciate the increased security of not having the secret key on the
-backup server. It would only be needed if I wanted to verify or restore
-backups.
-
-> Added "encryption=sharedpubkey" [[done]] --[[Joey]]
diff --git a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment b/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment
deleted file mode 100644
index 0e2f5e3ba6..0000000000
--- a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-03-31T19:37:20Z"
- content="""
-When you use encryption=pubkey, the symmetric key that is used for
-HMAC encryption of filenames is encrypted using your gpg private key.
-The contents of files are also encrypted using your gpg private key
-(not using the symmetric key; that mode is encryption=hybrid).
-
-So, with encryption=pubkey, all that can be done with that symmetric key is
-to HMAC encrypt filenames and try to find results that match the HMACed
-filenames used on the remote. So, if you don't care about filenames
-leaking, you could publish that symmetric key with no bad effects. Its
-security is not important to you based on what you've said.
-
-But again, that symmetric key is encrypted with your gpg private key.
-The only way to decrypt it would be to break your gpg key somehow. In which
-case you have big problems. But not ones caused by the existence of the
-symmetric key.
-
-So, I see no benefit to the suggested mode.
-"""]]
diff --git a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment b/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment
deleted file mode 100644
index f75bb58b6c..0000000000
--- a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawl6rte43qSRK1o2zn7Ww4Z8pgBmJm8gDrc"
- nickname="Rickard"
- subject="comment 2"
- date="2015-04-04T07:34:58Z"
- content="""
-> The contents of files are also encrypted using your gpg private key
-
-I assume you meant to say gpg *public* key here?
-
-You're correct in that I can publish the symmetric HMAC key unencrypted with no bad effects for me. I've searched the documents but haven't found a way to tell git-annex to use a specific, unencrypted, symmetric key for HMAC, though. Is there a way?
-
-> So, I see no benefit to the suggested mode.
-
-I don't understand the reasoning that made you come to this conclusion.
-
-Let me restate my use case:
-
-With only the public part of a gpg key id available to a user, I would like that user to be able to add files to a git-annex repository. The user should then be able to copy the files encrypted to remotes that support encryption (S3 etc). The user should not be able to fetch or verify files from the encrypted remotes (since she lacks the private gpg key). The remote would be write-only for the user, basically. However, a friend of the user, possessing the private key (and having access to the remote), should be able to use the remote just like a normal git-annex remote.
-
-This is the normal way of using gpg for asymmetric encryption of files. I would find it useful to be able to use git-annex in a similar way. As far as I can understand, only the encrypted HMAC key is stopping me from using git-annex in this way. 
-
-However, there might be other things in git-annex' design that would make it difficult or even impossible to implement this functionality. It could also be the case that there's no benefit to adding this functionality to git-annex because there is some other (simpler) way to achieve the same thing. Both these cases are perfectly acceptable, but I would then be interested in knowing a bit more details.
-"""]]
diff --git a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment b/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment
deleted file mode 100644
index 1278aaab38..0000000000
--- a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-04-06T17:04:34Z"
- content="""
-I somehow completely misread what you wanted! Thanks, it makes sense now.
-
-I anticipate there would be one problem with this mode; `git annex fsck --from remote` 
-would fail because it would be unable to decrypt the encrypted content
-when run on the client that is only able to encrypt to the public key, but
-lacks the necessary private key to decrypt.
-
-(So would `git annex move --to remote; git annex get --from remote`, but
-presumably that failure is the point of the mode..)
-
-It would be fairly easy to add this, I think. There is already support
-for configuring the MAC algorithm to use to encrypt filenames. Your mode seems
-to just need a "clear" mode that doesn't encrypt filenames at all.
-
-It does add complication to crypto paths, and potential for user
-foot-shooting though.
-
-I'm going to move this feature request from bugs/ to todo/ 
-"""]]
diff --git a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_4_2ccd5e75f175f09b08cee2290720fdea._comment b/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_4_2ccd5e75f175f09b08cee2290720fdea._comment
deleted file mode 100644
index 558b037962..0000000000
--- a/doc/todo/feature_request__58___pubkey-only_encryption_mode/comment_4_2ccd5e75f175f09b08cee2290720fdea._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2016-05-10T17:59:03Z"
- content="""
-Thinking about this some more, I think it makes sense that your friend who
-is doing the uploading is doing it from a clone of your repository.
-
-So, they could have access to the HMAC key, and could use it to encrypt
-filenames, rather than using the un-encrypted keys. filenames seems better,
-because there's no point in exposing the un-encrypted filenames to S3.
-
-So, the encryption setup on such a repository would be the un-encrypted
-HMAC key, and an indication of what gpg public key to encrypt file contents
-to.
-
-(Of course, you might choose to expose a sanitized form of your real
-repository for cloning, that's more or less empty. And could even expose
-it to the whole world if you want to let anyone use it for sending files
-to you. In this case the un-encrypted HMAC key would be a pretty open secret.)
-"""]]
diff --git a/doc/todo/find_unlocked_files.mdwn b/doc/todo/find_unlocked_files.mdwn
deleted file mode 100644
index 2ed6b157ba..0000000000
--- a/doc/todo/find_unlocked_files.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-As suggested at [[forum/Find_unlocked__47__locked_files]], can the file matching conditions be extended to be able to find unlocked files?
-
-> sure, [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex-fromkey_behavior_when_target_file_exists.mdwn b/doc/todo/git-annex-fromkey_behavior_when_target_file_exists.mdwn
deleted file mode 100644
index 17414993b9..0000000000
--- a/doc/todo/git-annex-fromkey_behavior_when_target_file_exists.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-Currently, git-annex-fromkey errors if the target file exists.  It would help if, when the target file is the same symlink that would be created by the command (i.e. to the same key), this wasn't considered an error.  Together with [[todo/batch_command_result_status]] this would make the command a more robust building block for higher-level operations.
-
-> idempotency is good, [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex-inprogress_--key.mdwn b/doc/todo/git-annex-inprogress_--key.mdwn
deleted file mode 100644
index efb9ae6f3b..0000000000
--- a/doc/todo/git-annex-inprogress_--key.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-Unlike `whereis` and other subcommands, `inprogress` does not offer a `--key` argument to select files by key rather than checked-out name,
-making it unusable in bare repositories.
-
-Please consider adding a `--key` option there, which would display the single incomplete file corresponding to the key if one is in progress.
-
-My use case is serving git-annexed files to the web from a bare repository (, see also [[todo/git-annex-cat]]), which would be especially useful with gitolite repositories as they are by design bare, and on devices where checkouts are cumbersome (cf. [[forum/Dealing_with_crippled_Android_file_system]]).
-
-A workaround is running `git annex inprogress --all | grep $KEY`, but that's probably relying on an implementation detail that could be changed at any time (though it probably won't as to avoid race conditions as in `tail -f $(git annex inprogress file-thats-almost.done)`).
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch.mdwn b/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch.mdwn
deleted file mode 100644
index a0986b2adf..0000000000
--- a/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-    [249 of 596] Compiling Database.Init    ( Database/Init.hs, dist/build/git-annex/git-annex-tmp/Database/Init.o )
-    
-    Database/Init.hs:52:27: error:
-        Not in scope: type constructor or class ‘SqliteConnectionInfo’
-    Makefile:32: recipe for target 'git-annex' failed
-    make[1]: *** [git-annex] Error 1
-
-Backporting recent persistent-sqlite to stretch is highly unlikely to succeed, given how tangled Haskell library dependencies tend to be.  So, unless there is an easy fix for this, git-annex will have to be removed from stretch-backports.  That would be a shame, but I guess buster isn't so far away now!
-
---spwhitton
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch/comment_1_6ce1c5cbfbf1d3428e54c98fddf2de1c._comment b/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch/comment_1_6ce1c5cbfbf1d3428e54c98fddf2de1c._comment
deleted file mode 100644
index ce590f326d..0000000000
--- a/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch/comment_1_6ce1c5cbfbf1d3428e54c98fddf2de1c._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-11-09T17:09:50Z"
- content="""
-I've ifdefed in support.
-"""]]
diff --git a/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch/comment_2_10fe16e5bb93267b5143f1091a9ed975._comment b/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch/comment_2_10fe16e5bb93267b5143f1091a9ed975._comment
deleted file mode 100644
index ad573347d6..0000000000
--- a/doc/todo/git-annex_7.20181105_not_buildable_against_Debian_stretch/comment_2_10fe16e5bb93267b5143f1091a9ed975._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 2"
- date="2018-11-09T21:07:32Z"
- content="""
-Thank you.  I am excited to try v7 on my own repos!
-"""]]
diff --git a/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch.mdwn b/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch.mdwn
deleted file mode 100644
index 5c17a89ddc..0000000000
--- a/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-When trying to build the latest release on stretch,
-
-    [206 of 597] Compiling Messages.Concurrent ( Messages/Concurrent.hs, dist/build/git-annex/git-annex-tmp/Messages/Concurrent.o )
-    
-    Messages/Concurrent.hs:138:20: error:
-        * Couldn't match type `MessageState' with `Annex a -> Annex a'
-          Expected type: MessageState -> Annex a -> Annex a
-            Actual type: (Annex a -> Annex a) -> Annex a -> Annex a
-        * In the expression: id
-          In an equation for `hideRegionsWhile': hideRegionsWhile = id
-        * Relevant bindings include
-            hideRegionsWhile :: MessageState -> Annex a -> Annex a
-              (bound at Messages/Concurrent.hs:138:1)
-    Makefile:32: recipe for target 'git-annex' failed
-
-It would be nice if this could be patched so that git-annex can continue to be shipped in the stretch-backports repository.
-
---spwhitton
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch/comment_1_46ec79457d85a772d8c8f830da80ffab._comment b/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch/comment_1_46ec79457d85a772d8c8f830da80ffab._comment
deleted file mode 100644
index 5b53c8082c..0000000000
--- a/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch/comment_1_46ec79457d85a772d8c8f830da80ffab._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-03T16:33:17Z"
- content="""
-Simple fix in [[!commit 19372e47ea2d4e153c1ba35cc3267879ebaa2050]].
-"""]]
diff --git a/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch/comment_2_cbbb66f73d4e7348e9ba56de50962611._comment b/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch/comment_2_cbbb66f73d4e7348e9ba56de50962611._comment
deleted file mode 100644
index 28be62f7d2..0000000000
--- a/doc/todo/git-annex_7.20181121_not_buildable_against_Debian_stretch/comment_2_cbbb66f73d4e7348e9ba56de50962611._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 2"
- date="2018-12-03T16:38:12Z"
- content="""
-Thanks!  Once the buildds catch up, I am excited to have git-annex v7 in both buster and stretch-backports.
-"""]]
diff --git a/doc/todo/git-annex_ignores_GIT__95__SSH.mdwn b/doc/todo/git-annex_ignores_GIT__95__SSH.mdwn
deleted file mode 100644
index f3c80e152f..0000000000
--- a/doc/todo/git-annex_ignores_GIT__95__SSH.mdwn
+++ /dev/null
@@ -1,43 +0,0 @@
-### Please describe the problem.
-
-git uses environment variable GIT_SSH to determine SSH client.
-
-I set it to plink.exe because I extensively use pageant infrastructure and do NOT want to have 2 systems lying around.
-
-Unfortunately git-annex seems to ignore that.
-
-Even worse, it results in unpredicted behavior because the git part works (e.g. clone) whereas annex/rsync does not resulting in half-ok repositories without meaningful error messages.
-
-It only becomes evident when ssh.exe in the git repository is deleted.
-
-### What steps will reproduce the problem?
-
-Set %GIT_SSH% and remove ssh.exe
-
-You will get
-
-     git-annex: ssh: createProcess: does not exist (No such file or directory)
-     failed
-     git-annex: drop: 1 failed
-
-### What version of git-annex are you using? On what operating system?
-
-Windows 8,
-
-     $ git annex version
-     git-annex version: 5.20140411-gda795e0
-     build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
-     key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
-     remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
-     local repository version: 5
-     supported repository version: 5
-     upgrade supported from repository versions: 2 3 4
-
-
-### Please provide any additional information below.
-
-
-> This got fixed a while back, but you have to set `GIT_ANNEX_USE_GIT_SSH`
-> to make it use it because the `GIT_SSH` command needs to support a
-> parameter that some commands may not support.
-> See the git-annex man page for details. [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex_ignores_GIT__95__SSH/comment_1_958dd21d7e981232f03b4516521ac226._comment b/doc/todo/git-annex_ignores_GIT__95__SSH/comment_1_958dd21d7e981232f03b4516521ac226._comment
deleted file mode 100644
index c13c3d0896..0000000000
--- a/doc/todo/git-annex_ignores_GIT__95__SSH/comment_1_958dd21d7e981232f03b4516521ac226._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 1"
- date="2014-05-16T16:42:41Z"
- content="""
-This is good spotting of a git configuration that git-annex does not support.
-
-However, I doubt that even if I made it use `GIT_SSH`, it would be useful. git-annex uses several features that are probably unique to openssh, including connection caching. While you could disable annex.sshcaching and perhaps get a different ssh to work, it would be much slower.
-"""]]
diff --git a/doc/todo/git-annex_ignores_GIT__95__SSH/comment_2_319a7e8122e7bc25d9399ba463a16158._comment b/doc/todo/git-annex_ignores_GIT__95__SSH/comment_2_319a7e8122e7bc25d9399ba463a16158._comment
deleted file mode 100644
index 1294196ba9..0000000000
--- a/doc/todo/git-annex_ignores_GIT__95__SSH/comment_2_319a7e8122e7bc25d9399ba463a16158._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="divB"
- ip="171.67.172.81"
- subject="comment 2"
- date="2014-05-17T23:58:19Z"
- content="""
-Hi Joey,
-
-Thanks for your answer. In my opinion, this would be an important requirement for various reasons:
-
-1.) It is very confusing and results in unpredictable errors. I spent days in finding out what caused all the weird stuff that happened. Even if it is not supported, an error message or at least warning should be issued.
-
-2.) At least in Windows, plink.exe is the quasi-standard SSH client. All SW I am aware of supports at least plink.exe as alternative to openssh (SVN, git, unison, ...). Even within cygwin I often use plink for X11 forwarding etc. If features like SSH caching do not work with that it's totally fine.
-
-3.) Even for a unix environment, it is critical to be able to use a wrapper (or at least to configure SSH parameters). In my opinion, this should and must work consistently (git, git-annex and rsync). For example what if I have a dedicated public key for a repository and to not want to use %HOME%\.ssh\id_rsa ?
-For unison, I use a wrapper my_ssh.cmd which wraps specialized parameters (in particular SSH key, port) with plink.exe to ssh.exe's interface. Similarly, I might be interested in disabling agent functionality and use GSSAPI etc. etc.
-
-A little bit OT now: I already wondered if and how inefficient git-annex is in this regard. For example, if I sync content, it seems that ssh opens a new connection for each file! (at least each file results in a signing request in my agent). This happens even if I use ssh.exe. Is there anything wrong?
-
-Thanks
-
-"""]]
diff --git a/doc/todo/git-annex_ignores_GIT__95__SSH/comment_3_cc1936f18721a912bb77903be6c4a45f._comment b/doc/todo/git-annex_ignores_GIT__95__SSH/comment_3_cc1936f18721a912bb77903be6c4a45f._comment
deleted file mode 100644
index ff50c0599c..0000000000
--- a/doc/todo/git-annex_ignores_GIT__95__SSH/comment_3_cc1936f18721a912bb77903be6c4a45f._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm5WyknJirJJridJjiPNgrlYxGG9xrZBvA"
- nickname="Daniel"
- subject="comment 3"
- date="2014-06-06T10:49:27Z"
- content="""
-Agreed. I'd rather lose connection caching than have to maintain both putty keys and openssh keys on my windows machines.
-"""]]
diff --git a/doc/todo/git-lfs_http_authentication.mdwn b/doc/todo/git-lfs_http_authentication.mdwn
deleted file mode 100644
index 2dd5e21cd4..0000000000
--- a/doc/todo/git-lfs_http_authentication.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-Currently the git-lfs special remote needs a ssh url to the server,
-because it only supports authentication over ssh. To support a http url,
-it needs to do http basic authentication (easy enough) using a username
-and password that it prompts the user for, ideally the same way git would
-when accessing that repository over http.
-
-`git credential` provides a way to reuse git's authentication system,
-and would be more appropriate to use here than git-annex's own creds
-system for special remotes. --[[Joey]]
-
-> [[done]] --[[Joey]]
-
diff --git a/doc/todo/git_annex_open.mdwn b/doc/todo/git_annex_open.mdwn
deleted file mode 100644
index 8edbfbd373..0000000000
--- a/doc/todo/git_annex_open.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-I had an idea the other night that there could be a `git annex open` command. What this would do would be the following:
-
-* if the file is already present locally: just `xdg-open` it
-* if it is not present and cannot be streamed: `git annex get "$@" && xdg-open "$@"`
-* if it can be streamed: `git annex get "$@"` and `xdg-open` when enough content has been streamed that we are confident it will play completely (unless network conditions change)
-
-This would need some [[metadata]] support partly to guess if the file can be streamed, but also to find the content. It would also assume some more intelligence in `git annex get` where git annex would have progress information (maybe through [[chunking]]?).
-
-How does that idea sound? --[[anarcat]]
-
-I think this idea can be considered obsoleted by the [[git-annex-inprogress]] command. --[[anarcat]] [[done]]
diff --git a/doc/todo/git_annex_open/comment_1_67d90a1cb104d98e816354d96e1b0306._comment b/doc/todo/git_annex_open/comment_1_67d90a1cb104d98e816354d96e1b0306._comment
deleted file mode 100644
index e1b442d174..0000000000
--- a/doc/todo/git_annex_open/comment_1_67d90a1cb104d98e816354d96e1b0306._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2014-11-10T17:11:52Z"
- content="""
-Hmm, well, there have been requests for access to files as they're being
-get-ed before. This does have the advantage of providing that,
-but I don't know if I like trying in xdg-open, which might not always
-be the way a user wants to open a file.
-
-git-annex does have progress info available while a file is being
-transferred. (If nothing else, it tends to know the key size, and can
-see the file size.) However I don't know how it could tell if "enough"
-of the file was available to stream it.
-
-I guess what I'd be most comfortable with is putting in plumbing.
-Like making `examinekey` be able to report the temporary file
-that is used when a key is being downloaded. It might also make sense to
-have a bit of plumbing that waits for a file being downloaded to get
-to X% complete, or something.
-"""]]
diff --git a/doc/todo/hide_missing_files.mdwn b/doc/todo/hide_missing_files.mdwn
deleted file mode 100644
index b478b863d6..0000000000
--- a/doc/todo/hide_missing_files.mdwn
+++ /dev/null
@@ -1,29 +0,0 @@
-I seem to recall a time when [[direct mode]] would hide files that were not present in the local repository. While this created a bunch of headaches for people that wanted to get the missing files, it was great for users that didn't care and only wanted to see what was actually there. (In fact, it was suggested as a solution in [[forum/usability:_what_are_those_arrow_things__63__/]], a year and a half ago.)
-
-Now this behavior has changed, and with v6 coming up, all those distinctions have basically gone away anyways...
-
-So what's someone to do if he wants to deal with the usability issue mentioned above? To restate: the problem is users I share files with often see a *lot* of files, with only a fraction of them being actually present. A lot of those files are obviously large, and so they are having a frustrating experience with git-annex because they see all those promises of "files being there" but they have a hard time actually finding which files *really* are there. So they click one one broken link after the other and generally give up before they figure out how to pop a terminal open, use `find -L -type l` or `find -type l` (i can never remember which!) - something we can hardly expect from the average GUI user...
-
-Maybe this could be accomplished through a [[dumb, unsafe, human-readable backend]]?
-
-Thanks for any advice! --[[anarcat]]
-
-> This has never been done by direct mode AFAICR.
-> 
-> But, [[design/adjusted_branches]] can do it. The basic functionality is
-> implemented already; what's missing is that, once in an adjusted branch 
-> with missing files hidden, when a file's content arrives the adjusted
-> branch needs to be updated to expose the file.
-> 
-> This will need hooks into
-> the adjusted branch code when file contents are get/dropped, and the
-> naive way to do it could make things quite slow, if the branch needs to
-> be re-adjusted after each get/drop of each file. --[[Joey]]
-
-> > I ended up creating a new special remote for this, documented in
-> > [[forum/syncing_music_to_my_android_device]]. It would be much 
-> > cleaner, of course, if adjusted branches could do this. --[[anarcat]]
-
-Other discussions: [[forum/How_to_hide_broken_symlinks]], where the idea of using views to hide missing files is introduced and [[forum/How_do_I_hide_files_not_present_in_the_local_annex__63__]], where it is said that placeholders shouldn't be used in direct mode... --[[anarcat]]
-
-> [[done]]! --[[Joey]]
diff --git a/doc/todo/hide_missing_files/comment_1_9851558a528119279a901e97de285d39._comment b/doc/todo/hide_missing_files/comment_1_9851558a528119279a901e97de285d39._comment
deleted file mode 100644
index 555fbefdeb..0000000000
--- a/doc/todo/hide_missing_files/comment_1_9851558a528119279a901e97de285d39._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
- nickname="jason.dixon.email"
- avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
- subject="I hope the option to show missing files remains."
- date="2017-03-07T06:30:37Z"
- content="""
-I can certainly understand the issue when people are looking to git annex like a syncthing / dropbox / bittorrent sync alternative and expecting to only see files they have. But, at least for me personally, the feature of listing files I don't have, but *can get* is HUGE. I love being able to see what I have at a glance. Being able to rename and shuffle around files that are not present on my system. This to me is one of the biggest advantages of annex over the competition.
-
-This is both in context of personal file bookkeeping (ie photo library / music etc etc) and in projects (many maya files that are not currently being referenced, but at a glance can be seen).
-
-I suppose, a compromise for usability could be to add custom icons to missing files (yeah I know... cross platform!) such as other sync programs do for incomplete-syncing files, or gui's such as tortoiseGit/SVN do for tracked files.
-"""]]
diff --git a/doc/todo/hide_missing_files/comment_2_bdae4301aa8ddc6621d4eb2612627069._comment b/doc/todo/hide_missing_files/comment_2_bdae4301aa8ddc6621d4eb2612627069._comment
deleted file mode 100644
index a26c65ffe5..0000000000
--- a/doc/todo/hide_missing_files/comment_2_bdae4301aa8ddc6621d4eb2612627069._comment
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-10-14T05:08:18Z"
- content="""
-The blocker to implementing this in views (or adjusted branch) has been
-how to efficiently update the tree after a get/drop. Doing it after every
-file is certianly too slow and also would create lots of unused tree
-objects in git that would linger until gced.
-
-And less of a blocker, but still kind of a problem is, how to run `git
-annex get` on a file if its symlink is hidden due to it not being available?
-
-Occurred to me tonight that this could be done in `git annex sync --content`,
-at the end. That way the tree update would only be done once, after however
-many gets/drops. And sync could look at the original branch when finding
-content to transfer, so would avoid the other problem too.
-
-One of my use cases for wanting this is to use it on my phone, to load up
-podcasts I want to listen to on a trip. One way I could do this is
-to use metadata to tag those podcasts with a tag that is preferred content
-for the phone. Then `sync --content` run on the phone
-would download them, and update the visible tree.
-
-The assistant could also update the visible tree at the end of a sync run.
-
-Could `sync --content` cause an update of a remotes visible tree too?
-It would need an addtion to the P2P protocol, but seems worth
-doing for symmetry.
-
-(For users who don't want to use sync but want to git-annex get/drop
-manually, they could check out the real branch temporarily, run whatever
-there, and then run a command to get back into the view where
-missing files are hidden. Of course this could be slow when the repo has a
-lot of files. Especially in v6 mode where checkout runs git-annex once per
-file.)
-"""]]
diff --git a/doc/todo/hide_missing_files/comment_3_a9590ef65875a68eb1d1d7becc98b8b8._comment b/doc/todo/hide_missing_files/comment_3_a9590ef65875a68eb1d1d7becc98b8b8._comment
deleted file mode 100644
index fe7e9bae6e..0000000000
--- a/doc/todo/hide_missing_files/comment_3_a9590ef65875a68eb1d1d7becc98b8b8._comment
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-10-17T15:50:46Z"
- content="""
-This will need some state maintained, to allow efficiently querying for
-worktree files that have gained/lost content since the last sync.
-
-At least need to maintain a map of all keys that were gained/lost since
-last time.
-
-It would be easy to loop through `git ls-tree` of the master branch,
-look up all the keys with `git cat-file`, and find in the map.
-But slow...
-
-Better would be to maintain an additional map from filename to key.
-
-The keys database already maintains a map from key to worktree file
-(and back), but only in v6 mode, and only for unlocked files.
-Not useful for this.
-
-This would need anything that changes annex pointers
-(fix/unlock/lock/pre-commit) to update the map. Would also need to make
-sure that it gets updated with any changes to the checked out branch
-made by git commit or git-annex sync. Doable, but complicated.
-
-Or, the map could be of the sha1s of the annex pointers, then loop
-through `git ls-files --stage` and look up the sha1s in the map
-would not be too slow. On my laptop, with 85000 files in the tree, 
-that command takes 0.13s. Still needs to update the map whenever
-annex pointers are changed though.
-"""]]
diff --git a/doc/todo/hide_missing_files/comment_4_e3bf8aaecc0f612873609c92814dcd12._comment b/doc/todo/hide_missing_files/comment_4_e3bf8aaecc0f612873609c92814dcd12._comment
deleted file mode 100644
index 23a8dfb9d6..0000000000
--- a/doc/todo/hide_missing_files/comment_4_e3bf8aaecc0f612873609c92814dcd12._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2018-10-18T19:27:43Z"
- content="""
-I implemented `git annex adjust --hide-missing`.
-It can be run after any change to content availability to update
-the adjusted branch, hiding or unhiding files.
-
-My implementation is not as fast as it could be; each update
-is a linear scan of the whole original branch and rebuild of the adjusted
-branch. But it all works so we'll defer speeding this up to later bug
-reports about it being too slow. ;)
-"""]]
diff --git a/doc/todo/import_--reinject.mdwn b/doc/todo/import_--reinject.mdwn
deleted file mode 100644
index b9f15cb472..0000000000
--- a/doc/todo/import_--reinject.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-There's `git annex reinject  ` for re-adding one file's contents to the local annex. But what if I have a whole bunch of files, and want git-annex itself to decide whether & where it needs to reinject them? (And if the file doesn't need to be reinjected, it would remain in its original place.)
-
-None of the `git annex import` modes work properly in this case. By default, importing adds another, unnecessary copy of the imported file (which I have to `rm` after importing). The `--clean-duplicates` mode seems close, but it insists on verifying the content in other repositories rather than just reinjecting it locally. (Let's assume that the main reason I'm trying to reinject is that I cannot access other repos.)
-
-So I'm hoping for something like `git annex import --reinject ...`. Or are there other existing ways to achieve the same? I couldn't find any.
-
-> implemented `git annex reinject --known` [[done]] (and also `git annex
-> import --reinject-known` now) --[[Joey]] 
diff --git a/doc/todo/import_--reinject/comment_1_659f0d18de4f5ee94adaf85ca106e196._comment b/doc/todo/import_--reinject/comment_1_659f0d18de4f5ee94adaf85ca106e196._comment
deleted file mode 100644
index 2aeb49cfa7..0000000000
--- a/doc/todo/import_--reinject/comment_1_659f0d18de4f5ee94adaf85ca106e196._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- subject="comment 1"
- date="2016-02-23T12:24:48Z"
- content="""
-git-annex verifies the content in other repositories when you use --clean-duplicates because if it did not, it could delete the only copy of a file you had, because it was deleting files it knew about, but didn't have.
-
-As for what you are attempting, [maybe something like this](https://git-annex.branchable.com/tips/recover_data_from_lost+found/)?
-"""]]
diff --git a/doc/todo/import_--reinject/comment_2_04074324f866420ebf0d39ddfae85ff7._comment b/doc/todo/import_--reinject/comment_2_04074324f866420ebf0d39ddfae85ff7._comment
deleted file mode 100644
index eed8434b57..0000000000
--- a/doc/todo/import_--reinject/comment_2_04074324f866420ebf0d39ddfae85ff7._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
- nickname="grawity"
- subject="comment 2"
- date="2016-03-01T07:10:55Z"
- content="""
-Thanks, but you missed my point entirely... I wasn't asking for a mode that would delete data without checking. I was asking for the complete opposite – a mode that would _inject an extra copy_ of the data without checking.
-
-Yeah, I guess I could `annex add` the files, then un-annex them, and _then_ `annex import --clean-duplicates`, but that's a somewhat long-winded approach, needing twice the space and twice the time.
-
-(...speaking of losing data, it seems that `git annex reinject` is perfectly happy to delete files if I accidentally give it the wrong target. I.e. after failing content verification, it still throws away the source.)
-
----
-
-It doesn't have to be part of git-annex; I could _script_ this feature myself, though there aren't nearly enough plumbing commands either. (For example, a command to hash a file and give its key (like `git hash-object`), or a command to find all paths for a key.)
-
-Having an equivalent of `git hash-object -w` (inject an arbitrary object) would make it even easier, but I couldn't find anything like that either.
-
----
-
-Anyway, let's cancel this todo, I'll find other ways.
-"""]]
diff --git a/doc/todo/import_--reinject/comment_3_25d650c160db9114f13c192d9fee0748._comment b/doc/todo/import_--reinject/comment_3_25d650c160db9114f13c192d9fee0748._comment
deleted file mode 100644
index 79bf038d9e..0000000000
--- a/doc/todo/import_--reinject/comment_3_25d650c160db9114f13c192d9fee0748._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2016-04-20T17:20:10Z"
- content="""
-Good point about reinject deleting files that don't verify. I've fixed that
-so it leaves them alone.
-"""]]
diff --git a/doc/todo/import_--reinject/comment_4_2ff1a97aea8c0a565a23d5f007e4490c._comment b/doc/todo/import_--reinject/comment_4_2ff1a97aea8c0a565a23d5f007e4490c._comment
deleted file mode 100644
index 8c6004a00a..0000000000
--- a/doc/todo/import_--reinject/comment_4_2ff1a97aea8c0a565a23d5f007e4490c._comment
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2016-04-20T17:22:06Z"
- content="""
-I think this would fit better as an option to `git annex reinject` than
-it would to `git annex import`. The latter has too many options anyway.
-
-It would not be hard to add something like `git annex reinject
---all-known-files`, which would check if a source file hashes to a known
-key and ingest its content into the annex if so, otherwise leaving the
-source file along.
-
-That would reinject files that had been added to the repo long ago, and
-then were deleted. I don't know if that would be considered suprising
-behavior, but it's hard to only ingest files that have a current link in
-the repo (because a. git-annex keeps no such index (mostly) and b. branches and c.
-tags). Even if it was surprising behavior to reinject old deleted files,
-I suppose `git annex unused` could be used to drop such old unused file
-contents after reinjecting them.
-
-There's also the problem of different backends; it seems such a thing would
-need to hash a file 5 different ways to make sure no hash of it is known.
-
-As to adding plumbing, I'm always open to ideas for more useful plumbing.
-
-* You can use `git annex find` to get eg, a list of keys of files in the
-  currently checked out branch. 
-* I've added a `git annex calckey` that can calculate the key that would be
-  used for a file. (eg, hashing it)
-"""]]
diff --git a/doc/todo/import_--reinject/comment_5_ab63877b47869c78a3f17465cd985bb1._comment b/doc/todo/import_--reinject/comment_5_ab63877b47869c78a3f17465cd985bb1._comment
deleted file mode 100644
index d80e6c14dd..0000000000
--- a/doc/todo/import_--reinject/comment_5_ab63877b47869c78a3f17465cd985bb1._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
- nickname="grawity"
- subject="comment 5"
- date="2016-04-20T19:21:33Z"
- content="""
-\"There's also the problem of different backends; it seems such a thing would need to hash a file 5 different ways to make sure no hash of it is known.\"
-
-Yeah, I guess you're right – and there might even be different 'hashes' in the same backend, e.g. SHA256E considers `Foo.ISO` different from `Foo.iso`...
-
-Actually I ended up doing this only twice, so manual `annex add everything` + duplicate cleaner wasn't really that bad in the end. And `annex calckey` and `annex find` with ${key} will be useful for the other scripts I have; thanks.
-"""]]
diff --git a/doc/todo/import_--reinject/comment_6_2254aee4729f8710076e08992c3ed746._comment b/doc/todo/import_--reinject/comment_6_2254aee4729f8710076e08992c3ed746._comment
deleted file mode 100644
index 95d0f588ae..0000000000
--- a/doc/todo/import_--reinject/comment_6_2254aee4729f8710076e08992c3ed746._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- subject="comment 6"
- date="2016-04-21T11:41:09Z"
- content="""
-    There's also the problem of different backends; it seems such a thing would need to hash a file 5 different ways to make sure no hash of it is known.
-
-As it leaves non-matched files alone, the user could specify the backend to minimise this requirement.
-
-Perhaps a new command \"ingest\", with an option for the backend and require --force to try all known backends?
-
-This would be very useful for my file sorting project (when I restart it).
-"""]]
diff --git a/doc/todo/import_--reinject/comment_7_76eba3fba57f8db0e7fd3a5832650145._comment b/doc/todo/import_--reinject/comment_7_76eba3fba57f8db0e7fd3a5832650145._comment
deleted file mode 100644
index 4ef9660110..0000000000
--- a/doc/todo/import_--reinject/comment_7_76eba3fba57f8db0e7fd3a5832650145._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
- subject="comment 7"
- date="2017-01-11T22:29:55Z"
- content="""
-Can I avoid git-annex making a copy of the file when using *reinject --known*? I have files larger than the available free space..
-"""]]
diff --git a/doc/todo/import_--reinject/comment_8_cd6ef504e8779088ac50cfaf2c8d96e4._comment b/doc/todo/import_--reinject/comment_8_cd6ef504e8779088ac50cfaf2c8d96e4._comment
deleted file mode 100644
index 84518a8697..0000000000
--- a/doc/todo/import_--reinject/comment_8_cd6ef504e8779088ac50cfaf2c8d96e4._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 8"""
- date="2017-02-07T21:09:58Z"
- content="""
-@CandyAngel, reinject --known moves the file into the annex. The only time I can
-see that it would make a copy is when importing from some other drive
-than the drive the repository is on, and it would then delete the source file
-after copying.
-
-It does currently always check that enough disk space exists to copy
-the file, even though it's probably going to move it. Perhaps that's why
-you thought it copied it?
-"""]]
diff --git a/doc/todo/import_from_special_remote_large_git_log.mdwn b/doc/todo/import_from_special_remote_large_git_log.mdwn
deleted file mode 100644
index 5949367156..0000000000
--- a/doc/todo/import_from_special_remote_large_git_log.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-After import from a special remote and merge, git log --stat shows
-a large diff, because every file that got imported from the special 
-remote is put on a commit with no parent, so the diff shows it as if those
-files are newly added.
-
-(Of course when using S3 with versioning, the commit tree does have
-parents, but still a root commit with no parent.)
-
-This does not seem avoidable for the initial import, even if the remote was
-populated by an earlier export, that starts a new, disconnected history for
-reasons explained in the import tree design. 
-
-Subsequent imports though could fix it, by setting the parent of the new
-import to the previous import.
-
-For versioned imports, it reuses commits from the old imported history,
-and adds more commits on top of those, so this is mostly not a problem
-there. If the old and new imported histories are disjoint, a commit or
-commits will be made with no parent, but that seems acceptable; it's an
-edge case and it's replicating the information from the remote.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/improve_gcrypt_remote.mdwn b/doc/todo/improve_gcrypt_remote.mdwn
deleted file mode 100644
index 7957fc2921..0000000000
--- a/doc/todo/improve_gcrypt_remote.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-I just created a [[bug report|bugs/gcrypt_rsync_remotes_don__39__t_work]] regarding gcrypt rsync remotes. In fact, I think the gcrypt special remote should allow rsync urls as well. The annexed files are going to be transferred using rsync anyway, aren't they? That would speed up `git annex sync` a lot, especially on slow (mobile) connections.
-
--- Lykos
-
-> There is no need to file todo items about bug reports. Closing this.
-> [[done]] --[[Joey]]
diff --git a/doc/todo/inneficiency_on_slow_filesystems_opening_nonexistant_journal_files.mdwn b/doc/todo/inneficiency_on_slow_filesystems_opening_nonexistant_journal_files.mdwn
deleted file mode 100644
index 8ffae4e860..0000000000
--- a/doc/todo/inneficiency_on_slow_filesystems_opening_nonexistant_journal_files.mdwn
+++ /dev/null
@@ -1,60 +0,0 @@
-`git-annex info uuid` was observed to be slow on a slow NFS, because
-it is opening lots of .git/annex/journal files that DNE. So does
-`git annex find --in remote`.
-
-Normally the journal is empty, but each query of a file from the git-annex
-branch still tries to open the corresponding journal file.
-
-It seems that this could be improved by making such query commands
-either commit the journal to the branch once at startup, or check if the
-journal is empty, and once there's known to be nothing in the journal,
-avoid opening files from there.
-
-Minimum patch to test if this is a significant performance impact:
-
-	diff --git a/Annex/Branch.hs b/Annex/Branch.hs
-	index 0d8eb7944..686791a3a 100644
-	--- a/Annex/Branch.hs
-	+++ b/Annex/Branch.hs
-	@@ -222,7 +222,7 @@ get file = do
-	  - (Changing the value this returns, and then merging is always the
-	  - same as using get, and then changing its value.) -}
-	 getLocal :: FilePath -> Annex L.ByteString
-	-getLocal file = go =<< getJournalFileStale file
-	+getLocal file = go =<< pure Nothing -- getJournalFileStale file
-	   where
-	 	go (Just journalcontent) = return journalcontent
-	 	go Nothing = getRef fullname file
-
-I don't see any measuable speed gain with this on my laptop SSD, but maybe
-on a slower filesystem it will?
-
-But: Concurrency. Another process may be writing changes to the git-annex
-branch, via the journal, and so this would be a behavior change. Mostly
-that seems acceptible, because there's no defined ordering of events in
-such a situation, and this change only makes it so that the writes
-effectively always come after the reads.
-
-But: Batch jobs. When a git-annex command is run in a batch mode,
-its caller can currently safely expect that running some other command,
-that modifies the git-annex branch, followed by asking the batch
-mode command to query it will yield a result that takes the earlier write
-into account.
-
-So, this optimisation seems it would be limited to commands that
-are not in batch mode and do strictly read-only queries. Which seems a bit
-hard to plumb through to the git-annex branch reading code.
-
-> Unless, perhaps, we can rely on the process that modifies the git-annex
-> branch having cleanly exited, and so committed its changes to the branch,
-> before the next batch query. Can we rely on that, or might a batch
-> mode command expect to see changes made up to the point it started
-> by a concurrent command?
-
-An easier alternative would be an option that bypasses reading the journal.
-But maybe there's some other, better way to avoid this slow case?
---[[Joey]]
-
-> yoh benchmarked the above patch on the slow NFS system, and it did not
-> result in a notable difference in speed, so it seems the basis of this
-> todo is false. [[done]] --[[Joey]]
diff --git a/doc/todo/inode_based_clean_filter_for_less_surprising_git_add.mdwn b/doc/todo/inode_based_clean_filter_for_less_surprising_git_add.mdwn
deleted file mode 100644
index 14b076dd6d..0000000000
--- a/doc/todo/inode_based_clean_filter_for_less_surprising_git_add.mdwn
+++ /dev/null
@@ -1,48 +0,0 @@
-[[forum/lets_discuss_git_add_behavior]] shows that v7 git add
-behavior when annex.largefiles is not configured is surprising to many
-users.
-
-As described in comment 2 on that thread, a major driver of `git add`
-adding files to the annex by default is that it's just as surprising for
-annexed files to get added to git, and that surprise is much harder to
-recover from. Two main cases are:
-
-	git annex add bigfile; git annex unlock bigfile; mv bigfile newname; git add .
-
-	git annex add bigfile; git annex unlock bigfile; git commit; modify bigfile; git commit -a
-
-The modify case is already handled; git-annex checks if bigfile was annexed
-before, and if so, it knows it needs to be annexed again. (Although
-annex.largefiles overrides that check.)
-
-Ilya suggested an improvement that solves the rename case: 
-Since git-annex has a record of the inode of bigfile, it can check if the
-new file has the same inode. If so, the user renamed it, so add it to the
-annex not to git.
-
-That frees git-annex to let `git add` behave as usual and not annex files
-otherwise, unless the user has indicated they always want to annex files by
-configuring annex.largefiles or whatever.
-
-Cases where a file gets added to git accidentially seem to then be limited
-to a modify+rename:
-
-	git annex add bigfile; git annex unlock bigfile; git commit; modify bigfile; mv bigfile newname; git add .
-
-Pretty uncommon case, and easy to argue that the user shot their own
-foot there; there's no way for git-annex to know that the modified renamed
-file has its origin in an annexed file. So seems acceptable.
-
-The inodes of all unlocked files are known, via the InodeCache stored in
-the keys database. Unfortunately there is not an index to make queries for
-inodes be fast. One would need to be added, at least eventually.
-[[todo/sqlite_database_improvements]] discusses how to improve the
-databases.
-
-Some filesystems don't have stable inodes etc, but all that is already
-handled by the InodeCache machinery, so I think this could work pretty
-well. --[[Joey]]
-
-> [[done]] although the sql database is used in a horrible way by the
-> current implementation, which is probably very slow in some situations,
-> so [[sqlite_database_improvements]] are now really needed. --[[Joey]]
diff --git a/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_1_cee176c02f9103e8cfce6204827bf263._comment b/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_1_cee176c02f9103e8cfce6204827bf263._comment
deleted file mode 100644
index cb94a35071..0000000000
--- a/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_1_cee176c02f9103e8cfce6204827bf263._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 1"
- date="2019-10-23T15:28:55Z"
- content="""
-Indeed, as you say, it is not reasonable for the user to expect git-annex to do the right thing in the modify+rename case.  So this proposal seems like a great way to avoid the sort of mistakes you have brought up, without having `git add` add to the annex by default.
-"""]]
diff --git a/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment b/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment
deleted file mode 100644
index 87ff161d66..0000000000
--- a/doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_2_d70a5cfdfbb3ae3d3ad5310c3896d0b0._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="searching by inode"
- date="2019-10-23T16:32:37Z"
- content="""
-\"there is not an index to make queries for inodes be fast\" -- you'd only need to query for inodes in case of a rename, and only if the rename didn't use `git mv`.  So if adding a db index is non-trivial (requires v8?), maybe it's ok if this case is slow?  Also, the git index has the [inode](https://github.com/git/git/blob/master/Documentation/technical/index-format.txt#L60) info and other `stat(2)` info preserved by a rename, and you'd only need to check index entries where the working copy file has disappeared; or maybe a [wmemchr()](https://hackage.haskell.org/package/bindings-0.1/docs/src/Bindings-StandardC.html#line-722) through the index would be fast enough?
-"""]]
diff --git a/doc/todo/integrate_support_for_spideroak_as_archive__47__backup.mdwn b/doc/todo/integrate_support_for_spideroak_as_archive__47__backup.mdwn
deleted file mode 100644
index 86254d4059..0000000000
--- a/doc/todo/integrate_support_for_spideroak_as_archive__47__backup.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-SpiderOak is a great backup service and many of us have unlimited accounts with them since World Backup Day.  That makes SpiderOak a very interesting candidate for use as an archive or backup node.  I can think of only two ways to go about this:
-
-1. Designate one of your computers as an archive/backup and use spideroak independantly to sync that archive.  This is very unattractive, since it makes the spideroak backup completely unknown to git-annex.
-
-2. Integrate the SpiderOak CLI tool somehow as a remote.  I don't know to what extent this would be possible, but if it were, that'd be awesome.  And a lot of work, presumably.
-
-Bonus option:
-
-3. Can the SpiderOak API be useful? https://spideroak.com/faq/questions/37/how_do_i_use_the_spideroak_web_api/
-
-> I don't hear much about spideroak these days, and it seems nobody has
-> wanted it enough to build an external special remote. So keeping a todo
-> about building it into git-annex seems not worthwhile. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/integrate_support_for_spideroak_as_archive__47__backup/comment_1_a47ea814f6d7727bbd0eeca6d1fd3219._comment b/doc/todo/integrate_support_for_spideroak_as_archive__47__backup/comment_1_a47ea814f6d7727bbd0eeca6d1fd3219._comment
deleted file mode 100644
index 7790a7f2d4..0000000000
--- a/doc/todo/integrate_support_for_spideroak_as_archive__47__backup/comment_1_a47ea814f6d7727bbd0eeca6d1fd3219._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="216.145.95.162"
- subject="comment 1"
- date="2014-05-19T15:05:49Z"
- content="""
-If spideroak has a CLI tool that can get/put/delete individual files, it should be quite easy to use [[the_external_special_remote|special_remotes/external]] to support it. The demo shell script could be used as a starting place.
-
-I built that so that others can easily write special remotes, and so unless spideroak's CLI is free software, I don't anticipate working on this myself.
-"""]]
diff --git a/doc/todo/integrate_support_for_spideroak_as_archive__47__backup/comment_2_6b14f729446c2e52f07ce6c9ad2ab627._comment b/doc/todo/integrate_support_for_spideroak_as_archive__47__backup/comment_2_6b14f729446c2e52f07ce6c9ad2ab627._comment
deleted file mode 100644
index 51efa49b4d..0000000000
--- a/doc/todo/integrate_support_for_spideroak_as_archive__47__backup/comment_2_6b14f729446c2e52f07ce6c9ad2ab627._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="not free software"
- date="2015-06-04T14:37:33Z"
- content="""
-According to [wikipedia](https://en.wikipedia.org/wiki/Spideroak):
-
-> *Some components of SpiderOak are open-source, and as early as 2009 the company announced their intent for the client to be fully open-source in the future.[4] As of 2015, SpiderOak's source code is not available.[5]*
-
-So that seems to be a dead end, since 2010 - total vaporware and a bunch of broken links. There is supposedly an API, but this is also a bunch of broken links. There's a copy of a very basic API [on archive.org](https://web.archive.org/web/20141019212745/https://spideroak.com/faq/questions/37/how_do_i_use_the_spideroak_web_api/) but it doesn't look like it answers the requirement here.
-
-There is a [Github page](https://github.com/SpiderOak/) with [some HTML5 client](https://github.com/SpiderOak/SpiderOakMobileClient) but it's unclear the status of this project...
-
-One has to wonder how or why Snowden gave his benediction to this project... --[[anarcat]]
-"""]]
diff --git a/doc/todo/more_efficient_memory_usage_with_git-annex_unused.mdwn b/doc/todo/more_efficient_memory_usage_with_git-annex_unused.mdwn
deleted file mode 100644
index 908ddc2084..0000000000
--- a/doc/todo/more_efficient_memory_usage_with_git-annex_unused.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-While running *git-annex unused* on an annex with tens of thousands of items, *git-annex*'s memory usage ballooned to over 3 gigs and my PC froze. I cannot run *git-annex unused* on this annex because of this issue.
-
-If it's possible, more efficient memory management would prevent this from happening.
-
-> [[done]] -- assuming the memory leak I saw was the same one you saw...
-> --[[Joey]]
diff --git a/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_1_e7811b548054d3d6851facb8d3bf8153._comment b/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_1_e7811b548054d3d6851facb8d3bf8153._comment
deleted file mode 100644
index 5247bb61cd..0000000000
--- a/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_1_e7811b548054d3d6851facb8d3bf8153._comment
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-01-31T15:36:58Z"
- content="""
-You need to provide at least a version number, and ideally enough
-information to reproduce the bug when filing bug reports.
-
-Anyhow, I ran git-annex (HEAD) unused in my big repo, and its memory use
-got up to over 1 gb which is much more than I would expect (should be
-a couple hundred mb max).
-
-The memory growth happens in the stage when it's
-constructing the bloom filter for the keys in the diff between the
-index and other branches. In my big repo, those diffs are quite large;
-eg I have a branch with 70k files and another with 0 files.
-
-I replaced insertMB with noop, so the bloom filters are not really
-populated, and it still uses as much memory. So
-the memory is not being leaked by the bloom filters themselves, but
-is instead being leaked when processing the branch diffs,
-or something like that.
-
-Need to profile to find what's leaking.
-"""]]
diff --git a/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_2_1eff4497bf0a3e87dc47a1226c5d4af8._comment b/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_2_1eff4497bf0a3e87dc47a1226c5d4af8._comment
deleted file mode 100644
index df285478cb..0000000000
--- a/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_2_1eff4497bf0a3e87dc47a1226c5d4af8._comment
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-01-31T20:24:04Z"
- content="""
-The heap profile has multiple spikes (so not an accumulating memory leak).
-The diff parsing code is indeed what's using so much memory. Looks like
-data is failing to stream through that code and instead the whole
-diff output gets buffered.
-
-Aha.. Git.DiffTree.parseDiffRaw used to return a list, but changed
-in [[!commit 8d124beba8]]
-to a Maybe list in order to avoid being a partial function. But 
-that change destroyed laziness, since the whole input has to be parsed
-in order to determine if Nothing should be returned.
-
-However, fixing that only eliminated part of the spike. There's something
-else keeping data from streaming.
-"""]]
diff --git a/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_3_3c712e871ea3cd12916497f2d8152004._comment b/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_3_3c712e871ea3cd12916497f2d8152004._comment
deleted file mode 100644
index 2a5130a950..0000000000
--- a/doc/todo/more_efficient_memory_usage_with_git-annex_unused/comment_3_3c712e871ea3cd12916497f2d8152004._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2017-01-31T23:31:03Z"
- content="""
-Fixed the rest of the streaming problem.
-
-(Also found/fixed an unrelated memory blow up in git annex unused that
-only happened when a large file got checked right into git.)
-"""]]
diff --git a/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json.mdwn b/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json.mdwn
deleted file mode 100644
index 3e9c30970e..0000000000
--- a/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-ATM I am experiencing sporadic failures of the batched  git annex addurl call -- seems to report failure (success: False) once in a while, but succeeds on a retry:
-
-[[!format sh """
-(Pdb) p url
-'http://openneuro.s3.amazonaws.com/ds000001/ds000001_R1.1.0/uncompressed/sub016/BOLD/task001_run003/QA/QA_report.pdf?versionId=null'
-
-(Pdb) p out_json
-{u'note': u'from datalad', u'command': u'addurl', u'file': u'ds000001_R1.1.0/uncompressed/sub016/BOLD/task001_run003/QA/QA_report.pdf', u'success': False}
-
-(Pdb) up
-> /home/yoh/proj/datalad/datalad/datalad/support/gitrepo.py(210)newfunc()
--> return func(self, file_new, *args, **kwargs)
-
-(Pdb) func(self, file_new, *args, **kwargs)
-{u'note': u'from datalad', u'file': u'ds000001_R1.1.0/uncompressed/sub016/BOLD/task001_run003/QA/QA_report.pdf', u'command': u'addurl', u'key': u'MD5E-s1191419--cb4efab8104b5117f64b58ee6d6a79ba.pdf', u'success': True}
-"""]]
-
-besides me blindly trying to re-run it e.g. 3 times and only then declare total failure, I wondered if json output could provide more information (if any known) about the failure... e.g. if a custom remote crashed/errorred (I guess the case here due to "from datalad") -- what was stderr/exit code for that process if crashed/ERROR msg... if wget -- what was stderr there
-
-[[!meta name=yoh]]
-
-> Switched to curl with -sS in --json mode. [[done]] I suppose. --[[Joey]]
diff --git a/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json/comment_1_0eeb859b57d4dc8a3c9c9c3c4f70bb45._comment b/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json/comment_1_0eeb859b57d4dc8a3c9c9c3c4f70bb45._comment
deleted file mode 100644
index 80dfe504b3..0000000000
--- a/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json/comment_1_0eeb859b57d4dc8a3c9c9c3c4f70bb45._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-02-20T18:50:18Z"
- content="""
-Probably wget is just failing to download the url sometimes.
-Eg, `git annex addurl http://localhost/dne` fails with the same not useful
-output.
-
-wget is run with -q, which is the only way to turn off all its informational
-messages, but unfortunately that also turns off display of HTTP error messages.
-
-Using -nv instead of -q would display HTTP errors,
-but also 1 extra line of output once the download is complete.
-I suppose that's worth the trade-off.
-"""]]
diff --git a/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json/comment_2_82b851629c695084cbf62e2b636bcc91._comment b/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json/comment_2_82b851629c695084cbf62e2b636bcc91._comment
deleted file mode 100644
index 2455f6f660..0000000000
--- a/doc/todo/more_of_diagnostic_information_in_case_of_failures_into_returned_json/comment_2_82b851629c695084cbf62e2b636bcc91._comment
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-02-20T19:15:18Z"
- content="""
-It seems there is no way to get only errors on
-stderr with wget; the choice is between no output, and a mixture of errors
-and informational messages on stderr. In --json or --quiet mode, only
-errors should be output to stderr.
-
-In general, the --json output does include a "note" with any
-available message about why an operation failed. 
-
-It would not be hard to use a HTTP library and propagate the HTTP errors
-into the json "note", but it might be hard to get resumption of partial
-downloads to work as well with a HTTP library as it works with wget/curl.
-
-What we could do is use curl in preference to wget in json mode; 
-curl -s -S avoids all progress etc output and displays the
-http errors to stderr.
-"""]]
diff --git a/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net.mdwn b/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net.mdwn
deleted file mode 100644
index bd34770724..0000000000
--- a/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-Hi Joey,
-
-Although I haven't remembered that "hash thing" to perform the job, we looked around for other ways to accomplish the mission:  quickly/simultaneously distribute annexed files to multiple hosts on the same network.  So, there are such tools as uftp to efficiently multicast files to multiple recipients.  Initial setup takes a bit but I wondered how feasible it could be to e.g. establish some "custom annex remote" (if to avoid coming up with a new command eg. "annex serve") so e.g. I could e.g. `git annex copy --to=udp-multicast ` on the host A which has all the keys, and then run `git annex get --from=udp-multicast` on the clients (B) which want to get it all.  To make it even more efficient, A could may be provide/announce on the local net a service to receive requests for desired keys to be transmitted.  But even if it just multicasts all the content of the current tree, while those clients suck them all in, it could be super useful.
-
-What do you think?
-
-[[!meta name=yoh]]
-
-> [[done]]! I've only tested it with sender and receiver on the same
-> laptop, but it seems to work. --[[Joey]] 
diff --git a/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net/comment_1_5353dc46ccecc6077f2643d281d58f99._comment b/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net/comment_1_5353dc46ccecc6077f2643d281d58f99._comment
deleted file mode 100644
index a38457d533..0000000000
--- a/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net/comment_1_5353dc46ccecc6077f2643d281d58f99._comment
+++ /dev/null
@@ -1,92 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-03-30T16:51:24Z"
- content="""
-Using a remote for this seems problimatic, because the remote is not
-pointing at a single well-defined data store, but instead whatever peers
-happen to exist on the network.
-
-For one, `copy --to=udp-multicast` would not try to send files that it thinks
-are already located in that remote. I suppose this could be dealt with by
-making the transfers always seem to fail, so it never thinks that the
-multicast remote has any files.
-
-But then, `copy --from=udp-multicast` would not try to receive files,
-unless it thinks they're in that remote. And we just established it should
-not think any files are in that remote. So that's a problem.
-
-Also, the copy from/to would need to be operating on the same file at the
-same time, which seems problimatic. If a receiving git-annex is a little
-slower than the sender, or is operating on a slightly different set of
-files, it would then miss a file being broadcast by the sender.
-
-These issues seem to point to this needing to use some other, more
-special-purpose commands for muticast.
-
-----
-
-It probably needs encryption, both for privacy and to ensure that files
-are being received from the sender you intended, and not someone else
-who might be broadcasting the contents of a different repository.
-
-Here's how to set up encryption and authentication with uftp,
-so that both client and server actually encrypt and check that they're
-talking with a known entity. It took a while to figure out.
-
-Client:
-
-	uftp_keymgt -g rsa:512 ~/client_key
-	# Parse the fingerprint value from its output; does not
-	# seem to be a better way, except perhaps using openssl to examine
-	# the key file. This is CLIENT_FINGERPRINT
-
-	# Pick a UID for the client. This is an 8-diget hex number,
-	# which needs to be unique across clients. Default is based on IP
-	# adddres, but for git-annex it could be derived from the git-annex
-	# UUID.	This is CLIENT_UID.
-
-Server:
-
-	uftp_keymgt -g rsa:512 ~/servant_key
-	# Parse the SERVER_FINGERPRINT from its output.
-	
-	# Pick a SERVER_UID for the server.
-
-Client:
-
-	# create a file "authlist" that contains "$SERVER_UID|$SERVER_FINGERPRINT"
-
-	uftpd -E -d -D/tmp/xx -k ~/client_key -U $CLIENT_UID -S '@authlist'
-
-Server:
-
-	# create file "authlist" that contains "$CLIENT_UID|$CLIENT_FINGERPRINT"
-	# lines for each allowed client
-
-	uftp -c -Y aes256-cbc -h sha1 -k ~/server_key -U $SERVER_UID -H '@authlist' file_to_send
-
-----
-
-Notice that the client and server UID and key generation steps above 
-are the same. So, a command like `git annex multicast --gen-address`
-could be run on both the server and clients, and could store
-the addresses in the git-annex branch. 
-The uftp authlist file would be derived from all known such addresses.
-
-(Unlike `p2p --gen-address`, where the address allows connecting with
-and authentication with a remote over TOR, these multicast addresses
-are safe to make public.)
-
-The process of setting up a multicast classroom would then be:
-
-1. Teacher runs `git annex multicast --gen-address; git annex sync`
-2. Students each run `git annex multicast --gen-address; git annex sync`
-3. Teacher runs `git annex sync` once all the students have generated addresses.  
-   (Now the students all have received the teacher's address, and the teacher
-   has received all the student's addresses.)
-4. Students each run `git annex multicast-receive`, which listens for 
-   files going by and stores them.
-5. Once the students are listening (*ahem*), teacher runs
-   `git annex multicast-send [file]` to distribute files.
-"""]]
diff --git a/doc/todo/need_to_remove_remoteGitConfig_for_checkuuid_support.mdwn b/doc/todo/need_to_remove_remoteGitConfig_for_checkuuid_support.mdwn
deleted file mode 100644
index 215c27cb81..0000000000
--- a/doc/todo/need_to_remove_remoteGitConfig_for_checkuuid_support.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-annex-checkuuid=false prevents the git config of a remote from being read.
-So, the remoteGitConfig will be an empty config when that's set.
-
-I've mostly removed uses of remoteGitConfig, but there are two in
-Remote.Git, which are needed for annexDifferences.
-So, `annex.tune.*` config the remote won't be honored when
-annex-checkuuid=false.
-
-The best thing would be to remove remoteGitConfig, to avoid such problems
-in the future. --[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/only_allow_one_git_queue_to_be_flushed_at_a_time.mdwn b/doc/todo/only_allow_one_git_queue_to_be_flushed_at_a_time.mdwn
deleted file mode 100644
index bbff2ee7fe..0000000000
--- a/doc/todo/only_allow_one_git_queue_to_be_flushed_at_a_time.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-A git queue is used when doing things that update .git/index.
-If two git-annex processes are both building up a git queue and happen
-to flush at the same time, one will fail due to git's locking of the index
-file.
-
-This doesn't affect multiple threads with --jobs; while threads have
-individual git queues, inter-thread locking allows only one to flush
-at a time. That locking is handled in `Annex.Queue.flush'` using a
-semaphore.
-
-Seems that it would be better to use a lock file. --[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/optimize_by_converting_String_to_ByteString.mdwn b/doc/todo/optimize_by_converting_String_to_ByteString.mdwn
deleted file mode 100644
index 830f18d549..0000000000
--- a/doc/todo/optimize_by_converting_String_to_ByteString.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-git-annex uses FilePath (String) extensively. That's a slow data type.
-Converting to ByteString, and RawFilePath, should speed it up
-significantly, according to [[/profiling]].
-
-I've made a test branch, `bs`, to see what kind of performance improvement
-to expect. 
-
-Benchmarking `git-annex find`, speedups range from 28-66%. The files fly by
-much more snappily. Other commands likely also speed up, but do more work
-than find so the improvement is not as large.
-
-The `bs` branch is in a mergeable state now. [[done]]
-
-Stuff not entirely finished:
-
-* Profile various commands and look for hot spots involving conversion
-  between RawFilePath and FilePath.
diff --git a/doc/todo/optimize_by_converting_String_to_ByteString/comment_1_403601fa8ad6946eca8f598bdc31f2d7._comment b/doc/todo/optimize_by_converting_String_to_ByteString/comment_1_403601fa8ad6946eca8f598bdc31f2d7._comment
deleted file mode 100644
index 0d24a70d0c..0000000000
--- a/doc/todo/optimize_by_converting_String_to_ByteString/comment_1_403601fa8ad6946eca8f598bdc31f2d7._comment
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""profiling"""
- date="2019-11-26T20:05:28Z"
- content="""
-Profiling the early version of the `bs` branch. 
-
-		Tue Nov 26 16:05 2019 Time and Allocation Profiling Report  (Final)
-	
-		   git-annex +RTS -p -RTS find
-	
-		total time  =        2.75 secs   (2749 ticks @ 1000 us, 1 processor)
-		total alloc = 1,642,607,120 bytes  (excludes profiling overheads)
-	
-	COST CENTRE                      MODULE                         SRC                                                 %time %alloc
-	
-	inAnnex'.\                       Annex.Content                  Annex/Content.hs:(103,61)-(118,31)                   31.2   46.8
-	keyFile'                         Annex.Locations                Annex/Locations.hs:(567,1)-(577,30)                   5.3    6.2
-	encodeW8                         Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:(189,1)-(191,70)        3.3    4.2
-	>>=.\                            Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:(146,9)-(147,44)    2.9    0.8
-	>>=.\.succ'                      Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:146:13-76           2.6    0.3
-	keyFile'.esc                     Annex.Locations                Annex/Locations.hs:(573,9)-(577,30)                   2.5    5.5
-	parseLinkTarget                  Annex.Link                     Annex/Link.hs:(254,1)-(262,25)                        2.4    4.4
-	getAnnexLinkTarget'.probesymlink Annex.Link                     Annex/Link.hs:78:9-46                                 2.4    2.8
-	w82s                             Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:217:1-15                2.3    6.0
-	keyPath                          Annex.Locations                Annex/Locations.hs:(606,1)-(608,23)                   1.9    4.0
-	parseKeyVariety                  Types.Key                      Types/Key.hs:(323,1)-(371,42)                         1.8    0.0
-	getState                         Annex                          Annex.hs:(251,1)-(254,27)                             1.7    0.4
-	fileKey'.go                      Annex.Locations                Annex/Locations.hs:588:9-55                           1.4    0.8
-	fileKey'                         Annex.Locations                Annex/Locations.hs:(586,1)-(596,41)                   1.4    1.7
-	hashUpdates.\.\.\                Crypto.Hash                    Crypto/Hash.hs:85:48-99                               1.3    0.0
-	parseLinkTargetOrPointer         Annex.Link                     Annex/Link.hs:(239,1)-(243,25)                        1.2    0.1
-	withPtr                          Basement.Block.Base            Basement/Block/Base.hs:(395,1)-(404,31)               1.2    0.6
-	primitive                        Basement.Monad                 Basement/Monad.hs:72:5-18                             1.0    0.1
-	decodeBS'                        Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:151:1-31                1.0    2.8
-	mkKeySerialization               Types.Key                      Types/Key.hs:(115,1)-(117,22)                         0.7    1.1
-	w82c                             Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:211:1-28                0.6    1.1
-
-Comparing with [[/profiling]] results, the alloc is down significantly.
-And the main IO actions are getting a larger share of the runtime.
-
-There is still significantly conversion going on, encodeW8 and w82s and
-decodeBS' and w82c. Likely another 5% or so speedup if that's eliminated.
-"""]]
diff --git a/doc/todo/optimize_by_converting_String_to_ByteString/comment_2_9c51e1986aeb16b3138b6824be9f5a58._comment b/doc/todo/optimize_by_converting_String_to_ByteString/comment_2_9c51e1986aeb16b3138b6824be9f5a58._comment
deleted file mode 100644
index d3f545d556..0000000000
--- a/doc/todo/optimize_by_converting_String_to_ByteString/comment_2_9c51e1986aeb16b3138b6824be9f5a58._comment
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="representing paths"
- date="2019-11-27T15:08:40Z"
- content="""
-Thanks for working on this Joey.
-
-I don't know Haskell or git-annex architecture, so my thoughts might make no sense, but I'll post just in case.
-
-\"There are likely quite a few places where a value is converted back and forth several times\" -- as a quick/temp fix, could memoization speed this up? Or memoizing the results of some system calls?
-
-The many filenames flying around often share long prefixes.  Could that be used to speed things up?  E.g. if they could be represented as pointers into some compact storage, maybe cache performance would improve.
-
-\"git annex find... files fly by much more snappily\" -- does this mean `git-annex-find` is testing each file individually, as opposed to constructing a SQL query to an indexed db?  Maybe, simpler `git-annex-find` queries that are fully mappable to SQL queries could be special-cased?
-
-Sorry for naive comments, I'll eventually read up on Haskell and make more sense...
-
-"""]]
diff --git a/doc/todo/optimize_by_converting_String_to_ByteString/comment_3_5cad0557a1409703f8c71078f0785309._comment b/doc/todo/optimize_by_converting_String_to_ByteString/comment_3_5cad0557a1409703f8c71078f0785309._comment
deleted file mode 100644
index c888f617c0..0000000000
--- a/doc/todo/optimize_by_converting_String_to_ByteString/comment_3_5cad0557a1409703f8c71078f0785309._comment
+++ /dev/null
@@ -1,40 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2019-12-11T18:16:13Z"
- content="""
-Updated profiling. git-annex find is now ByteString end-to-end!
-Note the massive reduction in alloc, and improved runtime.
-
-	        Wed Dec 11 14:41 2019 Time and Allocation Profiling Report  (Final)
-	
-	           git-annex +RTS -p -RTS find
-	
-	        total time  =        1.51 secs   (1515 ticks @ 1000 us, 1 processor)
-	        total alloc = 608,475,328 bytes  (excludes profiling overheads)
-	
-	COST CENTRE                      MODULE                           SRC                                                    %time %alloc
-	
-	keyFile'                         Annex.Locations                  Annex/Locations.hs:(590,1)-(600,30)                      8.2   16.6
-	>>=.\.succ'                      Data.Attoparsec.Internal.Types   Data/Attoparsec/Internal/Types.hs:146:13-76              4.7    0.7
-	getAnnexLinkTarget'.probesymlink Annex.Link                       Annex/Link.hs:79:9-46                                    4.2    7.6
-	>>=.\                            Data.Attoparsec.Internal.Types   Data/Attoparsec/Internal/Types.hs:(146,9)-(147,44)       3.9    2.3
-	parseLinkTarget                  Annex.Link                       Annex/Link.hs:(255,1)-(263,25)                           3.9   11.8
-	doesPathExist                    Utility.RawFilePath              Utility/RawFilePath.hs:30:1-25                           3.4    0.6
-	keyFile'.esc                     Annex.Locations                  Annex/Locations.hs:(596,9)-(600,30)                      3.2   14.7
-	fileKey'                         Annex.Locations                  Annex/Locations.hs:(609,1)-(619,41)                      3.0    4.7
-	parseLinkTargetOrPointer         Annex.Link                       Annex/Link.hs:(240,1)-(244,25)                           2.8    0.2
-	hashUpdates.\.\.\                Crypto.Hash                      Crypto/Hash.hs:85:48-99                                  2.5    0.1
-	combineAlways                    System.FilePath.Posix.ByteString System/FilePath/Posix/../Internal.hs:(698,1)-(704,67)    2.0    3.3
-	getState                         Annex                            Annex.hs:(251,1)-(254,27)                                2.0    1.1
-	withPtr.makeTrampoline           Basement.Block.Base              Basement/Block/Base.hs:(401,5)-(404,31)                  1.9    1.7
-	withMutablePtrHint               Basement.Block.Base              Basement/Block/Base.hs:(468,1)-(482,50)                  1.8    1.2
-	parseKeyVariety                  Types.Key                        Types/Key.hs:(323,1)-(371,42)                            1.8    0.0
-	fileKey'.go                      Annex.Locations                  Annex/Locations.hs:611:9-55                              1.7    2.2
-	isLinkToAnnex                    Annex.Link                       Annex/Link.hs:(299,1)-(305,47)                           1.7    1.0
-	hashDirMixed                     Annex.DirHashes                  Annex/DirHashes.hs:(82,1)-(90,27)                        1.7    1.3
-	primitive                        Basement.Monad                   Basement/Monad.hs:72:5-18                                1.6    0.1
-	withPtr                          Basement.Block.Base              Basement/Block/Base.hs:(395,1)-(404,31)                  1.5    1.6
-	mkKeySerialization               Types.Key                        Types/Key.hs:(115,1)-(117,22)                            1.1    2.8
-	decimal.step                     Data.Attoparsec.ByteString.Char8 Data/Attoparsec/ByteString/Char8.hs:448:9-49             0.8    1.2
-"""]]
diff --git a/doc/todo/option_in_git-annex-export_to_include_git_files.mdwn b/doc/todo/option_in_git-annex-export_to_include_git_files.mdwn
deleted file mode 100644
index 6e9dfb713a..0000000000
--- a/doc/todo/option_in_git-annex-export_to_include_git_files.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-[[git-annex-export]] currently only copies git-annexed files to the target remote, omitting files under normal git control.  So for the target to fully reflect the exported treeish, all files in the treeish must be git-annexed.  It would help if there was an option to export git-controlled files along with the git-annexed ones.  This is useful e.g. if you have a version-controlled website, and want to version the basic html skeleton with normal git, while versioning heavy data files with git-annex.
-
-> [[done]] notabug --[[Joey]]
diff --git a/doc/todo/option_in_git-annex-export_to_include_git_files/comment_1_91408bd6ed584cfd3ee17d126c9b698f._comment b/doc/todo/option_in_git-annex-export_to_include_git_files/comment_1_91408bd6ed584cfd3ee17d126c9b698f._comment
deleted file mode 100644
index 412c4075b1..0000000000
--- a/doc/todo/option_in_git-annex-export_to_include_git_files/comment_1_91408bd6ed584cfd3ee17d126c9b698f._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-08-26T16:17:10Z"
- content="""
-No, git-annex export *does* export regular git files.
-
-This is easy to verify, so I'm puzzled why you'd say it doesn't work.
-"""]]
diff --git a/doc/todo/option_in_git-annex-export_to_include_git_files/comment_2_0c970babf9bb88278b502fe10a3d5080._comment b/doc/todo/option_in_git-annex-export_to_include_git_files/comment_2_0c970babf9bb88278b502fe10a3d5080._comment
deleted file mode 100644
index f68eddcbe4..0000000000
--- a/doc/todo/option_in_git-annex-export_to_include_git_files/comment_2_0c970babf9bb88278b502fe10a3d5080._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 2"
- date="2019-08-26T20:58:13Z"
- content="""
-Oh, sorry -- I remembered reading on some doc page that export remotes are like git remotes except they do not contain regular git files, or something to that effect; I must have misunderstood.
-"""]]
diff --git a/doc/todo/per-remote_metadata_needs_to_be_cleaned_in_dropdead.mdwn b/doc/todo/per-remote_metadata_needs_to_be_cleaned_in_dropdead.mdwn
deleted file mode 100644
index 394f2bafd7..0000000000
--- a/doc/todo/per-remote_metadata_needs_to_be_cleaned_in_dropdead.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-The newly added per-remote metadata log files need to be scrubbed clean of
-dead remotes during a transition. --[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/prevent_unwanted_init.mdwn b/doc/todo/prevent_unwanted_init.mdwn
deleted file mode 100644
index b452a4735d..0000000000
--- a/doc/todo/prevent_unwanted_init.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-My $HOME is a git repo, but I don't want to use git-annex in that repo,
-only in sub-repos. If I'm in ~/tmp/foo/ and forgot to git init, git annex
-init initializes my $HOME repo, and I have to go clean it up which is
-annoying. --[[Joey]]
-
-This could be a git configuration setting, or it could be something
-checked into the repo. Either might make sense depending on the scope
-in which one wants to prevent the accidental init.
-
-> [[done]] using .noannex file. --[[Joey]]
diff --git a/doc/todo/prevent_unwanted_init/comment_1_d3f2f6b7b56a57c70614114f88baaec6._comment b/doc/todo/prevent_unwanted_init/comment_1_d3f2f6b7b56a57c70614114f88baaec6._comment
deleted file mode 100644
index 95b0d98a18..0000000000
--- a/doc/todo/prevent_unwanted_init/comment_1_d3f2f6b7b56a57c70614114f88baaec6._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 1"
- date="2017-12-11T19:41:35Z"
- content="""
-+1 for this feature.  For our usecase I would vote for \"something checked into the repo\", e.g. a file `.noannex`, optionally containing a message to be displayed whenever `annex init` detects its presence and refuses to proceed forward.  Message could then provide instructions on what repository authors advise to do (e.g. establish submodules with git-annex'ed repositories).
-"""]]
diff --git a/doc/todo/prevent_unwanted_init/comment_2_019ab8f24611f668ab57cd771564d6de._comment b/doc/todo/prevent_unwanted_init/comment_2_019ab8f24611f668ab57cd771564d6de._comment
deleted file mode 100644
index bc97f1400e..0000000000
--- a/doc/todo/prevent_unwanted_init/comment_2_019ab8f24611f668ab57cd771564d6de._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-12-13T16:41:26Z"
- content="""
-Displaying the file content is a useful idea.
-(There is some possible security exposure with eg escape codes,
-but I think generally we accept those risks when using git repos
-and running "ls" or "cat" etc.)
-"""]]
diff --git a/doc/todo/prevent_unwanted_init/comment_3_08bdae4e0c07b7833089b8b40472c3b0._comment b/doc/todo/prevent_unwanted_init/comment_3_08bdae4e0c07b7833089b8b40472c3b0._comment
deleted file mode 100644
index 7e105341f5..0000000000
--- a/doc/todo/prevent_unwanted_init/comment_3_08bdae4e0c07b7833089b8b40472c3b0._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2017-12-13T16:52:22Z"
- content="""
-Of course, `git annex uninit` should make it easy to undo an accidental
-init if you know you don't want to use git-annex in the repo.
-
-So, this idea must be more about repos whose users don't know there's a
-policy reason not to use git-annex in them.
-"""]]
diff --git a/doc/todo/prevent_unwanted_init/comment_4_e73327b773db8ba8720af44ea46ffa2f._comment b/doc/todo/prevent_unwanted_init/comment_4_e73327b773db8ba8720af44ea46ffa2f._comment
deleted file mode 100644
index 919f827b47..0000000000
--- a/doc/todo/prevent_unwanted_init/comment_4_e73327b773db8ba8720af44ea46ffa2f._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2017-12-13T17:44:18Z"
- content="""
-If git had a general-purpose config file checked into the repo, I'd use
-that. The closest there is is the .gitattributes file, but that's very
-unsuited for this purpose. It is per-file, so a hack like "*" would be
-needed to refer to the whole repo. Worse, it doesn't allow setting values
-containing spaces, which prevents putting a message to the user in there
-in any reasonable format.
-"""]]
diff --git a/doc/todo/prevent_unwanted_init/comment_5_99af015fca81035af490919632fdcb5f._comment b/doc/todo/prevent_unwanted_init/comment_5_99af015fca81035af490919632fdcb5f._comment
deleted file mode 100644
index 0d88351cb4..0000000000
--- a/doc/todo/prevent_unwanted_init/comment_5_99af015fca81035af490919632fdcb5f._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 5"
- date="2017-12-13T18:12:05Z"
- content="""
-oh, indeed -- forgot about .gitattributes and indeed sad that spaces seems to be nohow allowed.  But could be as obscure as requiring _ instead of a space to encode the message:
-
-[[!format sh \"\"\"
-$> builtin cd /tmp/; rm -rf /tmp/testds3; datalad create --no-annex /tmp/testds3; cd /tmp/testds3; echo 123 > 123; echo '* annex.noannex=Because_I_said_so/and\"meant:it' > .gitattributes 123; datalad add -m atrr .gitattributes 123; git check-attr --all 123  
-[INFO   ] Creating a new git repo at /tmp/testds3 
-create(ok): /tmp/testds3 (dataset)
-add(ok): /tmp/testds3/.gitattributes (file)
-add(ok): /tmp/testds3/123 (file)
-save(ok): /tmp/testds3 (dataset)
-action summary:
-  add (ok: 2)
-  save (ok: 1)
-123: annex.noannex: Because_I_said_so/and\"meant:it
-123: 123: set
-\"\"\"]]
-"""]]
diff --git a/doc/todo/redundancy_stats_in_status.mdwn b/doc/todo/redundancy_stats_in_status.mdwn
deleted file mode 100644
index 24b6d63dff..0000000000
--- a/doc/todo/redundancy_stats_in_status.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-Currently, `git annex status` only shows the size of 1 copy of each file.
-If numcopies is being used for redundancy, much more disk can actually be
-in use than status shows.
-
-One idea:
-
-	known annex size: 2 terabytes (plus 4 terabytes of redundant copies)
-
-But, to get that number, it would have to walk every location log, 
-counting how many copies currently exist of each file. That would make
-status a lot slower than it is.
-
-One option is to just put it at the end of the status:
-
-	redundancy: 300% (4 terabytes of copies)
-
-And ctrl-c if it's taking too long.
-
-Hmm, fsck looks at that same info. Maybe it could cache the redundancy
-level it discovers? Since fsck can be run incrementally, it would be tricky
-to get an overall number. And the number would tend to be stale, but
-then again it might also be nice if status shows how long ago the last fsck
-was.
-
-> `git annex info .` now includes this, which is basically the same
-> idea:
-
-	combined size of repositories containing these files: 711.4 gigabytes
-
-> I think that's close enough, it doesn't calculate a percentage, but
-> it tells the total size of the directory earlier so the same information
-> is there. [[done]] --[[Joey]]
diff --git a/doc/todo/redundancy_stats_in_status/comment_1_9f1c10f8cea4fa60a99cbcc8306dd5de._comment b/doc/todo/redundancy_stats_in_status/comment_1_9f1c10f8cea4fa60a99cbcc8306dd5de._comment
deleted file mode 100644
index 801c1da039..0000000000
--- a/doc/todo/redundancy_stats_in_status/comment_1_9f1c10f8cea4fa60a99cbcc8306dd5de._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
- nickname="Richard"
- subject="comment 1"
- date="2012-10-30T08:09:13Z"
- content="""
-I like the idea of using fsck as a pre-run for status.
-
-Basically, it's the same as `updatedb` and `locate`; locate will warn the user if it considers its cache to be too old, as well.
-"""]]
diff --git a/doc/todo/redundancy_stats_in_status/comment_2_686ced0684d10511caf07953c64cd5b6._comment b/doc/todo/redundancy_stats_in_status/comment_2_686ced0684d10511caf07953c64cd5b6._comment
deleted file mode 100644
index a4711b2a3a..0000000000
--- a/doc/todo/redundancy_stats_in_status/comment_2_686ced0684d10511caf07953c64cd5b6._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.152.108.220"
- subject="comment 2"
- date="2013-09-25T18:03:55Z"
- content="""
-`git annex status .` or otherwise running it with a directory has recently started walking all the location logs for all files in the directory in order to display variance from configured numcopies. It would be easy to add a redundancy counter to that.
-
-It would slow down the global status when not passed a directory to add redundancy info there. Maybe local is enough?
-"""]]
diff --git a/doc/todo/renameremote.mdwn b/doc/todo/renameremote.mdwn
deleted file mode 100644
index 360043d6ba..0000000000
--- a/doc/todo/renameremote.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-Sometimes a name has been used for a special remote, and you want to change
-the name. A common reason is that the special remote has become dead, and
-you want to reuse the name for a new special remote. 
-
-Initremote prevents reusing a name when the old one exists, even if the old
-one is dead. And that makes sense in general, because a dead remote can
-come back sometimes, and that would leave the repo with two special remotes
-with the same name, and so enableremote would need to be run with a uuid
-instead of a name to specify which one to enable, which is not a desirable
-state of affairs.
-
-So, add `git annex renameremote oldname newname`. Updates the remote.log
-with the new name.
-
-This could also do a `git
-remote rename`, or equivilant. (`git remote rename` gets confused by special
-remotes not having a fetch url and fails; this can be worked around by
-manually renaming the stanza in git config.) But.. Perhaps it's better to
-keep it simple and not do that. There's no necessarily a correspondance
-between the name of a remote in the local repo and the name of a
-special remote in the remote.log.
-
-[[done]] --[[Joey]]
diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings.mdwn b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings.mdwn
deleted file mode 100644
index 94c0c1f147..0000000000
--- a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-Could there be separate `annex.git-add.largefiles` and `annex.git-annex-add.largefiles` settings, applying to files added via `git add` and `git annex add`, respectively?  If not given, their value defaults to the value of `annex.largefiles`.
-
-Reason: to prevent `git add` from inadvertently adding annexed files in unlocked form, I set `* annex.largefiles=nothing` at repo root; but then, `git annex add` won't annex anything either, unless specifically asked.   I want to use `git add` to add files to git only (since it can't add them to git-annex in locked form), and to use `git annex add` to add files to either git or annex based on `annex.git-annex-add.largefiles` setting.
-
-Related: [[forum/lets_discuss_git_add_behavior]]
-
-> [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_1_affdfd11cee2c6bfe5a2ed434708ee64._comment b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_1_affdfd11cee2c6bfe5a2ed434708ee64._comment
deleted file mode 100644
index 12983b2d88..0000000000
--- a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_1_affdfd11cee2c6bfe5a2ed434708ee64._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-10-22T17:23:54Z"
- content="""
-I am not convinced that making this configurable does anything other than
-give users a new way to shoot themselves in their foot, and adding another
-config setting I have to tease out of them in the ensuring bug report.
-
-My comment on [[forum/lets_discuss_git_add_behavior]] describes scenarios
-where such a git add behavior would result in accidentially adding large
-files to the git object store.
-
-The only way that would seem to avoid that is a config setting that
-disables all support for populating annexed unlocked files, as well as
-making git-add not smudge them, so the repository is basically treated
-just like a v5 repository.
-"""]]
diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_2_876d01d37dbad664b064428da65bd910._comment b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_2_876d01d37dbad664b064428da65bd910._comment
deleted file mode 100644
index 560fcb98a7..0000000000
--- a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_2_876d01d37dbad664b064428da65bd910._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-10-22T18:29:44Z"
- content="""
-[[todo/inode_based_clean_filter_for_less_surprising_git_add]]
-seems to open the door to adding such a config as this.
-
-Although, if that were implemented, I suspect that demand for such a config
-might dry up..
-"""]]
diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_6f720c44e6c5ad8b9df6c2003b1b1c40._comment b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_6f720c44e6c5ad8b9df6c2003b1b1c40._comment
deleted file mode 100644
index a9a4ca6099..0000000000
--- a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_6f720c44e6c5ad8b9df6c2003b1b1c40._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2019-10-23T19:25:21Z"
- content="""
-I suspect that anyone who would have wanted this will instead be happy
-with setting the new annex.gitaddtoannex to false.
-
-If someone does have a good reason to want git add and git annex add to
-have different opinions about what constitutes a large file, please reopen
-the todo with a justification.
-"""]]
diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment
deleted file mode 100644
index 1ce6c180bc..0000000000
--- a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_3_c64efa42f8dd8c319bef86c038f8518c._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="preventing `git add` from annexing new files"
- date="2019-10-23T17:05:41Z"
- content="""
-\"if that were implemented, I suspect that demand for such a config might dry up\" -- not quite.  I'd still want to use `git add` for adding to git and `git annex add` for adding to the annex.  It's [[simple|forum/lets_discuss_git_add_behavior/#comment-065d2ab55fe0683a3c186df9211fd522]], so less error-prone; it's compatible with v5 and has worked well there; it lets me avoid accidentally annexing files as unlocked, where one can't see they're annexed by looking at the dir.  `git add` re-annexing already-annexed files doesn't involve these concerns: the file had to have been deliberately annexed *and* deliberately unlocked at some point prior, before `git add` will (re-)add it as annexed and unlocked.
-
-So, I may want to configure `annex.largefiles=anything` and *still* not have `git add` add new files to the annex.
-
-If you don't want to add a new config setting, maybe, extend the `annex.largefiles` [[syntax|tips/largefiles]] with something like `command=git-add`?
-"""]]
diff --git a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment b/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment
deleted file mode 100644
index d7e1e007f2..0000000000
--- a/doc/todo/separate_annex.largefiles.git-add_and_annex.largefiles.git-annex-add_settings/comment_4_aa12a81ca2015945f548d029b720ff33._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="configuring git add behavior"
- date="2019-10-23T17:57:03Z"
- content="""
-Or, could add a variable `annex.git-add-new-largefiles-action`, which determines what `git add` does with files that match `annex.largefiles` but were not already annexed.  The possible values would be
-
- * `git` (default): add to git
- * `git-warn`: add to git but print a warning
- * `error`: exit with an error code
- * `annex`: add to the annex
- * `annex-warn`: add to the annex but print a warning
- * `annex-autolock`: add to the annex but mark them to be [[auto-locked|todo/auto-lock_files_after_one_edit]] when committed.
-"""]]
diff --git a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn
deleted file mode 100644
index 37da39a8d2..0000000000
--- a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn
+++ /dev/null
@@ -1,145 +0,0 @@
-Some git-annex backends allow embedding enough data in the names of keys
-that it could be used for a SHA1 collision attack. So, a signed git commit
-could point to a tree with such a key in it, and the blob for the key could
-have two versions with the same SHA1.
-
-> All issues below are [[done]] --[[Joey]]
-
-Users who want to use git-annex with signed commits to mitigate git's own
-SHA1 insecurities would like at least a way to disable the insecure
-git-annex backends:
-
-* WORM can contain fairly arbitrary data in a key name
-* URL too (also, of course, URLs download arbitrary data from the web,
-  so a signed git commit pointing at URL keys doesn't have any security
-  even w/o SHA1 collisions)
-* SHA1 and MD5 backends are insecure because there can be colliding
-  versions of the data they point to.
-
-There could be a config setting, which would prevent git-annex from using
-keys with such insecure backends. A user who checks git commit signatures
-could enable the config setting when they initially clone their repository.
-This should prevent any file contents using insecure backends from being
-downloaded into the repository. (Even git-annex-shell recvkey would
-refuse data using such a key, since it would fail parsing the key.)
-The user would thus know that any file contents in their repository match
-the files in signed git commits.
-
-Enabling the config setting in a repository that already contains
-file contents would be a mistake, because it might contain insecure keys.
-And since git-annex would skip over such files, `git annex fsck` cannot
-warn about such a mistake.
-
-Perhaps, then, the config setting should be turned on by `git annex init`?
-Or, we can document this gotcha.
-
-> I've done some groundwork for this, but making git-annex not accept
-> insecure keys into the repo at all requires changing file2key,
-> which is a pure function that's used in eg, instances for serialization.
-> 
-> So, how to make it vary depending on git config? Can't. Alternative
-> would be to add lots of checks everywhere a key is read from disk
-> or network, which feels like it would be a hard security boundary to
-> manage.
-> 
-> It doesn't really matter if content under an insecure key is in the
-> repo, as long as there's not a signed commit referencing such a key.
-> So, we could say, this is up to the user constucting a signed commit, to not
-> put such keys in the commit.
-> 
-> Or, we could use the pre-commit hook, and when 
-> the config setting disallows insecure keys, make it reject commits
-> that contain them. But, if a past commit added a file using an insecure
-> key, and the current commit does not touch it, should it be rejected?
-> Rejecting it would then require a somewhat expensive look at the tree
-> being committed.
-> 
-> The user might be merging a branch from someone else; there seems no
-> git hook that can sanity check a fast-forward merge.
-> 
-> Perhaps leave it up to the person making signed commits to get it 
-> right, and make git annex fsck warn about such keys? That seems
-> reasonable. --[[Joey]]
-
-> > Rather than preventing SHA1/URL/WORM Keys, could put checks in
-> > Annex.Content.moveAnnex to prevent SHA1/URL/WORM objects reaching the
-> > repository. That would make moveAnnex a security boundary, which is is
-> > not currently. Would need to audid to check if anything else populates
-> > .git/annex/objects.
-> >
-> > Annex.Transfer.runTransfer could also check for disallowed objects,
-> > not as a security boundary, but to prevent accidental expensive
-> > transfers that would fail at the moveAnnex stage.
-
-> > As to how to enable this, it may make sense to use git-annex-config
-> > but only read the value from the git-annex branch when initializing the
-> > repository, and cache it in git-config.
-> > 
-> > This way, a repository can be created and configured not to allow
-> > SHA1/URL/WORM, and all clones will inherit this configuration. 
-> >
-> > Users can also set it in git-config on a per repository basis.
-> > 
-> > If the git-annex-config setting is changed, existing clone's won't
-> > change their behavior, although new ones will.  That's a mixed
-> > blessing; it makes it harder to switch an existing repo to disallowing
-> > SHA1/URL/WORM, but an accidental/malicious re-enabling won't affect
-> > clones made while it was disabled. 
-> > > This is done now.
-> > 
-> > Could a repository be configured to either always disallow
-> > SHA1/URL/WORM, or always allow them, and then not let that be changed?
-> > Maybe -- Look through all the history of the git-annex branch from the
-> > earliest commit forward. The first value stored in 
-> > git-annex/disableinsecurehashes (eg 0 or 1) is the value to use;
-> > any later changes are ignored. 
-> > That would be a little slow, but only needs to be done at init time.
-> > It might be possible to fool this though. Create a new empty branch,
-> > with an old date, make a commit enabling insecure hashes, and
-> > merge it into git-annex branch HEAD. It now looks as if insecure hashes
-> > were disabled earliest.
-
-> > > Well, annex.securehashesonly is implemented now. It currently needs to be
-> > > set in each clone that cares about it. --[[Joey]]
-
-----
-
-A few other potential problems:
-
-* A symlink target like .git/annex/objects/XX/YY/SHA256--foo
-  might be able to be manipulated to add collision data in the path.
-  For example, .git/annex/objects/collisiondata/../XX/YY/SHA256--foo
-
-  I think this is not a valid attack, because at least on linux,
-  such a symlink won't be followed, unless the
-  .git/annex/objects/collisiondata directory exists.
-
-* `*E` backends could embed sha1 collision data in a long filename
-  extension in a key.
-
-  The recent SHA1 common-prefix attack could be used to exploit this;
-  the result would be two keys that have the same SHA1.
-
-  This can be fixed by limiting the length
-  of an extension allowed in such a key to the longest such extension
-  git-annex has ever supported (probably < 20 bytes or so), which would
-  be less than the size of the data needed for current SHA1 collision
-  attacks. Now done; git-annex refuses to use keys with super
-  long extensions.
-
-* It might be possible to embed colliding data in a specially constructed
-  key name with an extra field in it, eg "SHA256-cXXXXXXXXXXXXXXX-...".
-  Need to review the code and see if such extra fields are allowed.  
-
-  Update: All fields are numeric, but could contain arbitrary data
-  after the number. Could have been used in a common-prefix attack.
-  This has been fixed; git-annex refuses to parse
-  such fields, so it won't work with files that try to exploit this.
-
-* A symlink target like .git/annex/objects/XX/YY/SHA256--foo
-  might be able to be manipulated to add collision data in the path.
-  For example, .git/annex/objects/collisiondata/../XX/YY/SHA256--foo
-
-  I think this is not a valid attack, because at least on linux,
-  such a symlink won't be followed, unless the
-  .git/annex/objects/collisiondata directory exists.
diff --git a/doc/todo/simpler_setup_for_remote_worktree_update_on_push.mdwn b/doc/todo/simpler_setup_for_remote_worktree_update_on_push.mdwn
deleted file mode 100644
index d3ce8cad05..0000000000
--- a/doc/todo/simpler_setup_for_remote_worktree_update_on_push.mdwn
+++ /dev/null
@@ -1,75 +0,0 @@
-A git post-update hook can run git-annex merge and so make all pushes
-into a repository update its working tree.
-
-But, there are some complications to writing that hook. See
-
-IIRC different versions of git may behave differently.
-
-And, such a hook can't be used on a filesystem that doesn't support
-executables. (Except on Windows which has a workaround to allow
-non-executable hooks.)
-
-Could there be a single command that sets it up? Something like 
-`git annex merge --run-automatically`
-
-That could install the hook, and also set an annex.automerge config.
-
-The config could be checked by git-annex sync (and assistant) when pushing
-to a local remote, and they could perform a merge on the remote. This way,
-it would work for repos on removable drives that don't support execute
-bits. (Ssh remotes on such filesystems would not be handled, but that's a
-rare configuration; the hook would handle ssh remotes on non-crippled
-filesystems, and on Windows.)
-
----
-
-Alternatively, receive.denyCurrentBranch can be set to updateInstead.
-With this configuration, `git annex sync` automatically updates the
-work-tree of the remote already. 
-
-This wouldn't work for direct mode repositories, which are often used
-on removable drives, since git thinks they're bare repos.
-
-Nor will it work for adjusted branches, since the adjusted branch is not
-updated by the push.
-
----
-
-Could the updateInstead configuration be made to work for direct mode and
-adjusted branches? Could install a post-update hook, that runs a git-annex
-command that checks for updateInstead, and emulates its behavior, handling
-direct mode and adjusted branches.
-
-To support direct mode repos on removable drives w/o execute bits,
-could make sync check local remotes and run the equivilant action as the
-hook would run.
-
-To fully emulate updateInstead, the post-update hook 
-should abort if the tree is unclean or if there are merge conflicts.
-But, in a direct mode repo, the only way the user will likely resolve such
-a situation is git-annex sync/merge, so the hook could just run git-annex
-merge instead of trying to fully emulate regular updateInstead behavior.
-Similarly, in an adjusted branch, the push will update master, and git
-annex sync/merge is what the user will likely do. Although they could
-choose to reset changes to the tree.
-
----
-
-Potential least surprise violation:
-
-If a repository is updating when git annex pushes changes to it, 
-the user might also expect that the same git annex sync
-would pull changes from that repository. Even though nothing has been
-run on the repository to commit changes made there.
-
-Particularly when the assistant is being used, this seems an easy confusion 
-to have. In one clone the user sees every file change getting committed
-and synced around, so why would that not happen in the other clone, on the
-removable drive?
-
-Keeping this a command-line setup, and not something the assistant does,
-will avoid that confusion.
-
---[[Joey]]
-
-> all above [[done]] --[[Joey]]
diff --git a/doc/todo/smudge.mdwn b/doc/todo/smudge.mdwn
deleted file mode 100644
index fd4f408a0f..0000000000
--- a/doc/todo/smudge.mdwn
+++ /dev/null
@@ -1,368 +0,0 @@
-git-annex should use smudge/clean filters. v7 mode
-
-[[done]]! Continued in [[v7_path_toward_default]]
-
-### historical notes
-
-2013: Currently, this does not look likely to work. In particular,
-the clean filter needs to consume all stdin from git, which consists of the
-entire content of the file. It cannot optimise by directly accessing
-the file in the repository, because git may be cleaning a different
-version of the file during a merge. 
-
-So every `git status` would need to read the entire content of all
-available files, and checksum them, which is too expensive.
-
-> Update from GitTogether: Peff thinks a new interface could be added to
-> git to handle this sort of case in an efficient way.. just needs someone
-> to do the work. --[[Joey]] 
-
->> Update 2015: git status only calls the clean filter for files
->> that the index says are modified, so this is no longer a problem.
->> --[[Joey]]
-
-### background
-
-The clean filter is run when files are staged for commit. So a user could copy
-any file into the annex, git add it, and git-annex's clean filter causes
-the file's key to be staged, while its value is added to the annex.
-
-The smudge filter is run when files are checked out. Since git annex
-repos have partial content, this would not git annex get the file content.
-Instead, if the content is not currently available, it would need to do
-something like return empty file content. (Sadly, it cannot create a
-symlink, as git still wants to write the file afterwards.)
-
-So the nice current behavior of unavailable files being clearly missing due
-to dangling symlinks, would be lost when using smudge/clean filters.
-(Contact git developers to get an interface to do this?)
-
-Instead, we get the nice behavior of not having to remeber to `git annex
-add` files, and just being able to use `git add` or `git commit -a`,
-and have it use git-annex when .gitattributes says to. Also, annexed
-files can be directly modified without having to `git annex unlock`.
-
-### configuration
-
-In .gitattributes, the user would put something like "* filter=git-annex".
-This way they could control which files are annexed vs added normally.
-
-It would also be good to allow using this without having to specify
-the files in .gitattributes. Just use "* filter=git-annex" there, and then
-let git-annex decide which files to annex and which to pass through the
-smudge and clean filters as-is. The smudge filter can just read a little of
-its input to see if it's a pointer to an annexed file. The clean filter
-could apply annex.largefiles to decide whether to annex a file's content or
-not.
-
-For files not configured this way in .gitattributes, git-annex could
-continue to use its symlink method -- this would preserve backwards
-compatability, and even allow mixing the two methods in a repo as desired.
-(But not switching an existing repo between indirect and direct modes;
-the user decides which mode to use when adding files to the repo.)
-
-### clean
-
-The trick is doing it efficiently. Since git a2b665d, v1.7.4.1,
-something like this works to provide a filename to the clean script:
-
-	git config --global filter.huge.clean huge-clean %f
-
-This could avoid it needing to read all the current file content from stdin
-when doing eg, a git status or git commit. Instead it is passed the
-filename that git is operating on, in the working directory.
-(Update: No, doesn't work; git may be cleaning a different file content
-than is currently on disk, and git requires all stdin be consumed too.)
-
-So, WORM could just look at that file and easily tell if it is one
-it already knows (same mtime and size). If so, it can short-circuit and
-do nothing, file content is already cached.
-
-SHA1 has a harder job. Would not want to re-sha1 the file every time,
-probably. So it'd need a local cache of file stat info, mapped to known
-objects.
-
-But: Even with %f, git actually passes the full file content to the clean
-filter, and if it fails to consume it all, it will crash (may only happen
-if the file is larger than some chunk size; tried with 500 mb file and 
-saw a SIGPIPE.) This means unnecessary works needs to be done, 
-and it slows down *everything*, from `git status` to `git commit`.
-**showstopper** I have sent a patch to the git mailing list to address
-this.  (Update: apparently
-can't be fixed.)
-
-> Update: I tried this again (2015) and it seems that git status and git
-> add avoid re-sending the file content to the clean filter, as long as the
-> file stat has not changed. I'm not sure when git started doing that,
-> but it seems to avoid this problem.
-> --[[Joey]]
-
-### smudge
-
-The smudge script can also be provided a filename with %f, but it
-cannot directly write to the file or git gets unhappy.
-
-> Still the case in 2015. Means an unnecesary read and pipe of the file
-> even if the content is already locally available on disk. --[[Joey]]
-
-### partial checkouts
-
-.. Are very important, otherwise a repo can't scale past the size of the
-smallest client's disk!
-
-It would be nice if the smudge filter could hard link a work
-tree file to the annex object.
-
-But currently, the smudge filter can't modify the work tree file on its own
--- git always modifies the file after getting the output of the smudge
-filter, and will stumble over any modifications that the smudge filter
-makes. And, it's important that the smudge filter never fail as that will
-leave the repo in a bad state.
-
-Seems the best that can be done is for the smudge filter to copy from the
-annex object when the object is present. When it's not present, the smudge
-filter should provide a pointer to its content.
-
-The clean filter should detect when it's operating on that pointer file.
-
-I've a demo implementation of this technique in the scripts below.
-
-### deduplication
-
-.. Is nice; needing 2 copies of every annexed file is annoying.
-
-Unfortunately, when using smudge/clean, `git merge` does not preserve a
-smudged file in the work tree when renaming it. It instead deletes the old
-file and asks the smudge filter to smudge the new filename.
-
-So, copies need to be maintained in .git/annex/objects, though it's ok
-to use hard links to the work tree files. (Although somewhat unsafe
-since modification of the file will lose the old version. annex.thin
-setting can enable this.)
-
-Even if hard links are used, smudge needs to output the content of an
-annexed file, which will result in duplication when merging in renames of
-files.
-
-### design
-
-Goal: Get rid of current direct mode, using smudge/clean filters instead to
-cover the same use cases, more flexibly and robustly.
-
-Use case 1:
-
-A user wants to be able to edit files, and git-add, git commit,
-without needing to worry about using git-annex to unlock files, add files,
-etc.
-
-Use case 2:
-
-Using git-annex on a crippled filesystem that does not support symlinks.
-
-Data:
-
-* An annex pointer file has as its first line the git-annex key
-  that it's standing in for (prefixed with "annex/objects/", similar to
-  an annex symlink target). Subsequent lines of the file might
-  be a message saying that the file's content is not currently available.
-  An annex pointer file is checked into the git repository the same way
-  that an annex symlink is checked in.
-* A file map is  maintained by git-annex, to keep track of the keys
-  that are used by files in the working tree.
-
-Configuration: 
-
-* .gitattributes tells git which files to use git-annex's smudge/clean
-  filters with. Typically, all files except for dotfiles:
-
-	* filter=annex
-	.* !filter
-
-* annex.largefiles tells git-annex which files should in fact be put in 
-  the annex. Other files are passed through the smudge/clean as-is and
-  have their contents stored in git.
-
-* annex.direct is repurposed to configure how git-annex adds files.
-  When set to false, it adds symlinks and when true it adds pointer files.
-
-git-annex clean:
-
-* Run by `git add` (and diff and status, etc), and passed the
-  filename, as well as fed the file content on stdin.
-
-  Look at configuration to decide if this file's content belongs in the
-  annex. If not, output the file content to stdout.
-
-  Generate annex key from filename and content from stdin.
-
-  Hard link (annex.thin) or copy .git/annex/objects to the file,
-  if it doesn't already exist.
-
-  This is done to prevent losing the only copy of a file when eg
-  doing a git checkout of a different branch, or merging a commit that
-  renames or deletes a file. But, with annex.thin no attempt is made to 
-  protect the object from being modified. If a user wants to
-  protect object contents from modification, they should use
-  `git annex add`, not `git add`, or they can `git annex lock` after adding,
-  or not enable annex.thin.
-
-  Update file map.
-
-  Output the pointer file content to stdout.
-
-git-annex smudge:
-
-* Run by eg `git checkout`
-  and passed the filename, as well as fed the pointer file content on stdin.
-
-  Update file map.
-
-  When an object is present in the annex, outputs its content to stdout.
-  Otherwise, outputs the file pointer content.
-
-git annex direct/indirect:
-
-  Previously these commands switched in and out of direct mode.
-  Now they become no-ops.
-
-git annex lock/unlock:
-
-  Makes sense for these to change to switch files between using
-  git-annex symlinks and pointers. So, this provides both a way to
-  transition repositories to using pointers, and a cleaner unlock/lock
-  for repos using symlinks.
-
-  unlock will stage a pointer file, and will link the content of the object
-  from .git/annex/objects to the work tree file.
-  
-  lock will replace the current work tree file with the symlink, and stage it,
-  and lock down the permissions of the annex object.
-
-#### file map
-
-The file map needs to map from `Key -> [File]`. `File -> Key`
-seems useful to have, but in practice is not worthwhile.
-
-Drop and get operations need to know what files in the work tree use a
-given key in order to update the work tree. And, we don't want to
-overwrite a work tree file if it's been modified when dropping or getting.
-
-git-annex commands that look at annex symlinks to get keys to act on will
-need fall back to either consulting the file map, or looking at the staged
-file to see if it's a pointer to a key. So a `File -> Key` map is a possible
-optimisation.
-
-Question: If the smudge/clean filters update the file map incrementally
-based on the pointer files they generate/see, will the result
-always be consistent with the content of the working tree?
-
-This depends on when git calls the smudge/clean filters and on what.
-In particular:
-
-* Does the clean filter always get called when adding a relevant 
-  file to git? Yes.
-* Is the clean filter called at any other time? Yes, for example
-  git diff will clean relevant modified files to generate the diff.
-  So, the clean filter may see file versions that have not yet been staged
-  in git.
-* Is the clean filter ever passed content not in the work tree?
-  I don't think so, but not 100% sure.
-* Is the smudge filter always called when git updates a relevant file
-  in the work tree? Yes.
-* Is the smudge filter called at any other time? Seems unlikely but then
-  there could be situations with a detached work tree or such.
-* Does git call any useful hooks when removing a file from the work tree,
-  or converting it to not be annexed, or for `git mv` of an annexed file?
-  No!
-
-From this analysis, any file map generated by the smudge/clean filters
-is necessary potentially innaccurate. It may list deleted files.
-It may or may not reflect current unstaged changes from the work tree.
-
-
-Follows that any use of the file map needs to verify the info from it,
-and throw out bad cached info (updating the map to match reality). 
-
-When downloading a key, check if the files listed in the file map are
-still pointer files in the work tree, and only replace them with the
-content if so. 
-
-When dropping a key, check if the files listed for it in the file map are
-unmodified in the work tree, and are staged as pointers to the key,
-and only reset them to the pointers if so. Note that this means that
-a modified work tree file that has not yet been staged, but that
-corresponds to a key, won't be reset when the key is dropped.
-This is probably not a big deal; the user will either add the
-file, which will add the key back, or reset the file.
-
-Does the `File -> Key` map have any benefits given this innaccuracy?
-Answer seems to be no; any answer that map gives may be innaccurate and
-needs to be verified by looking at actual repo content, so might as well
-just look at the repo content in the first place..
-
-#### Upgrading
-
-annex.version changes to 7
-
-git config for filter.annex.smudge and filter.annex.clean is set up.
-
-.gitattributes is updated with a stock configuration,
-unless it already mentions "filter=annex".
-
-Upgrading a direct mode repo needs to switch it out of bare mode, and
-needs to run `git annex unlock` on all files (or reach the same result).
-So will need to stage changes to all annexed files.
-
-When a repo has some clones indirect and some direct, the upgraded repo
-will have all files unlocked, necessarily in all clones. This happens
-automatically, because when the direct repos are upgraded that causes the
-files to be unlocked, while the indirect upgrades don't touch the files.
-
-----
-
-### test files
-
-huge-smudge:
-
-
-#!/bin/sh
-read f
-file="$1"
-echo "smudging $f" >&2
-if [ -e ~/$f ]; then
-	cat ~/$f # possibly expensive copy here
-else
-	echo "$f not available"
-fi
-

-
-huge-clean:
-
-
-#!/bin/sh
-file="$1"
-cat >/tmp/file
-# in real life, this should be done more efficiently, not trying to read
-# the whole file content!
-if grep -q 'not available' /tmp/file; then
-	awk '{print $1}' /tmp/file # provide what we would if the content were avail!
-	exit 0
-fi
-echo "cleaning $file" >&2
-# XXX store file content here
-echo $file
-

-
-.gitattributes:
-
-
-*.huge filter=huge
-

-
-in .git/config:
-
-
-[filter "huge"]
-        clean = huge-clean %f
-        smudge = huge-smudge %f
-
diff --git a/doc/todo/smudge/comment_10_19dd6be938d71c7311aecb3081849792._comment b/doc/todo/smudge/comment_10_19dd6be938d71c7311aecb3081849792._comment
deleted file mode 100644
index 634b34e83f..0000000000
--- a/doc/todo/smudge/comment_10_19dd6be938d71c7311aecb3081849792._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 10"""
- date="2016-04-09T17:22:11Z"
- content="""
-Hardlinks now used on windows when annex.thin is enabled.
-"""]]
diff --git a/doc/todo/smudge/comment_11_ace695aa9d6c5d888b91a2eebb19f97b._comment b/doc/todo/smudge/comment_11_ace695aa9d6c5d888b91a2eebb19f97b._comment
deleted file mode 100644
index e67ccdf2d9..0000000000
--- a/doc/todo/smudge/comment_11_ace695aa9d6c5d888b91a2eebb19f97b._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="davicastro"
- avatar="http://cdn.libravatar.org/avatar/4e708663cf4d5b9e8cfea74caf4307fc"
- subject="What are the drawbacks of repo v6?"
- date="2018-03-12T19:00:36Z"
- content="""
-Hi. I read the post http://git-annex.branchable.com/tips/unlocked_files/, and got into this post through the comment to check the limitations of repo v6.
-I read through this post, but I still don't grasp the drawbacks of repo v6.
-I like the idea of mixed mode repositories with locked and unlocked co-existing. And I need repo v6 for that right?
-I also like the annex.largefiles to control what is annex what is normal git files.
-With these two combined feature I can configure my project and let users without too much burden on controlling what is annex, what is not, and what are locked or unlocked.
-I want to use repo v6, but what are the drawbacks on adopting it? Is it in terms of git could be bugged? Or the smudge filters could be bugged?
-Sorry for not being able to grasp this from the current post. I appreciate any help. Thanks.
-"""]]
diff --git a/doc/todo/smudge/comment_12_a4712d510432931062406c4e256f04b1._comment b/doc/todo/smudge/comment_12_a4712d510432931062406c4e256f04b1._comment
deleted file mode 100644
index cfa1be8bca..0000000000
--- a/doc/todo/smudge/comment_12_a4712d510432931062406c4e256f04b1._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""re: Git 2.5 allows smudge filters to not read all of stdin"""
- date="2018-08-09T22:11:00Z"
- content="""
-@torarnv thanks for pointing that out.. I finally got around to verifying
-that, and was able to speed up the smudge filter. Also this avoids the
-problem that git for some reason buffers the whole file content in memory
-when it sends it to the smudge filter, which is a pretty bad memory leak in git
-that no longer affects this.
-"""]]
diff --git a/doc/todo/smudge/comment_1_4ea616bcdbc9e9a6fae9f2e2795c31c9._comment b/doc/todo/smudge/comment_1_4ea616bcdbc9e9a6fae9f2e2795c31c9._comment
deleted file mode 100644
index a4eb3cf235..0000000000
--- a/doc/todo/smudge/comment_1_4ea616bcdbc9e9a6fae9f2e2795c31c9._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://christian.amsuess.com/chrysn"
- nickname="chrysn"
- subject="git-add instead of git-annex-add"
- date="2011-02-26T21:43:21Z"
- content="""
-would, with these modifications in place, there still be a way to *really* git-add a file? (my main repository contains both normal git and git-annex files.)
-"""]]
diff --git a/doc/todo/smudge/comment_2_e04b32caa0d2b4c577cdaf382a3ff7f6._comment b/doc/todo/smudge/comment_2_e04b32caa0d2b4c577cdaf382a3ff7f6._comment
deleted file mode 100644
index 3a223e1c7b..0000000000
--- a/doc/todo/smudge/comment_2_e04b32caa0d2b4c577cdaf382a3ff7f6._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://dieter-be.myopenid.com/"
- nickname="dieter"
- subject="symlinks"
- date="2011-04-03T20:30:21Z"
- content="""
-> (Sadly, it cannot create a symlink, as git still wants to write the file afterwards.
-> So the nice current behavior of unavailable files being clearly missing due to dangling symlinks, would be lost when using smudge/clean filters. (Contact git developers to get an interface to do this?)
-
-Have you checked what the smudge filter sees when the input is a symlink? Because git supports tracking symlinks, so it should also support pushing symlinks through a smudge filter, right?
-Either way: yes, contact the git devs, one can only ask and hope.  And if you can demonstrate the awesomeness of git-annex they might get more 1interested :)
-"""]]
diff --git a/doc/todo/smudge/comment_3_4e7c25fe24a1e71f58a8354fa64f41c2._comment b/doc/todo/smudge/comment_3_4e7c25fe24a1e71f58a8354fa64f41c2._comment
deleted file mode 100644
index cd64b70019..0000000000
--- a/doc/todo/smudge/comment_3_4e7c25fe24a1e71f58a8354fa64f41c2._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawn1QhtPvsRBV7pfaDW_ZTPFv_ZIxSzQ8Rg"
- nickname="Paul Léo"
- subject="comment 3"
- date="2013-11-13T20:41:52Z"
- content="""
-> SHA1 has a harder job. Would not want to re-sha1 the file every time, probably. So it'd need a local cache of file stat info, mapped to known objects.
-
-I think that is not true? If gits wants the file to be cleaned, it thinks that the file was changed. So you would have to SHA1 it anyway if you don't want rely on WORM (which git already does in the first step anyway).
-"""]]
diff --git a/doc/todo/smudge/comment_4_5ff4ad15865a93dc8c066220561936b2._comment b/doc/todo/smudge/comment_4_5ff4ad15865a93dc8c066220561936b2._comment
deleted file mode 100644
index 392df53899..0000000000
--- a/doc/todo/smudge/comment_4_5ff4ad15865a93dc8c066220561936b2._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="tomekwi"
- subject="How about the other way round?"
- date="2015-04-25T09:13:31Z"
- content="""
-If I understand this right, this feature should allow us to say to *git*: “Hey, from now on whenever I `git add` a `*.png` file, add it to *git-annex* instead!”
-
-How about saying to *git-annex*: “Hey, whenever I `git-annex add` a file which is *not* `*.png`, add it to *git* instead! Or at least leave it unadded so that I can decide later.” Is it possible now? If not, would it be reasonable to add such a feature?
-"""]]
diff --git a/doc/todo/smudge/comment_5_80bbc3710f9a18644571c6dd60baf4e5._comment b/doc/todo/smudge/comment_5_80bbc3710f9a18644571c6dd60baf4e5._comment
deleted file mode 100644
index 04904dc7c1..0000000000
--- a/doc/todo/smudge/comment_5_80bbc3710f9a18644571c6dd60baf4e5._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2015-04-29T15:30:50Z"
- content="""
-That feature already exists (annex.largefiles).
-"""]]
diff --git a/doc/todo/smudge/comment_6_86f536515575a6c2ed3a89c80b2c232f._comment b/doc/todo/smudge/comment_6_86f536515575a6c2ed3a89c80b2c232f._comment
deleted file mode 100644
index 6a15157bc8..0000000000
--- a/doc/todo/smudge/comment_6_86f536515575a6c2ed3a89c80b2c232f._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="tomekwi"
- subject="comment 6"
- date="2015-04-29T20:38:51Z"
- content="""
-Thanks! Looks great :)
-"""]]
diff --git a/doc/todo/smudge/comment_7_e428e4a1207d426a53e067fb5211510e._comment b/doc/todo/smudge/comment_7_e428e4a1207d426a53e067fb5211510e._comment
deleted file mode 100644
index f1fca6a9ef..0000000000
--- a/doc/todo/smudge/comment_7_e428e4a1207d426a53e067fb5211510e._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="torarnv@6179ecd599a0e00709a67306f015e46307a66eb6"
- nickname="torarnv"
- subject="Git 2.5 allows smudge filters to not read all of stdin"
- date="2015-07-29T10:35:07Z"
- content="""
-It seems git 2.5 allows smudge filters to not read all of stdin:
-
-https://github.com/git/git/blob/master/Documentation/RelNotes/2.5.0.txt
-
-\"
- * Filter scripts were run with SIGPIPE disabled on the Git side,
-   expecting that they may not read what Git feeds them to filter.
-   We however treated a filter that does not read its input fully
-   before exiting as an error.  We no longer do and ignore EPIPE
-   when writing to feed the filter scripts.
-
-   This changes semantics, but arguably in a good way.  If a filter
-   can produce its output without fully consuming its input using
-   whatever magic, we now let it do so, instead of diagnosing it
-   as a programming error.\"
-"""]]
diff --git a/doc/todo/smudge/comment_8_ab39263b7145094a9eb4a86bb5410421._comment b/doc/todo/smudge/comment_8_ab39263b7145094a9eb4a86bb5410421._comment
deleted file mode 100644
index 7f8882a504..0000000000
--- a/doc/todo/smudge/comment_8_ab39263b7145094a9eb4a86bb5410421._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="ExGen"
- subject="Harlinks"
- date="2016-04-02T23:32:24Z"
- content="""
-Why not use **hardlinks** on Windows? This could fix \"only direct mode\" issue too. 
-Symlinks on windows sure want admin privilege but hardlinks won't. At least not with this tool: 
-
-"""]]
diff --git a/doc/todo/smudge/comment_9_e194d6371384f2db560f026d6ef728ff._comment b/doc/todo/smudge/comment_9_e194d6371384f2db560f026d6ef728ff._comment
deleted file mode 100644
index 104fc6ffe6..0000000000
--- a/doc/todo/smudge/comment_9_e194d6371384f2db560f026d6ef728ff._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="ExGen"
- subject="Harlinks"
- date="2016-04-03T11:21:02Z"
- content="""
-Also I tried now and confirmed both git's ln and cygwin's ln work on windows with hardlink, and it's supported since XP.
-"""]]
diff --git a/doc/todo/smudge/git-patches b/doc/todo/smudge/git-patches
deleted file mode 100644
index 3736ba2e3e..0000000000
--- a/doc/todo/smudge/git-patches
+++ /dev/null
@@ -1,1643 +0,0 @@
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/VX/gq/SHA256E-s5263957--977af1c7373ecbca2f2df44e782afb143e71a38b0af965f02cd1178ab5b82b4e.gz/SHA256E-s5263957--977af1c7373ecbca2f2df44e782afb143e71a38b0af965f02cd1178ab5b82b4e.gz
-Return-Path: 
-X-Original-To: joeyh@joeyh.name
-Delivered-To: joey@kitenet.net
-X-Question: 42
-Authentication-Results: kitenet.net;
-	dkim=pass (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=ier2ZdRe;
-	dkim-atps=neutral
-DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277197; bh=kOlU+hQ5LyTEz/eutsD10qEeMefFCuV9/88MgBjyH3k=;
-	h=From:To:Cc:Subject:Date:From;
-	b=ier2ZdReiz3+8cyLyfBhIuFH0zribYdza324RRso423MVVwX5Z5dXjkqHvfVpRxVA
-	 SLJCxSfGmOuiiQikb4CcFpmTi8rt+gcLqcgvQGgQMug+ee8CysZVHW76EpSILa8eIN
-	 1qIOb5q8Q8fHMaRifEWQvbQiw4XTzTdDJZdyPMIE=
-From: Joey Hess 
-To: git@vger.kernel.org
-Cc: Joey Hess 
-Subject: [PATCH v5 0/8] extend smudge/clean filters with direct file access (for pu)
-Date: Mon, 11 Jul 2016 18:45:04 -0400
-Message-Id: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-X-Spam-Status: No, score=-95.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
-	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_PBL,
-	RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,SPF_SOFTFAIL,URIBL_BLOCKED,USER_IN_WHITELIST
-	autolearn=no autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Content-Length: 1441
-Lines: 40
-
-Back from vacation with a reroll of jh/clean-smudge-annex.
-
-Deals with conflicting changes from cc/apply-am in pu.
-
-Since tb/convert-peek-in-index is not currently in pu, this reroll isn't
-based on it, and will conflict if that topic gets added back into pu.
-Not sure what the status of tb/convert-peek-in-index is at this point?
-
-Improvements from Junio's review:
-
-	fix build with DEVELOPER=1
-	style fixes
-	use test_cmp in test cases
-	improve robustness of a test case
-	clean up some confusing code
-	small performance tweak
-
-Joey Hess (8):
-  clarify %f documentation
-  add smudgeToFile and cleanFromFile filter configs
-  use cleanFromFile in git add
-  use smudgeToFile in git checkout etc
-  warn on unusable smudgeToFile/cleanFromFile config
-  better recovery from failure of smudgeToFile filter
-  use smudgeToFile filter in git am
-  use smudgeToFile filter in recursive merge
-
- Documentation/config.txt        |  18 ++++-
- Documentation/gitattributes.txt |  42 ++++++++++++
- apply.c                         |  16 +++++
- convert.c                       | 148 ++++++++++++++++++++++++++++++++++++----
- convert.h                       |  10 +++
- entry.c                         |  59 ++++++++++++----
- merge-recursive.c               |  53 +++++++++++---
- sha1_file.c                     |  42 ++++++++++--
- t/t0021-conversion.sh           | 117 +++++++++++++++++++++++++++++++
- 9 files changed, 459 insertions(+), 46 deletions(-)
-
--- 
-2.8.1
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id B1F5B1C677
-	for ; Mon, 11 Jul 2016 18:46:53 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=hbTM55ad;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752420AbcGKWqv (ORCPT );
-	Mon, 11 Jul 2016 18:46:51 -0400
-Received: from kitenet.net ([66.228.36.95]:60934 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1751854AbcGKWqu (ORCPT );
-	Mon, 11 Jul 2016 18:46:50 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277197; bh=Q37/p1l59xZISgA1LWyXTUqwJEg7T96CGx2mCEyU9UM=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=hbTM55adTxAE7hwBgj9q7PkR66nfsMxhWSpQn/R9iSUOaJ11fW10rEUxkLzcXKK5x
-	 ktVQ6sdgyCC5CbgYfBn6sMJ+EH6sTTJlLS0czzSkl453Izvk85rBtBGYsVSCzgbPai
-	 1rM45vbD/pViJQ2IUyiT/WxLexQFFn0DnVLiWuWA=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 1/8] clarify %f documentation
-Date:	Mon, 11 Jul 2016 18:45:05 -0400
-Message-Id: <1468277112-9909-2-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 1148
-Lines: 31
-
-It's natural to expect %f to be an actual file on disk; help avoid that
-mistake.
-
-Signed-off-by: Joey Hess 
----
- Documentation/gitattributes.txt | 5 +++++
- 1 file changed, 5 insertions(+)
-
-diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
-index f2afdb6..197ece8 100644
---- a/Documentation/gitattributes.txt
-+++ b/Documentation/gitattributes.txt
-@@ -379,6 +379,11 @@ substitution.  For example:
- 	smudge = git-p4-filter --smudge %f
- ------------------------
- 
-+Note that "%f" is the name of the path that is being worked on. Depending
-+on the version that is being filtered, the corresponding file on disk may
-+not exist, or may have different contents. So, smudge and clean commands
-+should not try to access the file on disk, but only act as filters on the
-+content provided to them on standard input.
- 
- Interaction between checkin/checkout attributes
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id 04F251C677
-	for ; Mon, 11 Jul 2016 18:47:07 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=NOnwhtEt;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752532AbcGKWrD (ORCPT );
-	Mon, 11 Jul 2016 18:47:03 -0400
-Received: from kitenet.net ([66.228.36.95]:60970 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752439AbcGKWrA (ORCPT );
-	Mon, 11 Jul 2016 18:47:00 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277198; bh=NRbzz9lX+l0UUh9pAD1CQEaHhmhOg2qk05TuAMiBsPo=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=NOnwhtEtJu+wBwiPrABDPIiic0tTHORjOkouxfQbD+rgbTjsY2mKzfmOsW0JdL5c9
-	 UyIeOOTmDA8jFAvt/o/9Yj7P39nbgg7fjX/tS8xd5oYSRV15Vg0ePEZ98nSHu+KjOR
-	 q06IOF8YyqtTAz4S3lSXXlNFfpqrFw8bQT4Xhq6Y=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 2/8] add smudgeToFile and cleanFromFile filter configs
-Date:	Mon, 11 Jul 2016 18:45:06 -0400
-Message-Id: <1468277112-9909-3-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 13634
-Lines: 374
-
-This adds new smudgeToFile and cleanFromFile filter commands,
-which are similar to smudge and clean but allow direct access to files on
-disk.
-
-This interface can be much more efficient when operating on large files,
-because the whole file content does not need to be streamed through the
-filter. It even allows for things like cleanFromFile commands that avoid
-reading the whole content of the file, and for smudgeToFile commands that
-populate a work tree file using an efficient Copy On Write operation.
-
-The new filter commands will not be used for all filtering. They are
-efficient to use when git add is adding a file, or when the work tree is
-being updated, but not a good fit when git is internally filtering blob
-objects in memory for eg, a diff.
-
-So, a user who wants to use smudgeToFile should also provide a smudge
-command to be used in cases where smudgeToFile is not used. And ditto
-with cleanFromFile and clean. To avoid foot-shooting configurations, the
-new commands are not used unless the old commands are also configured.
-
-That also ensures that a filter driver configuration that includes these
-new commands will work, although less efficiently, when used with an older
-version of git that does not support them.
-
-Signed-off-by: Joey Hess 
----
- Documentation/config.txt        |  18 ++++++-
- Documentation/gitattributes.txt |  37 ++++++++++++++
- convert.c                       | 111 +++++++++++++++++++++++++++++++++++-----
- convert.h                       |  10 ++++
- 4 files changed, 160 insertions(+), 16 deletions(-)
-
-diff --git a/Documentation/config.txt b/Documentation/config.txt
-index 19493aa..a55bed8 100644
---- a/Documentation/config.txt
-+++ b/Documentation/config.txt
-@@ -1325,15 +1325,29 @@ format.useAutoBase::
- 	format-patch by default.
- 
- filter..clean::
--	The command which is used to convert the content of a worktree
-+	The command which is used as a filter to convert the content of a worktree
- 	file to a blob upon checkin.  See linkgit:gitattributes[5] for
- 	details.
- 
- filter..smudge::
--	The command which is used to convert the content of a blob
-+	The command which is used as a filter to convert the content of a blob
- 	object to a worktree file upon checkout.  See
- 	linkgit:gitattributes[5] for details.
- 
-+filter..cleanFromFile::
-+	Similar to filter..clean but the specified command
-+	directly accesses a worktree file on disk, rather than
-+	receiving the file content from standard input.
-+	Only used when filter..clean is also configured.
-+	See linkgit:gitattributes[5] for details.
-+
-+filter..smudgeToFile::
-+	Similar to filter..smudge but the specified command
-+	writes the content of a blob directly to a worktree file,
-+	rather than to standard output.
-+	Only used when filter..smudge is also configured.
-+	See linkgit:gitattributes[5] for details.
-+
- fsck.::
- 	Allows overriding the message type (error, warn or ignore) of a
- 	specific message ID such as `missingEmail`.
-diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
-index 197ece8..a58aafc 100644
---- a/Documentation/gitattributes.txt
-+++ b/Documentation/gitattributes.txt
-@@ -385,6 +385,43 @@ not exist, or may have different contents. So, smudge and clean commands
- should not try to access the file on disk, but only act as filters on the
- content provided to them on standard input.
- 
-+There are two extra commands "cleanFromFile" and "smudgeToFile", which
-+can optionally be set in a filter driver. These are similar to the "clean"
-+and "smudge" commands, but avoid needing to pipe the contents of files
-+through the filters, and instead read/write files in the filesystem.
-+This can be more efficient when using filters with large files that are not
-+directly stored in the repository.
-+
-+Both "cleanFromFile" and "smudgeToFile" are provided a path as an
-+added parameter after the configured command line.
-+
-+The "cleanFromFile" command is provided the path to the file that
-+it should clean. Like the "clean" command, it should output the cleaned
-+version to standard output.
-+
-+The "smudgeToFile" command is provided a path to the file that it
-+should write to. (This file will already exist, as an empty file that can
-+be written to or replaced.) Like the "smudge" command, "smudgeToFile"
-+is fed the blob object from its standard input.
-+
-+Some git operations that need to apply filters cannot use "cleanFromFile"
-+and "smudgeToFile", since the files are not present to disk. So, to avoid
-+inconsistent behavior, "cleanFromFile" will only be used if "clean" is
-+also configured, and "smudgeToFile" will only be used if "smudge" is also
-+configured.
-+
-+An example large file storage filter driver using cleanFromFile and
-+smudgeToFile follows:
-+
-+------------------------
-+[filter "bigfiles"]
-+	clean = store-bigfile --from-stdin
-+	cleanFromFile = store-bigfile --from-file
-+	smudge = retrieve-bigfile --to-stdout
-+	smudgeToFile = retrieve-bigfile --to-file
-+	required
-+------------------------
-+
- Interaction between checkin/checkout attributes
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- 
-diff --git a/convert.c b/convert.c
-index 214c99f..eb7774f 100644
---- a/convert.c
-+++ b/convert.c
-@@ -358,7 +358,8 @@ struct filter_params {
- 	unsigned long size;
- 	int fd;
- 	const char *cmd;
--	const char *path;
-+	const char *path; /* Path within the git repository */
-+	const char *fspath; /* Path to file on disk */
- };
- 
- static int filter_buffer_or_fd(int in, int out, void *data)
-@@ -387,6 +388,15 @@ static int filter_buffer_or_fd(int in, int out, void *data)
- 	strbuf_expand(&cmd, params->cmd, strbuf_expand_dict_cb, &dict);
- 	strbuf_release(&path);
- 
-+	/* append fspath to the command if it's set, separated with a space */
-+	if (params->fspath) {
-+		struct strbuf fspath = STRBUF_INIT;
-+		sq_quote_buf(&fspath, params->fspath);
-+		strbuf_addstr(&cmd, " ");
-+		strbuf_addbuf(&cmd, &fspath);
-+		strbuf_release(&fspath);
-+	}
-+
- 	argv[0] = cmd.buf;
- 
- 	child_process.argv = argv;
-@@ -425,7 +435,8 @@ static int filter_buffer_or_fd(int in, int out, void *data)
- 	return (write_err || status);
- }
- 
--static int apply_filter(const char *path, const char *src, size_t len, int fd,
-+static int apply_filter(const char *path, const char *fspath,
-+			const char *src, size_t len, int fd,
-                         struct strbuf *dst, const char *cmd)
- {
- 	/*
-@@ -454,6 +465,7 @@ static int apply_filter(const char *path, const char *src, size_t len, int fd,
- 	params.fd = fd;
- 	params.cmd = cmd;
- 	params.path = path;
-+	params.fspath = fspath;
- 
- 	fflush(NULL);
- 	if (start_async(&async))
-@@ -484,6 +496,8 @@ static struct convert_driver {
- 	struct convert_driver *next;
- 	const char *smudge;
- 	const char *clean;
-+	const char *smudge_to_file;
-+	const char *clean_from_file;
- 	int required;
- } *user_convert, **user_convert_tail;
- 
-@@ -510,8 +524,9 @@ static int read_convert_config(const char *var, const char *value, void *cb)
- 	}
- 
- 	/*
--	 * filter..smudge and filter..clean specifies
--	 * the command line:
-+	 * filter..smudge, filter..clean,
-+	 * filter..smudgeToFile, filter..cleanFromFile
-+	 * specifies the command line:
- 	 *
- 	 *	command-line
- 	 *
-@@ -524,6 +539,12 @@ static int read_convert_config(const char *var, const char *value, void *cb)
- 	if (!strcmp("clean", key))
- 		return git_config_string(&drv->clean, var, value);
- 
-+	if (!strcmp("smudgetofile", key))
-+		return git_config_string(&drv->smudge_to_file, var, value);
-+
-+	if (!strcmp("cleanfromfile", key))
-+		return git_config_string(&drv->clean_from_file, var, value);
-+
- 	if (!strcmp("required", key)) {
- 		drv->required = git_config_bool(var, value);
- 		return 0;
-@@ -821,7 +842,37 @@ int would_convert_to_git_filter_fd(const char *path)
- 	if (!ca.drv->required)
- 		return 0;
- 
--	return apply_filter(path, NULL, 0, -1, NULL, ca.drv->clean);
-+	return apply_filter(path, NULL, NULL, 0, -1, NULL, ca.drv->clean);
-+}
-+
-+int can_clean_from_file(const char *path)
-+{
-+	struct conv_attrs ca;
-+
-+	convert_attrs(&ca, path);
-+	if (!ca.drv)
-+		return 0;
-+
-+	/*
-+	 * Only use the cleanFromFile filter when the clean filter is also
-+	 * configured.
-+	 */
-+	return (ca.drv->clean_from_file && ca.drv->clean);
-+}
-+
-+int can_smudge_to_file(const char *path)
-+{
-+	struct conv_attrs ca;
-+
-+	convert_attrs(&ca, path);
-+	if (!ca.drv)
-+		return 0;
-+
-+	/*
-+	 * Only use the smudgeToFile filter when the smudge filter is also
-+	 * configured.
-+	 */
-+	return (ca.drv->smudge_to_file && ca.drv->smudge);
- }
- 
- const char *get_convert_attr_ascii(const char *path)
-@@ -864,7 +915,7 @@ int convert_to_git(const char *path, const char *src, size_t len,
- 		required = ca.drv->required;
- 	}
- 
--	ret |= apply_filter(path, src, len, -1, dst, filter);
-+	ret |= apply_filter(path, NULL, src, len, -1, dst, filter);
- 	if (!ret && required)
- 		die("%s: clean filter '%s' failed", path, ca.drv->name);
- 
-@@ -889,14 +940,34 @@ void convert_to_git_filter_fd(const char *path, int fd, struct strbuf *dst,
- 	assert(ca.drv);
- 	assert(ca.drv->clean);
- 
--	if (!apply_filter(path, NULL, 0, fd, dst, ca.drv->clean))
-+	if (!apply_filter(path, NULL, NULL, 0, fd, dst, ca.drv->clean))
- 		die("%s: clean filter '%s' failed", path, ca.drv->name);
- 
- 	crlf_to_git(path, dst->buf, dst->len, dst, ca.crlf_action, checksafe);
- 	ident_to_git(path, dst->buf, dst->len, dst, ca.ident);
- }
- 
--static int convert_to_working_tree_internal(const char *path, const char *src,
-+void convert_to_git_filter_from_file(const char *path, struct strbuf *dst,
-+				   enum safe_crlf checksafe)
-+{
-+	struct conv_attrs ca;
-+	convert_attrs(&ca, path);
-+
-+	assert(ca.drv);
-+	assert(ca.drv->clean);
-+	assert(ca.drv->clean_from_file);
-+
-+	if (!apply_filter(path, path, "", 0, -1, dst, ca.drv->clean_from_file))
-+		die("%s: cleanFromFile filter '%s' failed", path, ca.drv->name);
-+
-+	crlf_to_git(path, dst->buf, dst->len, dst, ca.crlf_action,
-+		checksafe);
-+	ident_to_git(path, dst->buf, dst->len, dst, ca.ident);
-+}
-+
-+static int convert_to_working_tree_internal(const char *path,
-+					    const char *destpath,
-+					    const char *src,
- 					    size_t len, struct strbuf *dst,
- 					    int normalizing)
- {
-@@ -907,7 +978,10 @@ static int convert_to_working_tree_internal(const char *path, const char *src,
- 
- 	convert_attrs(&ca, path);
- 	if (ca.drv) {
--		filter = ca.drv->smudge;
-+		if (destpath)
-+			filter = ca.drv->smudge_to_file;
-+		else
-+			filter = ca.drv->smudge;
- 		required = ca.drv->required;
- 	}
- 
-@@ -918,7 +992,7 @@ static int convert_to_working_tree_internal(const char *path, const char *src,
- 	}
- 	/*
- 	 * CRLF conversion can be skipped if normalizing, unless there
--	 * is a smudge filter.  The filter might expect CRLFs.
-+	 * is a filter.  The filter might expect CRLFs.
- 	 */
- 	if (filter || !normalizing) {
- 		ret |= crlf_to_worktree(path, src, len, dst, ca.crlf_action);
-@@ -928,21 +1002,30 @@ static int convert_to_working_tree_internal(const char *path, const char *src,
- 		}
- 	}
- 
--	ret_filter = apply_filter(path, src, len, -1, dst, filter);
-+	ret_filter = apply_filter(path, destpath, src, len, -1, dst, filter);
- 	if (!ret_filter && required)
--		die("%s: smudge filter %s failed", path, ca.drv->name);
-+		die("%s: %s filter %s failed", path, destpath ? "smudgeToFile" : "smudge", ca.drv->name);
- 
- 	return ret | ret_filter;
- }
- 
- int convert_to_working_tree(const char *path, const char *src, size_t len, struct strbuf *dst)
- {
--	return convert_to_working_tree_internal(path, src, len, dst, 0);
-+	return convert_to_working_tree_internal(path, NULL, src, len, dst, 0);
-+}
-+
-+int convert_to_working_tree_filter_to_file(const char *path, const char *destpath, const char *src, size_t len)
-+{
-+	struct strbuf output = STRBUF_INIT;
-+	int ret = convert_to_working_tree_internal(path, destpath, src, len, &output, 0);
-+	/* The smudgeToFile filter stdout is not used. */
-+	strbuf_release(&output);
-+	return ret;
- }
- 
- int renormalize_buffer(const char *path, const char *src, size_t len, struct strbuf *dst)
- {
--	int ret = convert_to_working_tree_internal(path, src, len, dst, 1);
-+	int ret = convert_to_working_tree_internal(path, NULL, src, len, dst, 1);
- 	if (ret) {
- 		src = dst->buf;
- 		len = dst->len;
-diff --git a/convert.h b/convert.h
-index 82871a1..6f46d10 100644
---- a/convert.h
-+++ b/convert.h
-@@ -42,6 +42,10 @@ extern int convert_to_git(const char *path, const char *src, size_t len,
- 			  struct strbuf *dst, enum safe_crlf checksafe);
- extern int convert_to_working_tree(const char *path, const char *src,
- 				   size_t len, struct strbuf *dst);
-+extern int convert_to_working_tree_filter_to_file(const char *path,
-+						  const char *destpath,
-+						  const char *src,
-+						  size_t len);
- extern int renormalize_buffer(const char *path, const char *src, size_t len,
- 			      struct strbuf *dst);
- static inline int would_convert_to_git(const char *path)
-@@ -53,6 +57,12 @@ extern void convert_to_git_filter_fd(const char *path, int fd,
- 				     struct strbuf *dst,
- 				     enum safe_crlf checksafe);
- extern int would_convert_to_git_filter_fd(const char *path);
-+/* Precondition: can_clean_from_file(path) == true */
-+extern void convert_to_git_filter_from_file(const char *path,
-+					    struct strbuf *dst,
-+					    enum safe_crlf checksafe);
-+extern int can_clean_from_file(const char *path);
-+extern int can_smudge_to_file(const char *path);
- 
- /*****************************************************************
-  *
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id 92F4B1C677
-	for ; Mon, 11 Jul 2016 18:47:02 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=O21fZnmu;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752507AbcGKWq7 (ORCPT );
-	Mon, 11 Jul 2016 18:46:59 -0400
-Received: from kitenet.net ([66.228.36.95]:60948 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752439AbcGKWq6 (ORCPT );
-	Mon, 11 Jul 2016 18:46:58 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277197; bh=ID7Cvl2BMx/TZGvnWWIJ3y9tfZmZmZ0hcgqOsxLVm9Q=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=O21fZnmuEK0afkVNZdA2KL+bhF+skap1V8rdhqtR0vzDPg7cri/BlGPK8eY5G/xi6
-	 7f7vYgrq3QCN/0Q7cXsHSm0k8sgA2DLnriNR0Ga/gtk6OjqDr2JNHEMDoEt6MMyVto
-	 4wAJLa+dzSUA8Y+8bwZ760DVTucDOLRoEINUvJ0Y=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 3/8] use cleanFromFile in git add
-Date:	Mon, 11 Jul 2016 18:45:07 -0400
-Message-Id: <1468277112-9909-4-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 3641
-Lines: 127
-
-Includes test cases.
-
-Signed-off-by: Joey Hess 
----
- sha1_file.c           | 42 ++++++++++++++++++++++++++++++++++++------
- t/t0021-conversion.sh | 36 ++++++++++++++++++++++++++++++++++++
- 2 files changed, 72 insertions(+), 6 deletions(-)
-
-diff --git a/sha1_file.c b/sha1_file.c
-index 2fc22b0..549a20f 100644
---- a/sha1_file.c
-+++ b/sha1_file.c
-@@ -3335,6 +3335,29 @@ static int index_stream_convert_blob(unsigned char *sha1, int fd,
- 	return ret;
- }
- 
-+static int index_from_file_convert_blob(unsigned char *sha1,
-+				      const char *path, unsigned flags)
-+{
-+	int ret;
-+	const int write_object = flags & HASH_WRITE_OBJECT;
-+	struct strbuf sbuf = STRBUF_INIT;
-+
-+	assert(path);
-+	assert(can_clean_from_file(path));
-+
-+	convert_to_git_filter_from_file(path, &sbuf,
-+				 write_object ? safe_crlf : SAFE_CRLF_FALSE);
-+
-+	if (write_object)
-+		ret = write_sha1_file(sbuf.buf, sbuf.len, typename(OBJ_BLOB),
-+				      sha1);
-+	else
-+		ret = hash_sha1_file(sbuf.buf, sbuf.len, typename(OBJ_BLOB),
-+				     sha1);
-+	strbuf_release(&sbuf);
-+	return ret;
-+}
-+
- static int index_pipe(unsigned char *sha1, int fd, enum object_type type,
- 		      const char *path, unsigned flags)
- {
-@@ -3427,12 +3450,19 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, unsigned
- 
- 	switch (st->st_mode & S_IFMT) {
- 	case S_IFREG:
--		fd = open(path, O_RDONLY);
--		if (fd < 0)
--			return error_errno("open(\"%s\")", path);
--		if (index_fd(sha1, fd, st, OBJ_BLOB, path, flags) < 0)
--			return error("%s: failed to insert into database",
--				     path);
-+		if (can_clean_from_file(path)) {
-+			if (index_from_file_convert_blob(sha1, path, flags) < 0)
-+				return error("%s: failed to insert into database",
-+					     path);
-+		}
-+		else {
-+			fd = open(path, O_RDONLY);
-+			if (fd < 0)
-+				return error_errno("open(\"%s\")", path);
-+			if (index_fd(sha1, fd, st, OBJ_BLOB, path, flags) < 0)
-+				return error("%s: failed to insert into database",
-+					     path);
-+		}
- 		break;
- 	case S_IFLNK:
- 		if (strbuf_readlink(&sb, path, st->st_size))
-diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
-index 7bac2bc..bd84b80 100755
---- a/t/t0021-conversion.sh
-+++ b/t/t0021-conversion.sh
-@@ -12,6 +12,14 @@ tr \
- EOF
- chmod +x rot13.sh
- 
-+cat <rot13-from-file.sh
-+#!$SHELL_PATH
-+fsfile="\$1"
-+touch rot13-from-file.ran
-+cat "\$fsfile" | ./rot13.sh
-+EOF
-+chmod +x rot13-from-file.sh
-+
- test_expect_success setup '
- 	git config filter.rot13.smudge ./rot13.sh &&
- 	git config filter.rot13.clean ./rot13.sh &&
-@@ -268,4 +276,32 @@ test_expect_success 'disable filter with empty override' '
- 	test_must_be_empty err
- '
- 
-+test_expect_success 'cleanFromFile filter is used when adding a file' '
-+	test_config filter.rot13.cleanFromFile ./rot13-from-file.sh &&
-+
-+	echo "*.t filter=rot13" >.gitattributes &&
-+
-+	cat test >fstest.t &&
-+	git add fstest.t &&
-+	test -e rot13-from-file.ran &&
-+	rm -f rot13-from-file.ran &&
-+
-+	rm -f fstest.t &&
-+	git checkout -- fstest.t &&
-+	test_cmp test fstest.t
-+'
-+
-+test_expect_success 'cleanFromFile filter is not used when clean filter is not configured' '
-+	test_config filter.noclean.smudge ./rot13.sh &&
-+	test_config filter.noclean.cleanFromFile ./rot13-from-file.sh &&
-+
-+	echo "*.no filter=noclean" >.gitattributes &&
-+
-+	cat test >test.no &&
-+	git add test.no &&
-+	test ! -e rot13-from-file.ran &&
-+	git cat-file blob :test.no >actual &&
-+	test_cmp test actual
-+'
-+
- test_done
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id 363761C677
-	for ; Mon, 11 Jul 2016 18:47:18 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=P+WpFgpS;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752612AbcGKWrO (ORCPT );
-	Mon, 11 Jul 2016 18:47:14 -0400
-Received: from kitenet.net ([66.228.36.95]:32768 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752439AbcGKWrN (ORCPT );
-	Mon, 11 Jul 2016 18:47:13 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277198; bh=tAWpo3wY2ayI3N2P5PIoaKI4XKz6M0EPI7WSh1kSoZc=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=P+WpFgpSST+oHI+yvWOFavctP60LP4dRf0CJA1N75Wk/pQIHue3j4sxVPNsjTAuj6
-	 IzUxRBE2Ilz3E0UF3r6iL2lCVMtITzMvvTqYjr9xEXi8mGgInDOWD1bi7bdmt2NY1z
-	 ZlAIY9kjZhF+1jmpxhc1YP+tkocCMOsmT/DbiGRI=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 4/8] use smudgeToFile in git checkout etc
-Date:	Mon, 11 Jul 2016 18:45:08 -0400
-Message-Id: <1468277112-9909-5-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 4367
-Lines: 147
-
-This makes git checkout, git reset, etc use smudgeToFile.
-
-Includes test cases.
-
-(There's a call to convert_to_working_tree in merge-recursive.c
-that could also be made to use smudgeToFile as well.)
-
-Signed-off-by: Joey Hess 
----
- entry.c               | 40 ++++++++++++++++++++++++++++++++--------
- t/t0021-conversion.sh | 34 ++++++++++++++++++++++++++++++++--
- 2 files changed, 64 insertions(+), 10 deletions(-)
-
-diff --git a/entry.c b/entry.c
-index 519e042..81d12a1 100644
---- a/entry.c
-+++ b/entry.c
-@@ -146,6 +146,7 @@ static int write_entry(struct cache_entry *ce,
- 	unsigned long size;
- 	size_t wrote, newsize = 0;
- 	struct stat st;
-+	int regular_file, smudge_to_file;
- 
- 	if (ce_mode_s_ifmt == S_IFREG) {
- 		struct stream_filter *filter = get_stream_filter(ce->name, ce->sha1);
-@@ -175,8 +176,13 @@ static int write_entry(struct cache_entry *ce,
- 
- 		/*
- 		 * Convert from git internal format to working tree format
-+		 * unless the smudgeToFile filter can write to the
-+		 * file directly.
- 		 */
--		if (ce_mode_s_ifmt == S_IFREG &&
-+		regular_file = ce_mode_s_ifmt == S_IFREG;
-+		smudge_to_file = regular_file
-+			&& can_smudge_to_file(ce->name);
-+		if (regular_file && !smudge_to_file &&
- 		    convert_to_working_tree(ce->name, new, size, &buf)) {
- 			free(new);
- 			new = strbuf_detach(&buf, &newsize);
-@@ -189,13 +195,31 @@ static int write_entry(struct cache_entry *ce,
- 			return error_errno("unable to create file %s", path);
- 		}
- 
--		wrote = write_in_full(fd, new, size);
--		if (!to_tempfile)
--			fstat_done = fstat_output(fd, state, &st);
--		close(fd);
--		free(new);
--		if (wrote != size)
--			return error("unable to write file %s", path);
-+		if (!smudge_to_file) {
-+			wrote = write_in_full(fd, new, size);
-+			if (!to_tempfile)
-+				fstat_done = fstat_output(fd, state, &st);
-+			close(fd);
-+			free(new);
-+			if (wrote != size)
-+				return error("unable to write file %s", path);
-+		}
-+		else {
-+			close(fd);
-+			convert_to_working_tree_filter_to_file(ce->name, path, new, size);
-+			free(new);
-+			/*
-+			 * The smudgeToFile filter may have replaced the
-+			 * file; open it to make sure that the file
-+			 * exists.
-+			 */
-+			fd = open(path, O_RDONLY);
-+			if (fd < 0)
-+				return error_errno("unable to create file %s", path);
-+			if (!to_tempfile)
-+				fstat_done = fstat_output(fd, state, &st);
-+			close(fd);
-+		}
- 		break;
- 	case S_IFGITLINK:
- 		if (to_tempfile)
-diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
-index bd84b80..ea18b17 100755
---- a/t/t0021-conversion.sh
-+++ b/t/t0021-conversion.sh
-@@ -14,12 +14,20 @@ chmod +x rot13.sh
- 
- cat <rot13-from-file.sh
- #!$SHELL_PATH
--fsfile="\$1"
-+srcfile="\$1"
- touch rot13-from-file.ran
--cat "\$fsfile" | ./rot13.sh
-+cat "\$srcfile" | ./rot13.sh
- EOF
- chmod +x rot13-from-file.sh
- 
-+cat <rot13-to-file.sh
-+#!$SHELL_PATH
-+destfile="\$1"
-+touch rot13-to-file.ran
-+./rot13.sh >"\$destfile"
-+EOF
-+chmod +x rot13-to-file.sh
-+
- test_expect_success setup '
- 	git config filter.rot13.smudge ./rot13.sh &&
- 	git config filter.rot13.clean ./rot13.sh &&
-@@ -291,6 +299,17 @@ test_expect_success 'cleanFromFile filter is used when adding a file' '
- 	test_cmp test fstest.t
- '
- 
-+test_expect_success 'smudgeToFile filter is used when checking out a file' '
-+	test_config filter.rot13.smudgeToFile ./rot13-to-file.sh &&
-+
-+	rm -f fstest.t &&
-+	git checkout -- fstest.t &&
-+	test_cmp test fstest.t &&
-+
-+	test -e rot13-to-file.ran &&
-+	rm -f rot13-to-file.ran
-+'
-+
- test_expect_success 'cleanFromFile filter is not used when clean filter is not configured' '
- 	test_config filter.noclean.smudge ./rot13.sh &&
- 	test_config filter.noclean.cleanFromFile ./rot13-from-file.sh &&
-@@ -304,4 +323,15 @@ test_expect_success 'cleanFromFile filter is not used when clean filter is not c
- 	test_cmp test actual
- '
- 
-+test_expect_success 'smudgeToFile filter is not used when smudge filter is not configured' '
-+	test_config filter.nosmudge.clean ./rot13.sh &&
-+	test_config filter.nosmudge.smudgeToFile ./rot13-to-file.sh &&
-+
-+	echo "*.no filter=nosmudge" >.gitattributes &&
-+
-+	rm -f fstest.t &&
-+	git checkout -- fstest.t &&
-+	test ! -e rot13-to-file.ran
-+'
-+
- test_done
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id 714E61C67C
-	for ; Mon, 11 Jul 2016 18:47:12 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=Yy9dgbAc;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752555AbcGKWrI (ORCPT );
-	Mon, 11 Jul 2016 18:47:08 -0400
-Received: from kitenet.net ([66.228.36.95]:60984 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752439AbcGKWrI (ORCPT );
-	Mon, 11 Jul 2016 18:47:08 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277198; bh=ZPsSRNaHriT6igc+PUYizSKSXZl5YDOyDcX0bJMWFqk=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=Yy9dgbAcC69LAmxyt4U9d2lqehM4dKl+NuDIHbQ//uTjX1mmOMkj/Pe4n7vrShEUP
-	 D4h/CYU5C4oRTJMhV1MF501fgcvPvOujxUMOviTB+g1EH5YfP989HvZT+7xafE3M4m
-	 8+IYWJC1JpDN45UcBwYBROl/ch/87+shPUlms+ds=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 5/8] warn on unusable smudgeToFile/cleanFromFile config
-Date:	Mon, 11 Jul 2016 18:45:09 -0400
-Message-Id: <1468277112-9909-6-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 2309
-Lines: 84
-
-Let the user know when they have a smudgeToFile/cleanFromFile config
-that cannot be used because the corresponding smudge/clean config
-is missing.
-
-The warning is only displayed a maximum of once per git invocation,
-and only when doing an operation that would use the filter.
-
-Signed-off-by: Joey Hess 
----
- convert.c | 36 ++++++++++++++++++++++++++----------
- 1 file changed, 26 insertions(+), 10 deletions(-)
-
-diff --git a/convert.c b/convert.c
-index eb7774f..e1b0b44 100644
---- a/convert.c
-+++ b/convert.c
-@@ -845,34 +845,50 @@ int would_convert_to_git_filter_fd(const char *path)
- 	return apply_filter(path, NULL, NULL, 0, -1, NULL, ca.drv->clean);
- }
- 
-+static int can_filter_file(const char *filefilter, const char *filefiltername,
-+			   const char *stdiofilter, const char *stdiofiltername,
-+			   const struct conv_attrs *ca,
-+			   int *warncount)
-+{
-+	if (!filefilter)
-+		return 0;
-+
-+	if (stdiofilter)
-+		return 1;
-+
-+	if (*warncount == 0)
-+		warning("Not running your configured filter.%s.%s command, because filter.%s.%s is not configured",
-+			ca->drv->name, filefiltername,
-+			ca->drv->name, stdiofiltername);
-+		*warncount=*warncount+1;
-+
-+	return 0;
-+}
-+
- int can_clean_from_file(const char *path)
- {
- 	struct conv_attrs ca;
-+	static int warncount = 0;
- 
- 	convert_attrs(&ca, path);
- 	if (!ca.drv)
- 		return 0;
- 
--	/*
--	 * Only use the cleanFromFile filter when the clean filter is also
--	 * configured.
--	 */
--	return (ca.drv->clean_from_file && ca.drv->clean);
-+	return can_filter_file(ca.drv->clean_from_file, "cleanFromFile",
-+			       ca.drv->clean, "clean", &ca, &warncount);
- }
- 
- int can_smudge_to_file(const char *path)
- {
- 	struct conv_attrs ca;
-+	static int warncount = 0;
- 
- 	convert_attrs(&ca, path);
- 	if (!ca.drv)
- 		return 0;
- 
--	/*
--	 * Only use the smudgeToFile filter when the smudge filter is also
--	 * configured.
--	 */
--	return (ca.drv->smudge_to_file && ca.drv->smudge);
-+	return can_filter_file(ca.drv->smudge_to_file, "smudgeToFile",
-+			       ca.drv->smudge, "smudge", &ca, &warncount);
- }
- 
- const char *get_convert_attr_ascii(const char *path)
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id 839871C677
-	for ; Mon, 11 Jul 2016 18:47:27 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=e1tj3LJk;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752603AbcGKWrW (ORCPT );
-	Mon, 11 Jul 2016 18:47:22 -0400
-Received: from kitenet.net ([66.228.36.95]:32788 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752616AbcGKWrT (ORCPT );
-	Mon, 11 Jul 2016 18:47:19 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277198; bh=4aNAzyRt9bz6y9MPC2VC5pj9+5O3Gb5fUsDopvg0K64=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=e1tj3LJkIi1ro6kUH77lZhTIqJt1N6KgyzFzcDDEdrFFz4x49MywJnSCKy9xtgY4h
-	 gc/cr1oZKUTrgmSXwMT8HD5yRltK8eWXnXOYn816pWnnRSkFlcwB+VWR4hhVcYahcV
-	 KM71p6oYWBbs2BULmxjndGZX1lRSx34zt8DePh2Y=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 6/8] better recovery from failure of smudgeToFile filter
-Date:	Mon, 11 Jul 2016 18:45:10 -0400
-Message-Id: <1468277112-9909-7-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 4558
-Lines: 151
-
-If the smudgeToFile filter fails, it can leave the worktree file with the
-wrong content, or even deleted. Recover from this by falling back to
-running the smudge filter.
-
-Signed-off-by: Joey Hess 
----
- entry.c               | 66 ++++++++++++++++++++++++++++++++++-----------------
- t/t0021-conversion.sh | 24 +++++++++++++++++++
- 2 files changed, 68 insertions(+), 22 deletions(-)
-
-diff --git a/entry.c b/entry.c
-index 81d12a1..7811e31 100644
---- a/entry.c
-+++ b/entry.c
-@@ -182,12 +182,6 @@ static int write_entry(struct cache_entry *ce,
- 		regular_file = ce_mode_s_ifmt == S_IFREG;
- 		smudge_to_file = regular_file
- 			&& can_smudge_to_file(ce->name);
--		if (regular_file && !smudge_to_file &&
--		    convert_to_working_tree(ce->name, new, size, &buf)) {
--			free(new);
--			new = strbuf_detach(&buf, &newsize);
--			size = newsize;
--		}
- 
- 		fd = open_output_fd(path, ce, to_tempfile);
- 		if (fd < 0) {
-@@ -195,7 +189,51 @@ static int write_entry(struct cache_entry *ce,
- 			return error_errno("unable to create file %s", path);
- 		}
- 
-+		if (smudge_to_file) {
-+			close(fd);
-+			if (convert_to_working_tree_filter_to_file(ce->name, path, new, size)) {
-+				free(new);
-+				/*
-+				 * The smudgeToFile filter may have replaced
-+				 * or deleted the file; reopen it to make
-+				 * sure that the file exists.
-+				 */
-+				fd = open(path, O_RDONLY);
-+				if (fd < 0)
-+					return error_errno("unable to create file %s", path);
-+				if (!to_tempfile)
-+					fstat_done = fstat_output(fd, state, &st);
-+				close(fd);
-+			}
-+			else {
-+				/*
-+				 * The failing smudgeToFile filter may have
-+				 * deleted or replaced the file; delete
-+				 * the file and re-open for recovery write.
-+				 */
-+				unlink(path);
-+				fd = open_output_fd(path, ce, to_tempfile);
-+				if (fd < 0) {
-+					free(new);
-+					return error_errno("unable to create file %s", path);
-+				}
-+				/* Fall through to normal write below. */
-+				smudge_to_file = 0;
-+			}
-+		}
-+
-+		/*
-+		 * Not an else of above if (smudge_to_file) because the
-+		 * smudgeToFile filter may fail and in that case this is
-+		 * run to recover.
-+		 */
- 		if (!smudge_to_file) {
-+			if (regular_file &&
-+			    convert_to_working_tree(ce->name, new, size, &buf)) {
-+				free(new);
-+				new = strbuf_detach(&buf, &newsize);
-+				size = newsize;
-+			}
- 			wrote = write_in_full(fd, new, size);
- 			if (!to_tempfile)
- 				fstat_done = fstat_output(fd, state, &st);
-@@ -204,22 +242,6 @@ static int write_entry(struct cache_entry *ce,
- 			if (wrote != size)
- 				return error("unable to write file %s", path);
- 		}
--		else {
--			close(fd);
--			convert_to_working_tree_filter_to_file(ce->name, path, new, size);
--			free(new);
--			/*
--			 * The smudgeToFile filter may have replaced the
--			 * file; open it to make sure that the file
--			 * exists.
--			 */
--			fd = open(path, O_RDONLY);
--			if (fd < 0)
--				return error_errno("unable to create file %s", path);
--			if (!to_tempfile)
--				fstat_done = fstat_output(fd, state, &st);
--			close(fd);
--		}
- 		break;
- 	case S_IFGITLINK:
- 		if (to_tempfile)
-diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
-index ea18b17..0efad9b 100755
---- a/t/t0021-conversion.sh
-+++ b/t/t0021-conversion.sh
-@@ -28,6 +28,14 @@ touch rot13-to-file.ran
- EOF
- chmod +x rot13-to-file.sh
- 
-+cat <delete-file-and-fail.sh
-+#!$SHELL_PATH
-+destfile="\$1"
-+rm -f "\$destfile"
-+exit 1
-+EOF
-+chmod +x delete-file-and-fail.sh
-+
- test_expect_success setup '
- 	git config filter.rot13.smudge ./rot13.sh &&
- 	git config filter.rot13.clean ./rot13.sh &&
-@@ -310,6 +318,22 @@ test_expect_success 'smudgeToFile filter is used when checking out a file' '
- 	rm -f rot13-to-file.ran
- '
- 
-+test_expect_success 'recovery from failure of smudgeToFile filter, using smudge filter' '
-+	test_config filter.rot13.smudgeToFile false &&
-+
-+	rm -f fstest.t &&
-+	git checkout -- fstest.t &&
-+	test_cmp test fstest.t
-+'
-+
-+test_expect_success 'recovery from failure of smudgeToFile filter that deletes the worktree file' '
-+	test_config filter.rot13.smudgeToFile ./delete-file-and-fail.sh &&
-+
-+	rm -f fstest.t &&
-+	git checkout -- fstest.t &&
-+	test_cmp test fstest.t
-+'
-+
- test_expect_success 'cleanFromFile filter is not used when clean filter is not configured' '
- 	test_config filter.noclean.smudge ./rot13.sh &&
- 	test_config filter.noclean.cleanFromFile ./rot13-from-file.sh &&
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id 3B2531C677
-	for ; Mon, 11 Jul 2016 18:47:23 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=P7RXYLHP;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752629AbcGKWrT (ORCPT );
-	Mon, 11 Jul 2016 18:47:19 -0400
-Received: from kitenet.net ([66.228.36.95]:32782 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752603AbcGKWrS (ORCPT );
-	Mon, 11 Jul 2016 18:47:18 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277198; bh=R6DA3FWAltlIvvD5mJEp7ZgM7JFZFfGDS/9auV9Z+0Q=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=P7RXYLHPbs0CXSl4ChFu0IJTC7WGua7f0VyocRm/r3ZZK/2HscKr3lMHDy0fxfD3I
-	 grgLgEiaffIZ5+vMX0FWQIYDLISJD4NlDMYYt3NoONm10nDHJp/vSm1/YdyoaT8+3p
-	 RnZbAzgY6m43Lhx7BxNApQ8/UPzUL5hWD45Jl5YU=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 7/8] use smudgeToFile filter in git am
-Date:	Mon, 11 Jul 2016 18:45:11 -0400
-Message-Id: <1468277112-9909-8-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 4808
-Lines: 156
-
-git am updates the work tree and so should use the smudgeToFile filter.
-
-This includes some refactoring into convert_to_working_tree_filter_to_file
-to make it check the file after running the smudgeToFile command, and clean
-up from a failing command.
-
-Signed-off-by: Joey Hess 
----
- apply.c               | 16 ++++++++++++++++
- convert.c             | 25 +++++++++++++++++++++++--
- entry.c               | 21 ++++-----------------
- t/t0021-conversion.sh | 13 +++++++++++++
- 4 files changed, 56 insertions(+), 19 deletions(-)
-
-diff --git a/apply.c b/apply.c
-index 4a6b2db..7db8344 100644
---- a/apply.c
-+++ b/apply.c
-@@ -4322,6 +4322,22 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf,
- 	if (fd < 0)
- 		return 1;
- 
-+	if (can_smudge_to_file(path)) {
-+		close(fd);
-+		fd = convert_to_working_tree_filter_to_file(path, path, buf, size);
-+		if (fd < 0) {
-+			/* smudgeToFile filter failed; continue
-+			 * with regular file creation instead. */
-+			fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);
-+			if (fd < 0)
-+				return -1;
-+		}
-+		else {
-+			close(fd);
-+			return 0;
-+		}
-+	}
-+
- 	if (convert_to_working_tree(path, buf, size, &nbuf)) {
- 		size = nbuf.len;
- 		buf  = nbuf.buf;
-diff --git a/convert.c b/convert.c
-index e1b0b44..3746ad5 100644
---- a/convert.c
-+++ b/convert.c
-@@ -1030,13 +1030,34 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc
- 	return convert_to_working_tree_internal(path, NULL, src, len, dst, 0);
- }
- 
-+/*
-+ * Returns fd open to read the worktree file on success.
-+ * On failure, the worktree file will not exist.
-+ */
- int convert_to_working_tree_filter_to_file(const char *path, const char *destpath, const char *src, size_t len)
- {
- 	struct strbuf output = STRBUF_INIT;
--	int ret = convert_to_working_tree_internal(path, destpath, src, len, &output, 0);
-+	int ok = convert_to_working_tree_internal(path, destpath, src, len, &output, 0);
- 	/* The smudgeToFile filter stdout is not used. */
- 	strbuf_release(&output);
--	return ret;
-+	if (ok) {
-+		/*
-+		 * Open the file to make sure that it's present
-+		 * (and readable) after the command populated it.
-+		 */
-+		int fd = open(path, O_RDONLY);
-+		if (fd < 0)
-+			unlink(path);
-+		return fd;
-+	}
-+	else {
-+		/*
-+		 * The command could have created the file before failing,
-+		 * so delete it.
-+		 */
-+		unlink(path);
-+		return -1;
-+	}
- }
- 
- int renormalize_buffer(const char *path, const char *src, size_t len, struct strbuf *dst)
-diff --git a/entry.c b/entry.c
-index 7811e31..40662eb 100644
---- a/entry.c
-+++ b/entry.c
-@@ -191,34 +191,21 @@ static int write_entry(struct cache_entry *ce,
- 
- 		if (smudge_to_file) {
- 			close(fd);
--			if (convert_to_working_tree_filter_to_file(ce->name, path, new, size)) {
-+			fd = convert_to_working_tree_filter_to_file(ce->name, path, new, size);
-+			if (fd >= 0) {
- 				free(new);
--				/*
--				 * The smudgeToFile filter may have replaced
--				 * or deleted the file; reopen it to make
--				 * sure that the file exists.
--				 */
--				fd = open(path, O_RDONLY);
--				if (fd < 0)
--					return error_errno("unable to create file %s", path);
- 				if (!to_tempfile)
- 					fstat_done = fstat_output(fd, state, &st);
- 				close(fd);
- 			}
- 			else {
--				/*
--				 * The failing smudgeToFile filter may have
--				 * deleted or replaced the file; delete
--				 * the file and re-open for recovery write.
--				 */
--				unlink(path);
-+				/* Fall through to normal write below. */
-+				smudge_to_file = 0;
- 				fd = open_output_fd(path, ce, to_tempfile);
- 				if (fd < 0) {
- 					free(new);
- 					return error_errno("unable to create file %s", path);
- 				}
--				/* Fall through to normal write below. */
--				smudge_to_file = 0;
- 			}
- 		}
- 
-diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
-index 0efad9b..42b28aa 100755
---- a/t/t0021-conversion.sh
-+++ b/t/t0021-conversion.sh
-@@ -334,6 +334,19 @@ test_expect_success 'recovery from failure of smudgeToFile filter that deletes t
- 	test_cmp test fstest.t
- '
- 
-+test_expect_success 'smudgeToFile filter is used by git am' '
-+	test_config filter.rot13.smudgeToFile ./rot13-to-file.sh &&
-+
-+	git commit fstest.t -m "added fstest.t" &&
-+	git format-patch HEAD^ --stdout >fstest.patch &&
-+	git reset --hard HEAD^ &&
-+	git am fstest.patch &&
-+
-+	test -e rot13-to-file.ran &&
-+	rm -f rot13-to-file.ran &&
-+	test_cmp test fstest.t
-+'
-+
- test_expect_success 'cleanFromFile filter is not used when clean filter is not configured' '
- 	test_config filter.noclean.smudge ./rot13.sh &&
- 	test_config filter.noclean.cleanFromFile ./rot13-from-file.sh &&
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-From mairix@mairix Mon Jan  1 12:34:56 1970
-X-source-folder: /home/joey/mail/.git/annex/objects/0k/FJ/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz/SHA256E-s162778--6d2a0fc6afd1077eccdca2e92f314c00ef70a06273242429035e0ce52cce2e13.gz
-Return-Path: 
-X-Original-To: joey@kitenet.net
-Delivered-To: joey@kitenet.net
-Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by kitenet.net (Postfix) with ESMTP id C58671C677
-	for ; Mon, 11 Jul 2016 18:47:18 -0400 (EDT)
-Authentication-Results: kitenet.net;
-	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=joeyh.name header.i=@joeyh.name header.b=VKChWnWm;
-	dkim-atps=neutral
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1752615AbcGKWrR (ORCPT );
-	Mon, 11 Jul 2016 18:47:17 -0400
-Received: from kitenet.net ([66.228.36.95]:32778 "EHLO kitenet.net"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752603AbcGKWrO (ORCPT );
-	Mon, 11 Jul 2016 18:47:14 -0400
-X-Question: 42
-DKIM-Signature:	v=1; a=rsa-sha256; c=simple/simple; d=joeyh.name; s=mail;
-	t=1468277198; bh=e7pd1+fJ7kJE3zbr6Uuf5rQkwlF5ZqMSMu31as4SNuw=;
-	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
-	b=VKChWnWmsu86vvKjaYknMgW76bozccToHJNzUBKXMXKt57vEc+PiDgxiMNKvA57iJ
-	 /S26T8zVRqNUsPdzXsLMoCVA+T2EPLwSv/dLjBIwrTT+yveUiaH2Q4U9jzqDkU/GYy
-	 8iEtbg7ly/pnrWgjApNsnbMY5OogcAINTDod/flY=
-From:	Joey Hess 
-To:	git@vger.kernel.org
-Cc:	Joey Hess 
-Subject: [PATCH v5 8/8] use smudgeToFile filter in recursive merge
-Date:	Mon, 11 Jul 2016 18:45:12 -0400
-Message-Id: <1468277112-9909-9-git-send-email-joeyh@joeyh.name>
-X-Mailer: git-send-email 2.8.1
-In-Reply-To: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-References: <1468277112-9909-1-git-send-email-joeyh@joeyh.name>
-X-Spam-Status: No, score=-8.2 required=10.0 tests=BAYES_00,DKIM_SIGNED,
-	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,
-	URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1
-X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
-Sender:	git-owner@vger.kernel.org
-Precedence: bulk
-List-ID: 
-X-Mailing-List:	git@vger.kernel.org
-Content-Length: 3928
-Lines: 134
-
-Recursive merge updates the work tree and so should use the smudgeToFile
-filter.
-
-At this point, smudgeToFile is run by everything that updates work
-tree files.
-
-Signed-off-by: Joey Hess 
----
- merge-recursive.c     | 53 ++++++++++++++++++++++++++++++++++++++++-----------
- t/t0021-conversion.sh | 16 +++++++++++++++-
- 2 files changed, 57 insertions(+), 12 deletions(-)
-
-diff --git a/merge-recursive.c b/merge-recursive.c
-index a4a1195..5fe3f50 100644
---- a/merge-recursive.c
-+++ b/merge-recursive.c
-@@ -758,6 +758,7 @@ static void update_file_flags(struct merge_options *o,
- 		enum object_type type;
- 		void *buf;
- 		unsigned long size;
-+		int isreg;
- 
- 		if (S_ISGITLINK(mode)) {
- 			/*
-@@ -774,22 +775,16 @@ static void update_file_flags(struct merge_options *o,
- 			die(_("cannot read object %s '%s'"), oid_to_hex(oid), path);
- 		if (type != OBJ_BLOB)
- 			die(_("blob expected for %s '%s'"), oid_to_hex(oid), path);
--		if (S_ISREG(mode)) {
--			struct strbuf strbuf = STRBUF_INIT;
--			if (convert_to_working_tree(path, buf, size, &strbuf)) {
--				free(buf);
--				size = strbuf.len;
--				buf = strbuf_detach(&strbuf, NULL);
--			}
--		}
- 
- 		if (make_room_for_path(o, path) < 0) {
- 			update_wd = 0;
- 			free(buf);
- 			goto update_index;
- 		}
--		if (S_ISREG(mode) || (!has_symlinks && S_ISLNK(mode))) {
-+		isreg = S_ISREG(mode);
-+		if (isreg || (!has_symlinks && S_ISLNK(mode))) {
- 			int fd;
-+			int smudge_to_file;
- 			if (mode & 0100)
- 				mode = 0777;
- 			else
-@@ -797,8 +792,44 @@ static void update_file_flags(struct merge_options *o,
- 			fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
- 			if (fd < 0)
- 				die_errno(_("failed to open '%s'"), path);
--			write_in_full(fd, buf, size);
--			close(fd);
-+
-+			smudge_to_file = can_smudge_to_file(path);
-+			if (smudge_to_file) {
-+				close(fd);
-+				fd = convert_to_working_tree_filter_to_file(path, path, buf, size);
-+				if (fd < 0) {
-+					/*
-+					 * smudgeToFile filter failed;
-+					 * continue with regular file
-+					 * creation.
-+					 */
-+					smudge_to_file = 0;
-+					fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
-+					if (fd < 0)
-+						die_errno(_("failed to open '%s'"), path);
-+				}
-+				else {
-+					close(fd);
-+				}
-+			}
-+
-+			/*
-+			 * Not an else of above if (smudge_to_file) because
-+			 * the smudgeToFile filter may fail and in that case
-+			 * this is run to recover.
-+			 */
-+			if (!smudge_to_file) {
-+				if (isreg) {
-+					struct strbuf strbuf = STRBUF_INIT;
-+					if (convert_to_working_tree(path, buf, size, &strbuf)) {
-+						free(buf);
-+						size = strbuf.len;
-+						buf = strbuf_detach(&strbuf, NULL);
-+					}
-+				}
-+				write_in_full(fd, buf, size);
-+				close(fd);
-+			}
- 		} else if (S_ISLNK(mode)) {
- 			char *lnk = xmemdupz(buf, size);
- 			safe_create_leading_directories_const(path);
-diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
-index 42b28aa..64b2b8f 100755
---- a/t/t0021-conversion.sh
-+++ b/t/t0021-conversion.sh
-@@ -334,10 +334,24 @@ test_expect_success 'recovery from failure of smudgeToFile filter that deletes t
- 	test_cmp test fstest.t
- '
- 
-+test_expect_success 'smudgeToFile filter is used in merge' '
-+	test_config filter.rot13.smudgeToFile ./rot13-to-file.sh &&
-+
-+	git commit -m "added fstest.t" fstest.t &&
-+	git checkout -b old &&
-+	git reset --hard HEAD^ &&
-+	git merge master &&
-+	git checkout master &&
-+
-+	test -e rot13-to-file.ran &&
-+	rm -f rot13-to-file.ran &&
-+
-+	test_cmp test fstest.t
-+'
-+
- test_expect_success 'smudgeToFile filter is used by git am' '
- 	test_config filter.rot13.smudgeToFile ./rot13-to-file.sh &&
- 
--	git commit fstest.t -m "added fstest.t" &&
- 	git format-patch HEAD^ --stdout >fstest.patch &&
- 	git reset --hard HEAD^ &&
- 	git am fstest.patch &&
--- 
-2.8.1
-
---
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__.mdwn b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__.mdwn
deleted file mode 100644
index fdd660706d..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-ATM, even with ControlPersist=yes, on a fast interconnection between hosts (so it a millisecond or so to transfer a single file I have there), majority of time is spent I guess on running a new ssh (although with instructions for persistent connection etc) or is there some intentional sleep somewhere (or just output flushed at 1 sec intervals so ts has those consistent subsec offset), which ends up spending up to a second to transfer a single file.  I have ~25,000 files so would need about 5 hours, although with direct rsync -e 'ssh' -L  it takes total of 2 seconds for those 100MB .  Here is the protocol (with ts with subsecond timing):
-
-    Aug 04 10:46:02.1438699562 get stimulus/task002/generate/part_1-182x121/000251.jpeg (from origin...)
-    Aug 04 10:46:02.1438699562 SHA256E-s1650--768d78ad49fc413d178a5cd9407b56bb442f40aaa629b7f608844330c2c4bbf9.jpeg
-    Aug 04 10:46:02.1438699562 ^M              0   0%    0.00kB/s    0:00:00  ^M          1,650 100%    1.57MB/s    0:00:00 (xfr#1, to-chk=0/1)
-    Aug 04 10:46:02.1438699562 ok
-    Aug 04 10:46:02.1438699562 get stimulus/task002/generate/part_1-182x121/000252.jpeg (from origin...)
-    Aug 04 10:46:02.1438699562 SHA256E-s1662--d156f08ecfcc248aeb01239f5e605f3ac9ed72fa77c54e593a54b1f6a8b3f0f4.jpeg
-    Aug 04 10:46:02.1438699562 ^M              0   0%    0.00kB/s    0:00:00  ^M          1,662 100%    1.59MB/s    0:00:00 (xfr#1, to-chk=0/1)
-    Aug 04 10:46:02.1438699562 ok
-    Aug 04 10:46:02.1438699562 get stimulus/task002/generate/part_1-182x121/000253.jpeg (from origin...)
-    Aug 04 10:46:02.1438699562 SHA256E-s1673--47562fe25853fe2972678cbaa1ef8e03bad068095d9f8575ba96f8df0a18cff0.jpeg
-    Aug 04 10:46:02.1438699562 ^M              0   0%    0.00kB/s    0:00:00  ^M          1,673 100%    1.60MB/s    0:00:00 (xfr#1, to-chk=0/1)
-    Aug 04 10:46:03.1438699563 ok
-    Aug 04 10:46:03.1438699563 get stimulus/task002/generate/part_1-182x121/000254.jpeg (from origin...)
-    Aug 04 10:46:03.1438699563 SHA256E-s1675--a3dae03d805040af4a7341479b782342431ee5377713c061e02daa075d188037.jpeg
-    Aug 04 10:46:03.1438699563 ^M              0   0%    0.00kB/s    0:00:00  ^M          1,675 100%    1.60MB/s    0:00:00 (xfr#1, to-chk=0/1)
-    Aug 04 10:46:03.1438699563 ok
-    Aug 04 10:46:03.1438699563 get stimulus/task002/generate/part_1-182x121/000255.jpeg (from origin...)
-    Aug 04 10:46:03.1438699563 SHA256E-s1674--a6743261238a87f9f3574295665896be2a8f373dd5b400fbf1552fb8d3b8fc66.jpeg
-    Aug 04 10:46:03.1438699563 ^M              0   0%    0.00kB/s    0:00:00  ^M          1,674 100%    1.60MB/s    0:00:00 (xfr#1, to-chk=0/1)
-    Aug 04 10:46:04.1438699564 ok
-    Aug 04 10:46:04.1438699564 get stimulus/task002/generate/part_1-182x121/000256.jpeg (from origin...)
-    Aug 04 10:46:04.1438699564 SHA256E-s1659--e1bd4829f53b226ad62ebccfbbb1a132d977af930545ade4161b5f9acf2e80b1.jpeg
-    Aug 04 10:46:04.1438699564 ^M              0   0%    0.00kB/s    0:00:00  ^M          1,659 100%    1.58MB/s    0:00:00 (xfr#1, to-chk=0/1)
-    Aug 04 10:46:04.1438699564 ok
-    Aug 04 10:46:04.1438699564 get stimulus/task002/generate/part_1-182x121/000257.jpeg (from origin...)
-    Aug 04 10:46:04.1438699564 SHA256E-s1663--ae0e673c60dede66c773441ee198fa8979c6de4a169e468fbb10dc22860afb27.jpeg
-    Aug 04 10:46:04.1438699564 ^M              0   0%    0.00kB/s    0:00:00  ^M          1,663 100%    1.59MB/s    0:00:00 (xfr#1, to-chk=0/1)
-    Aug 04 10:46:05.1438699565 ok  
-
-
-
-both hosts do not show any high CPU load
-
-> [[closed|done]]; wrung out all the perf gains we can without
-> [[accellerate_ssh_remotes_with_git-annex-shell_mass_protocol]] --[[Joey]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_10_c2d87b07f8197003b9489a8124680b59._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_10_c2d87b07f8197003b9489a8124680b59._comment
deleted file mode 100644
index 381bed86fb..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_10_c2d87b07f8197003b9489a8124680b59._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 10"""
- date="2018-03-06T18:47:34Z"
- content="""
-See [[accellerate_ssh_remotes_with_git-annex-shell_mass_protocol]].
-I'm going to close this todo in favor of that one.
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_1_3c92115f8162ba81149949d4c810bf43._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_1_3c92115f8162ba81149949d4c810bf43._comment
deleted file mode 100644
index 10d34d3039..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_1_3c92115f8162ba81149949d4c810bf43._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
- subject="comment 1"
- date="2015-08-04T15:00:02Z"
- content="""
-doh -- and apparently I had some aged annex -- git-annex version: 5.20141125, but even with a freshier   5.20150706+gitgefc3bcd-1~ndall+1  situation is the same
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_2_7605d67785288e5945999ca6b677c579._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_2_7605d67785288e5945999ca6b677c579._comment
deleted file mode 100644
index 26d2c4ec59..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_2_7605d67785288e5945999ca6b677c579._comment
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
- subject="comment 2"
- date="2015-08-04T15:28:29Z"
- content="""
-since I am not sure what is the actual overhead here, can't provide any good advice, but may be it is worth looking at least into bundling multiple transfers within the same rsync call?  rsync man page says
-
-       The syntax for requesting multiple files from a remote host is done by specifying
-       additional remote-host args in the same style as the  first,  or
-       with the hostname omitted.  For instance, all these work:
-
-              rsync -av host:file1 :file2 host:file{3,4} /dest/
-
-so it should be quite possible to batch a hundred or two transfers into the same rsync call I guess.  Probably on other systems limit is different but on linux the cmdline size is quite hefty:
-
-    $> xargs --show-limits
-    Your environment variables take up 3441 bytes
-    POSIX upper limit on argument length (this system): 2091663
-    POSIX smallest allowable upper limit on argument length (all systems): 4096
-    Maximum length of command we could actually use: 2088222
-    Size of command buffer we are actually using: 131072
-
-not sure if there are inherent limits within ssh etc
-
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_3_15c4b941a4af8354fee3209c64e89e33._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_3_15c4b941a4af8354fee3209c64e89e33._comment
deleted file mode 100644
index d8a85006cd..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_3_15c4b941a4af8354fee3209c64e89e33._comment
+++ /dev/null
@@ -1,56 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-08-04T16:07:23Z"
- content="""
-I don't know how you used ts to get that output, but it does not appear to
-be accurate. Here's `git annex get | ts "%b %d %H:%M:%.s"`:
-
-	Aug 04 12:10:1438704612.238164 get bob (from origin...) 
-	Aug 04 12:10:1438704612.238336 SHA256E-s30--7c3722f359d8cfbc594e5dec6d7f096bf4e88adbfb786548a607708d32ef49bb
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	Aug 04 12:10:1438704612.597912 ok
-	Aug 04 12:10:1438704612.642574 get bob2 (from origin...) 
-	Aug 04 12:10:1438704612.642653 SHA256E-s30--22fdcad0fba3537a7a0bc2b824f805fdd2d2c032b6450352cb8d099d03c8d796
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	Aug 04 12:10:1438704613.001088 ok
-	Aug 04 12:10:1438704613.043018 get bob3 (from origin...) 
-	Aug 04 12:10:1438704613.043105 SHA256E-s30--9f0e99611fe904e173fb1c81d57ba9f01a111afdf222a7763844c7b893af86ff
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	Aug 04 12:10:1438704613.393817 ok
-	Aug 04 12:10:1438704613.421080 get bob5 (from origin...) 
-	Aug 04 12:10:1438704613.421198 SHA256E-s30--7b851aa7791136f783271c109c287614bf2c0e9014d0fab50b1bf32f4ad4678e
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	Aug 04 12:10:1438704613.769410 ok
-	Aug 04 12:10:1438704613.800044 get bob6 (from origin...) 
-	Aug 04 12:10:1438704613.800133 SHA256E-s33--a165803131075f75132f632a6f295b12910f84a5d1776b60d1d998b96a6f20d5
-	             33 100%   32.23kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	Aug 04 12:10:1438704614.148597 ok
-	Aug 04 12:10:1438704614.200786 get bob7 (from origin...) 
-	Aug 04 12:10:1438704614.200881 SHA256E-s30--8b5b0b239b465a407ca98c8dc82a0081ee5ced4f7402854dc9afac75b65b5b51
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	Aug 04 12:10:1438704614.560315 ok
-	Aug 04 12:10:1438704614.602174 get bob8 (from origin...) 
-	Aug 04 12:10:1438704614.602255 SHA256E-s30--70657536d54051bd020f984f866b017d5919b7705bf08ffa2786c0dd14f90280
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	Aug 04 12:10:1438704614.961264 ok
-
-Note that this shows up to 3 files sent per second. The output you pasted shows not 1 file/s, but 2 or almost 3.
-
-There are no 1s (or other) sleeps. This is quite likely simply the overhead of
-git-annex needing to query git to work out what remote each file is located on,
-coupled with the overhead of needing to start a new git-annex-shell and rsync
-processes.
-
-Using -J4 or so will speed this up quite a lot.
-
-Without -J4:
-
-	0.22user 0.09system 0:04.84elapsed 6%CPU (0avgtext+0avgdata 33644maxresident)k
-	0inputs+832outputs (0major+16191minor)pagefaults 0swaps
-
-With -J4:
-
-	0.34user 0.06system 0:01.35elapsed 30%CPU (0avgtext+0avgdata 35996maxresident)k
-	0inputs+752outputs (0major+17451minor)pagefaults 0swaps
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_4_2669ce8914d75eda225607d4d0b45ab0._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_4_2669ce8914d75eda225607d4d0b45ab0._comment
deleted file mode 100644
index e6c16db6d6..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_4_2669ce8914d75eda225607d4d0b45ab0._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
- subject="my bad"
- date="2015-08-05T02:33:46Z"
- content="""
-indeed my use of ts timestamp was somewhat incorrect ;), I have used ts \"%b %d %H:%M:%S.%s\"
-
-\" This is quite likely simply the overhead of git-annex needing to query git to work out what remote each file is located on\" -- unlikely since CPU utilization is close to none.
-
-\"coupled with the overhead of needing to start a new git-annex-shell and rsync processes\" -- that is the likely major part of the overhead here 
-
--J is indeed of notable help BUT overall disproportionate to mitigate the overhead at large.  I seem can successfully raise it to -J 4. With -J 6 I already start getting \"E: channel 22: open failed: administratively prohibited: open failed\" from time to time (not sure if it is benign or results in that particular transfer not succeeding). Not quite sure on the exact reason for it, i.e. why server side refuses to open a new channel -- I guess because of the same issue of too quickly following requests for new connections (i.e. \"the overhead\").
-  
-Why transfer requests could not be queued up and batched for execution within the same ssh invocation?  Keys are unique, so could be received within the same tmp/ in a batch transfer and then sorted into their corresponding hash subdirs.   Bundled with -J to possibly even split among multiple source remotes from which different content could be available from it could lead to greatly improved transfer rates.  Or would it be a major undertaking?
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_5_fca151591d0c6c75013711cb5de81d47._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_5_fca151591d0c6c75013711cb5de81d47._comment
deleted file mode 100644
index a7130ea749..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_5_fca151591d0c6c75013711cb5de81d47._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2015-08-11T17:27:23Z"
- content="""
-AFAIK, it's not possible to run multiple separate rsync transfers over a single
-connection; rsync closes the connection after a transfer is complete (and
-the rsync protocol is nowhere documented, and has only one implementation
-so there's no way to avoid this behavior). 
-
-So, rsync would need to be told a whole list of files to transfer in one go,
-which poses many difficulties, including for git-annex's progress display,
-and for needing to queue up a set of files when eg `git annex get` is picking
-which ones to get.
-
-I'd want to see a lot more measurements of where bottlenecks are in
-the current system, before seriously considering such a thing.
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_6_8f9a3dd1c021b862f97934b6b25f6aa9._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_6_8f9a3dd1c021b862f97934b6b25f6aa9._comment
deleted file mode 100644
index 009a21af07..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_6_8f9a3dd1c021b862f97934b6b25f6aa9._comment
+++ /dev/null
@@ -1,79 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""measure twice, cut once"""
- date="2015-08-13T17:22:17Z"
- content="""
-Debug output has been enhanced with fractional seconds and also shows when
-a command exits so the time spent in a command can be determined.
-
-	[2015-08-13 13:54:29.578099] process done ExitSuccess
-	ok
-	get ook8 (from origin...) 
-	[2015-08-13 13:54:29.588827] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/localhost' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'localhost' 'git-annex-shell ''sendkey'' ''/home/joey/tmp/r'' ''SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128'' --uuid ba2a51f9-f356-40a7-9600-2ac4193c7d58 ''--'' ''remoteuuid=72078ee3-1150-45f0-b00e-53e971921982'' ''direct='' ''associatedfile=ook8'' ''--'''","--","dummy:",".git/annex/tmp/SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128"]
-	SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	[2015-08-13 13:54:29.635771] transferinfo starting up
-	[2015-08-13 13:54:29.636097] feed: ssh ["-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","localhost","git-annex-shell 'transferinfo' '/home/joey/tmp/r' 'SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128' --uuid ba2a51f9-f356-40a7-9600-2ac4193c7d58 '--' 'remoteuuid=72078ee3-1150-45f0-b00e-53e971921982' 'associatedfile=ook8' '--'"]
-	[2015-08-13 13:54:29.656803] process done ExitSuccess
-	[2015-08-13 13:54:29.657487] transferinfo shutting down
-	[2015-08-13 13:54:29.987744] process done ExitSuccess
-	ok
-
-Here we can see:
-
-1. 0.409645s -- total time spent on this one file (12 files took 4.124s overall)
-2. 0.010728s -- is spent in between finishing one file and
-   starting the transfer of the next. This includes updating location
-   tracking, figuring out what the next file that needs transfer is 
-   (in this case the very next one in the work tree), and other bookkeeping.
-3. 0.067976s -- The rsync transfer of one (small) file, including ssh and
-   git-annex-shell overhead. It would be good to get this part broken down
-   in more detail.
-4. 0.330941 -- This is pure overhead involved in shutting down the
-   transferinfo process. Yikes!
-
-So, that transferinfo is the unexpected meat of the time. Since all
-that does it open another ssh connection back to the remote and tell git-annex-shell
-the progress of the download, for git-annex status or the assistant to display,
-that's really not a justifyable overhead.
-
-Here it is without the transferinfo being done:
-
-	[2015-08-13 13:49:26.860914] process done ExitSuccess
-	ok
-	get ook8 (from origin...) 
-	[2015-08-13 13:49:26.865482] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/localhost' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'localhost' 'git-annex-shell ''sendkey'' ''/home/joey/tmp/r'' ''SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128'' --uuid ba2a51f9-f356-40a7-9600-2ac4193c7d58 ''--'' ''remoteuuid=72078ee3-1150-45f0-b00e-53e971921982'' ''direct='' ''associatedfile=ook8'' ''--'''","--","dummy:",".git/annex/tmp/SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128"]
-	SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	[2015-08-13 13:49:26.926932] process done ExitSuccess
-	ok
-
-1. 0.066018s -- massive improvement! (12 files took 0.885s overall)
-2. 0.004568s -- Weird that this is half what it was before. I have made enough
-   measurements that I'm pretty sure it is, consistently lower though. Maybe
-   this time reduced because avoiding the transferinfo means less threads and/or
-   less garbage collection time.
-3. 0.061450s -- Much as before, so the concurrent ssh connection made
-   for transferinfo doesn't slow down the rsync appreciably.
-
-So, I made it spin off a new thread to do the transferinfo cleanup.
-This one word change to the code performs almost as well as eliminating
-transferinfo entirely did!
-
-	[2015-08-13 14:11:10.275867] process done ExitSuccess
-	[2015-08-13 14:11:10.276359] transferinfo shutting down
-	ok
-	get ook8 (from origin...) 
-	[2015-08-13 14:11:10.282027] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/localhost' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'localhost' 'git-annex-shell ''sendkey'' ''/home/joey/tmp/r'' ''SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128'' --uuid ba2a51f9-f356-40a7-9600-2ac4193c7d58 ''--'' ''remoteuuid=72078ee3-1150-45f0-b00e-53e971921982'' ''direct='' ''associatedfile=ook8'' ''--'''","--","dummy:",".git/annex/tmp/SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128"]
-	SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128
-	             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
-	[2015-08-13 14:11:10.324395] transferinfo starting up
-	[2015-08-13 14:11:10.324624] feed: ssh ["-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","localhost","git-annex-shell 'transferinfo' '/home/joey/tmp/r' 'SHA256E-s30--fc394d2854169d3a85b7ffda59f30b797e915fd98368c30d11588df7a20ee128' --uuid ba2a51f9-f356-40a7-9600-2ac4193c7d58 '--' 'remoteuuid=72078ee3-1150-45f0-b00e-53e971921982' 'associatedfile=ook8' '--'"]
-	[2015-08-13 14:11:10.34482] process done ExitSuccess
-
-1. 0.068953s -- nearly as good as eliminating transferinfo (12 files took 0.925s overall)
-2. 0.006160 -- little bit higher, perhaps this is thread or GC overhead
-3. 0.062793 -- much as before (possibly slowed a tiny bit by the extra ssh traffic)
-
-Now, with -J4, all 12 files transfer in 0.661s.
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_7_3161719c0e2a72cdc44d7c7263c44ed9._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_7_3161719c0e2a72cdc44d7c7263c44ed9._comment
deleted file mode 100644
index 09082f3368..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_7_3161719c0e2a72cdc44d7c7263c44ed9._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 7"""
- date="2015-08-13T18:27:35Z"
- content="""
-I've made --debug be passed along to git-annex-shell, so here's a more
-detailed view:
-
-	[2015-08-13 15:29:05.183231] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/localhost' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'localhost' 'git-annex-shell ''sendkey'' ''/home/joey/tmp/r'' ''--debug'' ''SHA256E-s30--6b1bd2aa19d658de59c3a5a1eb239cefb87bdfa0f9b64d1a670d88c211972c0d'' --uuid ba2a51f9-f356-40a7-9600-2ac4193c7d58 ''--'' ''remoteuuid=72078ee3-1150-45f0-b00e-53e971921982'' ''direct='' ''associatedfile=ook2'' ''--'''","--","dummy:",".git/annex/tmp/SHA256E-s30--6b1bd2aa19d658de59c3a5a1eb239cefb87bdfa0f9b64d1a670d88c211972c0d"]
-	[2015-08-13 15:29:05.219572] transfer start
-	[2015-08-13 15:29:05.221625] call: rsync ["--server","-t","--inplace","-e.Lsf",".","--sender","tmp/r/.git/annex/objects/wX/k9/SHA256E-s30--6b1bd2aa19d658de59c3a5a1eb239cefb87bdfa0f9b64d1a670d88c211972c0d/SHA256E-s30--6b1bd2aa19d658de59c3a5a1eb239cefb87bdfa0f9b64d1a670d88c211972c0d"]
-	[2015-08-13 15:29:05.226709] process done ExitSuccess # rsync server
-	[2015-08-13 15:29:05.22709] transfer done
-	[2015-08-13 15:29:05.247464] process done ExitSuccess # rsync client
-
-1. 0.036341s -- starting local rsync, ssh connection (using mux), and git-annex-shell startup to the point it parses parameters and can start
-   printing debug messages
-2. 0.002053s -- time git-annex-shell spends starting transfer (locking file, etc)
-3. 0.005084s -- actual file transfer time (including rsync server startup)
-4. 0.000381s -- git-annex-shell shutdown time
-5. 0.020374s -- time from when git-annex-shell exits until the local rsync exits.  
-   This must consist of rsync writing the file, the ssh connection shutdown, and rsync shutdown. 
-   I don't know in what porportions, except that writing the file is only a very small part of it.
-
-So, over 25000 files, I'd estimate the newly optimised git-annex to take
-around 28 minutes here (unoptimized would have taken 171 minutes).
-The rough time breakdown is:
-
-* 15 minutes is needed to start the rsync clients, ssh connections, git-annex-shell processes
-* 9 minutes more overhead seems to be involved in shutting down those 
-  connections
-* 1 minute is used by git-annex-shell to do locking, etc
-* 2 minutes is used by git-annex to find files to transfer, update location logs, etc
-* 1 minute is used by rsync server to start running and send the files (assuming very small files and fast network)
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_8_0209467fbfb83b4b5aace9767179b7ab._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_8_0209467fbfb83b4b5aace9767179b7ab._comment
deleted file mode 100644
index a3175b2199..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_8_0209467fbfb83b4b5aace9767179b7ab._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- subject="great!"
- date="2015-08-17T04:07:28Z"
- content="""
-it's great to see such improvements! i was wondering if git-annex was slower than an equivalent rsync transfer... 
-
-how does git-annex compare with rsync now?
-
-how should we decide how many -J we should use? are there good heuristics on that?
-
-should this todo be marked as done?
-"""]]
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_9_88dbe6602f273b7600776228ec099955._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_9_88dbe6602f273b7600776228ec099955._comment
deleted file mode 100644
index ae4e77279b..0000000000
--- a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_9_88dbe6602f273b7600776228ec099955._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 9"""
- date="2018-03-06T17:29:16Z"
- content="""
-I think that any further improvements here would need to be a fundamental 
-change, rather than shaving away fractions of a second from the above
-benchmarks. Most of the remaining overhead seems to be outside of
-git-annex's own code.
-
-I think it could use sftp, rather than rsync, when git-annex does not
-need to resume transfer of a file. git-annex could keep sftp running, and
-ask it for each file in turn, and avoid all the connection overheads.
-"""]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__.mdwn b/doc/todo/split_off_clean__47__smudge_filter__63__.mdwn
deleted file mode 100644
index c568d9b466..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-If running the clean/smudge filter once per file is a [[bottleneck|forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase]], might it speed things up to split them off into something more lightweight than the full git-annex binary?
-
-> This is a duplicate of stuff discussed at
-> [[todo/git_smudge_clean_interface_suboptiomal]], so closing. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_1_e365d5374ca46114149c30d4dbe60148._comment b/doc/todo/split_off_clean__47__smudge_filter__63__/comment_1_e365d5374ca46114149c30d4dbe60148._comment
deleted file mode 100644
index c47b3a5029..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_1_e365d5374ca46114149c30d4dbe60148._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="git-annex REST API"
- date="2019-09-18T22:55:06Z"
- content="""
-Even better would be if git-annex had a \"server\" mode where one git-annex process runs and exposes a REST API for invoking git-annex commands (cf. [[todo/universal_batch_mode]]; something like [this](https://cromwell.readthedocs.io/en/stable/api/RESTAPI/)).  Then the clean and smudge filters could be lightweight scripts that just call curl.
-"""]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_2_871a198d8ababf5f554607208c00bdb8._comment b/doc/todo/split_off_clean__47__smudge_filter__63__/comment_2_871a198d8ababf5f554607208c00bdb8._comment
deleted file mode 100644
index 98a8c0e407..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_2_871a198d8ababf5f554607208c00bdb8._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 2"
- date="2019-09-20T15:58:08Z"
- content="""
-In general, does `git-annex` (or packages it uses) keep global state, or is everything purely functional?  (Trying to understand if adding a \"git-annex server\" mode that spawns lightweight threads to run git-annex commands in response to requests is even theoretically possible).
-"""]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_3_568ca39690bef083189ad158553683d3._comment b/doc/todo/split_off_clean__47__smudge_filter__63__/comment_3_568ca39690bef083189ad158553683d3._comment
deleted file mode 100644
index 6564e5291c..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_3_568ca39690bef083189ad158553683d3._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2019-09-20T16:13:39Z"
- content="""
-What is your evidence that the size of the git-annex
-executable has anything to do with that?
-
-I hope you're aware that linux does not load entire programs into memory
-before running them. It mmaps them and loads pages on demand. (I assume
-most other modern OS's do similar things.)
-
-It's easy to build a significantly smaller git-annex, just disable
-the assistant build flag, and you should get a binary around 30mb rather
-than 60mb. I'll wager you do not find any statistically significant
-differences in the performance of such a build of git-annex with one
-containing the assistant.
-"""]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_4_dbfb6deef8956c4b71cc30c0019d0bb5._comment b/doc/todo/split_off_clean__47__smudge_filter__63__/comment_4_dbfb6deef8956c4b71cc30c0019d0bb5._comment
deleted file mode 100644
index 3d8be7f785..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_4_dbfb6deef8956c4b71cc30c0019d0bb5._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2019-09-20T16:50:24Z"
- content="""
-git-annex isolates all runtime state in its Annex monad. This
-makes it easy to have multiple threads each with their own isolated state,
-which is how all its concurrency features work.
-"""]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_5_0d22b900fad406c0bc144de146e2668d._comment b/doc/todo/split_off_clean__47__smudge_filter__63__/comment_5_0d22b900fad406c0bc144de146e2668d._comment
deleted file mode 100644
index 098a023f9a..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_5_0d22b900fad406c0bc144de146e2668d._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2019-09-20T16:51:56Z"
- content="""
-This is not to say that the idea of having a longer-running git-annex
-process that responds to all git's smudge/clean is a bad idea. Each new
-invokation of git-annex has to re-open databases, start up git cat-file
-to query from, link the executable, read git config, etc. That takes a
-few hundred milliseconds.
-
-The best way to get a longer-running git-annex process for smudge/clean
-would be to use git's long-running filter process interface. But that
-interface currently feeds the entire content of large files through a pipe
-to the git-annex process, which *very* innefficient. So git-annex doesn't
-use that interface. Improving the interface to let the clean filter read
-the content of the file itself, rather than it being piped through,
-would be the best way to improve `git add` performance.
-[[todo/git_smudge_clean_interface_suboptiomal]] does discuss this.
-"""]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_6_9e656e32ff2090aede8f403cb915e059._comment b/doc/todo/split_off_clean__47__smudge_filter__63__/comment_6_9e656e32ff2090aede8f403cb915e059._comment
deleted file mode 100644
index 469156b95e..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_6_9e656e32ff2090aede8f403cb915e059._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 6"
- date="2019-09-20T20:41:25Z"
- content="""
-\" Improving the interface to let the clean filter read the content of the file itself, rather than it being piped through, would be the best way to improve git add performance\" -- right, but that sounds unlikely near-term?
-"""]]
diff --git a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_7_9817fd2cbb46c97124cd35a7a2a9c4bd._comment b/doc/todo/split_off_clean__47__smudge_filter__63__/comment_7_9817fd2cbb46c97124cd35a7a2a9c4bd._comment
deleted file mode 100644
index 1b05c62bac..0000000000
--- a/doc/todo/split_off_clean__47__smudge_filter__63__/comment_7_9817fd2cbb46c97124cd35a7a2a9c4bd._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="limiting clean/smudge filter to unlocked files"
- date="2019-11-08T19:48:11Z"
- content="""
-\"Each new invokation of git-annex has to re-open databases, start up git cat-file to query from, link the executable, read git config, etc. That takes a few hundred milliseconds.\" -- this is somewhat more of an issue now that all `git add/checkout` operations call the clean/smudge filter, even when there are no unlocked files.  One option is to [[only configure the filters for unlocked files|todo/only_pass_unlocked_files_through_the_clean__47__smudge_filter]] when only a few files are unlocked.
-"""]]
diff --git a/doc/todo/stop_using_curl_and_wget.mdwn b/doc/todo/stop_using_curl_and_wget.mdwn
deleted file mode 100644
index 6de3c527b4..0000000000
--- a/doc/todo/stop_using_curl_and_wget.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-Currently git-annex uses wget and curl for downloading urls.
-Which is used depends on the situation, since both have their limitations
-and quirks.
-
-This often confuses users, who expect annex.web-options to only apply
-to whichever program git-annex was running, and put in an option that
-breaks the other program. Or, configure a netrc file, which wget uses by
-default, but curl does not.
-
-Also, using these external programs avoids keeping a http connection open
-and pipelining requests, so it makes mass url downloads a lot slower than
-if git-annex used http-conduit to do url downloads itself. [[users/yoh]]
-has requested http pipelining.
-
-(git-annex was creating a new http manager each time it hit an url,
-except for in the S3 remote which reused a single manager. That's now been
-improved, so all http-conduit use in git-annex reuses a http manager, and
-so will do http pipelining.)
-
-For file: ftp: and more unusual urls, http-conduit can't support them.
-git-annex does support those urls, and people rely on that, so it would
-still need to use wget or curl for those.
-
-wget is also not shipped with git-annex on Windows or OSX, only curl is,
-and it would be good to only use one of the programs, not both, when
-handing those unusual urls.
-
-See also, [[support_.netrc_for_fsck_--from_web]]. That some users rely on
-git-annex using wget and a netrc file is kind of problimatic if switching
-to http-conduit which does not support it. Maybe require users to set
-`annex.web-download-command` if they want to make it use something that
-supports netrc?
-
---[[Joey]]
-
-> Implemented Utility.Url.downloadC that is the (nontrivial)
-> download a file with resume support using http-conduit.
-> It falls back to curl to handle urls that http-conduit does not support.
-> Now we only have to decide what to do about the above edge cases..
-
-> > Let's drop use of wget entirely, as it was only using it because I
-> > preferred wget's progress bar to curl's. The user can still force wget
-> > with annex.web-download-command.
-> >
-> > That leaves users who have a .netrc file or want to use
-> > annex.web-options. Since curl requires --netrc in order to use the
-> > .netrc file, require users who want to use the .netrc to
-> > set "annex.web-options = --netrc". When "annex.web-options" is
-> > set, always use curl (unless overridden by annex.web-download-command).
-> > Otherwise, use conduit.
-
-[[done]] --[[Joey]]
diff --git a/doc/todo/stop_using_curl_and_wget/comment_1_c1ac05dc1969b64f08f717667cda0240._comment b/doc/todo/stop_using_curl_and_wget/comment_1_c1ac05dc1969b64f08f717667cda0240._comment
deleted file mode 100644
index a341358cd7..0000000000
--- a/doc/todo/stop_using_curl_and_wget/comment_1_c1ac05dc1969b64f08f717667cda0240._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
- subject="comment 1"
- date="2018-05-17T20:15:13Z"
- content="""
-Just as a cross-reference, this may have broken downloads in some cases, where [addurl results in a different file to wget](https://git-annex.branchable.com/bugs/addurl_results_in_different_file_to_wget), seemingly because it is being decompressedon-the-fly by the http library.
-"""]]
diff --git a/doc/todo/stream_feature__63__.mdwn b/doc/todo/stream_feature__63__.mdwn
deleted file mode 100644
index cbea0bbf72..0000000000
--- a/doc/todo/stream_feature__63__.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-I am just asking myself, is it stupid to think that streaming in git annex would be a good idea and wouldnt it be totaly easy to implement?
-
-Ok just tried to link to files over ssh, it creates a link but you cant open with it its content ^^
-
-But at least the files you have access over some filesystem as example samba/sshfs or just a other directory or usb-drive you could stream instead of "get"
-
-you could add another mode like direct and indirect, like symbolic-links or something like that?
-
-Sadly linux is to stupid to allow direct ssh links ( thats maybe one of the biggest features hurd has over linux  ) but you could mount with sshfs readonly (checking first if sshfs is installed) to mount the files there and then map the links there.
-
-ok I am not so shure how hard it would be and how much bug potentials it creates, but it would be great I guess.
-
-git annex is a bit like a telephone book, where you get a list of where the targets are. So using it to call the persons so that they drive to you to talk with you is nice. But I think the better feature would be if you just talk with the guy over the telephone directly bevore he comes to you (streaming)
-
-I mean you did one great thing, you did make cloudy thing peer to peer, like git is targeted too but for smaller files, yes there are may use cases without this feature, but I would be really glad if it could do that too, if I give annex 5 locations on other pcs usb-sticks etc, I find it stupid to additionaly do setup all this sources again a second time for streaming, and then I have maybe even 2 different file names because you map stuff in git.
-
-So sorry its late here, I am a bit tired so I maybe dont know what I am talking right now, my english isnt the best, too, but I think it would be a great feature.
-
-I mean on your setup, with slow internet, you maybe always make a get command, but here, if I link to youtube, I have no problem to stream it, or even on internal network between my pcs I have gb-lan, I start directly movies streaming, I would only use get, in rare cases where I need them on a train, the normal thing is to stream stuff.
-
-So I have to go sleep now 
-
-bye
-
-> I think that `git annex inprogress` is kind of what you were looking for.
-> [[done]] --[[Joey]]
diff --git a/doc/todo/stream_feature__63__/comment_1_99f1f1872f86d4571c03a99fff1a7212._comment b/doc/todo/stream_feature__63__/comment_1_99f1f1872f86d4571c03a99fff1a7212._comment
deleted file mode 100644
index 82b43335fd..0000000000
--- a/doc/todo/stream_feature__63__/comment_1_99f1f1872f86d4571c03a99fff1a7212._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
- nickname="Stefan"
- subject="did I wrote this suggestion"
- date="2015-02-11T17:25:52Z"
- content="""
-thought about that feature just now and found this feature request here, just wonder if I wrote it, sounds a bit like me. If not I add a +1 to it :)
-"""]]
diff --git a/doc/todo/support_.netrc_for_fsck_--from_web.mdwn b/doc/todo/support_.netrc_for_fsck_--from_web.mdwn
deleted file mode 100644
index fca0bd4e34..0000000000
--- a/doc/todo/support_.netrc_for_fsck_--from_web.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-On my computer, `git annex get filename --from web` uses wget which does support
-.netrc, but for some reason `git annex fsck filename --from web` does not.
-Instead, I get a message that the content is missing and git annex is "fixing
-location log" (slightly unrelated question, but is there any way to stop it from
-doing this? Just because a URL isn't accessible now, doesn't mean it's content
-is gone permanently).
-
-I do not want to encode my credentials into the URLs (eg.
-username:password@example.com) because my password changes frequently and I would
-have to update all of the URLs.
-
-> git-annex 6.20180406 and onwards use http-conduit for everything
-> by default. To use the .netrc file, run:
-
-	git config annex.web-options --netrc
-
-> That will make git-annex use curl for all web accesses, and configures
-> curl to use your netrc file. [[done]] --[[Joey]] 
diff --git a/doc/todo/support_.netrc_for_fsck_--from_web/comment_1_27fc7996be9cbff994fb19b0e213f28b._comment b/doc/todo/support_.netrc_for_fsck_--from_web/comment_1_27fc7996be9cbff994fb19b0e213f28b._comment
deleted file mode 100644
index 7dfb25da97..0000000000
--- a/doc/todo/support_.netrc_for_fsck_--from_web/comment_1_27fc7996be9cbff994fb19b0e213f28b._comment
+++ /dev/null
@@ -1,29 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-01-15T17:12:43Z"
- content="""
-This is complicated because git-annex uses wget, curl, and http-conduit at
-different times. wget always uses .netrc, curl only uses it with a --netrc
-option (which git-annex does not currently provide although the user can),
-and http-conduit does not support .netrc.
-
-The choices of which git-annex uses when are constrained by the limitations
-of all three, and were chosen to make it work as well as possible. Also,
-curl and wget are not available in all installations of git-annex.
-
-As far as I can see, `git annex fsck --from web` makes the same wget/curl
-choice as `git annex get --from web` will make, typically wget, but
-curl if wget is not available or if run with --quiet.
-
-However, `git annex fsck --fast --from web` uses http-conduit by default.
-It could be changed to default to using curl (wget is not an option there).
-
-But, I'm kind of inclined toward moving away from using wget/curl at all,
-and toward http-conduit for all http urls. Thus avoiding the
-inconsistencies and various annoying behaviors of wget/curl. So, making a
-change that requires .netrc be supported going forward needs to be
-considered in that light. One possibility would be to use
- to make netrc work with
-http-conduit.
-"""]]
diff --git a/doc/todo/support_.netrc_for_fsck_--from_web/comment_2_01b513a530e8887567aca0e187ad0f7e._comment b/doc/todo/support_.netrc_for_fsck_--from_web/comment_2_01b513a530e8887567aca0e187ad0f7e._comment
deleted file mode 100644
index 6542c5958f..0000000000
--- a/doc/todo/support_.netrc_for_fsck_--from_web/comment_2_01b513a530e8887567aca0e187ad0f7e._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="mbekkema97@66b135681014f005a3a14c4011d148fcb6655f81"
- nickname="mbekkema97"
- avatar="http://cdn.libravatar.org/avatar/a5037b8a5914bd9f803af7b7e881d632"
- subject="comment 2"
- date="2018-01-19T03:46:29Z"
- content="""
-That's strange, I was observing the process list and didn't see any instances of wget or curl. Could it be that `fsck` uses http-conduit to ping the URL before proceeding with the full check?
-"""]]
diff --git a/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol.mdwn b/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol.mdwn
deleted file mode 100644
index c00e4663a1..0000000000
--- a/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol.mdwn
+++ /dev/null
@@ -1,61 +0,0 @@
-git-annex-shell p2pstdio currently always verifies content it receives.
-git-annex-shell recvkey has a speed optimisation, when it's told the file
-being sent is locked, it can avoid an expensive verification, when
-annex.verify=false. (Similar for transfers in the other direction.)
-
-The P2P protocol does not have a way to communicate when that happens.
-File content can be modified while it's sent, and if annex.verify=false
-is allowed to take effect, bad data will get into the repository.
-
-It would be nice to support annex.verify=false when it's safe but not
-when the file got modified, but if it added an extra round trip
-to the P2P protocol, that could lose some of the speed gains.
-
-The way that git-annex-shell recvkey handles this is the client
-communicates to it if it's sending an unlocked file, which forces
-verification. Otherwise, verification can be skipped.
-
-Seems the best we could do with the P2P protocol, barring adding
-rsync-style rolling hashing to it, is to detect when a file got modified
-as it was being sent, and inform the peer that the data it got is invalid.
-It can then force verification.
-
-> [[done]] --[[Joey]]
-
-----
-
-A related problem is resumes. What if a file starts to be transferred,
-gets changed while it's transferred so some bad bytes are sent, then the
-transfer is interrupted, and later is resumed from a different remote
-that has the correct content. How can it tell that the bad data was sent
-in this case?
-
-In the case where an upload is started from one repository and later
-resumed by another, rsync wipes out any differences, so if the first
-repository was unlocked, and the second is locked, it's safe for recvkey to
-treat it locked and skip verification.
-
-This is not really unique to the P2P protocol -- special remotes
-can be written to support resuming. The web special remote does; there may
-be external special remotes that do too. While the content of a key on
-a special remote is not allowed to change, a download could start from
-an unlocked git repo, and then be resumed from such a special remote.
-When verification is disabled, this can result in bad content getting into
-the repository.
-
-So, let's solve this broadly. Whenever a download is resumed, force
-AlwaysVerify, unless the remote returns Verified. This can be done in
-Annex.Content.getViaTmp, so it will affect all downloads involving the tmp
-key for a file.
-
-> [[done]] --[[Joey]]
-
-This would change handling of resumes of downloads using rsync too.
-But those are always safe to skip verification of, although they don't
-quite do a full verification of the key's hash. To still allow disabling of
-verification of those, could add a third state in between UnVerified and
-Verified, that means it's sure it's gotten exactly the same bytes as are on
-the remote.
-
-> Decided this added too much complexity for such an edge case, so
-> skipped dealing with it. --[[Joey]]
diff --git a/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol/comment_1_70840f9fc06f2f111f89d5b6cf6ad7e0._comment b/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol/comment_1_70840f9fc06f2f111f89d5b6cf6ad7e0._comment
deleted file mode 100644
index a3346fa6a3..0000000000
--- a/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol/comment_1_70840f9fc06f2f111f89d5b6cf6ad7e0._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd"
- nickname="Anthony DeRobertis"
- avatar="http://cdn.libravatar.org/avatar/1007bfece547e9f2d86fafa142cd240a62456c37f104a9d96ba9db5bf18e1934"
- subject="How expensive is verification anyway?"
- date="2018-03-13T17:58:19Z"
- content="""
-A quick check with `openssl speed -evp sha256` (and `-evp sha512`) shows SHA-256 is ~210MB/sec and SHA-512 ~275MB/sec on my not that recent i7 930. I'm sure its more of an issue on embedded or phones... but there of course the network is often slower. If the hash is faster than the transfer, seems like it shouldn't really cause that much of a slowdown (unless I guess its competing with ssh for CPU time, but that seems unlikely on multi-core machines).
-
-I wonder if a easier way to speed it up wouldn't be to support BLAKE2 as a backend. Wouldn't help with existing hash keys, of course (without a migrate).
-"""]]
diff --git a/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol/comment_2_22831e802e6e4b6a95e1901699c11d09._comment b/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol/comment_2_22831e802e6e4b6a95e1901699c11d09._comment
deleted file mode 100644
index bef2c7c7e9..0000000000
--- a/doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol/comment_2_22831e802e6e4b6a95e1901699c11d09._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-03-13T19:10:38Z"
- content="""
-The hash speed is not really significant; re-reading the content of the
-file to hash it is the expensive part. At some point git-annex may gain the
-ability to do this on the fly as it's being downloaded and then the
-verification overhead would be negligible.
-
-Thanks for mentioning BLAKE2.. I've added support for it!
-"""]]
diff --git a/doc/todo/support_longer_file_extensions.mdwn b/doc/todo/support_longer_file_extensions.mdwn
deleted file mode 100644
index 338cf295d7..0000000000
--- a/doc/todo/support_longer_file_extensions.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-Current *E key-value backends support file extensions of length <=4.  Files with longer extensions (such as .fasta files common in bioinformatics) get linked to extension-less files, potentially causing hard-to-predict problems.  Simple fix is to add backends like MD5E5 which keeps extensions of length <=5 .   Better fix would be to keep the entire filename:
-file myfile.fasta becomes the symlink .git/annex/objects/xx/xx/key/myfile.fasta .  If there's anotherfile.fasta with the same key but different filename, it becomes a symlink to
-.git/annex/objects/xx/xx/key/anotherfile.fasta which is a hardlink to myfile.fasta . An added plus is that the symlinks checked into git typically becomes shorter. Or, for better backwards compatibility, the symlinks checked into git don't change, but
-.git/annex/objects/xx/xx/key/key becomes a symlink to .git/annex/objects/xx/xx/key/myfile.fasta .   However, if there is anotherfile.fasta with the same key, its symlink will still end up terminating at myfile.fasta rather than anotherfile.fasta .
-It's useful to preserve full filenames, because it's not uncommon to e.g. encode parameter information in filenames (myresult.threshold100.dat); and it's not uncommon to call something like python's os.path.realpath to unwind symlink chains before processing a file.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/support_longer_file_extensions/comment_1_c17fdd288b4912455f48d95b0bdc2390._comment b/doc/todo/support_longer_file_extensions/comment_1_c17fdd288b4912455f48d95b0bdc2390._comment
deleted file mode 100644
index d298c06d43..0000000000
--- a/doc/todo/support_longer_file_extensions/comment_1_c17fdd288b4912455f48d95b0bdc2390._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-09-24T15:45:07Z"
- content="""
-What you're suggesting with the full filenames is basically on the same
-level of complexity as direct mode or v6's unlocked files, which both avoid
-symlinks and so avoid problems with the rare program that looks at the
-extension of a symlink target, instead of the extension of the symlink.
-
-Doing something to allow longer extensions is maybe worth talking more
-about though. I am not very keen on adding a parameter to the backend name.
-
-The way git-annex picks extensions doesn't need to be stable across all
-versions of git-annex, because it's only done when initially adding a file,
-and then the key, with whatever extension, is added as-is and git-annex
-does not care about the extension thereafter. So, a
-configuration setting to pick the extension length, or something like that,
-would be possible to add.
-"""]]
diff --git a/doc/todo/support_longer_file_extensions/comment_2_a01fbe5b4f72989532051f5e1bb55104._comment b/doc/todo/support_longer_file_extensions/comment_2_a01fbe5b4f72989532051f5e1bb55104._comment
deleted file mode 100644
index 541dd24a35..0000000000
--- a/doc/todo/support_longer_file_extensions/comment_2_a01fbe5b4f72989532051f5e1bb55104._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-09-24T15:50:47Z"
- content="""
-Added annex.maxextensionlength configuration.
-"""]]
diff --git a/doc/todo/support_longer_file_extensions/comment_3_4408f1bd38527b2fd83a31a904aaca95._comment b/doc/todo/support_longer_file_extensions/comment_3_4408f1bd38527b2fd83a31a904aaca95._comment
deleted file mode 100644
index a4e49c8b02..0000000000
--- a/doc/todo/support_longer_file_extensions/comment_3_4408f1bd38527b2fd83a31a904aaca95._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 3"
- date="2018-09-24T18:50:46Z"
- content="""
-thanks a lot!
-
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid.mdwn b/doc/todo/support_multiple_special_remotes_with_same_uuid.mdwn
deleted file mode 100644
index 785c294632..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-If the same data storage can be accessed via two protocols, two different
-special remotes could be configured that access the same data, and so
-should have the same uuids.
-
-This is not possible though, because remote.log is uuid-based and so
-the special remote configs stored in it for a given uuid would apply to
-both special remotes.
-
-It is already possible of course for two git remotes to have the same uuid,
-and also for a special remote and git remotes to have the same uuid.
-
-----
-
-One approach would be to add some kind of namespace to the configs in
-remote.log. But this seems problematic, the user would need to juggle
-remote names and namespaces.
-
-Another approach is to have a way to make two uuids be treated as
-equivilant. Eg, to make uuid B be treated the same as uuid A. 
-
-Suppose there's an equivilance.log that contains "ts B A". Then when git
-config is read, a remote with uuid B will result in constuction of a
-`Remote` with uuid A, but with the `RemoteConfig` of uuid B.
-
-Seems like this would be the only place the equivilance.log would need to
-be used, once the `Remote` is constucted using the equivilant uuid the rest
-of the code will work as-is.
-
-That would add overhead of an additional git-annex branch read on every
-program start. That could be avoided by instead putting the equivilance in
-the remote.log. Eg, "B sameas=A foo=bar ..."
-
-> [[done]]; this is implemented as `git annex initremote --sameas`
-> --[[Joey]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_10_c40d002cdc478321dc93c3a02a9bcf17._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_10_c40d002cdc478321dc93c3a02a9bcf17._comment
deleted file mode 100644
index db201dc7b8..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_10_c40d002cdc478321dc93c3a02a9bcf17._comment
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 10"""
- date="2019-10-08T15:25:05Z"
- content="""
-It might be possible to isolate the sameas changes only to things
-involving the location log. Use different uuids for sameas
-remotes. When updating the location log, substitute the sameas uuid.
-
-There would need to be a sameas-aware way to check if a uuid is in the
-location log. Currently, loggedLocations is used to both see what remotes
-to try to get a key from, and for numcopies checking and related stuff
-(like skipping dropping entirely when loggedLocations does not have enough
-items in it). So there would need to be two variants of it. That seems
-likely to be a source of mistakes.
-
-Another small problem with this idea is that a special remote may record
-its uuid somehow in the data store and check that it has the right uuid
-later (S3 does this with an "annex-uuid" in the bucket), and if two remotes
-with different uuids did that, there would be a conflict between them.
-
-Also, it couldn't only be the location log; sameas mapping would also need
-to be done when using the chunk log. And a bit of encryption config
-inheritance would still be needed.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_11_35e79b18923ef1c8cb8473b849262955._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_11_35e79b18923ef1c8cb8473b849262955._comment
deleted file mode 100644
index 975d64070b..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_11_35e79b18923ef1c8cb8473b849262955._comment
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 11"""
- date="2019-10-10T15:49:20Z"
- content="""
-Comment 6 talked about how to prevent old git-annex from getting confused
-when used in a repo with sameas remotes.
-
-If remote.name.annex-uuid contains the uuid that sameas pointed to, then
-old git-annex will load the RemoteConfig for that uuid. Which is kind of
-... ok? The other gitconfig settings for the remote may or may not work
-with that RemoteConfig. But if accessing that remote fails with old
-git-annex, no problem. The only concerning thing I think would be if
-checkpresent somehow reported all content as missing from the remote... But
-if a misconfiguration of the gitconfig can do that, the special remote
-implementation is arguably already buggy.
-
-So, I think it's ok to set remote.name.annex-uuid to the sameas
-uuid. There will need to be a new config key that indicates the uuid to
-get the RemoteConfig from.
-
-Old git-annex enableremote still needs to be prevented from initializing a
-sameas remote, as it would set annex-uuid to the wrong uuid.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_12_704637f56a74a0f561798ae398e1470b._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_12_704637f56a74a0f561798ae398e1470b._comment
deleted file mode 100644
index eabad462a2..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_12_704637f56a74a0f561798ae398e1470b._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 12"""
- date="2019-10-11T19:56:12Z"
- content="""
-Looking over all my comments now that I have an implementatation..
-
-`git annex dead` on a sameas remote name marks the parent remote dead.
-I think this is ok; dead means the content is gone, so which remote is used
-to access it is immaterial; they're all dead.
-
-sameas loops are not a problem, it only looks up the sameas-uuid value
-once, will not loop.
-
-old git-annex are prevented from enabling a sameas remote, since it has no
-name=
-
-old git-annex with an enabled sameas remote will see the annex-uuid of the
-parent, and treat it as the parent. Some git config values needed to use
-the parent may not be set, or may potentially be set differently than for
-the parent. Unlikely to cause any bad behavior, other than the remote not
-working.
-
-encrypted data and legacy chunking is inherited, and cannot be overridden
-
-RemoteConfig always contains any inherited parameters of a sameas remote.
-Logs.Remote.configSet filters those out.
-
-Logs.Remote.configSet is a little bit less safe; if its caller passed the
-RemoteConfig from a sameas remote, it needs to make sure to not pass the
-uuid of the parent remote, or it will overwrite the wrong config. All calls
-to it handle that now.
-
-per-remote state still to be done.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_1_620388b7ef3ebcc1f9228533f07a1f86._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_1_620388b7ef3ebcc1f9228533f07a1f86._comment
deleted file mode 100644
index 209935ec20..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_1_620388b7ef3ebcc1f9228533f07a1f86._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-04-16T17:09:39Z"
- content="""
-Dug a little into implementing this.
-
-One problem is that things like `git annex dead` look up a name
-in the remote list, and then use the uuid of the returned remote. 
-But if remote foo has sameas=bar-uuid, then the remote in the remote
-list that it looks up will have that uuid, and so the uuid that will
-be marked as dead is almost certianly not the one that the user expected.
-
-And the user can't pass the masked uuid of the sameas remote to `git-annex
-dead`, because there will be no remote in the list with that uuid.
-
-And for that matter, the user is not likely to know the masked uuid,
-because things like `git annex info` won't display it..
-
-Another gotcha is that the user might make remote B with sameas=A-uuid,
-and remote C with sameas=B-uuid. Which really needs to resolve to A-uuid,
-so it needs to do multiple lookups, but then a sameas loop becomes a problem.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_2_8fd57279ec4d0bae6c32c222c88740d8._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_2_8fd57279ec4d0bae6c32c222c88740d8._comment
deleted file mode 100644
index 5250312891..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_2_8fd57279ec4d0bae6c32c222c88740d8._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-09-27T15:53:25Z"
- content="""
-Yet another problem with the sameas idea is that old git-annex won't know
-what the sameas= value means, and will ignore it. So they'd proceed to use
-the wrong uuid for the special remote. That could result in a big mess.
-
-Also, two remotes using the same underlying data need to be encrypted the
-same way. Including using the same cipher= value, which is not a value that
-the user provides. Basically, all the encryption parameters need to be
-shared between two such remotes. 
-
-Also the chunksize parameter needs to be shared, or at least be
-set on both if not to the same value.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_3_0c213bd1ee39dbc7236540370b92466e._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_3_0c213bd1ee39dbc7236540370b92466e._comment
deleted file mode 100644
index 9ebcf89d27..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_3_0c213bd1ee39dbc7236540370b92466e._comment
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2019-09-27T15:59:28Z"
- content="""
-Alternate idea:
-
-	git annex initremote foo type=directory directory=/foo encryption=shared
-	git annex initremote --sameas=foo foo-rsync type=rsync rsyncurl=server:/foo
-
-The second command would inherit the encryption etc fields from the foo remote,
-and set up the foo-rsync remote with the same uuid as it.
-And it would add additional fields to the remote.log:
-
-	-uuid name=foo type=directory encryption=shared cipher=...
-	+uuid name=foo type=directory encryption=shared cipher=... type+foo-rsync=rsync rsyncurl!foo-rsync=server:/foo
-
-When enableremote foo-rsync is later run and fails to find a name=foo-rsync,
-it can look for a remote with the "type+foo-rsync" field, and generate a
-RemoteConfig with type=rsync rsyncurl=server:/foo encryption=shared cipher=...
-From there the enableremote would proceed as usual.
-
-(And, if enableremote foo-rsync is passed new/changed parameters, they need to get
-stored under its namespace.)
-
-I picked + as the separator because it's not likely to be in a remote
-name (although it could be) and it seems fine to not support field names containing 
-it. (I had first used period, but there may well be special remotes with field names
-that contain a period.) There's no parsing ambiguity: 'x+y+z=bar' means the x
-field of a remote named  "y+z".
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_4_76d747fe5fb8296d8728cc3af7503972._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_4_76d747fe5fb8296d8728cc3af7503972._comment
deleted file mode 100644
index d0ad50f63b..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_4_76d747fe5fb8296d8728cc3af7503972._comment
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2019-10-01T16:26:12Z"
- content="""
-Started a `sameas` branch for this.
-
-Logs.Remote.configSet will need some changes because it currently works
-on the basis of UUID, and so can't know when it's supposed to change a
-sameas remote. It will need an added RemoteName parameter.
-
-The RemoteConfig is generated each run from the remote.log, and so the
-handling of sameas remotes needs to be done in Logs.Remote.readRemoteLog
-not by enableremote.
-
-readRemoteLog makes a `Map UUID RemoteConfig`, which will need to
-change to `Map (UUID, RemoteName) RemoteConfig`
-
-Digging into changing readRemoteLog, there are several problems. Here are
-some of the less tractable ones:
-
-Remote.List.remoteGen looks up RemoteConfig by UUID. While it does have a
-Git remote and could look up the name of the remote from that, if the user
-renames a remote in .git/config, that would confuse it. That is not an
-acceptable tradeoff. So, a sameas remote would need to have some additional
-git config be set, giving the namespace that's used for it in the
-remote.log. If that's missing, it un-namespaced. initremote/enableremote
-need to set that git config.
-
-Annex.SpecialRemote.autoEnable uses readRemoteLog. It would likewise need
-to look at the git config for namespace to tell which sameas remotes
-have been auto-enabled.
-
-Preferred content looks at the preferreddir= value from RemoteConfig,
-and only a uuid is available. So it would have to look at the preferreddir
-values from all RemoteConfigs for remotes with that uuid and somehow pick
-one consistently. Or, preferreddir could be inherited like encryption
-settings are, and not allowed to be set in a sameas remote's config.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_5_4c6aca9ad876a3963e100f008aea0011._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_5_4c6aca9ad876a3963e100f008aea0011._comment
deleted file mode 100644
index 0400830955..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_5_4c6aca9ad876a3963e100f008aea0011._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2019-10-01T19:52:22Z"
- content="""
-Further problem with namespaces: If two people init new sameas remotes with
-the same uuid at the same time, on merge one of them will be lost.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_6_8c6c6cbfdc82db708d5c693a18d3872c._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_6_8c6c6cbfdc82db708d5c693a18d3872c._comment
deleted file mode 100644
index 4fc2747017..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_6_8c6c6cbfdc82db708d5c693a18d3872c._comment
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2019-10-01T19:53:06Z"
- content="""
-Revisiting the idea of using different uuids with a sameas= parameter:
-
-If one remote is marked dead, it ought to be the one that sameas= points
-to, since that's the uuid in the location log. So that's ok.
-
-As long as enableremote does not allow changing the sameas= paramter,
-sameas loops could only occur maliciously, not in normal operation.
-So it's fine to break such a loop in an arbitrary way.
-
-There would need to be a way to prevent a remote with sameas= from being
-used by a version of git-annex that does not support it. One way would be
-to omit the name= parameter from remote.log, and use some other parameter
-for the name. Then old git-annex could not enableremote with the wrong uuid.
-
-Using remote.name.annex-uuid-sameas=uuid instead of remote.name.annex-uuid
-would prevent old git-annex from using initialized sameas remotes.
-(Need a better name, since the uuid stored there should be the remote's own
-uuid (needed to get its RemoteConfig), not the one that sameas= points to.)
-
-Seems that encryption parameter inheritance would happen the same way as
-has been discussed above. When constructing the RemoteConfig, copy over the
-encryption parameters from the parent remote.
-
-All in all, using separate uuids instead of name= seems perhaps better.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_7_cad7edecb526f3bdf9bcff5aa3569f91._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_7_cad7edecb526f3bdf9bcff5aa3569f91._comment
deleted file mode 100644
index eb221f22fb..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_7_cad7edecb526f3bdf9bcff5aa3569f91._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="different repos with same uuid"
- date="2019-10-02T15:13:55Z"
- content="""
-\"It is already possible of course for two git remotes to have the same uuid, and also for a special remote and git remotes to have the same uuid\" -- but, in general, that's a situation to be avoided, right?  Other than two protocols accessing the same datastore, are there times when you'd want that?
-
-(Related: [[`git-annex-reinit`|git-annex-reinit]], [[todo/reinit_current_repo_to_new_uuid]])
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_8_22176bc5cab6c694537c2238009a8e5a._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_8_22176bc5cab6c694537c2238009a8e5a._comment
deleted file mode 100644
index 8426bacb65..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_8_22176bc5cab6c694537c2238009a8e5a._comment
+++ /dev/null
@@ -1,38 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 8"""
- date="2019-10-07T16:37:39Z"
- content="""
-Looked into the extent of changes needed for the sameas parameter approach.
-
-The only thing that looks at the "name" parameter is Annex.SpecialRemote,
-so the new alternative name parameter for sameas remotes can be handled
-entirely there.
-
-That's good, but its specialRemoteMap will need to be changed since
-it assumes each uuid has a single associated name, which stops being the case.
-
-Either Annex.SpecialRemote or Logs.Remote.readRemoteLog will need to handle
-the sameas paramter. Both have their problems. Comment 4 discussed how
-changing readRemoteLog would cause difficulties for some callers. But if
-Annex.Special remote handles the sameas parameter, there will be times when
-a RemoteConfig contains sameas inherited encryption etc, and times when it
-does not. Would be worth making two different data types for those.
-
-Remote.List.remoteGen gets the cached UUID and looks it up in the
-readRemoteLog map, so if readRemoteLog does not handle the sameas
-parameter, that will need to change to use something that does.
-
-(There could be other readRemoteLog users that will similarly be problems.)
-
-Logs.Remote.configSet will need to be changed as discussed in comment 4.
-
-To avoid using remote.name.annex-uuid for sameas remotes,
-Remote.Helper.Special.gitConfigSpecialRemote will need to somehow know that
-it's a sameas remote. (It could look at the RemoteConfig for a sameas
-parameter.)
-
-There are a couple of other places that set remote.name.annex-uuid, 
-like Remote.GCrypt, so will need to factor out all setting of that into
-something that is sameas-aware.
-"""]]
diff --git a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_9_5a47567bdc63b2a8fa080b438bb3f79a._comment b/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_9_5a47567bdc63b2a8fa080b438bb3f79a._comment
deleted file mode 100644
index 2aac333716..0000000000
--- a/doc/todo/support_multiple_special_remotes_with_same_uuid/comment_9_5a47567bdc63b2a8fa080b438bb3f79a._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 9"""
- date="2019-10-08T15:17:06Z"
- content="""
-Per-remote state is an added complication. A sameas remote should not
-use the same per-remote state, because what's stored in it is up to the
-remote backend and would conflict.
-
-So Logs.RemoteState would need to use something other than a UUID,
-which contains the underlying uuid of the sameas remote. (Logs.MetaData too for
-per-remote metadata.) That would have to be passed in when constructing the
-remote.
-
-And, `git-annex forget` would need to be made to remote the per-remote state of
-sameas remotes that point to a dead uuid.
-"""]]
diff --git a/doc/todo/support_public_versioned_S3_access.mdwn b/doc/todo/support_public_versioned_S3_access.mdwn
deleted file mode 100644
index f9e9cd6738..0000000000
--- a/doc/todo/support_public_versioned_S3_access.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-When a S3 remote uses exporttree=yes versioning=yes public=yes,
-it's possible to use anonymous http to download anything from it. git-annex
-does not yet support that, nor does whereis show the urls.
-
-Should not be super hard to add, but it involves converting `getpublicurl`
-into an Annex action and distinguishing between different uses of it,
-some of which work with this and some don't. --[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/switch_from_quvi_to_youtube-dl.mdwn b/doc/todo/switch_from_quvi_to_youtube-dl.mdwn
deleted file mode 100644
index 3fa7b0ccb1..0000000000
--- a/doc/todo/switch_from_quvi_to_youtube-dl.mdwn
+++ /dev/null
@@ -1,71 +0,0 @@
-quvi does not seem maintained (last upstream release in 2013)
-and it supports many fewer videos than youtube-dl does.
-
-The difficulty with using youtube-dl is it, by design, does not
-provide a way to probe if it supports an url, other than running it
-and seeing if it finds a video at the url. This would make `git annex
-addurl` significantly slower if it ran youtube-dl to probe every url.
-
-It is possible to use youtube-dl to download arbitrary non-video files;
-it stores the file to disk just as wget or curl. But, that's well outside
-its intended use case, and so it does not feel like a good idea to make
-git-annex depend on using youtube-dl to download generic urls.
-(Also, youtube-dl has bugs with downloading non-video 
-urls, see for example http://bugs.debian.org/874321)
-
-So, switching to youtube-dl would probably need a new switch, like `git
-annex addurl --rip` that enables using it.
-
-(Importfeed only treats links in the feed as video urls, not enclosures,
-so this problem does not affect it and it would not need a new switch.)
-
-That would need changes to users' workflows. git-annex could keep
-supporting quvi for some time, and warn when it uses quvi, to
-help with the transition.
-
-> Alternatively, git-annex addurl could download the url first, and then
-> check the file to see if it looks like html. If so, run youtube-dl (which
-> unfortunately has to download it again) and see if it manages to rip
-> media from it. This way, addurl of non-html files does not have extra
-> overhead, and the redundant download is fairly small compared to ripping
-> the media. Only the unusual case where addurl is being used on html that
-> does not contain media becomes more expensive.
-> 
-> However, for --relaxed, running youtube-dl --get-filename would be
-> significantly more expensive since it hits the network. It seems that
-> --relaxed would need to change to not rip videos; users who want that
-> could use --fast.
-> 
-> --fast already hits the network, but
-> if it uses youtube-dl --get-filename, it would fall afoul of
-> bugs like , although those can be worked
-> around (/dev/null stderr in cast youtube-dl crashes)
-
-Another gotcha is playlists. youtube-dl downloads playlists automatically.
-But, git-annex needs to record an url that downloads a single file so that
-`git annex get` works right. So, playlists will need to be disabled when
-git-annex runs youtube-dl. But, `--no-playlist` does not always disable
-playlists. Best option seems to be `--no-playlist --playlist-items 0` which works for
-non-playlists, and downloads only 1 item from playlists (hopefully a fairly
-stable item, but who knows..).
-
-(`git annex importfeed` handles youtube playlist downloads, but needs the
-user to find the url to the rss feed for the playlist. Youtube still has
-these, although it makes them hard to find.)
-
-Another gotcha is that youtube-dl's -o option does not fully determine the
-filename it downloads to. Sometims it will tack on an additional extension
-(seen with youtube videos where it added a ".mkv").
-And --get-filename does not report the actual filename when that happens.
-This seems to be due to format merging by ffmpeg; with -f best, it does
-not merge and so does not do that.
-
-
-To do disk free space checking will need a different technique than
-git-annex normally uses, because youtube-dl does not provide an easy way to
-query for size. Could use --dump-json, but that would require downloading
-the web page yet again, so too expensive.. and, the json seems to have
-"filesize: null" for youtube videos. What does work is the --max-filesize
-option, which makes youtube-dl abort if it's too big.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file.mdwn b/doc/todo/sync_content_of_a_single_directory_or_file.mdwn
deleted file mode 100644
index 90eb3b4326..0000000000
--- a/doc/todo/sync_content_of_a_single_directory_or_file.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-`git annex sync --content` operates on the whole work tree, not only the
-current directory. This is different than other git-annex commands, and
-makes sense in a way since git pull works like that too. But, sometimes
-I only want the content of a single directory, or perhaps file. 
-
-This could be implemented as `git annex sync --content thedir`, except
-that would conflict with the name of the remote to sync with that it
-currently takes. Perhaps `git annex sync --dir==thedir`, which
-automatically enables content syncing?
-
---[[Joey]]
-
-> Going with --content-of, so it's clear it enables content syncing.
-> With a -C short option. [[done]] --[[Joey]]
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_1_2db914588ea635aeaf7031c5ca418b2f._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_1_2db914588ea635aeaf7031c5ca418b2f._comment
deleted file mode 100644
index a881ebb911..0000000000
--- a/doc/todo/sync_content_of_a_single_directory_or_file/comment_1_2db914588ea635aeaf7031c5ca418b2f._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="konubinix"
- avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
- subject="Nice job!"
- date="2017-03-21T15:35:27Z"
- content="""
-I've been waiting for this for 5 years. I can't wait to use this :-).
-"""]]
diff --git a/doc/todo/sync_git-lfs_special_remote_should_sync_git_too.mdwn b/doc/todo/sync_git-lfs_special_remote_should_sync_git_too.mdwn
deleted file mode 100644
index ebefc2c59f..0000000000
--- a/doc/todo/sync_git-lfs_special_remote_should_sync_git_too.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-git annex sync with a git-lfs special remote does not pull or push.
-It should.
---[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/sync_to_non_tracking_export_confusing.mdwn b/doc/todo/sync_to_non_tracking_export_confusing.mdwn
deleted file mode 100644
index 2f67fed5d8..0000000000
--- a/doc/todo/sync_to_non_tracking_export_confusing.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-git annex sync --content to a exporttree remote that does not have a
-tracking branch configured can be confusing. It will sometimes try to
-upload files to the remote, but not files that were just committed.
-
-Part of the problem is that the tracking branch is stored in local git
-config, but the exported tree is stored in git-annex branch. So 
-`git annex sync --content` can be behaving as desired, updating a tracking
-branch, but then in a new clone of the same repository, it will behave
-differently.
-
-On the other hand, tracking branches are a locally configured concept in
-git, and that's why it seems to make sense to have them be locally
-configured in git-annex too.
-
-Maybe git-annex sync could just display a message when the remote doesn't
-have a tracking branch, to help the user understand why it's not syncing
-their recent changes to it.
-
---[[Joey]] 
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/termux_package.mdwn b/doc/todo/termux_package.mdwn
deleted file mode 100644
index 4b2eeb1ee1..0000000000
--- a/doc/todo/termux_package.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-Termux is an android terminal with apt. It should be possible to build
-git-annex this way, and this would be a nice alternative (or perhaps
-replacement) for the git-annex.apk.
-
-Looks like termux uses ubuntu to build, but cross-compiles for android,
-using bionic. So, ghc-android would still need to be used to build
-git-annex.
-
-Packages: 
-
-May be easier to build an appropriate .deb from the android git-annex
-binary, and add it to termux's sources.list?
-
-> Update: There's already an open issue in termux for this!
-> 
-> --[[Joey]] 
-
-This would also help with [[tor]] support on android, since termux has a
-tor package. And would avoid needing to bundle other 
-often out of date stuff with git-annex.apk.
-
---[[Joey]]
-
-> Retargeting this todo to be about making the git-annex linux standalone
-> build work well when unpacked in termux. --[[Joey]]
-> 
-> [[done]]; it seems to work pretty well now. --[[Joey]]
diff --git a/doc/todo/termux_package/comment_1_713568120dda33b83d02408ed9321fb8._comment b/doc/todo/termux_package/comment_1_713568120dda33b83d02408ed9321fb8._comment
deleted file mode 100644
index 809e651ad9..0000000000
--- a/doc/todo/termux_package/comment_1_713568120dda33b83d02408ed9321fb8._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="sunny256"
- avatar="http://cdn.libravatar.org/avatar/8a221001f74d0e8f4dadee3c7d1996e4"
- subject="Oh yes"
- date="2017-01-16T07:56:59Z"
- content="""
-That would be great. I'm not very fond of Android because it's only a crippled Linux, but Termux has made my life with Android much better, almost like in the old days on my Nokia N900, R.I.P. :'( I often sync files between the mobile and laptop, and being able to do that in Termux from the command line would be totally awesome.
-"""]]
diff --git a/doc/todo/termux_package/comment_2_b5b80f02cf0bdebd6e5e2af681e62ca7._comment b/doc/todo/termux_package/comment_2_b5b80f02cf0bdebd6e5e2af681e62ca7._comment
deleted file mode 100644
index 3f8974a861..0000000000
--- a/doc/todo/termux_package/comment_2_b5b80f02cf0bdebd6e5e2af681e62ca7._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2018-04-24T23:03:09Z"
- content="""
-The Linux standalone arm build of git-annex WORKS in termux!
-
-Just untar somewhere other than /sdcard. Your termux user's home directory
-works. 
-
-`cd git-annex.linux && runshell`
-
-Just works. 100%. OMG
-"""]]
diff --git a/doc/todo/termux_package/comment_3_a60b6e4511c1df23d76c6e6e8028eeaa._comment b/doc/todo/termux_package/comment_3_a60b6e4511c1df23d76c6e6e8028eeaa._comment
deleted file mode 100644
index 622862d73f..0000000000
--- a/doc/todo/termux_package/comment_3_a60b6e4511c1df23d76c6e6e8028eeaa._comment
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-04-24T23:35:33Z"
- content="""
-A few problems with using git-annex this way..
-
-git init fails in sdcard because it tries to chmod something. It works in
-the termux home directory. Note that only the git bundled with git-annex
-has this problem; the termux one works (probably it's patched like I did in
-the android git-annex port). Hacking the standalone build to not run the
-bundled git should work. This could be done only when uname -o = Android.
-(Update: Fixed)
-
-git annex init fails with a getUserEntryForID exception. 
-[[!commit 526243d6f5db6e16c32ed7f835da590b877f78b8]] probably fixed this,
-but not tested yet. (Update: Fixed)
-
-The webapp is able to open an url (after I upgraded termux) via xdg-open
-(alias for termux-open), but when in /sdcard/t2 it opened an url that
-chrome was not able to access, apparently a permissions problem. The
-webapp.html does not add any security on android, since it's not a
-multiuser unix system, and so it should open the url to the webapp
-directly. (Done)
-
-Accessing the sdcard may need termux-setup-storage to be run once, 
-depending on the version of android. That sets up $HOME/storage.
-The webapp ought to default to making a repository somewhere in there.
-(Done)
-
-The assistant won't start on boot, but could be made to using
-https://wiki.termux.com/wiki/Termux:Boot (Integration in place now)
-
-Apparently termux-exec sets a `LD_PRELOAD` that is not compatible, so
-the wrapper script would need to unset it. (Done now)
-
-Webapp mountwatcher crashes "getMounts: does not exist" (caught exception
-now))
-"""]]
diff --git a/doc/todo/test_suite_failures_since_7.20181121.mdwn b/doc/todo/test_suite_failures_since_7.20181121.mdwn
deleted file mode 100644
index 781376a048..0000000000
--- a/doc/todo/test_suite_failures_since_7.20181121.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-Since 7.20181121 Debian has been seeing test suite failures, on the mips autobuilders and on the amd64 CI infrastructure, but not on the amd64 autobuilders.
-
-I attempted to reproduce the failure on a mips and could not; instead, four different tests failed in a different way.
-
-The most recent failures on the CI infrastructure and the mips autobuilders looks to be the same set of tests that have failed.
-
-- [mips autobuilder log](https://spwhitton.name/pub/git-annex-dec18/mipsbuildd.txt)
-
-- [mips reproduction attempt log](https://spwhitton.name/pub/git-annex-dec18/mipsporterbox.txt)
-
-- [CI log](https://spwhitton.name/pub/git-annex-dec18/debci.txt)
-
-I am inclined to think that there are several bugs here: the test suite is overly sensitive to its environment and can fail in different ways in different environments.  What's mysterious is why all this started happening so recently.
-
-It seems unlikely to me that anyone has time to fix these bugs before the upcoming Debian freeze.  Getting git-annex v7.x into buster is a priority.  Maybe the test suite should be disabled during the package build, since it's flaky?  I'd like to hear Joey's opinion on doing that.
-
---spwhitton
-
-> The logs are no longer available, but I recently did a lot
-> of pounding on the test suite to fix interrmittent failures,
-> and the mention of `git annex copy --from` sounds like
-> one of the failures I fixed. 
-> [[!commit fa62c3223383d8377d27576a0e32f7bfec0c826d]]
-> seems to have fixed the problem that made copying from v7 repos
-> sometimes fail.
-> 
-> Closing on that basis; if you see a new test suite failure, please open a
-> new bug. [[done]] --[[Joey]]
diff --git a/doc/todo/test_suite_failures_since_7.20181121/comment_1_6017b1a9af0e0f0c600640a00ca4c684._comment b/doc/todo/test_suite_failures_since_7.20181121/comment_1_6017b1a9af0e0f0c600640a00ca4c684._comment
deleted file mode 100644
index b76e65c4fb..0000000000
--- a/doc/todo/test_suite_failures_since_7.20181121/comment_1_6017b1a9af0e0f0c600640a00ca4c684._comment
+++ /dev/null
@@ -1,43 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-18T20:18:31Z"
- content="""
-The failure on mips seems to be due to NFS locking issues preventing deleting a
-directory. Running the test suite on NFS is likely to turn up this kind of
-problem. It should not be too hard to fix it, Utility.Gpg.testHarness probably
-just needs to catch more exceptions than the IO exceptions it already catches.
-
-The other two failures probably have the same underlying cause, it's a race
-condition or something like that involving unlocked files.
-
-I've been seeing this failure intermittently on the git-annex autobuilders
-for months, it's not a new problem. Probably longer than that, but there
-was another intermittent problem, since fixed, that occurred more often and
-so I probably didn't notice these.
-
-I think that disabling that part of the test suite would be a reasonable
-workaround, since if this is like the previous race it's unlikely to occur
-except when git-annex is used in the test suite or perhaps a script that runs a
-problimatic sequence of commands at a given speed.
-
-	diff --git a/Test.hs b/Test.hs
-	index be932cc51..f11260d71 100644
-	--- a/Test.hs
-	+++ b/Test.hs
-	@@ -145,8 +145,8 @@ tests crippledfilesystem opts = testGroup "Tests" $ properties :
-	 	map (\(d, te) -> withTestMode te initTests (unitTests d)) testmodes
-	   where
-	 	testmodes = catMaybes
-	-		[ Just ("v7 unlocked", (testMode opts (RepoVersion 7)) { unlockedFiles = True })
-	-		, unlesscrippled ("v5", testMode opts (RepoVersion 5))
-	+		-- Just ("v7 unlocked", (testMode opts (RepoVersion 7)) { unlockedFiles = True })
-	+		[ unlesscrippled ("v5", testMode opts (RepoVersion 5))
-	 		, unlesscrippled ("v7 locked", testMode opts (RepoVersion 7))
-	 		, Just ("v5 direct", (testMode opts (RepoVersion 5)) { forceDirect = True })
-	 		]
-
-Unfortunatly it's not at all clear how it's failing, there's no useful error
-message about what went wrong. If I had a good way to reproduce it I think I could
-get to the bottom of it in fairly short order.
-"""]]
diff --git a/doc/todo/test_suite_failures_since_7.20181121/comment_2_3fb92cc95bd270c04094d923eb8b2964._comment b/doc/todo/test_suite_failures_since_7.20181121/comment_2_3fb92cc95bd270c04094d923eb8b2964._comment
deleted file mode 100644
index 90049f31b5..0000000000
--- a/doc/todo/test_suite_failures_since_7.20181121/comment_2_3fb92cc95bd270c04094d923eb8b2964._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 2"
- date="2018-12-18T21:56:24Z"
- content="""
-Thank you for the useful feedback -- disabled as suggested.
-"""]]
diff --git a/doc/todo/test_suite_failures_since_7.20181121/comment_3_829a625f92538b40b6040684a5bdb3e9._comment b/doc/todo/test_suite_failures_since_7.20181121/comment_3_829a625f92538b40b6040684a5bdb3e9._comment
deleted file mode 100644
index 9a3ebca56a..0000000000
--- a/doc/todo/test_suite_failures_since_7.20181121/comment_3_829a625f92538b40b6040684a5bdb3e9._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2018-12-19T17:18:19Z"
- content="""
-The NFS problem is probably fixed by 
-[[!commit 14971414dc263fcb8124b4cf6b14b9b7a19189af]]
-"""]]
diff --git a/doc/todo/test_suite_failures_since_7.20181121/comment_4_a1bb2751333ed6a8fb0e4553d391264a._comment b/doc/todo/test_suite_failures_since_7.20181121/comment_4_a1bb2751333ed6a8fb0e4553d391264a._comment
deleted file mode 100644
index 72fd0b5718..0000000000
--- a/doc/todo/test_suite_failures_since_7.20181121/comment_4_a1bb2751333ed6a8fb0e4553d391264a._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2018-12-19T17:18:46Z"
- content="""
-If I could reproduce the remaining failure, what I'd do is run git-annex test 
-with --keep-failures, and then after it fails and prints out the test repo
-it failed in, go in there and try running the `git annex copy --from` or
-other command that appears to be failing, see how it's failing, and take it
-from there.
-"""]]
diff --git a/doc/todo/test_suite_failures_since_7.20181121/comment_5_2f036b985517f17378bdf24ee26b2393._comment b/doc/todo/test_suite_failures_since_7.20181121/comment_5_2f036b985517f17378bdf24ee26b2393._comment
deleted file mode 100644
index b13a8dcb68..0000000000
--- a/doc/todo/test_suite_failures_since_7.20181121/comment_5_2f036b985517f17378bdf24ee26b2393._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 5"
- date="2018-12-21T12:27:13Z"
- content="""
-Thanks for letting me know about `--keep-failures`.  I can't reliably reproduce the current failure but if that changes, I will investigate further.
-"""]]
diff --git a/doc/todo/testremote_for_read-only_remotes.mdwn b/doc/todo/testremote_for_read-only_remotes.mdwn
deleted file mode 100644
index a6920f2ee8..0000000000
--- a/doc/todo/testremote_for_read-only_remotes.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-It's not uncommon to create external special remotes for which, like for the built-in web remote, only download operations are defined.  It would be good if git-annex-testremote had the option of testing such remotes, using as test data the keys and URLs already registered as present in the remote.  This could also be used to test addurl-related functionality for fully implemented remotes; currently this part of a remote's implementation isn't tested.
-
-> Good idea, [[done]] using the --test-readonly option. --[[Joey]]
diff --git a/doc/todo/testremote_for_read-only_remotes/comment_1_0ba7de3d9c5da83f580a9ed240258b5e._comment b/doc/todo/testremote_for_read-only_remotes/comment_1_0ba7de3d9c5da83f580a9ed240258b5e._comment
deleted file mode 100644
index 245bd62574..0000000000
--- a/doc/todo/testremote_for_read-only_remotes/comment_1_0ba7de3d9c5da83f580a9ed240258b5e._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 1"
- date="2019-01-18T20:57:36Z"
- content="""
-Great, thanks!  Maybe, can make a new release soon?
-"""]]
diff --git a/doc/todo/transfer_between_git-annexes.mdwn b/doc/todo/transfer_between_git-annexes.mdwn
deleted file mode 100644
index 811b71654c..0000000000
--- a/doc/todo/transfer_between_git-annexes.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-What do you think of the ability to transfer a file between unrelated annexes? With "migrate" already taken, I would suggest "catapult" (or "teleport")!
-
-    git annex catapult dir1/ $HOME/otherannex/somedir/
-    git annex catapult dir2/thisfile.jpg $HOME/otherannex/somedir/
-
-git-annex would then:
-
-* Get list of present files
-* Copy the file to temporary space in $HOME/otherannex/.git/annex
-* fsck file
-* Move file to $HOME/otherannex/.git/annnex/objects
-* Create symlinks/directories in $HOME/otherannex/somedir/
-* Stage symlinks
-* Drop content and rm symlink
-
-with the usual modifiers (e.g. --fast would skip the fsck, --force to skip non-present files?).
-
-Reason I ask: I have a huge annex from importing the contents of a bunch of random harddrives and will eventually sort the contents into various other annexes I can put files into (personal, general family, specific people). Having git-annex guiding and checking the transfers from the sorting annex to the individual ones would be really nice.
-
-Not having this isn't a showstopper (I can use rsync) so no worries if you don't think it is worth it or think it is but put it on the backburner :) Would just be a nice-to-have.
-
-> So I get the feeling you found a way to do this in a script using
-> lower-level parts of git-annex. Closing on that basis, but feel free to
-> reopen if I'm wrong. [[done]] --[[Joey]]
-
->> Adding the source annex as a cache
->> ([[tips/local_caching_of_annexed_files/]]) and then adding the
->> symlinks to the local annex allows the content to be transferred with
->> all of the safeguards one usually gets from git-annex, but without
->> the merging of the repositories.
->> This is also very clean as the source annex doesn't get included in
->> the location tracking.
->> This works *really well* for me (even better than the script I was
->> using!), so happy with this being closed. -- [[CandyAngel]]
diff --git a/doc/todo/transfer_between_git-annexes/comment_1_e90f55ea43ba9e2931d72eaf929de18c._comment b/doc/todo/transfer_between_git-annexes/comment_1_e90f55ea43ba9e2931d72eaf929de18c._comment
deleted file mode 100644
index 79bad063b2..0000000000
--- a/doc/todo/transfer_between_git-annexes/comment_1_e90f55ea43ba9e2931d72eaf929de18c._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-06-02T17:46:24Z"
- content="""
-This feels like it's too particular to your use case, and not general
-enough to put in git-annex.
-
-But, I think it should be possible to accomplish each of those steps using
-git-annex commands, so you could write a shell script to do it.
-"""]]
diff --git a/doc/todo/transfer_between_git-annexes/comment_2_2a494355a114a3df7ff0b35aa12ed10d._comment b/doc/todo/transfer_between_git-annexes/comment_2_2a494355a114a3df7ff0b35aa12ed10d._comment
deleted file mode 100644
index e81266a7d4..0000000000
--- a/doc/todo/transfer_between_git-annexes/comment_2_2a494355a114a3df7ff0b35aa12ed10d._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- subject="comment 2"
- date="2015-07-15T10:20:55Z"
- content="""
-Been thinking about this as I am getting close to needing it, but would like some advice.
-
-My current plan is to copy the symlink to the target annex, add it to the index (fix it?), copy the source file from $source/.git/annex/objects to $target/.git/annex/tmp, then use 'reinject $target/.git/annex/tmp/$keyed_file $path_to_symlink'.
-
-As far as I can tell, this is safest way (uses mostly git-annex) to transfer a file between annexes. However, when transferring a directory of files, this will end up with 1 commit per file on the git-annex branch, which may be a problem.
-
-Is there any easy way to make this \"atomic\", so that git-annex will only get a commit if everything went okay and if not, revert any changes to $target? Am I looking at 'git stash', recording the master/git-annex references before the move and resetting to them in case of an error or rebasing(fixup) git-annex on success?
-"""]]
diff --git a/doc/todo/transfer_between_git-annexes/comment_3_adc2bfd00ffa6d85e68daabf7ad12aaa._comment b/doc/todo/transfer_between_git-annexes/comment_3_adc2bfd00ffa6d85e68daabf7ad12aaa._comment
deleted file mode 100644
index 3e90418eb7..0000000000
--- a/doc/todo/transfer_between_git-annexes/comment_3_adc2bfd00ffa6d85e68daabf7ad12aaa._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-07-15T15:50:35Z"
- content="""
-You can avoid the git-annex branch commits by passing -c
-annex.alwayscommit=false to git-annex commands. At the end, run `git annex
-merge` to commit all the changes in one go.
-
-The git-annex branch changes are temporarily stored in .git/anenx/journal/
-files if you wanted to delete them for rollback.
-"""]]
diff --git a/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows.mdwn b/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows.mdwn
deleted file mode 100644
index bdcd43e8c8..0000000000
--- a/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-I was trying to use the assistant, but when it didn't work I started troubleshooting. I wasn't able to get git-annex to work directly, so I'll start with it:
-
-    $ git annex add *jpg
-    add RnG.jpg
-    git-annex: .git\annex\objects\fc3\7ab\SHA256E-s63863--b26754195df2c07063401ab1dc8406a1f96c0a512724020b693e28bdbce9addf.jpg\: openTempFile: does not exist (No such file or directory)
-    failed
-    add Scan0005.jpg
-    git-annex: .git\annex\objects\3ae\9e3\SHA256E-s156803--617405c2e88c939a8cfa871a226c2fe04fe0b58b50667e4436250fcb7c59d09b.jpg\: openTempFile: does not exist (No such file or directory)
-    failed
-    (recording state in git...)
-    git-annex: add: 2 failed
-
-This is Windows 7. I've installed git 2.11 and git-annex 6.20161211-gc3ab3c6.
-
-> closing as dup of an existing bug [[done]] --[[Joey]]
diff --git a/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows/comment_1_2eeeab80aa00b8b47d57b59a49011820._comment b/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows/comment_1_2eeeab80aa00b8b47d57b59a49011820._comment
deleted file mode 100644
index 83a91a6cba..0000000000
--- a/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows/comment_1_2eeeab80aa00b8b47d57b59a49011820._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-06-06T19:50:19Z"
- content="""
-That sounds like this bug:
-
-
-Windows has some path length issues that come up especially when using
-git-annex in a deeply nested directory tree. Try cloning the repository to
-somewhere like c:\\ and see if that works around the problem.
-"""]]
diff --git a/doc/todo/unused_file_tracking_recommendation_changed_since_v7.mdwn b/doc/todo/unused_file_tracking_recommendation_changed_since_v7.mdwn
deleted file mode 100644
index 8036b61e2d..0000000000
--- a/doc/todo/unused_file_tracking_recommendation_changed_since_v7.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-I might be wrong, but I believe this stopped working since "pointer files" are used in v7 smudge/clean filters and [[tips/unlocked files]]:
-
-    $ git annex unused
-    unused . (checking for unused data...) (checking kingston/master...) (checking kingston/adjusted/master(unlocked)...) (checking master...) 
-      Some annexed data is no longer used by any files:
-        NUMBER  KEY
-
-        [...]
-
-    (To see where data was previously used, try: git log --stat -S'KEY')
-      
-      To remove unwanted data: git-annex dropunused NUMBER
-      
-    ok
-
-Indeed, -S doesn't find anything here. I suspect that is because git's
-smudge/clean interface kicks in in `--stat`. The above text should add
-the `--no-textconv` argument to avoid that. At least it works here. :)
--- [[anarcat]]
-
-> Nice catch, thanks! [[done]] --[[Joey]]
diff --git a/doc/todo/v7_InodeCache_timestamp_resolution.mdwn b/doc/todo/v7_InodeCache_timestamp_resolution.mdwn
deleted file mode 100644
index 8310710a98..0000000000
--- a/doc/todo/v7_InodeCache_timestamp_resolution.mdwn
+++ /dev/null
@@ -1,44 +0,0 @@
-InodeCache currently uses modificationTime which has a 1 second resolution.
-(And when comparing weakly, further weakens to 2 second resolution.)
-
-In [[!commit c28ca8294f7695c77e5f03762171e829de5d6ea4]], the clean filter
-started checking the InodeCache to see if a file is modified.
-
-This means that modifying a file, running `git add`, then modifying again
-and `git add` within the same second won't stage the second version of the
-file. (Although luckily it also compares file size.)
-
-I think that optimisation needs to be disabled when inode caches will be
-compared weakly, because 2 seconds is just too long. This will mean slow
-`git checkout` on FAT and also when a user moves a repo to a different
-filesystem. But I don't see a way to avoid it.
-
-> Hmm, on second thought, that would mean every inAnnex on FAT
-> would need to checksum the content. That's just too slow to be practical.
-> `git annex fsck` will clean up if trusting the timestamps causes
-> it to make a mistake on FAT.
-
-Otherwise, the problem can be fixed by using modificationTimeHiRes.
-
-But! All existing InodeCaches would then appear to have changed. This would
-confuse handling of existing v6 repos badly. (And direct mode uses
-InodeCache too..)
-
-So, need to detect, when reading a serialized InodeCache,
-if it's low res or high res. And when comparing two of different
-resolutions, truncate to low res.
-
-readInodeCache currently fails if the mtime contains a decimal, eg
-
-	ghci> readInodeCache "1 2 3.1"
-	Nothing
-
-What would work, w/o breaking back-compat is
-
-	ghci> readInodeCache "1 2 3 1"
-	Just (InodeCache (InodeCachePrim 1 2 3))
-
-So the decimal part of the mtime becomes the 4th word and old
-versions of git-annex will ignore it.
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/v7_path_toward_default.mdwn b/doc/todo/v7_path_toward_default.mdwn
deleted file mode 100644
index 4a10007802..0000000000
--- a/doc/todo/v7_path_toward_default.mdwn
+++ /dev/null
@@ -1,84 +0,0 @@
-Tracking v7 progress toward becoming the default.
-
-## step 1: release
-
-## step 2: default for new repositories that used to use direct mode
-
-## step 3: auto-upgrade from direct mode
-
-Direct mode is very buggy and limited, so it's easy for v7 (with adjusted
-unlocked branches) to be better than it.
-
-Note that direct mode repos with old git-annex interoperate with adjusted
-unlocked repos with new git-annex, so there is no need to wait for v7 to be
-widely supported.
-
-One problem with this is that direct mode stores only a single copy
-of a file, but v7 unlocked with annex.thin needs two copies if hard links
-are not supported. So some users will experience the repo doubling in size.
-Limited mostly to windows, also some FAT media. This seems difficult
-to avoid though, see discussion in
-
-
-On Windows Subsystem for Linux, adusted branches don't work due to
-some problem with sqlite, so upgrading a direct mode repo there
-would be a problem.
-
-But, regular v5 and v7 repos do work in WSL.
-
-## step 4: default for all new repositories
-
-Could probably happen fairly soon after switch of direct mode.
-
-This is entirely new repositories that git-annex init is run in for the
-first time (no sibling git-annex branches). Limiting to new repos
-avoids the problems discussed in step 5.
-
-## step 5: automatic v5 to v7 upgrades
-
-Since v5 repos and v7 repos not using unlocked files are functionally
-almost identical, this is unlikely to break much. Unlocking files will of
-course change behavior though.
-
-When not using unlocked files, the only significant difference is that
-Annex.Content in v7 reads and writes to the keys database. So any problem
-with the database code could prevent using git-annex.
-
-* WSL has such a problem currently,
-  but it doesn't seem to affect using v7 repos, only adjusted branches.
-  
-* A 2016 bug reported the keys database not working on lustre,
-  presumably due to sqlite needing part of POSIX that lustre does not provide
-  or something.
-  
-
-There are also some slight performance differences, but they go both ways,
-for example the pre-commit hook is faster in v7 than v5, but v7 runs git
-diff in reconcileStaged.
-
-A concern is that a v5 repository may be used by multiple machines,
-some not supporting v7 and some that do. If one upgrades to v7
-and starts using unlocked files, those files won't be accessible on the old
-v5 machines.
-
-> v7 is in debian stable now; oldstable (stretch) has v7 available
-> as a backport but not by default, and will remain supported
-> until 2022.
-> 
-> But workflows involving unlocking and re-locking that work on v5 will
-> also work on v7 and keep the repo compatible with v5. Only if some
-> users commit unlocked files is v5 compatability lost, and even then
-> it's easy to re-lock the file to fix compatabilityagain. So the risk
-> of a too early upgrade to v7 is not very big.
-
-Note that [[sqlite_database_improvements]] seems to need a v8 mode,
-and so is blocked on v5 auto-upgrading.
-
-## step 6: remove support for v5
-
-This won't simplify much code, worth doing eventually. Once automatic v5 to
-v7 upgrades happen, the remaining v5 specific code is not needed any
-longer.
-
-> all now [[done]]
-
diff --git a/doc/todo/versioning_in_export_remotes.mdwn b/doc/todo/versioning_in_export_remotes.mdwn
deleted file mode 100644
index 9714ba77e9..0000000000
--- a/doc/todo/versioning_in_export_remotes.mdwn
+++ /dev/null
@@ -1,83 +0,0 @@
-Some remotes like S3 support versioning of data stored in them.
-When git-annex updates an export, it deletes the old
-content from eg the S3 bucket, but with versioning enabled, S3 retains the
-content and it can be accessed using a version ID (that S3 returns when
-storing the content). So it should be possible for git-annex to allow
-downloading old versions of files from such a remote.
-
-
-
-Basically, store the S3 version ID in git-annex branch and support
-downloading using it. 
-
-But this has the problem that dropping makes git-annex think it's not in S3
-any more, while what we want for export is for it to be removed from the
-current bucket, but still tracked as present in S3.
-
-The drop from S3 could fail, or "succeed" in a way that prevents the location
-tracking being updated to say it lacks the content. Failing is how bup deals
-with it. It seems confusing to have a drop appear to succeed but not really drop,
-especially since dropping again would seem to do something a second time.
-
-This does mean that git-annex drop/sync --content/assistant might try to do a
-lot of drops from the remote, and generate a lot of noise when they fail.
-Which is kind of ok for drop, since the user should be told that they can't
-delete the data. Could add a way to say "this remote does not support drop",
-and make at sync --content/assistant use that.
-
-Note that git-annex export does not rely on location tracking to determine
-which files still need to be sent to an export. It uses the export database
-to keep track of that. This is important, because the location tracking
-won't be updated, as discussed above.
-
-The haskell aws library does not seem to support enabling versioning when
-creating a bucket, so it would need to be done from the web console.
-
-## other considerations
-
-If the user enables versioning in git-annex but forgets to enable it
-in the bucket (or later suspends versioning in the bucket), it's no
-big problem; old files will not be retained and git-annex will notice
-this in the usual way (drop locking, fsck). So, it seems that initremote
-does not need to check if the versioning=yes setting matches the bucket
-configuration. For same reasons, it's ok to enable versioning for an
-existing remote.
-
-S3 does allow DELETE of a version of an object from a bucket. So it would
-be possible to support `git annex drop` of old versions of a file from an
-export remote. Dropping the current version though, would make the export
-database inconsistent; it would not know that a file in the exported tree
-was no longer present. I don't think that inconsitency can easily be
-resolved -- bear in ming that multiple repositories can have an export db,
-so it would need to look at location tracking for all objects in the export
-to find ones that some other repository dropped. And dropping of only
-keys that are not used in the current export doesn't help because another
-repository may have changed the exported tree and be relying on the dropped
-key being present in the export. Unless... Could export conflict resultion
-somehow detect that?
-
-## final plan
-
-Add an "appendOnly" field to Remote, indicating it retains all content stored
-in it. done
-
-Make `git annex export` check appendOnly when removing a file from an
-export, and not update the location log, since the remote still contains
-the content. done
-
-Make git-annex sync and the assistant skip trying to drop from appendOnly
-remotes since it's just going to fail. done
-
-Make exporttree=yes remotes that are appendOnly not be untrusted, and not force
-verification of content, since the usual concerns about losing data when an
-export is updated by someone else don't apply. done
-
-Let S3 remotes be configured with versioning=yes which enables appendOnly.
-done
-
-Make S3 store version IDs for exported files in the per-remote log when so
-configured. done
-
-Use version IDs when retrieving keys and for checkpresent. done
-
-> all [[done]]! (but see [[support_public_versioned_S3_access]]) --[[Joey]] 
diff --git a/doc/todo/wishlist__58___do_not_import_new_files.mdwn b/doc/todo/wishlist__58___do_not_import_new_files.mdwn
deleted file mode 100644
index 6a0225f38b..0000000000
--- a/doc/todo/wishlist__58___do_not_import_new_files.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!meta title="mass reinject of any known content from a directory"]]
-
-Right now `git annex import DIR/*` will import all the files in DIR, both those that are already known to git-annex and those that are new. Using the option `--skip-duplicates` one can import only new files that are in DIR but unknown to git-annex.
-
-It would be nice if there were an opposite `--only-duplicates` option that could be used to import only the files that are already known to git, ignoring the new files in DIR.
-
-PS: it would also be nice to have aliases like `--only-new-files` and `--skip-new-files` for `--skip-duplicates` and `--only-duplicates`.
-
-> I think that either `git annex reinject --known` or `git annex import
-> --reinject-known` can handle this use case. So, [[done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___do_not_import_new_files/comment_1_b41c214599d6601257a9d824cebbffcc._comment b/doc/todo/wishlist__58___do_not_import_new_files/comment_1_b41c214599d6601257a9d824cebbffcc._comment
deleted file mode 100644
index fbb5571cb8..0000000000
--- a/doc/todo/wishlist__58___do_not_import_new_files/comment_1_b41c214599d6601257a9d824cebbffcc._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="http://ypid.wordpress.com/"
- ip="213.153.84.215"
- subject="gitignore"
- date="2014-07-12T17:59:42Z"
- content="""
-Hi
-
-The gitignore file is probably what you are looking for which is also honored by git-annex. Some documentation:
-
-* [On git-scm](http://git-scm.com/docs/gitignore)
-* [On gitready](http://de.gitready.com/beginner/2009/01/19/ignoring-files.html)
-* [On github](https://help.github.com/articles/ignoring-files)
-"""]]
diff --git a/doc/todo/wishlist__58___do_not_import_new_files/comment_2_7b26171458baaf5c0057276d2d97e14c._comment b/doc/todo/wishlist__58___do_not_import_new_files/comment_2_7b26171458baaf5c0057276d2d97e14c._comment
deleted file mode 100644
index bedf9a54cd..0000000000
--- a/doc/todo/wishlist__58___do_not_import_new_files/comment_2_7b26171458baaf5c0057276d2d97e14c._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 2"
- date="2014-07-14T18:30:38Z"
- content="""
-You can use --clean-duplicates unless your goal is for some reason to add the duplicate files to your repository a second time.
-"""]]
diff --git a/doc/todo/wishlist__58___do_not_import_new_files/comment_3_6f80ce6cee4519d4f69193d5086e194a._comment b/doc/todo/wishlist__58___do_not_import_new_files/comment_3_6f80ce6cee4519d4f69193d5086e194a._comment
deleted file mode 100644
index e66cc5ea9c..0000000000
--- a/doc/todo/wishlist__58___do_not_import_new_files/comment_3_6f80ce6cee4519d4f69193d5086e194a._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="http://svario.it/gioele"
- nickname="gioele"
- subject="comment 3"
- date="2014-07-15T06:54:40Z"
- content="""
->  You can use --clean-duplicates unless your goal is for some reason to add the duplicate files to your repository a second time.
-
-My use case is that I clone an existing remote on a PC where there are already some of the annexed files (+ others).
-
-My workflow would be:
-
-* clone git-annex server:~/Documents.git
-* git annex init \"other pc\"
-* git annex import --skip-new (or --only-duplicates) ~/Dump/*
-
-~/Dump contains many other files in addition to those found in the Documents repository.
-
-In this case --clean-duplicate would not be the correct solution.
-"""]]
diff --git a/doc/todo/wishlist__58___do_not_import_new_files/comment_4_22a7a03c30174e42e6d8e639e31e1d34._comment b/doc/todo/wishlist__58___do_not_import_new_files/comment_4_22a7a03c30174e42e6d8e639e31e1d34._comment
deleted file mode 100644
index f53fb6395c..0000000000
--- a/doc/todo/wishlist__58___do_not_import_new_files/comment_4_22a7a03c30174e42e6d8e639e31e1d34._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 4"
- date="2014-07-15T19:01:24Z"
- content="""
-So the goal is to inject any known objects from the dump into the local annex to avoid needing to re-transfer them.
-
-It seems to me that in this case, you would not even want to create new symlinks in the git repository.
-
-`git annex reinject` might be a better place to put code to handle this than `git annex import`.
-"""]]
diff --git a/doc/todo/wishlist__58___do_not_import_new_files/comment_5_4294e92e2f4efb9dd10b280f5c9843f7._comment b/doc/todo/wishlist__58___do_not_import_new_files/comment_5_4294e92e2f4efb9dd10b280f5c9843f7._comment
deleted file mode 100644
index e312c083d2..0000000000
--- a/doc/todo/wishlist__58___do_not_import_new_files/comment_5_4294e92e2f4efb9dd10b280f5c9843f7._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 5"
- date="2014-07-15T19:13:05Z"
- content="""
-A fundamental problem with this idea is that git-annex's keys can use any of many checksumming backends. So, which checksum should it try? Running every possible checksum on a file is going to re-read it repeatedly and be expensive.
-
-`git annex import` avoids this problem by using whatever the default backend is configured to be for the filename it's importing. This is good enough to make repeated runs of `git annex import` work ok, but when we get into trying to reinject whole directory trees like this, I don't think that's good enough.
-"""]]
diff --git a/doc/todo/wishlist__58___make_partial_files_available_during_transfer.mdwn b/doc/todo/wishlist__58___make_partial_files_available_during_transfer.mdwn
deleted file mode 100644
index f368faba96..0000000000
--- a/doc/todo/wishlist__58___make_partial_files_available_during_transfer.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-Imagine this situation:
-You have a laptop and a NAS.
-On your laptop you want to consume a large media file located on the NAS.
-So you type:
-
-    git annex get --from nas mediafile
-
-But now you have to wait for the download to complete, unless either 
-
-* rsync is pointed directly to the file in the object storage ("--inplace")
-or
-* the symlink temporarily points to the partial file during a transfer
-
-which would allow you instantaneous consumption of your media.
-It might make sense to make this behavior configurable, because not everyone might agree with having partial content (that mismatches its key) around.
-
-
-So what do you say?
-
-> The `git annex inprogress` command now can be used to more easily do what
-> I was suggesting be done with `git annex find` below. [[done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_2_8b1cfae6f2b61929a9c6f48ae63c921d._comment b/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_2_8b1cfae6f2b61929a9c6f48ae63c921d._comment
deleted file mode 100644
index c4c2224319..0000000000
--- a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_2_8b1cfae6f2b61929a9c6f48ae63c921d._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.154"
- subject="comment 2"
- date="2014-03-18T20:08:13Z"
- content="""
-There's now an easy way to do this:
-
-        git annex find --include=* --format='.git/annex/tmp/${hashdirmixed}${key}/${key}\n' 
-
-Pass it the file or files you're interested in to get their partially transferred contents.
-"""]]
diff --git a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment b/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment
deleted file mode 100644
index 2907dafc3a..0000000000
--- a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.152.108.194"
- subject="comment 3"
- date="2012-11-04T19:58:28Z"
- content="""
-I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentally git committing a bad symlink. Or the user accidentally doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.)
-
-However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`.
-"""]]
diff --git a/doc/todo/wishlist__58___pack_metadata_in_direct_mode.mdwn b/doc/todo/wishlist__58___pack_metadata_in_direct_mode.mdwn
deleted file mode 100644
index 18131d81fb..0000000000
--- a/doc/todo/wishlist__58___pack_metadata_in_direct_mode.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-The metadata storage for direct mode (V3) is this. In directory .git/annex/objects, there is one .map for all annexed file, and one .cache for all files in the working tree. Both are small files, containing only 1 line or a few lines. I have a repo with lots of photos, and this created lots of small files. I believe this will cause many performance issues. 
-
-It would be great if these files are packed, maybe also in the git pack files format.
-
-[[!meta tag=deprecateddirectmode]]
-
-> direct mode has been removed. Its replacement, v7 unlocked, does use a
-> sqlite database that packs all the metadata in one place. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/wishlist__58___pack_metadata_in_direct_mode/comment_1_1a550d6977a255b789337c3d1602db04._comment b/doc/todo/wishlist__58___pack_metadata_in_direct_mode/comment_1_1a550d6977a255b789337c3d1602db04._comment
deleted file mode 100644
index 543e1c048b..0000000000
--- a/doc/todo/wishlist__58___pack_metadata_in_direct_mode/comment_1_1a550d6977a255b789337c3d1602db04._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.35"
- subject="comment 1"
- date="2014-01-04T19:18:16Z"
- content="""
-\"I believe this will cause many performance issues.\"
-
-Such as?
-"""]]
diff --git a/doc/todo/wishlist__58___pack_metadata_in_direct_mode/comment_2_3cc9c69d33c658058daea9cb5e4ab669._comment b/doc/todo/wishlist__58___pack_metadata_in_direct_mode/comment_2_3cc9c69d33c658058daea9cb5e4ab669._comment
deleted file mode 100644
index 5028636c40..0000000000
--- a/doc/todo/wishlist__58___pack_metadata_in_direct_mode/comment_2_3cc9c69d33c658058daea9cb5e4ab669._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="namelessjon"
- ip="193.132.159.169"
- subject="inode starvation"
- date="2014-01-09T15:30:16Z"
- content="""
-This happened to me a few times when creating new annex folders.
-
-I use lvm to create virtual partitions and have/had several 'bulk media' logical volumes which used ext4 with -T largefile4 (i.e. one inode per 4mb) because they're storing files with 20mb+ sizes (RAW images, downloaded screencasts, FLAC soundfiles, etc). Between the extra directories git annex creates, the extra files, and the .git/object directory, I ran out of inodes on a few occasions from the profusion of small files.  In some cases, I worked around this by shunting data around, or adding incrementally and then 'git gc'ing a lot to at least have a small .git/objects dir.  A packed metadata would help to deal with this.
-"""]]
diff --git a/doc/todo/wishlist__58___per-repository_autocommit__61__false.mdwn b/doc/todo/wishlist__58___per-repository_autocommit__61__false.mdwn
deleted file mode 100644
index 40cdb0096f..0000000000
--- a/doc/todo/wishlist__58___per-repository_autocommit__61__false.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-when using git-annex as a minority participant in a repository (eg. because in a hardware project, at some point in time, photos get added), users will start to need to `git annex sync` (because a plain `git pull` / `git push` will work but show errors, and a `pull --all` / `annex merge` is difficult for users to remember). to stay in line with usual git usage, the `sync` must be used with `config annex.autocommit false`, but that needs to be configured on each repository.
-
-forgetting to do that explicit configuration results, in one sync command, easily results in an unwanted implicit commit that's pushed across remotes.
-
-could there be a per-repository option (somewhere around .gitattributes, or maybe in the git-annex branch) that disables autocommits for the repository?
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___per-repository_autocommit__61__false/comment_1_851483817d97de212932203c2e830293._comment b/doc/todo/wishlist__58___per-repository_autocommit__61__false/comment_1_851483817d97de212932203c2e830293._comment
deleted file mode 100644
index 7e5d850385..0000000000
--- a/doc/todo/wishlist__58___per-repository_autocommit__61__false/comment_1_851483817d97de212932203c2e830293._comment
+++ /dev/null
@@ -1,38 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-01-30T18:13:42Z"
- content="""
-This could be put in the git-annex branch similarly to the `git annex
-numcopies` configuration so all clones see it.
-
-As well as --no-commit, --content is the other option that I think 
-might make sense to have a clone-wide setting for. sync's --no-pull and
---no-push seem much less likely to need such a setting.
-
-I've been leaning toward eventually turning sync --content on by default,
-and such a clone-wide configuration would be useful to let users get back
-the current behavior.
-
-Hmm, this could be generalized all the way to having a file in the
-git-annex branch that stores default settings for `annex.*` configs.
-But then git-annex would have to pull that file out of the git-annex branch
-every time it's run, which would slow down commands that get run a lot in
-succession. So that's a generalization too far.
-
-Still, looking through the configs, I can see some other things
-that it would similarly make sense to sometimes want to set clone-wide,
-including: annex.genmetadata, annex.used-refspec, annex.diskreserve, 
-annex.addsmallfiles.
-
-So, we have some configs that are each only used by a few commands,
-that make sense to be allowed to be set clone-wide. We can make the file
-in the git-annex branch be only read by commands that look at those
-configs, and can consider when implementing each whether it would slow
-down any command too much to have it need to read the git-annex branch
-file.
-
-I've added a `git annex config` command that can set such clone-wide
-configurations. I have not yet made git annex sync look at it for
-annex.autocommit.
-"""]]
diff --git a/doc/todo/wishlist__58___per-repository_autocommit__61__false/comment_2_95e157d36c8ec91790cfd65037600332._comment b/doc/todo/wishlist__58___per-repository_autocommit__61__false/comment_2_95e157d36c8ec91790cfd65037600332._comment
deleted file mode 100644
index 9455252cec..0000000000
--- a/doc/todo/wishlist__58___per-repository_autocommit__61__false/comment_2_95e157d36c8ec91790cfd65037600332._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-02-03T17:35:37Z"
- content="""
-git annex config --set annex.autocommit false
-
-That works now, and will set the default autocommit behavior in all clones
-of the repository.
-"""]]
diff --git a/doc/todo/wishlist__58___rsync_efficiency.mdwn b/doc/todo/wishlist__58___rsync_efficiency.mdwn
deleted file mode 100644
index 21e8db7ec4..0000000000
--- a/doc/todo/wishlist__58___rsync_efficiency.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-If you look at the transfer rates during a copy job to remotes, you see it going down to zero for a short time between files.
-
-While that's understandable from rsync's PoV, it's not as efficient as git-annex could be.
-
-Would parallelization be an option? Are there alternate improvements?
-
-
--- Richard
-
-> I think that git-annex switching to the P2P protocol for ssh transfers
-> fixed this; it doesn't have the overhead of starting up rsync each time,
-> and even multiple transfers go over the same ssh connection, which also
-> adds efficiency. [[done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___rsync_efficiency/comment_1_6e7cceb9d23f0cad3d9f839dd2a04901._comment b/doc/todo/wishlist__58___rsync_efficiency/comment_1_6e7cceb9d23f0cad3d9f839dd2a04901._comment
deleted file mode 100644
index 35f6b885b4..0000000000
--- a/doc/todo/wishlist__58___rsync_efficiency/comment_1_6e7cceb9d23f0cad3d9f839dd2a04901._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-04-18T19:21:44Z"
- content="""
-The `concurrentprogress` branch can already parallelize transfers.
-It's waiting on some progress display improvements for merging.
-
-I imagine this would keep the pipe full more consistently.
-
-Although, ssh caching is perhaps even more important, since
-it avoids a tcp slow start having to be done for each file
-that's transferred. So make sure it's working.
-
-Even with those, I would not expect git-annex to be as efficient
-as pure rsync of a directory. git-annex's more general design mean
-that there are more moving parts..
-"""]]
diff --git a/doc/todo/wishlist__58___rsync_efficiency/comment_2_d87df8f1012f71248ed33f64f9ace17e._comment b/doc/todo/wishlist__58___rsync_efficiency/comment_2_d87df8f1012f71248ed33f64f9ace17e._comment
deleted file mode 100644
index 3acd6b74b7..0000000000
--- a/doc/todo/wishlist__58___rsync_efficiency/comment_2_d87df8f1012f71248ed33f64f9ace17e._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
- nickname="Richard"
- subject="comment 2"
- date="2015-04-20T14:37:03Z"
- content="""
-I read the blog after my time abroad and chuckled about the timing of my request, yah :)
-
-Could git-annex reasonably detach generating the list of files to transfer from the actual transfer? That way, there is never a delay while git-annex looks for the next file.
-
-Richard
-"""]]
diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn
deleted file mode 100644
index 40eecbd758..0000000000
--- a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-Apart from Tahoe-LAFS (covered by [[todo/tahoe lfs for reals]] and [[forum/tips: special_remotes/hook with tahoe-lafs]]), [[special remotes]] (which I understand as real storage backends) for other other [peer network data stores](http://en.wikipedia.org/wiki/Distributed_data_store#Peer_network_node_data_stores_2) would be interesting.
-
-I mean gnunet, freenet, BitTorrent (also trackerless).
-
-Before dropping a file locally, the BitTorrent client should check that all parts are still available from the peers.
-
-Of course, there is no guarantee assumed that the content won't disappear from the peer network in future: they act more like a cache rather than an archive on whose lifespan you decide. (I'm only not sure about gnunet now: whether there is a rule of dropping unused content from it, like in freenet.)
-
-So, a copy in peer networks shouldn't be counted on by git-annex as much as a copy on a storage you control: probably, by efault, it shouldn't let you delete the local copy if there is a copy in a peer network unless you saved it somewhere else. 
-
-(Think of such a scenario: I could save some of my public large data on external disks/DVDs and keep them at home, and also put them onto peer networks with the same nterface of git-annex which I would be used to; I would also use the git-annex interface to check from time to time that the content is still present, i.e. "cached", on the peer networks. Whenever I'm away from home, and unexpectedly need to show this content to someone, or have a look at it for some reason, I could get it from the peer network "cache".)
-
-Also networks like namecoin (derived from bitcoin) can be used as a key-value store. Despite being a peer network, a system like namecoin actually could offer the publisher more control over the lifespan of the content: he should be able to offer "financial" reward for others processing his key-value data. (But I'm not sure namecoin is designed reasonably for this reward system to work actually; but there might be appearing other similar systems.)
-
-## A different view: extend the key-value backends with ways to look for the content in other content-addressable storage systems
-We might want to look for the registered files in other [content-addressable storage systems](http://en.wikipedia.org/wiki/Content-addressable_storage#Open-source_implementations) (and also to be able to put the files there for storage).
-
-For example:
-
-* [**GNUnet**](http://en.wikipedia.org/wiki/Gnunet) uses its own hash format to address the content. git-annex could extend its own [[backends]] with a one to work with GNUnet, and by default have a built-in [[special remote|special remotes]] that would interact with GNUnet when looking for a content or storing some content. No special setup of the special remote in each repo should be necessary, because GNUnet is "global", so we'd just use the user's already configured GNUnet client. Just turning the builtin GNUnet special remote on or off should be an option (in the repo configuration, and when calling the commands that would query it, like `whereis`).
-* **freenet** is similar.
-* Similarly, a backend  for the hashes used in **BitTorrent** and **magnet links** could be used. If we want a trackerless mode, then probably it's a similar case for a "global"/built-in special remote that needs no local setup in each repo. Using a selected tracker would mean setting up a special remote in our repo.
-* **Git**  itself can be viwed as place to look for the content. There could be a corresponding backend and a builtin special remote (needing no extra setup) to look for the content among the objects stored in the local Git repo. (What if we have a copy of a file that we've put under the control of git-annex in a previous Git commit? We could get it from the object store of Git.)
-* **Venti**, [[**Tahoe-LAFS**|todo/tahoe lfs for reals]] would need a backend for their hashes, and a specially setup special remote in each repo where we'd like to use them--because these are not "global" system, we must setup the path to the instance of the filesystem we'd like to use.
-* probably, there must be other interesting cases of this kind...
-* (I'm also thinking about using somethng like a **bibliographic information** as a key, but then it wouldn't guarantee identical files: the same paper can be stored in different formats, etc. Cf. [**URNs**](http://en.wikipedia.org/wiki/Uniform_resource_name#Examples), via . Also, an URN like bibliographic information can't be computed from the file, it will have to be entered manually or obtained from another directory of URNs.)
-
-> I don't think there is anything else to do in git-annex, it has
-> everything necessary to let people create such external special remotes
-> and several of the ones discussed here actually exist now. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_1_e2c2047e7401cb95a82ffb686a732859._comment b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_1_e2c2047e7401cb95a82ffb686a732859._comment
deleted file mode 100644
index 80a245d144..0000000000
--- a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_1_e2c2047e7401cb95a82ffb686a732859._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.153.14.141"
- subject="comment 1"
- date="2012-09-25T22:57:19Z"
- content="""
-The best first step to adding such kinds of data stores to git-annex is probably to use the [[special_remotes/hook]] special remote to access them. 
-"""]]
diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_2_472b576afdb169b233edd01adcb2123d._comment b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_2_472b576afdb169b233edd01adcb2123d._comment
deleted file mode 100644
index c58f97c1cb..0000000000
--- a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_2_472b576afdb169b233edd01adcb2123d._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://lj.rossia.org/users/imz/"
- ip="79.165.56.162"
- subject="comment 2"
- date="2012-09-25T23:29:49Z"
- content="""
-I see. But then, as with Tahoe-LAFS, they also have their own formats for checksums, keys, which could be re-used in git-annex, and that needs special treatment.
-"""]]
diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_3_b4ff519ece76c6c3fb29b981320e2e1c._comment b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_3_b4ff519ece76c6c3fb29b981320e2e1c._comment
deleted file mode 100644
index dac3331740..0000000000
--- a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_3_b4ff519ece76c6c3fb29b981320e2e1c._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.154"
- subject="comment 3"
- date="2014-03-18T19:49:09Z"
- content="""
-The new [[special_remotes/external]] special remote's protocol has GETSTATE and SETSTATE commands that can be used to store per-remote values in the git-annex branch.
-
-So, please go make these special remotes using it!
-"""]]
diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_4_469c952a131d2aac45615afb3a69d10c._comment b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_4_469c952a131d2aac45615afb3a69d10c._comment
deleted file mode 100644
index 4fd2ddc210..0000000000
--- a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_4_469c952a131d2aac45615afb3a69d10c._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730"
- nickname="0xloem"
- subject="freenet special remote"
- date="2016-04-09T10:37:22Z"
- content="""
-I've gotten derailed, but in case somebody else is interested for now, I've started a freenet special remote at https://github.com/xloem/gitlakepy .  Also includes beginnings of a generic python class for special remotes in the same scriptfile.
-
-SETSTATE is helpful but doesn't allow for any form of hashing the file offline, to ensure the hash matches.  It means there could be data corruption uploading the file and there would be no way to check that the hash matched the local data.  It would be nice to provide new hashing backends as well, perhaps then somebody could make a multi-hash which stores different hashes side-by-side to resolve such paranoia.
-
-I guess for now the right way to do these things is to add the new capabilities straight to the internals of git-annex, but learning haskell is an adventure when time is a constraint.
-"""]]
diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_5_0c40bb64126957a25ec1b20dc856529c._comment b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_5_0c40bb64126957a25ec1b20dc856529c._comment
deleted file mode 100644
index f345043dfe..0000000000
--- a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_5_0c40bb64126957a25ec1b20dc856529c._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="xloem"
- subject="Freenet Special Remote"
- date="2016-05-19T03:02:18Z"
- content="""
-The freenet external special remote at https://github.com/xloem/gitlakepy is working now.
-
-No bells and whistles, but you can install it and start git-annex copy --to=freenet and git-annex get --from=freenet .
-"""]]
diff --git a/doc/todo/wishlist__58___special_remote_Ubuntu_One.mdwn b/doc/todo/wishlist__58___special_remote_Ubuntu_One.mdwn
deleted file mode 100644
index 964045899b..0000000000
--- a/doc/todo/wishlist__58___special_remote_Ubuntu_One.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-Special remote support for [Ubuntu One](http://one.ubuntu.com) would be nice. They're [using propietary but open protocol](https://wiki.ubuntu.com/UbuntuOne/TechnicalDetails#ubuntuone-storageprotocol) based on [Google Protocol Buffers](http://code.google.com/p/protobuf/). There's [protobuf for Haskell](http://code.google.com/p/protobuf-haskell/) so it should be possible to compile [the protocol file](http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk/view/head:/ubuntuone/storageprotocol/protocol.proto) to Haskell code and then use that to implement the native Ubuntu special remote.
-
-> [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___special_remote_Ubuntu_One/comment_1_ab0c761030bc55e8fb75d1b344bb98b9._comment b/doc/todo/wishlist__58___special_remote_Ubuntu_One/comment_1_ab0c761030bc55e8fb75d1b344bb98b9._comment
deleted file mode 100644
index 4fb9bc95ea..0000000000
--- a/doc/todo/wishlist__58___special_remote_Ubuntu_One/comment_1_ab0c761030bc55e8fb75d1b344bb98b9._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.154"
- subject="comment 1"
- date="2014-03-18T20:02:14Z"
- content="""
-I suggest that if someone wants to build this, they use the new external special remote protocol to do it.
-"""]]
diff --git a/doc/todo/wishlist__58___special_remote_Ubuntu_One/comment_2_17e948acb1e29793cf172cd6def4160b._comment b/doc/todo/wishlist__58___special_remote_Ubuntu_One/comment_2_17e948acb1e29793cf172cd6def4160b._comment
deleted file mode 100644
index 20230e3f98..0000000000
--- a/doc/todo/wishlist__58___special_remote_Ubuntu_One/comment_2_17e948acb1e29793cf172cd6def4160b._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="madduck"
- ip="2001:a60:f0fb:0:224:d7ff:fe04:c82c"
- subject="Ubuntu One to be discontinued"
- date="2014-04-07T05:11:52Z"
- content="""
-Thanksfully, Canonical have stopped this silliness, Ubuntu One will be discontinued, so this todo can be marked \"wontfix\" and archived.
-"""]]