Remove closed bugs and todos that were last edited or commented before 2022.
Except for ones tagged projects/* since projects like datalad want to keep
around records of old deleted bugs longer.
Command line used:
for f in $(grep -l '|done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2022 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2022 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done
for f in $(grep -l '\[\[done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2022 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2022 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done
+++ /dev/null
-### Please describe the problem.
-
-cryptonite supports the hash skein512_256, which is just a truncated version of skein512. Could you please add support for using this as a key-value backend? Please note that cryptohash doesn't support this hash, so it'll have to go into the ifdef block alongside the sha3 hashes.
-
-Rationale: I've just done a benchmark of the different hash implementations in cryptonite, and the skein hashes beat all other hashes (except md5) by a large margin, so I'd like to use them. As with the other hashes, skein512 is a bit faster than skein256 (on x86-64), but I'd like to avoid the overly long file names it produces.
-
-
-### 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 just trying git-annex for the first time, but it definitly looks great.
-
-> Ok, going to reject this since the speedup is minimal, and there are
-> other faster hashes anyway, like blake2. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-10-31T16:54:30Z"
- content="""
-What kind of performance benefit are we talking about here?
-
-It seems it would be a bit hard to implement this, since Backend.Hash uses
-a HashSize that is just an Int, which would have to be extended with the
-number of bits to use of a longer hash. Not hard hard but it will
-complicate the code.
-
-(Also, the name "SKEIN512_256" is pretty long itself to include in a
-filename.")
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="aranea@650e41fad422f2a4d6f36ca1f20d41b7c0f18ab7"
- nickname="aranea"
- avatar="http://cdn.libravatar.org/avatar/8574023ce00757ca95b1708b7306602a"
- subject="comment 2"
- date="2016-10-31T21:29:42Z"
- content="""
-> What kind of performance benefit are we talking about here?
-
-Not much. In my benchmark, SKEIN512 was about 10% faster thank SKEIN256, and SKEIN256 has quite reasonable speed anyway. Thus, adding SKEIN512_256 is not neccessary if it complicated the code too much.
-
-Thanks anyway!
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Adding new files to a gcrypt remote ends up eating all inodes.
-
-### What steps will reproduce the problem?
-
-I have a docs directory, 780 files in it, various types, various subdirectories. I add these to a git annex repo. Create a gcrypt remote on a usb drive and use assistant to copy. Eventually all sorts of stuff stops working since there are no inodes left.
-
-### What version of git-annex are you using? On what operating system?
-
-Arch Linux 64 bit, stable. Git annex 6.20160613-8
-
-### 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
-
-Remote bare repo looks as follows:
-
- annex/objects - contains 4096 directories (000, 001, ...)
-
- annex/objects/XXX - contains ~1380 directories (001, ...)
-
- annex/objects/XXX/XXX - contains two or three directories, e.g. GPGHMACSHA1--3939af6b89c30015490ce9e19f9051bb9e9fe64e
-
- annex/objects/XXX/XXX/GPGHMACSHA1-XXXX - contains one or two files of the same name
-
-Let's multiply that out: 4096 * 1380 * 2 * 2 = 22,609,920
-
-Plus . and .. for all the directories, and boom, all my 59 million inodes are gone, before I even manage to store my 780 files!
-
-Disk is about 20% full.
-
-
-# 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)
-
-
-
-[[!tag moreinfo]]
-
-> [[closing|done]], the bug reporter did not seem to show that this was a
-> bug and not just an unfortunate case of too many versions of files.
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-10-05T16:56:25Z"
- content="""
-If your remote contains 4096*1380 "GPGHMACSHA1" directories
-with files in them then there are apparently 5652480 annexed objects
-stored in this remote... not 780.
-
-Unless the files in those directories are not the encrypted content
-of annexed objects, but I don't know what else they could be.
-
-You'll need to follow up with more information about what these files are,
-or a way to reproduce this.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="pot"
- subject="780 source files...."
- date="2016-10-06T20:05:41Z"
- content="""
-... annex on removeable disk somehow had a lot more!
-
-I don't know what they are, but all files had of the same format, e.g.:
-
- annex/objects/XXX/YYY/GPGHMACSHA1--ZZZ/GPGHMACSHA1--ZZZ
-
-which I believe is the correct structure, just that the sheer number of XXX, YYY and ZZZ was way too many. I have no idea what the assistant was doing, if it was failed uploads retrying, or what made it repeatedly spazz out and store that many files. I gave up with the assistant in the end and started again (3rd time, first time irrecoverable corruption raised in another bug that is apparently a gcrypt-remote one). The entirety of my computer doesn't come remotely close to 59 million inodes used, so pretty safe to say this issue isn't caused by user error uploading too many files or syncing the wrong directory and not realising it.
-
-I tried to decrypt one of the objects to have a look at it, maybe see what it was or where it came from, but got the following:
-
- $> gpg --decrypt docs.old/annex/objects/005/030/GPGHMACSHA1--5095b828bd5b51c2e21fe2c73882228fa39e396b/GPGHMACSHA1--5095b828bd5b51c2e21fe2c73882228fa39e396b
- gpg: AES encrypted data
- gpg: encrypted with 1 passphrase
- gpg: decryption failed: Bad session key
-
-Which confused me, where did AES get involved??
-
-I have had an rsync going for days on end trying to clear the inodes to avoid reformatting the disk
-
-I'm persisting with tying to use git-annex, this time manually without the assistant. Just setting wanted/group as appropriate and a cron job to run \"add, sync, sync --content, unload\" every 5 minutes.
-
-
-In terms of reproducing it, all I did was point the assistant at my docs directory and then set up a USB drive as a gcrypt remote. I did nothing manually.
-
-Here is some of the log of the rsync delete I have going (running since I raised this bug):
-
-...
-...
-deleting annex/objects/247/724/GPGHMACSHA1--170c379656e6b4a9c8a6ba40eea0b6abbe9af068/GPGHMACSHA1--170c379656e6b4a9c8a6ba40eea0b6abbe9af068
-deleting annex/objects/247/724/GPGHMACSHA1--170c379656e6b4a9c8a6ba40eea0b6abbe9af068/
-deleting annex/objects/247/724/
-deleting annex/objects/247/723/GPGHMACSHA1--935ea8024d049197aa924ae270008a2c46bcfd26/GPGHMACSHA1--935ea8024d049197aa924ae270008a2c46bcfd26
-deleting annex/objects/247/723/GPGHMACSHA1--935ea8024d049197aa924ae270008a2c46bcfd26/
-deleting annex/objects/247/723/GPGHMACSHA1--01ba35ae3734d4fa0a3f6a128cf630b2c413a880/GPGHMACSHA1--01ba35ae3734d4fa0a3f6a128cf630b2c413a880
-deleting annex/objects/247/723/GPGHMACSHA1--01ba35ae3734d4fa0a3f6a128cf630b2c413a880/
-deleting annex/objects/247/723/
-deleting annex/objects/247/722/GPGHMACSHA1--71dc0291cb090d1b56aeed3c613b9ab0d09e5bf1/GPGHMACSHA1--71dc0291cb090d1b56aeed3c613b9ab0d09e5bf1
-deleting annex/objects/247/722/GPGHMACSHA1--71dc0291cb090d1b56aeed3c613b9ab0d09e5bf1/
-deleting annex/objects/247/722/
-deleting annex/objects/247/720/GPGHMACSHA1--dfd50c4a8b8038c5f1422de11121a53d10c2ee2b/GPGHMACSHA1--dfd50c4a8b8038c5f1422de11121a53d10c2ee2b
-deleting annex/objects/247/720/GPGHMACSHA1--dfd50c4a8b8038c5f1422de11121a53d10c2ee2b/
-deleting annex/objects/247/720/
-deleting annex/objects/247/71d/GPGHMACSHA1--7846c602f4482b9799d74fa43626c04e13a54fd1/GPGHMACSHA1--7846c602f4482b9799d74fa43626c04e13a54fd1
-deleting annex/objects/247/71d/GPGHMACSHA1--7846c602f4482b9799d74fa43626c04e13a54fd1/
-deleting annex/objects/247/71d/
-deleting annex/objects/247/715/GPGHMACSHA1--b374ce280c695995b6fa53d8e69ddb26d0f78407/GPGHMACSHA1--b374ce280c695995b6fa53d8e69ddb26d0f78407
-deleting annex/objects/247/715/GPGHMACSHA1--b374ce280c695995b6fa53d8e69ddb26d0f78407/
-deleting annex/objects/247/715/
-deleting annex/objects/247/714/GPGHMACSHA1--aa189f81ef2897d7db35a54b93eceab81d0d50eb/GPGHMACSHA1--aa189f81ef2897d7db35a54b93eceab81d0d50eb
-deleting annex/objects/247/714/GPGHMACSHA1--aa189f81ef2897d7db35a54b93eceab81d0d50eb/
-deleting annex/objects/247/714/
-deleting annex/objects/247/70f/GPGHMACSHA1--c464d300ff73fec5c54cb901f827e6485b0e718d/GPGHMACSHA1--c464d300ff73fec5c54cb901f827e6485b0e718d
-deleting annex/objects/247/70f/GPGHMACSHA1--c464d300ff73fec5c54cb901f827e6485b0e718d/
-deleting annex/objects/247/70f/GPGHMACSHA1--6f4b104a14b0ff7e706d2c41cec5dfba88ea8dc2/GPGHMACSHA1--6f4b104a14b0ff7e706d2c41cec5dfba88ea8dc2
-deleting annex/objects/247/70f/GPGHMACSHA1--6f4b104a14b0ff7e706d2c41cec5dfba88ea8dc2/
-deleting annex/objects/247/70f/
-deleting annex/objects/247/70a/GPGHMACSHA1--ce4d890fe1bbe3f04073898b23a7d034b1f40e13/GPGHMACSHA1--ce4d890fe1bbe3f04073898b23a7d034b1f40e13
-deleting annex/objects/247/70a/GPGHMACSHA1--ce4d890fe1bbe3f04073898b23a7d034b1f40e13/
-deleting annex/objects/247/70a/
-deleting annex/objects/247/709/GPGHMACSHA1--6b33a1aa533172c104a5d9d46a6474336f7cb483/GPGHMACSHA1--6b33a1aa533172c104a5d9d46a6474336f7cb483
-deleting annex/objects/247/709/GPGHMACSHA1--6b33a1aa533172c104a5d9d46a6474336f7cb483/
-deleting annex/objects/247/709/
-deleting annex/objects/247/703/GPGHMACSHA1--ddb04cfcbcf0f02e2d66d94c445f4465a2821e5c/GPGHMACSHA1--ddb04cfcbcf0f02e2d66d94c445f4465a2821e5c
-deleting annex/objects/247/703/GPGHMACSHA1--ddb04cfcbcf0f02e2d66d94c445f4465a2821e5c/
-deleting annex/objects/247/703/GPGHMACSHA1--ae64586876848866ff2ceccc5edf85710becb033/GPGHMACSHA1--ae64586876848866ff2ceccc5edf85710becb033
-deleting annex/objects/247/703/GPGHMACSHA1--ae64586876848866ff2ceccc5edf85710becb033/
-deleting annex/objects/247/703/
-deleting annex/objects/247/6fe/GPGHMACSHA1--44debae83909c6c8b274df7946f067810ce2e021/GPGHMACSHA1--44debae83909c6c8b274df7946f067810ce2e021
-deleting annex/objects/247/6fe/GPGHMACSHA1--44debae83909c6c8b274df7946f067810ce2e021/
-deleting annex/objects/247/6fe/
-deleting annex/objects/247/6f3/GPGHMACSHA1--a6daa142be6a8b89577d24a385e6e3a2766e7c4d/GPGHMACSHA1--a6daa142be6a8b89577d24a385e6e3a2766e7c4d
-deleting annex/objects/247/6f3/GPGHMACSHA1--a6daa142be6a8b89577d24a385e6e3a2766e7c4d/
-deleting annex/objects/247/6f3/
-deleting annex/objects/247/6f0/GPGHMACSHA1--53357d1e9c86dce96c9531c387e25f4c836536ce/GPGHMACSHA1--53357d1e9c86dce96c9531c387e25f4c836536ce
-deleting annex/objects/247/6f0/GPGHMACSHA1--53357d1e9c86dce96c9531c387e25f4c836536ce/
-deleting annex/objects/247/6f0/
-deleting annex/objects/247/6ef/GPGHMACSHA1--1e9bd6ff153221c26657f69e01e8c7a9c29957b7/GPGHMACSHA1--1e9bd6ff153221c26657f69e01e8c7a9c29957b7
-deleting annex/objects/247/6ef/GPGHMACSHA1--1e9bd6ff153221c26657f69e01e8c7a9c29957b7/
-deleting annex/objects/247/6ef/
-deleting annex/objects/247/6ec/GPGHMACSHA1--7a8ccc28b9131111774b8e3221f9f0c4abfd8597/GPGHMACSHA1--7a8ccc28b9131111774b8e3221f9f0c4abfd8597
-deleting annex/objects/247/6ec/GPGHMACSHA1--7a8ccc28b9131111774b8e3221f9f0c4abfd8597/
-deleting annex/objects/247/6ec/
-deleting annex/objects/247/6eb/GPGHMACSHA1--2ad823b488c9b0a90151816030fc98f3e5230ba3/GPGHMACSHA1--2ad823b488c9b0a90151816030fc98f3e5230ba3
-deleting annex/objects/247/6eb/GPGHMACSHA1--2ad823b488c9b0a90151816030fc98f3e5230ba3/
-deleting annex/objects/247/6eb/
-deleting annex/objects/247/6ea/GPGHMACSHA1--02f576c0a7387f32a3951c4200c96c545dad26df/GPGHMACSHA1--02f576c0a7387f32a3951c4200c96c545dad26df
-deleting annex/objects/247/6ea/GPGHMACSHA1--02f576c0a7387f32a3951c4200c96c545dad26df/
-deleting annex/objects/247/6ea/
-deleting annex/objects/247/6e4/GPGHMACSHA1--29322261b9d5656e6aad6a996243e9af3bd1f044/GPGHMACSHA1--29322261b9d5656e6aad6a996243e9af3bd1f044
-deleting annex/objects/247/6e4/GPGHMACSHA1--29322261b9d5656e6aad6a996243e9af3bd1f044/
-deleting annex/objects/247/6e4/
-deleting annex/objects/247/6e3/GPGHMACSHA1--a6fdcce68aba986ccdd08380c74033ba0d2fc34b/GPGHMACSHA1--a6fdcce68aba986ccdd08380c74033ba0d2fc34b
-deleting annex/objects/247/6e3/GPGHMACSHA1--a6fdcce68aba986ccdd08380c74033ba0d2fc34b/
-deleting annex/objects/247/6e3/
-deleting annex/objects/247/6de/GPGHMACSHA1--6a20df04e80c0bbb110283421249eff2a6c28116/GPGHMACSHA1--6a20df04e80c0bbb110283421249eff2a6c28116
-deleting annex/objects/247/6de/GPGHMACSHA1--6a20df04e80c0bbb110283421249eff2a6c28116/
-deleting annex/objects/247/6de/
-deleting annex/objects/247/6dc/GPGHMACSHA1--c29f40d89cc64dfbf0d54ce1645bed4a6bf38391/GPGHMACSHA1--c29f40d89cc64dfbf0d54ce1645bed4a6bf38391
-deleting annex/objects/247/6dc/GPGHMACSHA1--c29f40d89cc64dfbf0d54ce1645bed4a6bf38391/
-deleting annex/objects/247/6dc/
-deleting annex/objects/247/6da/GPGHMACSHA1--ea7e87aef54d57aa148e14e52a4c2e8edcdd7ada/GPGHMACSHA1--ea7e87aef54d57aa148e14e52a4c2e8edcdd7ada
-deleting annex/objects/247/6da/GPGHMACSHA1--ea7e87aef54d57aa148e14e52a4c2e8edcdd7ada/
-deleting annex/objects/247/6da/
-deleting annex/objects/247/6d9/GPGHMACSHA1--77b13817763688dbacca4a1740d3b2f44c0c107f/GPGHMACSHA1--77b13817763688dbacca4a1740d3b2f44c0c107f
-deleting annex/objects/247/6d9/GPGHMACSHA1--77b13817763688dbacca4a1740d3b2f44c0c107f/
-deleting annex/objects/247/6d9/
-deleting annex/objects/247/6d2/GPGHMACSHA1--8a8604b14a9688aa7ff1fedf5641936c09bf5cca/GPGHMACSHA1--8a8604b14a9688aa7ff1fedf5641936c09bf5cca
-deleting annex/objects/247/6d2/GPGHMACSHA1--8a8604b14a9688aa7ff1fedf5641936c09bf5cca/
-deleting annex/objects/247/6d2/
-deleting annex/objects/247/6d1/GPGHMACSHA1--2537ac0a72d33099d5a56f92b3dc640e162ef07d/GPGHMACSHA1--2537ac0a72d33099d5a56f92b3dc640e162ef07d
-deleting annex/objects/247/6d1/GPGHMACSHA1--2537ac0a72d33099d5a56f92b3dc640e162ef07d/
-deleting annex/objects/247/6d1/
-deleting annex/objects/247/6cf/GPGHMACSHA1--c93779f6b21b2abd2c66992189b7d7febb9dcf07/GPGHMACSHA1--c93779f6b21b2abd2c66992189b7d7febb9dcf07
-deleting annex/objects/247/6cf/GPGHMACSHA1--c93779f6b21b2abd2c66992189b7d7febb9dcf07/
-deleting annex/objects/247/6cf/GPGHMACSHA1--41e57e9679361202c970960559613c7760583b3c/GPGHMACSHA1--41e57e9679361202c970960559613c7760583b3c
-deleting annex/objects/247/6cf/GPGHMACSHA1--41e57e9679361202c970960559613c7760583b3c/
-deleting annex/objects/247/6cf/GPGHMACSHA1--1287b5adc699aafcfac67428df18f072132b0822/GPGHMACSHA1--1287b5adc699aafcfac67428df18f072132b0822
-deleting annex/objects/247/6cf/GPGHMACSHA1--1287b5adc699aafcfac67428df18f072132b0822/
-deleting annex/objects/247/6cf/
-deleting annex/objects/247/6c6/GPGHMACSHA1--98f5cda5e44596b0e05e090ac939da231bab7ea3/GPGHMACSHA1--98f5cda5e44596b0e05e090ac939da231bab7ea3
-deleting annex/objects/247/6c6/GPGHMACSHA1--98f5cda5e44596b0e05e090ac939da231bab7ea3/
-deleting annex/objects/247/6c6/
-deleting annex/objects/247/6c4/GPGHMACSHA1--d94155d9f8f97c5f5ea5cf0323f31f4d9a08fd36/GPGHMACSHA1--d94155d9f8f97c5f5ea5cf0323f31f4d9a08fd36
-deleting annex/objects/247/6c4/GPGHMACSHA1--d94155d9f8f97c5f5ea5cf0323f31f4d9a08fd36/
-deleting annex/objects/247/6c4/
-deleting annex/objects/247/6bf/GPGHMACSHA1--4bb623be83d6d356cbfda0f64fec95c3ffdbcf11/GPGHMACSHA1--4bb623be83d6d356cbfda0f64fec95c3ffdbcf11
-deleting annex/objects/247/6bf/GPGHMACSHA1--4bb623be83d6d356cbfda0f64fec95c3ffdbcf11/
-deleting annex/objects/247/6bf/GPGHMACSHA1--06e160bda37431fde974f254cb42ff4c531f9d63/GPGHMACSHA1--06e160bda37431fde974f254cb42ff4c531f9d63
-deleting annex/objects/247/6bf/GPGHMACSHA1--06e160bda37431fde974f254cb42ff4c531f9d63/
-deleting annex/objects/247/6bf/
-deleting annex/objects/247/6be/GPGHMACSHA1--1633dd22b403d8ec0076b3138368179b0c05a930/GPGHMACSHA1--1633dd22b403d8ec0076b3138368179b0c05a930
-deleting annex/objects/247/6be/GPGHMACSHA1--1633dd22b403d8ec0076b3138368179b0c05a930/
-deleting annex/objects/247/6be/
-deleting annex/objects/247/6ba/GPGHMACSHA1--877bc52ac9977b3d1cb1772c4af6ea15b6e5a9c6/GPGHMACSHA1--877bc52ac9977b3d1cb1772c4af6ea15b6e5a9c6
-deleting annex/objects/247/6ba/GPGHMACSHA1--877bc52ac9977b3d1cb1772c4af6ea15b6e5a9c6/
-deleting annex/objects/247/6ba/
-deleting annex/objects/247/6b6/GPGHMACSHA1--f997fe07af28421edd2cfc8b2584660a03f37a00/GPGHMACSHA1--f997fe07af28421edd2cfc8b2584660a03f37a00
-deleting annex/objects/247/6b6/GPGHMACSHA1--f997fe07af28421edd2cfc8b2584660a03f37a00/
-deleting annex/objects/247/6b6/
-deleting annex/objects/247/6b4/GPGHMACSHA1--aba2860a370b2683bba2dfefd203db8f830f80a4/GPGHMACSHA1--aba2860a370b2683bba2dfefd203db8f830f80a4
-deleting annex/objects/247/6b4/GPGHMACSHA1--aba2860a370b2683bba2dfefd203db8f830f80a4/
-deleting annex/objects/247/6b4/
-deleting annex/objects/247/6b2/GPGHMACSHA1--90586dbd99e4a55a4a98153d9813241e342a0cfc/GPGHMACSHA1--90586dbd99e4a55a4a98153d9813241e342a0cfc
-deleting annex/objects/247/6b2/GPGHMACSHA1--90586dbd99e4a55a4a98153d9813241e342a0cfc/
-deleting annex/objects/247/6b2/
-deleting annex/objects/247/6b1/GPGHMACSHA1--e3bcf6e224b064505016cec6771f5ceaa6dbed67/GPGHMACSHA1--e3bcf6e224b064505016cec6771f5ceaa6dbed67
-deleting annex/objects/247/6b1/GPGHMACSHA1--e3bcf6e224b064505016cec6771f5ceaa6dbed67/
-deleting annex/objects/247/6b1/
-deleting annex/objects/247/6ac/GPGHMACSHA1--bf584a5c38c33bf14ad05b6219ac244e02aa251b/GPGHMACSHA1--bf584a5c38c33bf14ad05b6219ac244e02aa251b
-deleting annex/objects/247/6ac/GPGHMACSHA1--bf584a5c38c33bf14ad05b6219ac244e02aa251b/
-deleting annex/objects/247/6ac/
-deleting annex/objects/247/6ab/GPGHMACSHA1--6685b79b3450bb3386f9aecf77b0df9254d8aeff/GPGHMACSHA1--6685b79b3450bb3386f9aecf77b0df9254d8aeff
-deleting annex/objects/247/6ab/GPGHMACSHA1--6685b79b3450bb3386f9aecf77b0df9254d8aeff/
-deleting annex/objects/247/6ab/
-deleting annex/objects/247/6aa/GPGHMACSHA1--47ba5e85f50805512695e9981ca4e65a34fb49e2/GPGHMACSHA1--47ba5e85f50805512695e9981ca4e65a34fb49e2
-deleting annex/objects/247/6aa/GPGHMACSHA1--47ba5e85f50805512695e9981ca4e65a34fb49e2/
-deleting annex/objects/247/6aa/
-deleting annex/objects/247/6a9/GPGHMACSHA1--98818b49a059bdf24b7292d39301bc8fa800997e/GPGHMACSHA1--98818b49a059bdf24b7292d39301bc8fa800997e
-deleting annex/objects/247/6a9/GPGHMACSHA1--98818b49a059bdf24b7292d39301bc8fa800997e/
-deleting annex/objects/247/6a9/GPGHMACSHA1--5d433de5bf5f8af586839e6f6e5881394ce7753c/GPGHMACSHA1--5d433de5bf5f8af586839e6f6e5881394ce7753c
-deleting annex/objects/247/6a9/GPGHMACSHA1--5d433de5bf5f8af586839e6f6e5881394ce7753c/
-deleting annex/objects/247/6a9/
-deleting annex/objects/247/6a7/GPGHMACSHA1--842b4d379b833766f57d81eb8d9a7f59dc9e7e32/GPGHMACSHA1--842b4d379b833766f57d81eb8d9a7f59dc9e7e32
-deleting annex/objects/247/6a7/GPGHMACSHA1--842b4d379b833766f57d81eb8d9a7f59dc9e7e32/
-deleting annex/objects/247/6a7/
-deleting annex/objects/247/6a5/GPGHMACSHA1--faa62d0c76cfa51b0bf983cd981143ae0a8e644b/GPGHMACSHA1--faa62d0c76cfa51b0bf983cd981143ae0a8e644b
-deleting annex/objects/247/6a5/GPGHMACSHA1--faa62d0c76cfa51b0bf983cd981143ae0a8e644b/
-deleting annex/objects/247/6a5/
-deleting annex/objects/247/6a2/GPGHMACSHA1--8b22e4cec5e8d7413eaf4eeb116c45cae4aad4a7/GPGHMACSHA1--8b22e4cec5e8d7413eaf4eeb116c45cae4aad4a7
-deleting annex/objects/247/6a2/GPGHMACSHA1--8b22e4cec5e8d7413eaf4eeb116c45cae4aad4a7/
-deleting annex/objects/247/6a2/
-deleting annex/objects/247/6a0/GPGHMACSHA1--cc12f74b40a0dc2b2f962884be0de5f129dd2f29/GPGHMACSHA1--cc12f74b40a0dc2b2f962884be0de5f129dd2f29
-deleting annex/objects/247/6a0/GPGHMACSHA1--cc12f74b40a0dc2b2f962884be0de5f129dd2f29/
-deleting annex/objects/247/6a0/GPGHMACSHA1--6d3ea0b051d26b9fd33bd50e913edc8bb7958802/GPGHMACSHA1--6d3ea0b051d26b9fd33bd50e913edc8bb7958802
-deleting annex/objects/247/6a0/GPGHMACSHA1--6d3ea0b051d26b9fd33bd50e913edc8bb7958802/
-deleting annex/objects/247/6a0/
-deleting annex/objects/247/69e/GPGHMACSHA1--8bf51eb698b413e2e26228f05ea46e50eed90ecd/GPGHMACSHA1--8bf51eb698b413e2e26228f05ea46e50eed90ecd
-deleting annex/objects/247/69e/GPGHMACSHA1--8bf51eb698b413e2e26228f05ea46e50eed90ecd/
-deleting annex/objects/247/69e/
-deleting annex/objects/247/69c/GPGHMACSHA1--8e4ae21aea3fac1476477010464fa593427637bb/GPGHMACSHA1--8e4ae21aea3fac1476477010464fa593427637bb
-deleting annex/objects/247/69c/GPGHMACSHA1--8e4ae21aea3fac1476477010464fa593427637bb/
-deleting annex/objects/247/69c/
-deleting annex/objects/247/69a/GPGHMACSHA1--17a7e2efb6973e644f3a2c46ddf3c23a04252807/GPGHMACSHA1--17a7e2efb6973e644f3a2c46ddf3c23a04252807
-deleting annex/objects/247/69a/GPGHMACSHA1--17a7e2efb6973e644f3a2c46ddf3c23a04252807/
-deleting annex/objects/247/69a/GPGHMACSHA1--038192462f39548fcb767ff68868654a04d3742c/GPGHMACSHA1--038192462f39548fcb767ff68868654a04d3742c
-deleting annex/objects/247/69a/GPGHMACSHA1--038192462f39548fcb767ff68868654a04d3742c/
-deleting annex/objects/247/69a/
-deleting annex/objects/247/699/GPGHMACSHA1--ebf4456aae42a77fbbec10ea4a2dbbef6a3c0376/GPGHMACSHA1--ebf4456aae42a77fbbec10ea4a2dbbef6a3c0376
-deleting annex/objects/247/699/GPGHMACSHA1--ebf4456aae42a77fbbec10ea4a2dbbef6a3c0376/
-deleting annex/objects/247/699/GPGHMACSHA1--e2daee271ea42cc9b5004c38d4271c17403180e3/GPGHMACSHA1--e2daee271ea42cc9b5004c38d4271c17403180e3
-deleting annex/objects/247/699/GPGHMACSHA1--e2daee271ea42cc9b5004c38d4271c17403180e3/
-deleting annex/objects/247/699/
-deleting annex/objects/247/697/GPGHMACSHA1--b25242f316df75d10180bc946d7fe455570f8feb/GPGHMACSHA1--b25242f316df75d10180bc946d7fe455570f8feb
-deleting annex/objects/247/697/GPGHMACSHA1--b25242f316df75d10180bc946d7fe455570f8feb/
-deleting annex/objects/247/697/
-deleting annex/objects/247/695/GPGHMACSHA1--c336852b055947bc7f8de6fb9e10cd0a094713c8/GPGHMACSHA1--c336852b055947bc7f8de6fb9e10cd0a094713c8
-deleting annex/objects/247/695/GPGHMACSHA1--c336852b055947bc7f8de6fb9e10cd0a094713c8/
-deleting annex/objects/247/695/
-deleting annex/objects/247/693/GPGHMACSHA1--9d1a2d8c041969d4665e646868071d5b919e9f48/GPGHMACSHA1--9d1a2d8c041969d4665e646868071d5b919e9f48
-deleting annex/objects/247/693/GPGHMACSHA1--9d1a2d8c041969d4665e646868071d5b919e9f48/
-deleting annex/objects/247/693/
-deleting annex/objects/247/690/GPGHMACSHA1--bdf3ad43c80329313c2615071f4b3425900ddfb5/GPGHMACSHA1--bdf3ad43c80329313c2615071f4b3425900ddfb5
-deleting annex/objects/247/690/GPGHMACSHA1--bdf3ad43c80329313c2615071f4b3425900ddfb5/
-deleting annex/objects/247/690/GPGHMACSHA1--633bc661f6be86898c8b86a0bc617c76c5c05d5b/GPGHMACSHA1--633bc661f6be86898c8b86a0bc617c76c5c05d5b
-deleting annex/objects/247/690/GPGHMACSHA1--633bc661f6be86898c8b86a0bc617c76c5c05d5b/
-deleting annex/objects/247/690/
-deleting annex/objects/247/687/GPGHMACSHA1--a908420b6feadffbef8dc11e26b2c7dd801e62bc/GPGHMACSHA1--a908420b6feadffbef8dc11e26b2c7dd801e62bc
-deleting annex/objects/247/687/GPGHMACSHA1--a908420b6feadffbef8dc11e26b2c7dd801e62bc/
-deleting annex/objects/247/687/GPGHMACSHA1--4854a36dbe98d66523e3f81ba11ae19fa5b000ad/GPGHMACSHA1--4854a36dbe98d66523e3f81ba11ae19fa5b000ad
-deleting annex/objects/247/687/GPGHMACSHA1--4854a36dbe98d66523e3f81ba11ae19fa5b000ad/
-deleting annex/objects/247/687/
-deleting annex/objects/247/680/GPGHMACSHA1--be28ddb2b64ab0d126550f77b08d28003daed9f5/GPGHMACSHA1--be28ddb2b64ab0d126550f77b08d28003daed9f5
-deleting annex/objects/247/680/GPGHMACSHA1--be28ddb2b64ab0d126550f77b08d28003daed9f5/
-deleting annex/objects/247/680/GPGHMACSHA1--32f8b23783ae8c128d59a00cb56415582b7260df/GPGHMACSHA1--32f8b23783ae8c128d59a00cb56415582b7260df
-deleting annex/objects/247/680/GPGHMACSHA1--32f8b23783ae8c128d59a00cb56415582b7260df/
-deleting annex/objects/247/680/
-deleting annex/objects/247/67d/GPGHMACSHA1--cbe506d47fa8c7986af274ade75786348edfe629/GPGHMACSHA1--cbe506d47fa8c7986af274ade75786348edfe629
-deleting annex/objects/247/67d/GPGHMACSHA1--cbe506d47fa8c7986af274ade75786348edfe629/
-deleting annex/objects/247/67d/GPGHMACSHA1--274cf22593002c284739e6bbf055e845b186f758/GPGHMACSHA1--274cf22593002c284739e6bbf055e845b186f758
-deleting annex/objects/247/67d/GPGHMACSHA1--274cf22593002c284739e6bbf055e845b186f758/
-deleting annex/objects/247/67d/
-deleting annex/objects/247/67b/GPGHMACSHA1--6c92d27861fc721994b18c11042c43f06548b7c4/GPGHMACSHA1--6c92d27861fc721994b18c11042c43f06548b7c4
-deleting annex/objects/247/67b/GPGHMACSHA1--6c92d27861fc721994b18c11042c43f06548b7c4/
-deleting annex/objects/247/67b/GPGHMACSHA1--1b72db8f312c84787c2db090b6d8f1470b5101e4/GPGHMACSHA1--1b72db8f312c84787c2db090b6d8f1470b5101e4
-deleting annex/objects/247/67b/GPGHMACSHA1--1b72db8f312c84787c2db090b6d8f1470b5101e4/
-deleting annex/objects/247/67b/
-deleting annex/objects/247/677/GPGHMACSHA1--884eefed2eb49c523b0caddeebbdb4c8c99b124c/GPGHMACSHA1--884eefed2eb49c523b0caddeebbdb4c8c99b124c
-deleting annex/objects/247/677/GPGHMACSHA1--884eefed2eb49c523b0caddeebbdb4c8c99b124c/
-deleting annex/objects/247/677/
-deleting annex/objects/247/671/GPGHMACSHA1--7734e81c47fba2413b6ab20ab53a12d5b2b5fd40/GPGHMACSHA1--7734e81c47fba2413b6ab20ab53a12d5b2b5fd40
-deleting annex/objects/247/671/GPGHMACSHA1--7734e81c47fba2413b6ab20ab53a12d5b2b5fd40/
-deleting annex/objects/247/671/
-deleting annex/objects/247/670/GPGHMACSHA1--a8a923f284a21ab9d51cc8e1043e1ee1e0e1c52d/GPGHMACSHA1--a8a923f284a21ab9d51cc8e1043e1ee1e0e1c52d
-deleting annex/objects/247/670/GPGHMACSHA1--a8a923f284a21ab9d51cc8e1043e1ee1e0e1c52d/
-deleting annex/objects/247/670/
-deleting annex/objects/247/66d/GPGHMACSHA1--afa309fdc40f89129383f2543c5a81ba25377da7/GPGHMACSHA1--afa309fdc40f89129383f2543c5a81ba25377da7
-deleting annex/objects/247/66d/GPGHMACSHA1--afa309fdc40f89129383f2543c5a81ba25377da7/
-deleting annex/objects/247/66d/
-deleting annex/objects/247/66c/GPGHMACSHA1--6242d8b47814f9de875cee4c5cf87fe20761dc6f/GPGHMACSHA1--6242d8b47814f9de875cee4c5cf87fe20761dc6f
-deleting annex/objects/247/66c/GPGHMACSHA1--6242d8b47814f9de875cee4c5cf87fe20761dc6f/
-deleting annex/objects/247/66c/
-deleting annex/objects/247/66b/GPGHMACSHA1--c1e8348121e0aad254a6ee00c721cafefb29a7f8/GPGHMACSHA1--c1e8348121e0aad254a6ee00c721cafefb29a7f8
-deleting annex/objects/247/66b/GPGHMACSHA1--c1e8348121e0aad254a6ee00c721cafefb29a7f8/
-deleting annex/objects/247/66b/GPGHMACSHA1--905f20a5b38c0988d5b47b61ed2476695a3737a4/GPGHMACSHA1--905f20a5b38c0988d5b47b61ed2476695a3737a4
-deleting annex/objects/247/66b/GPGHMACSHA1--905f20a5b38c0988d5b47b61ed2476695a3737a4/
-deleting annex/objects/247/66b/
-deleting annex/objects/247/669/GPGHMACSHA1--3285b2d42125cc37f6d060b4e4f0cf1eebeb8ab8/GPGHMACSHA1--3285b2d42125cc37f6d060b4e4f0cf1eebeb8ab8
-deleting annex/objects/247/669/GPGHMACSHA1--3285b2d42125cc37f6d060b4e4f0cf1eebeb8ab8/
-deleting annex/objects/247/669/
-deleting annex/objects/247/668/GPGHMACSHA1--77c84003474e0d26f0a28c1f12bc1facb661cf88/GPGHMACSHA1--77c84003474e0d26f0a28c1f12bc1facb661cf88
-deleting annex/objects/247/668/GPGHMACSHA1--77c84003474e0d26f0a28c1f12bc1facb661cf88/
-deleting annex/objects/247/668/GPGHMACSHA1--426c97f946ff8a94cd5ef4a6d837165056e65f7b/GPGHMACSHA1--426c97f946ff8a94cd5ef4a6d837165056e65f7b
-deleting annex/objects/247/668/GPGHMACSHA1--426c97f946ff8a94cd5ef4a6d837165056e65f7b/
-deleting annex/objects/247/668/
-deleting annex/objects/247/662/GPGHMACSHA1--daa15474f59cf6b3f205aa382a9aed3d8dccad07/GPGHMACSHA1--daa15474f59cf6b3f205aa382a9aed3d8dccad07
-deleting annex/objects/247/662/GPGHMACSHA1--daa15474f59cf6b3f205aa382a9aed3d8dccad07/
-deleting annex/objects/247/662/
-deleting annex/objects/247/661/GPGHMACSHA1--69dcd6923078d7645fb10dde9da43498d3029672/GPGHMACSHA1--69dcd6923078d7645fb10dde9da43498d3029672
-deleting annex/objects/247/661/GPGHMACSHA1--69dcd6923078d7645fb10dde9da43498d3029672/
-deleting annex/objects/247/661/
-deleting annex/objects/247/65f/GPGHMACSHA1--dd83c0fc950d2d50a518abbf39ae7364f3dfcc2b/GPGHMACSHA1--dd83c0fc950d2d50a518abbf39ae7364f3dfcc2b
-deleting annex/objects/247/65f/GPGHMACSHA1--dd83c0fc950d2d50a518abbf39ae7364f3dfcc2b/
-deleting annex/objects/247/65f/
-deleting annex/objects/247/65d/GPGHMACSHA1--a74379634b5858f29282871be77653dd3bd85f9c/GPGHMACSHA1--a74379634b5858f29282871be77653dd3bd85f9c
-deleting annex/objects/247/65d/GPGHMACSHA1--a74379634b5858f29282871be77653dd3bd85f9c/
-deleting annex/objects/247/65d/
-deleting annex/objects/247/65b/GPGHMACSHA1--e518f349498e334cb42a0badee072b7182ada6a1/GPGHMACSHA1--e518f349498e334cb42a0badee072b7182ada6a1
-deleting annex/objects/247/65b/GPGHMACSHA1--e518f349498e334cb42a0badee072b7182ada6a1/
-deleting annex/objects/247/65b/
-deleting annex/objects/247/657/GPGHMACSHA1--f13db23e398d11e5ae416e6cc26720b2f11139be/GPGHMACSHA1--f13db23e398d11e5ae416e6cc26720b2f11139be
-deleting annex/objects/247/657/GPGHMACSHA1--f13db23e398d11e5ae416e6cc26720b2f11139be/
-deleting annex/objects/247/657/GPGHMACSHA1--1e9325d04e7a8007d0f10dc705a77e4385edb31c/GPGHMACSHA1--1e9325d04e7a8007d0f10dc705a77e4385edb31c
-deleting annex/objects/247/657/GPGHMACSHA1--1e9325d04e7a8007d0f10dc705a77e4385edb31c/
-deleting annex/objects/247/657/
-deleting annex/objects/247/655/GPGHMACSHA1--6f35926c1ddf7f2a5579bca38e89f1902913afe9/GPGHMACSHA1--6f35926c1ddf7f2a5579bca38e89f1902913afe9
-deleting annex/objects/247/655/GPGHMACSHA1--6f35926c1ddf7f2a5579bca38e89f1902913afe9/
-deleting annex/objects/247/655/
-deleting annex/objects/247/654/GPGHMACSHA1--498faf23d8f11a54e87abe6cccb51440b710bc32/GPGHMACSHA1--498faf23d8f11a54e87abe6cccb51440b710bc32
-deleting annex/objects/247/654/GPGHMACSHA1--498faf23d8f11a54e87abe6cccb51440b710bc32/
-deleting annex/objects/247/654/
-deleting annex/objects/247/64f/GPGHMACSHA1--1e7b26f9b7b50d57c892214edce187576980ed1f/GPGHMACSHA1--1e7b26f9b7b50d57c892214edce187576980ed1f
-deleting annex/objects/247/64f/GPGHMACSHA1--1e7b26f9b7b50d57c892214edce187576980ed1f/
-deleting annex/objects/247/64f/
-deleting annex/objects/247/64c/GPGHMACSHA1--37e007dbf5fab4fac696086051aa2169bcc6304c/GPGHMACSHA1--37e007dbf5fab4fac696086051aa2169bcc6304c
-deleting annex/objects/247/64c/GPGHMACSHA1--37e007dbf5fab4fac696086051aa2169bcc6304c/
-deleting annex/objects/247/64c/GPGHMACSHA1--2cd375aad0e7822c9a6737ab3ac8bd2334a6360f/GPGHMACSHA1--2cd375aad0e7822c9a6737ab3ac8bd2334a6360f
-deleting annex/objects/247/64c/GPGHMACSHA1--2cd375aad0e7822c9a6737ab3ac8bd2334a6360f/
-deleting annex/objects/247/64c/
-deleting annex/objects/247/648/GPGHMACSHA1--f22386dec26dd63c7c9021afe20dee4b5de717e2/GPGHMACSHA1--f22386dec26dd63c7c9021afe20dee4b5de717e2
-deleting annex/objects/247/648/GPGHMACSHA1--f22386dec26dd63c7c9021afe20dee4b5de717e2/
-deleting annex/objects/247/648/
-deleting annex/objects/247/646/GPGHMACSHA1--482d0374847fa9150981efb9381e47a05943e217/GPGHMACSHA1--482d0374847fa9150981efb9381e47a05943e217
-deleting annex/objects/247/646/GPGHMACSHA1--482d0374847fa9150981efb9381e47a05943e217/
-deleting annex/objects/247/646/
-deleting annex/objects/247/645/GPGHMACSHA1--eb7c3bea5737f53afeb5809036b6e1ab2b7095de/GPGHMACSHA1--eb7c3bea5737f53afeb5809036b6e1ab2b7095de
-deleting annex/objects/247/645/GPGHMACSHA1--eb7c3bea5737f53afeb5809036b6e1ab2b7095de/
-deleting annex/objects/247/645/
-deleting annex/objects/247/644/GPGHMACSHA1--3a35df0f925001772f434a66bab38fda007c8f35/GPGHMACSHA1--3a35df0f925001772f434a66bab38fda007c8f35
-deleting annex/objects/247/644/GPGHMACSHA1--3a35df0f925001772f434a66bab38fda007c8f35/
-deleting annex/objects/247/644/
-deleting annex/objects/247/63d/GPGHMACSHA1--eebadfddbeb809ff5d55cf8aa0439dd0fe61f7a6/GPGHMACSHA1--eebadfddbeb809ff5d55cf8aa0439dd0fe61f7a6
-deleting annex/objects/247/63d/GPGHMACSHA1--eebadfddbeb809ff5d55cf8aa0439dd0fe61f7a6/
-deleting annex/objects/247/63d/GPGHMACSHA1--bc76727a1097942a34bda9f354110cc9b8cfa256/GPGHMACSHA1--bc76727a1097942a34bda9f354110cc9b8cfa256
-deleting annex/objects/247/63d/GPGHMACSHA1--bc76727a1097942a34bda9f354110cc9b8cfa256/
-deleting annex/objects/247/63d/
-deleting annex/objects/247/63a/GPGHMACSHA1--cf9adc3c0d313b6df391b07588ecc10e07ca0644/GPGHMACSHA1--cf9adc3c0d313b6df391b07588ecc10e07ca0644
-deleting annex/objects/247/63a/GPGHMACSHA1--cf9adc3c0d313b6df391b07588ecc10e07ca0644/
-deleting annex/objects/247/63a/GPGHMACSHA1--7fb424869aea1b4d412e06d2279d63129d51fa12/GPGHMACSHA1--7fb424869aea1b4d412e06d2279d63129d51fa12
-deleting annex/objects/247/63a/GPGHMACSHA1--7fb424869aea1b4d412e06d2279d63129d51fa12/
-deleting annex/objects/247/63a/
-deleting annex/objects/247/637/GPGHMACSHA1--3ca1532c0344187fba45bf9ae646552dd34308d5/GPGHMACSHA1--3ca1532c0344187fba45bf9ae646552dd34308d5
-deleting annex/objects/247/637/GPGHMACSHA1--3ca1532c0344187fba45bf9ae646552dd34308d5/
-deleting annex/objects/247/637/
-deleting annex/objects/247/62f/GPGHMACSHA1--e996a49bcb63458c04794c3bbf8cdee664a04f21/GPGHMACSHA1--e996a49bcb63458c04794c3bbf8cdee664a04f21
-deleting annex/objects/247/62f/GPGHMACSHA1--e996a49bcb63458c04794c3bbf8cdee664a04f21/
-deleting annex/objects/247/62f/
-deleting annex/objects/247/629/GPGHMACSHA1--92e137890d8741d30524b6007f601ed374f69156/GPGHMACSHA1--92e137890d8741d30524b6007f601ed374f69156
-deleting annex/objects/247/629/GPGHMACSHA1--92e137890d8741d30524b6007f601ed374f69156/
-deleting annex/objects/247/629/
-deleting annex/objects/247/627/GPGHMACSHA1--9eb547817aebf490e2a5697be813585d9af44ad3/GPGHMACSHA1--9eb547817aebf490e2a5697be813585d9af44ad3
-deleting annex/objects/247/627/GPGHMACSHA1--9eb547817aebf490e2a5697be813585d9af44ad3/
-deleting annex/objects/247/627/
-deleting annex/objects/247/625/GPGHMACSHA1--16f964b4179c1e0158858aba33cc3ae5a9a61ba7/GPGHMACSHA1--16f964b4179c1e0158858aba33cc3ae5a9a61ba7
-deleting annex/objects/247/625/GPGHMACSHA1--16f964b4179c1e0158858aba33cc3ae5a9a61ba7/
-deleting annex/objects/247/625/
-deleting annex/objects/247/620/GPGHMACSHA1--e7077baa4fbe2f0500d185aeb39c21f1d958b023/GPGHMACSHA1--e7077baa4fbe2f0500d185aeb39c21f1d958b023
-deleting annex/objects/247/620/GPGHMACSHA1--e7077baa4fbe2f0500d185aeb39c21f1d958b023/
-deleting annex/objects/247/620/GPGHMACSHA1--322bdb40e4c644585673d013b9d87f3983fa5c34/GPGHMACSHA1--322bdb40e4c644585673d013b9d87f3983fa5c34
-deleting annex/objects/247/620/GPGHMACSHA1--322bdb40e4c644585673d013b9d87f3983fa5c34/
-deleting annex/objects/247/620/
-deleting annex/objects/247/61d/GPGHMACSHA1--ca424bc0cd5be896d5cdfbd0df4f636cfffb669c/GPGHMACSHA1--ca424bc0cd5be896d5cdfbd0df4f636cfffb669c
-deleting annex/objects/247/61d/GPGHMACSHA1--ca424bc0cd5be896d5cdfbd0df4f636cfffb669c/
-deleting annex/objects/247/61d/
-deleting annex/objects/247/61c/GPGHMACSHA1--73391c35dec76d791da13d6c73366cfb69d47909/GPGHMACSHA1--73391c35dec76d791da13d6c73366cfb69d47909
-deleting annex/objects/247/61c/GPGHMACSHA1--73391c35dec76d791da13d6c73366cfb69d47909/
-deleting annex/objects/247/61c/
-deleting annex/objects/247/61a/GPGHMACSHA1--f0bce1214699a5ef4da278476bec5fa67e65b116/GPGHMACSHA1--f0bce1214699a5ef4da278476bec5fa67e65b116
-deleting annex/objects/247/61a/GPGHMACSHA1--f0bce1214699a5ef4da278476bec5fa67e65b116/
-deleting annex/objects/247/61a/
-deleting annex/objects/247/615/GPGHMACSHA1--39573095483636b80a74d03cca58bda7f17bb2e6/GPGHMACSHA1--39573095483636b80a74d03cca58bda7f17bb2e6
-deleting annex/objects/247/615/GPGHMACSHA1--39573095483636b80a74d03cca58bda7f17bb2e6/
-deleting annex/objects/247/615/
-deleting annex/objects/247/612/GPGHMACSHA1--f17bdc3048e38a0bdb7284005175bc89e3f66f26/GPGHMACSHA1--f17bdc3048e38a0bdb7284005175bc89e3f66f26
-deleting annex/objects/247/612/GPGHMACSHA1--f17bdc3048e38a0bdb7284005175bc89e3f66f26/
-deleting annex/objects/247/612/
-deleting annex/objects/247/60e/GPGHMACSHA1--b0dfa110efc135a31852b7fdbc24a2620b4327e3/GPGHMACSHA1--b0dfa110efc135a31852b7fdbc24a2620b4327e3
-deleting annex/objects/247/60e/GPGHMACSHA1--b0dfa110efc135a31852b7fdbc24a2620b4327e3/
-deleting annex/objects/247/60e/
-deleting annex/objects/247/60b/GPGHMACSHA1--afa4a2aaeeaec2aa4976babc9256b0109d28ecc0/GPGHMACSHA1--afa4a2aaeeaec2aa4976babc9256b0109d28ecc0
-deleting annex/objects/247/60b/GPGHMACSHA1--afa4a2aaeeaec2aa4976babc9256b0109d28ecc0/
-deleting annex/objects/247/60b/GPGHMACSHA1--95d9760a4a05b110ccc307d3348c9cc9a462c0b9/GPGHMACSHA1--95d9760a4a05b110ccc307d3348c9cc9a462c0b9
-deleting annex/objects/247/60b/GPGHMACSHA1--95d9760a4a05b110ccc307d3348c9cc9a462c0b9/
-deleting annex/objects/247/60b/
-deleting annex/objects/247/609/GPGHMACSHA1--25b90316b6158121552060cdefdb5bc129ad5058/GPGHMACSHA1--25b90316b6158121552060cdefdb5bc129ad5058
-deleting annex/objects/247/609/GPGHMACSHA1--25b90316b6158121552060cdefdb5bc129ad5058/
-deleting annex/objects/247/609/
-deleting annex/objects/247/606/GPGHMACSHA1--a0b9667477be6bd1eb475b5ace126299015040c3/GPGHMACSHA1--a0b9667477be6bd1eb475b5ace126299015040c3
-deleting annex/objects/247/606/GPGHMACSHA1--a0b9667477be6bd1eb475b5ace126299015040c3/
-deleting annex/objects/247/606/
-deleting annex/objects/247/605/GPGHMACSHA1--77632b971059808457b15646631cd36762671a54/GPGHMACSHA1--77632b971059808457b15646631cd36762671a54
-deleting annex/objects/247/605/GPGHMACSHA1--77632b971059808457b15646631cd36762671a54/
-deleting annex/objects/247/605/
-deleting annex/objects/247/601/GPGHMACSHA1--258d7701d73c02a876de8487d4f264dcbba0ea97/GPGHMACSHA1--258d7701d73c02a876de8487d4f264dcbba0ea97
-deleting annex/objects/247/601/GPGHMACSHA1--258d7701d73c02a876de8487d4f264dcbba0ea97/
-deleting annex/objects/247/601/
-deleting annex/objects/247/5ff/GPGHMACSHA1--24b943db831c32e41d0c33e7fae234fbda2ea504/GPGHMACSHA1--24b943db831c32e41d0c33e7fae234fbda2ea504
-deleting annex/objects/247/5ff/GPGHMACSHA1--24b943db831c32e41d0c33e7fae234fbda2ea504/
-deleting annex/objects/247/5ff/
-deleting annex/objects/247/5fe/GPGHMACSHA1--6aa35048e84818df436db277a8913d257235a013/GPGHMACSHA1--6aa35048e84818df436db277a8913d257235a013
-deleting annex/objects/247/5fe/GPGHMACSHA1--6aa35048e84818df436db277a8913d257235a013/
-deleting annex/objects/247/5fe/GPGHMACSHA1--27724d561b47f0506c47b1c09c5a0712dc77c9ba/GPGHMACSHA1--27724d561b47f0506c47b1c09c5a0712dc77c9ba
-deleting annex/objects/247/5fe/GPGHMACSHA1--27724d561b47f0506c47b1c09c5a0712dc77c9ba/
-deleting annex/objects/247/5fe/
-deleting annex/objects/247/5ed/GPGHMACSHA1--d68b1377a5b3ae8715cf47698eef3ba7c7303561/GPGHMACSHA1--d68b1377a5b3ae8715cf47698eef3ba7c7303561
-deleting annex/objects/247/5ed/GPGHMACSHA1--d68b1377a5b3ae8715cf47698eef3ba7c7303561/
-deleting annex/objects/247/5ed/
-deleting annex/objects/247/5ea/GPGHMACSHA1--a578150a85f221b702c77c5b2ba3545c6d48eeb2/GPGHMACSHA1--a578150a85f221b702c77c5b2ba3545c6d48eeb2
-deleting annex/objects/247/5ea/GPGHMACSHA1--a578150a85f221b702c77c5b2ba3545c6d48eeb2/
-deleting annex/objects/247/5ea/
-deleting annex/objects/247/5de/GPGHMACSHA1--9eb7179e1cae9996c99ecc98d24af21501bcf631/GPGHMACSHA1--9eb7179e1cae9996c99ecc98d24af21501bcf631
-deleting annex/objects/247/5de/GPGHMACSHA1--9eb7179e1cae9996c99ecc98d24af21501bcf631/
-deleting annex/objects/247/5de/
-deleting annex/objects/247/5dd/GPGHMACSHA1--7c13f08a629f01bd310999f196744a624a3cf1e9/GPGHMACSHA1--7c13f08a629f01bd310999f196744a624a3cf1e9
-deleting annex/objects/247/5dd/GPGHMACSHA1--7c13f08a629f01bd310999f196744a624a3cf1e9/
-deleting annex/objects/247/5dd/
-deleting annex/objects/247/5da/GPGHMACSHA1--afdda198af7d490f7c8b13f38575ca79edc49635/GPGHMACSHA1--afdda198af7d490f7c8b13f38575ca79edc49635
-deleting annex/objects/247/5da/GPGHMACSHA1--afdda198af7d490f7c8b13f38575ca79edc49635/
-deleting annex/objects/247/5da/
-deleting annex/objects/247/5d6/GPGHMACSHA1--e3c008e950edf32969319f9212734b0e9e8cc84c/GPGHMACSHA1--e3c008e950edf32969319f9212734b0e9e8cc84c
-deleting annex/objects/247/5d6/GPGHMACSHA1--e3c008e950edf32969319f9212734b0e9e8cc84c/
-deleting annex/objects/247/5d6/
-deleting annex/objects/247/5d0/GPGHMACSHA1--44bfcd71b7c297425b3b5d9896975a38c3d0247c/GPGHMACSHA1--44bfcd71b7c297425b3b5d9896975a38c3d0247c
-deleting annex/objects/247/5d0/GPGHMACSHA1--44bfcd71b7c297425b3b5d9896975a38c3d0247c/
-deleting annex/objects/247/5d0/GPGHMACSHA1--0591aa70c32c6b29acdd179e8b8b03d177a37abe/GPGHMACSHA1--0591aa70c32c6b29acdd179e8b8b03d177a37abe
-deleting annex/objects/247/5d0/GPGHMACSHA1--0591aa70c32c6b29acdd179e8b8b03d177a37abe/
-deleting annex/objects/247/5d0/
-deleting annex/objects/247/5ca/GPGHMACSHA1--aefb2975a65578696558f3799bb672c203dc1fe5/GPGHMACSHA1--aefb2975a65578696558f3799bb672c203dc1fe5
-deleting annex/objects/247/5ca/GPGHMACSHA1--aefb2975a65578696558f3799bb672c203dc1fe5/
-deleting annex/objects/247/5ca/
-deleting annex/objects/247/5c5/GPGHMACSHA1--faec64b5e4f623f0ae03b899904f0f1e82a5d93d/GPGHMACSHA1--faec64b5e4f623f0ae03b899904f0f1e82a5d93d
-deleting annex/objects/247/5c5/GPGHMACSHA1--faec64b5e4f623f0ae03b899904f0f1e82a5d93d/
-deleting annex/objects/247/5c5/GPGHMACSHA1--35011afcb74beb2f0837f10db3bf649b3de30b69/GPGHMACSHA1--35011afcb74beb2f0837f10db3bf649b3de30b69
-deleting annex/objects/247/5c5/GPGHMACSHA1--35011afcb74beb2f0837f10db3bf649b3de30b69/
-deleting annex/objects/247/5c5/
-deleting annex/objects/247/5c4/GPGHMACSHA1--ee2ab252d5952dda2d48fdca5f91d3de517d0d1d/GPGHMACSHA1--ee2ab252d5952dda2d48fdca5f91d3de517d0d1d
-deleting annex/objects/247/5c4/GPGHMACSHA1--ee2ab252d5952dda2d48fdca5f91d3de517d0d1d/
-deleting annex/objects/247/5c4/GPGHMACSHA1--7412794e81ae37644ed7a40ff2ddaa9a4b2b8cf1/GPGHMACSHA1--7412794e81ae37644ed7a40ff2ddaa9a4b2b8cf1
-deleting annex/objects/247/5c4/GPGHMACSHA1--7412794e81ae37644ed7a40ff2ddaa9a4b2b8cf1/
-deleting annex/objects/247/5c4/
-deleting annex/objects/247/5c3/GPGHMACSHA1--13cf2d1f27a52a082c47e4b2c734dc37f0bb655a/GPGHMACSHA1--13cf2d1f27a52a082c47e4b2c734dc37f0bb655a
-deleting annex/objects/247/5c3/GPGHMACSHA1--13cf2d1f27a52a082c47e4b2c734dc37f0bb655a/
-deleting annex/objects/247/5c3/
-deleting annex/objects/247/5bf/GPGHMACSHA1--6878e81dbb9ab019333806d0195b7a1426083e04/GPGHMACSHA1--6878e81dbb9ab019333806d0195b7a1426083e04
-deleting annex/objects/247/5bf/GPGHMACSHA1--6878e81dbb9ab019333806d0195b7a1426083e04/
-deleting annex/objects/247/5bf/GPGHMACSHA1--2095360e977b5cd9b8b6455faaa49f01105941ff/GPGHMACSHA1--2095360e977b5cd9b8b6455faaa49f01105941ff
-deleting annex/objects/247/5bf/GPGHMACSHA1--2095360e977b5cd9b8b6455faaa49f01105941ff/
-deleting annex/objects/247/5bf/
-deleting annex/objects/247/5b7/GPGHMACSHA1--4f6f5e205ee81e50e59c3974a4874710e5b014e9/GPGHMACSHA1--4f6f5e205ee81e50e59c3974a4874710e5b014e9
-deleting annex/objects/247/5b7/GPGHMACSHA1--4f6f5e205ee81e50e59c3974a4874710e5b014e9/
-deleting annex/objects/247/5b7/
-deleting annex/objects/a58/49b/GPGHMACSHA1--e3aeb454f526e124fdfe09bbe2dde67a9014fdfd/GPGHMACSHA1--e3aeb454f526e124fdfe09bbe2dde67a9014fdfd
-deleting annex/objects/a58/49b/GPGHMACSHA1--e3aeb454f526e124fdfe09bbe2dde67a9014fdfd/
-deleting annex/objects/a58/49b/
-deleting annex/objects/a58/499/GPGHMACSHA1--fc6bb70d08c0f3ff06d117c09895f08bc57e15ae/GPGHMACSHA1--fc6bb70d08c0f3ff06d117c09895f08bc57e15ae
-deleting annex/objects/a58/499/GPGHMACSHA1--fc6bb70d08c0f3ff06d117c09895f08bc57e15ae/
-deleting annex/objects/a58/499/GPGHMACSHA1--b17fe85d9f9eba3246cd967ece843d811b7c8eba/GPGHMACSHA1--b17fe85d9f9eba3246cd967ece843d811b7c8eba
-deleting annex/objects/a58/499/GPGHMACSHA1--b17fe85d9f9eba3246cd967ece843d811b7c8eba/
-deleting annex/objects/a58/499/GPGHMACSHA1--0e0f301d6a0eb570f9836c3c50bb521726f575e2/GPGHMACSHA1--0e0f301d6a0eb570f9836c3c50bb521726f575e2
-deleting annex/objects/a58/499/GPGHMACSHA1--0e0f301d6a0eb570f9836c3c50bb521726f575e2/
-deleting annex/objects/a58/499/
-deleting annex/objects/a58/498/GPGHMACSHA1--50f574b0218714803a3594587afebb89e4695a3b/GPGHMACSHA1--50f574b0218714803a3594587afebb89e4695a3b
-deleting annex/objects/a58/498/GPGHMACSHA1--50f574b0218714803a3594587afebb89e4695a3b/
-deleting annex/objects/a58/498/GPGHMACSHA1--36891f54eca4aa3f1f9dd7136a1cb0772656904f/GPGHMACSHA1--36891f54eca4aa3f1f9dd7136a1cb0772656904f
-deleting annex/objects/a58/498/GPGHMACSHA1--36891f54eca4aa3f1f9dd7136a1cb0772656904f/
-deleting annex/objects/a58/498/
-deleting annex/objects/a58/497/GPGHMACSHA1--cd7e72aef9d4418bb7cee56627ccb30daba6a825/GPGHMACSHA1--cd7e72aef9d4418bb7cee56627ccb30daba6a825
-deleting annex/objects/a58/497/GPGHMACSHA1--cd7e72aef9d4418bb7cee56627ccb30daba6a825/
-deleting annex/objects/a58/497/GPGHMACSHA1--7e19c3642b6d48af9e07ff751c5dfb4478bd881a/GPGHMACSHA1--7e19c3642b6d48af9e07ff751c5dfb4478bd881a
-deleting annex/objects/a58/497/GPGHMACSHA1--7e19c3642b6d48af9e07ff751c5dfb4478bd881a/
-deleting annex/objects/a58/497/GPGHMACSHA1--4f40a7da04b6eeed622bdff1d2dc209e2874f175/GPGHMACSHA1--4f40a7da04b6eeed622bdff1d2dc209e2874f175
-deleting annex/objects/a58/497/GPGHMACSHA1--4f40a7da04b6eeed622bdff1d2dc209e2874f175/
-deleting annex/objects/a58/497/
-deleting annex/objects/a58/496/GPGHMACSHA1--d9126857ed0f79cc5ffc9230a7bb570e35b9e353/GPGHMACSHA1--d9126857ed0f79cc5ffc9230a7bb570e35b9e353
-deleting annex/objects/a58/496/GPGHMACSHA1--d9126857ed0f79cc5ffc9230a7bb570e35b9e353/
-deleting annex/objects/a58/496/GPGHMACSHA1--9946337bfe9fc8592ce225ad6c4b6dbce07a7695/GPGHMACSHA1--9946337bfe9fc8592ce225ad6c4b6dbce07a7695
-deleting annex/objects/a58/496/GPGHMACSHA1--9946337bfe9fc8592ce225ad6c4b6dbce07a7695/
-deleting annex/objects/a58/496/GPGHMACSHA1--8cb939761c19b8149cf5b423c10838c77848fc0f/GPGHMACSHA1--8cb939761c19b8149cf5b423c10838c77848fc0f
-deleting annex/objects/a58/496/GPGHMACSHA1--8cb939761c19b8149cf5b423c10838c77848fc0f/
-deleting annex/objects/a58/496/
-deleting annex/objects/a58/495/GPGHMACSHA1--a743ae9178e36114af219c196a7873282a652d9c/GPGHMACSHA1--a743ae9178e36114af219c196a7873282a652d9c
-deleting annex/objects/a58/495/GPGHMACSHA1--a743ae9178e36114af219c196a7873282a652d9c/
-deleting annex/objects/a58/495/
-deleting annex/objects/a58/493/GPGHMACSHA1--b4839bc63d53abe5d16723599b04b75bbbb78ff6/GPGHMACSHA1--b4839bc63d53abe5d16723599b04b75bbbb78ff6
-deleting annex/objects/a58/493/GPGHMACSHA1--b4839bc63d53abe5d16723599b04b75bbbb78ff6/
-deleting annex/objects/a58/493/GPGHMACSHA1--6c4c2f566fe7d835152ff6cbfd33781e18991449/GPGHMACSHA1--6c4c2f566fe7d835152ff6cbfd33781e18991449
-deleting annex/objects/a58/493/GPGHMACSHA1--6c4c2f566fe7d835152ff6cbfd33781e18991449/
-deleting annex/objects/a58/493/GPGHMACSHA1--1b97a7deb66b13d8582b5b9551db8f0b6fa394a8/GPGHMACSHA1--1b97a7deb66b13d8582b5b9551db8f0b6fa394a8
-deleting annex/objects/a58/493/GPGHMACSHA1--1b97a7deb66b13d8582b5b9551db8f0b6fa394a8/
-deleting annex/objects/a58/493/
-deleting annex/objects/a58/492/GPGHMACSHA1--dae61e12abbf5bfc020f413b37ab97e1482e86b2/GPGHMACSHA1--dae61e12abbf5bfc020f413b37ab97e1482e86b2
-deleting annex/objects/a58/492/GPGHMACSHA1--dae61e12abbf5bfc020f413b37ab97e1482e86b2/
-deleting annex/objects/a58/492/GPGHMACSHA1--21e559dd65b2f903806dc81d45cee9b4122dffd9/GPGHMACSHA1--21e559dd65b2f903806dc81d45cee9b4122dffd9
-deleting annex/objects/a58/492/GPGHMACSHA1--21e559dd65b2f903806dc81d45cee9b4122dffd9/
-deleting annex/objects/a58/492/GPGHMACSHA1--0d9c1738001301c60a0c6b279e4fcaf7b72e2d60/GPGHMACSHA1--0d9c1738001301c60a0c6b279e4fcaf7b72e2d60
-deleting annex/objects/a58/492/GPGHMACSHA1--0d9c1738001301c60a0c6b279e4fcaf7b72e2d60/
-deleting annex/objects/a58/492/
-deleting annex/objects/a58/490/GPGHMACSHA1--16720b93fc8677bf2bb664efd53376ee50368f2a/GPGHMACSHA1--16720b93fc8677bf2bb664efd53376ee50368f2a
-deleting annex/objects/a58/490/GPGHMACSHA1--16720b93fc8677bf2bb664efd53376ee50368f2a/
-deleting annex/objects/a58/490/
-deleting annex/objects/a58/48d/GPGHMACSHA1--16a4801a94772f419bdd8d7545e4dc62cf601a73/GPGHMACSHA1--16a4801a94772f419bdd8d7545e4dc62cf601a73
-deleting annex/objects/a58/48d/GPGHMACSHA1--16a4801a94772f419bdd8d7545e4dc62cf601a73/
-deleting annex/objects/a58/48d/
-deleting annex/objects/a58/48c/GPGHMACSHA1--11c14032c5f005a858cb842b7f83c44c29a7fc4f/GPGHMACSHA1--11c14032c5f005a858cb842b7f83c44c29a7fc4f
-deleting annex/objects/a58/48c/GPGHMACSHA1--11c14032c5f005a858cb842b7f83c44c29a7fc4f/
-deleting annex/objects/a58/48c/
-deleting annex/objects/a58/48b/GPGHMACSHA1--e7fc68e6cd6cd677a780b9fc9403e04d87490837/GPGHMACSHA1--e7fc68e6cd6cd677a780b9fc9403e04d87490837
-deleting annex/objects/a58/48b/GPGHMACSHA1--e7fc68e6cd6cd677a780b9fc9403e04d87490837/
-deleting annex/objects/a58/48b/GPGHMACSHA1--506b108c0a1cbacccebc647f40747ff79f5f836d/GPGHMACSHA1--506b108c0a1cbacccebc647f40747ff79f5f836d
-deleting annex/objects/a58/48b/GPGHMACSHA1--506b108c0a1cbacccebc647f40747ff79f5f836d/
-deleting annex/objects/a58/48b/
-deleting annex/objects/a58/48a/GPGHMACSHA1--d3ee658e9845bf5e14e2835419ec4445b33093de/GPGHMACSHA1--d3ee658e9845bf5e14e2835419ec4445b33093de
-deleting annex/objects/a58/48a/GPGHMACSHA1--d3ee658e9845bf5e14e2835419ec4445b33093de/
-deleting annex/objects/a58/48a/GPGHMACSHA1--42bffe3ea217b30b19af464d48916dd001c38ad2/GPGHMACSHA1--42bffe3ea217b30b19af464d48916dd001c38ad2
-deleting annex/objects/a58/48a/GPGHMACSHA1--42bffe3ea217b30b19af464d48916dd001c38ad2/
-deleting annex/objects/a58/48a/
-deleting annex/objects/a58/489/GPGHMACSHA1--cd3ef969340e4ad704b757d0a42a412abbfa492c/GPGHMACSHA1--cd3ef969340e4ad704b757d0a42a412abbfa492c
-deleting annex/objects/a58/489/GPGHMACSHA1--cd3ef969340e4ad704b757d0a42a412abbfa492c/
-deleting annex/objects/a58/489/
-deleting annex/objects/a58/488/GPGHMACSHA1--ed8b48a06919142fbf036d839f69edc15e4814e3/GPGHMACSHA1--ed8b48a06919142fbf036d839f69edc15e4814e3
-deleting annex/objects/a58/488/GPGHMACSHA1--ed8b48a06919142fbf036d839f69edc15e4814e3/
-deleting annex/objects/a58/488/GPGHMACSHA1--e4738706071a30af1f985c148d050a9deed2761e/GPGHMACSHA1--e4738706071a30af1f985c148d050a9deed2761e
-deleting annex/objects/a58/488/GPGHMACSHA1--e4738706071a30af1f985c148d050a9deed2761e/
-deleting annex/objects/a58/488/GPGHMACSHA1--0c3ce03cff065e2223e3da9c3fd6842b0ac91730/GPGHMACSHA1--0c3ce03cff065e2223e3da9c3fd6842b0ac91730
-deleting annex/objects/a58/488/GPGHMACSHA1--0c3ce03cff065e2223e3da9c3fd6842b0ac91730/
-deleting annex/objects/a58/488/
-deleting annex/objects/a58/486/GPGHMACSHA1--f3730f7afb8381612ab6d06ec3cc36c023a3142c/GPGHMACSHA1--f3730f7afb8381612ab6d06ec3cc36c023a3142c
-deleting annex/objects/a58/486/GPGHMACSHA1--f3730f7afb8381612ab6d06ec3cc36c023a3142c/
-deleting annex/objects/a58/486/GPGHMACSHA1--dd16892e59f6d7ae3529dbdad64291e9596dcf0e/GPGHMACSHA1--dd16892e59f6d7ae3529dbdad64291e9596dcf0e
-deleting annex/objects/a58/486/GPGHMACSHA1--dd16892e59f6d7ae3529dbdad64291e9596dcf0e/
-deleting annex/objects/a58/486/
-deleting annex/objects/a58/485/GPGHMACSHA1--c4305419b6756056fba7c37fb0d172d2901e5c9d/GPGHMACSHA1--c4305419b6756056fba7c37fb0d172d2901e5c9d
-deleting annex/objects/a58/485/GPGHMACSHA1--c4305419b6756056fba7c37fb0d172d2901e5c9d/
-deleting annex/objects/a58/485/GPGHMACSHA1--bca48d2ccbadc42c504d46d247439f7f62ce84a3/GPGHMACSHA1--bca48d2ccbadc42c504d46d247439f7f62ce84a3
-deleting annex/objects/a58/485/GPGHMACSHA1--bca48d2ccbadc42c504d46d247439f7f62ce84a3/
-deleting annex/objects/a58/485/GPGHMACSHA1--83ff887d652f832f192821adcd584c6b7aea8d29/GPGHMACSHA1--83ff887d652f832f192821adcd584c6b7aea8d29
-deleting annex/objects/a58/485/GPGHMACSHA1--83ff887d652f832f192821adcd584c6b7aea8d29/
-deleting annex/objects/a58/485/
-deleting annex/objects/a58/484/GPGHMACSHA1--3b351e040554f1b968ec6e42bfec68481241211a/GPGHMACSHA1--3b351e040554f1b968ec6e42bfec68481241211a
-deleting annex/objects/a58/484/GPGHMACSHA1--3b351e040554f1b968ec6e42bfec68481241211a/
-deleting annex/objects/a58/484/
-deleting annex/objects/a58/483/GPGHMACSHA1--b6ab476c95e3cdfe08ae45fad084bc1ee3264b2c/GPGHMACSHA1--b6ab476c95e3cdfe08ae45fad084bc1ee3264b2c
-deleting annex/objects/a58/483/GPGHMACSHA1--b6ab476c95e3cdfe08ae45fad084bc1ee3264b2c/
-deleting annex/objects/a58/483/GPGHMACSHA1--5f9bc6e525965d8e5b14c8067a2102ac579b2224/GPGHMACSHA1--5f9bc6e525965d8e5b14c8067a2102ac579b2224
-deleting annex/objects/a58/483/GPGHMACSHA1--5f9bc6e525965d8e5b14c8067a2102ac579b2224/
-deleting annex/objects/a58/483/GPGHMACSHA1--4da9c8cc1c7c48333d862f61dac3d34a9bc425f7/GPGHMACSHA1--4da9c8cc1c7c48333d862f61dac3d34a9bc425f7
-deleting annex/objects/a58/483/GPGHMACSHA1--4da9c8cc1c7c48333d862f61dac3d34a9bc425f7/
-deleting annex/objects/a58/483/GPGHMACSHA1--40d3736c7067fca2c881e67528598bdcddb6635f/GPGHMACSHA1--40d3736c7067fca2c881e67528598bdcddb6635f
-deleting annex/objects/a58/483/GPGHMACSHA1--40d3736c7067fca2c881e67528598bdcddb6635f/
-deleting annex/objects/a58/483/GPGHMACSHA1--241e68f1062d07c2014e5171dee812a7be48c517/GPGHMACSHA1--241e68f1062d07c2014e5171dee812a7be48c517
-deleting annex/objects/a58/483/GPGHMACSHA1--241e68f1062d07c2014e5171dee812a7be48c517/
-deleting annex/objects/a58/483/
-deleting annex/objects/a58/481/GPGHMACSHA1--4833d1788ca34a936f7f4e3f7cdeca332d9bfcc5/GPGHMACSHA1--4833d1788ca34a936f7f4e3f7cdeca332d9bfcc5
-deleting annex/objects/a58/481/GPGHMACSHA1--4833d1788ca34a936f7f4e3f7cdeca332d9bfcc5/
-deleting annex/objects/a58/481/
-deleting annex/objects/a58/480/GPGHMACSHA1--f18822b057d7e7ea0c8500ce2489fbbdb8de70cb/GPGHMACSHA1--f18822b057d7e7ea0c8500ce2489fbbdb8de70cb
-deleting annex/objects/a58/480/GPGHMACSHA1--f18822b057d7e7ea0c8500ce2489fbbdb8de70cb/
-deleting annex/objects/a58/480/GPGHMACSHA1--0230d274cb8d0d80efa07f466a5a6374cc308225/GPGHMACSHA1--0230d274cb8d0d80efa07f466a5a6374cc308225
-deleting annex/objects/a58/480/GPGHMACSHA1--0230d274cb8d0d80efa07f466a5a6374cc308225/
-deleting annex/objects/a58/480/
-deleting annex/objects/a58/47f/GPGHMACSHA1--0669b2f40a41c016608b04aa81f54a5b4d9210d7/GPGHMACSHA1--0669b2f40a41c016608b04aa81f54a5b4d9210d7
-deleting annex/objects/a58/47f/GPGHMACSHA1--0669b2f40a41c016608b04aa81f54a5b4d9210d7/
-deleting annex/objects/a58/47f/
-deleting annex/objects/a58/47d/GPGHMACSHA1--8fba4badeefd2fb38965e017c1c52196b212ad35/GPGHMACSHA1--8fba4badeefd2fb38965e017c1c52196b212ad35
-deleting annex/objects/a58/47d/GPGHMACSHA1--8fba4badeefd2fb38965e017c1c52196b212ad35/
-deleting annex/objects/a58/47d/GPGHMACSHA1--215ade6c261593b1911f29d633d2bdc1dbaaeedc/GPGHMACSHA1--215ade6c261593b1911f29d633d2bdc1dbaaeedc
-deleting annex/objects/a58/47d/GPGHMACSHA1--215ade6c261593b1911f29d633d2bdc1dbaaeedc/
-deleting annex/objects/a58/47d/GPGHMACSHA1--148038e297f562e8ae6baaad0cf90c2e9f55c80e/GPGHMACSHA1--148038e297f562e8ae6baaad0cf90c2e9f55c80e
-deleting annex/objects/a58/47d/GPGHMACSHA1--148038e297f562e8ae6baaad0cf90c2e9f55c80e/
-deleting annex/objects/a58/47d/
-deleting annex/objects/a58/47b/GPGHMACSHA1--ecad287be2fff9a89847c8b73ab85d91efbbb1b6/GPGHMACSHA1--ecad287be2fff9a89847c8b73ab85d91efbbb1b6
-deleting annex/objects/a58/47b/GPGHMACSHA1--ecad287be2fff9a89847c8b73ab85d91efbbb1b6/
-deleting annex/objects/a58/47b/GPGHMACSHA1--920a442140a8f0fc358285be7834674d00e05e73/GPGHMACSHA1--920a442140a8f0fc358285be7834674d00e05e73
-deleting annex/objects/a58/47b/GPGHMACSHA1--920a442140a8f0fc358285be7834674d00e05e73/
-deleting annex/objects/a58/47b/GPGHMACSHA1--0fa27452aaa9359a79918d3f3fd1e197a0693243/GPGHMACSHA1--0fa27452aaa9359a79918d3f3fd1e197a0693243
-deleting annex/objects/a58/47b/GPGHMACSHA1--0fa27452aaa9359a79918d3f3fd1e197a0693243/
-deleting annex/objects/a58/47b/
-deleting annex/objects/a58/47a/GPGHMACSHA1--2f2f58949389afae2f43f64931fc6ebc4f96b717/GPGHMACSHA1--2f2f58949389afae2f43f64931fc6ebc4f96b717
-deleting annex/objects/a58/47a/GPGHMACSHA1--2f2f58949389afae2f43f64931fc6ebc4f96b717/
-deleting annex/objects/a58/47a/
-deleting annex/objects/a58/479/GPGHMACSHA1--e138f073472b08f92fe60252c837de7dcef2d97e/GPGHMACSHA1--e138f073472b08f92fe60252c837de7dcef2d97e
-deleting annex/objects/a58/479/GPGHMACSHA1--e138f073472b08f92fe60252c837de7dcef2d97e/
-deleting annex/objects/a58/479/GPGHMACSHA1--d2077fcbdd85b264cd9ace6481e34fa39e39027d/GPGHMACSHA1--d2077fcbdd85b264cd9ace6481e34fa39e39027d
-deleting annex/objects/a58/479/GPGHMACSHA1--d2077fcbdd85b264cd9ace6481e34fa39e39027d/
-deleting annex/objects/a58/479/GPGHMACSHA1--2d7ada7e883a149c6786714ffe8b0845c22dfa3b/GPGHMACSHA1--2d7ada7e883a149c6786714ffe8b0845c22dfa3b
-deleting annex/objects/a58/479/GPGHMACSHA1--2d7ada7e883a149c6786714ffe8b0845c22dfa3b/
-deleting annex/objects/a58/479/
-deleting annex/objects/a58/478/GPGHMACSHA1--a2e87af63050cbc73fc11f6f5f36d2db153cdccf/GPGHMACSHA1--a2e87af63050cbc73fc11f6f5f36d2db153cdccf
-deleting annex/objects/a58/478/GPGHMACSHA1--a2e87af63050cbc73fc11f6f5f36d2db153cdccf/
-deleting annex/objects/a58/478/
-deleting annex/objects/a58/477/GPGHMACSHA1--d23a8576ee19c0a13b5ffe47cc58489c29ea550e/GPGHMACSHA1--d23a8576ee19c0a13b5ffe47cc58489c29ea550e
-deleting annex/objects/a58/477/GPGHMACSHA1--d23a8576ee19c0a13b5ffe47cc58489c29ea550e/
-deleting annex/objects/a58/477/GPGHMACSHA1--b2dc2c433882ab95f891591b49c77aeace301ff1/GPGHMACSHA1--b2dc2c433882ab95f891591b49c77aeace301ff1
-deleting annex/objects/a58/477/GPGHMACSHA1--b2dc2c433882ab95f891591b49c77aeace301ff1/
-deleting annex/objects/a58/477/GPGHMACSHA1--832a1d0fa42e650e4f64f5a8d7ea7f38434475c3/GPGHMACSHA1--832a1d0fa42e650e4f64f5a8d7ea7f38434475c3
-deleting annex/objects/a58/477/GPGHMACSHA1--832a1d0fa42e650e4f64f5a8d7ea7f38434475c3/
-deleting annex/objects/a58/477/
-deleting annex/objects/a58/476/GPGHMACSHA1--6f4cfe519d8376dc39f9fa22f2913ff457765755/GPGHMACSHA1--6f4cfe519d8376dc39f9fa22f2913ff457765755
-deleting annex/objects/a58/476/GPGHMACSHA1--6f4cfe519d8376dc39f9fa22f2913ff457765755/
-deleting annex/objects/a58/476/GPGHMACSHA1--31201160cd8b0edfe8be4773e0dab36ce5f2ede9/GPGHMACSHA1--31201160cd8b0edfe8be4773e0dab36ce5f2ede9
-deleting annex/objects/a58/476/GPGHMACSHA1--31201160cd8b0edfe8be4773e0dab36ce5f2ede9/
-deleting annex/objects/a58/476/
-deleting annex/objects/a58/475/GPGHMACSHA1--e1b760a9be3560d012ad0efa2f6d38ea4b2b7162/GPGHMACSHA1--e1b760a9be3560d012ad0efa2f6d38ea4b2b7162
-deleting annex/objects/a58/475/GPGHMACSHA1--e1b760a9be3560d012ad0efa2f6d38ea4b2b7162/
-deleting annex/objects/a58/475/GPGHMACSHA1--a3c6825ff4c361a4a82fe88cb36c1080e445629a/GPGHMACSHA1--a3c6825ff4c361a4a82fe88cb36c1080e445629a
-deleting annex/objects/a58/475/GPGHMACSHA1--a3c6825ff4c361a4a82fe88cb36c1080e445629a/
-deleting annex/objects/a58/475/GPGHMACSHA1--91cbf1d0d5f83c7a74e8302f2a0f93dd0634fa8a/GPGHMACSHA1--91cbf1d0d5f83c7a74e8302f2a0f93dd0634fa8a
-deleting annex/objects/a58/475/GPGHMACSHA1--91cbf1d0d5f83c7a74e8302f2a0f93dd0634fa8a/
-deleting annex/objects/a58/475/GPGHMACSHA1--7e7e893921e7f532233f2c5f93371d3da1cf5c8b/GPGHMACSHA1--7e7e893921e7f532233f2c5f93371d3da1cf5c8b
-deleting annex/objects/a58/475/GPGHMACSHA1--7e7e893921e7f532233f2c5f93371d3da1cf5c8b/
-deleting annex/objects/a58/475/
-deleting annex/objects/a58/474/GPGHMACSHA1--596180066590cc48510a07d434edb928c4369468/GPGHMACSHA1--596180066590cc48510a07d434edb928c4369468
-deleting annex/objects/a58/474/GPGHMACSHA1--596180066590cc48510a07d434edb928c4369468/
-deleting annex/objects/a58/474/
-deleting annex/objects/a58/472/GPGHMACSHA1--f2f8bdc1d425874268bfd12e2e1f6a109c5165f4/GPGHMACSHA1--f2f8bdc1d425874268bfd12e2e1f6a109c5165f4
-deleting annex/objects/a58/472/GPGHMACSHA1--f2f8bdc1d425874268bfd12e2e1f6a109c5165f4/
-deleting annex/objects/a58/472/
-deleting annex/objects/a58/471/GPGHMACSHA1--2d4068a5905dc2d9039cb48df32f94a4e5c6499a/GPGHMACSHA1--2d4068a5905dc2d9039cb48df32f94a4e5c6499a
-deleting annex/objects/a58/471/GPGHMACSHA1--2d4068a5905dc2d9039cb48df32f94a4e5c6499a/
-deleting annex/objects/a58/471/
-deleting annex/objects/a58/470/GPGHMACSHA1--c15a4fe0416b9e4ead16b94b53ff9533819f6e32/GPGHMACSHA1--c15a4fe0416b9e4ead16b94b53ff9533819f6e32
-deleting annex/objects/a58/470/GPGHMACSHA1--c15a4fe0416b9e4ead16b94b53ff9533819f6e32/
-deleting annex/objects/a58/470/GPGHMACSHA1--2638b731fa2ccd9d3c77bdf7e3925b84bd67c72c/GPGHMACSHA1--2638b731fa2ccd9d3c77bdf7e3925b84bd67c72c
-deleting annex/objects/a58/470/GPGHMACSHA1--2638b731fa2ccd9d3c77bdf7e3925b84bd67c72c/
-deleting annex/objects/a58/470/
-deleting annex/objects/a58/46e/GPGHMACSHA1--c9b43c6faf9d8ac36617ec3124c2458ce0685ad8/GPGHMACSHA1--c9b43c6faf9d8ac36617ec3124c2458ce0685ad8
-deleting annex/objects/a58/46e/GPGHMACSHA1--c9b43c6faf9d8ac36617ec3124c2458ce0685ad8/
-deleting annex/objects/a58/46e/GPGHMACSHA1--71df66ab164e2645e7bcc08255000da6579dee68/GPGHMACSHA1--71df66ab164e2645e7bcc08255000da6579dee68
-deleting annex/objects/a58/46e/GPGHMACSHA1--71df66ab164e2645e7bcc08255000da6579dee68/
-deleting annex/objects/a58/46e/GPGHMACSHA1--5713c4a32de0ab33843b77ae3aa3e9c7bdef768e/GPGHMACSHA1--5713c4a32de0ab33843b77ae3aa3e9c7bdef768e
-deleting annex/objects/a58/46e/GPGHMACSHA1--5713c4a32de0ab33843b77ae3aa3e9c7bdef768e/
-deleting annex/objects/a58/46e/
-deleting annex/objects/a58/46d/GPGHMACSHA1--6cadb794538fee6edaf862abb31dd9d56bdd2509/GPGHMACSHA1--6cadb794538fee6edaf862abb31dd9d56bdd2509
-deleting annex/objects/a58/46d/GPGHMACSHA1--6cadb794538fee6edaf862abb31dd9d56bdd2509/
-deleting annex/objects/a58/46d/
-deleting annex/objects/a58/46a/GPGHMACSHA1--56bc19394fe8de7b257739188782d0f7502658d8/GPGHMACSHA1--56bc19394fe8de7b257739188782d0f7502658d8
-deleting annex/objects/a58/46a/GPGHMACSHA1--56bc19394fe8de7b257739188782d0f7502658d8/
-deleting annex/objects/a58/46a/
-deleting annex/objects/a58/468/GPGHMACSHA1--e597d2df79d4687cd5b715dd0f267e3d765afcc5/GPGHMACSHA1--e597d2df79d4687cd5b715dd0f267e3d765afcc5
-deleting annex/objects/a58/468/GPGHMACSHA1--e597d2df79d4687cd5b715dd0f267e3d765afcc5/
-deleting annex/objects/a58/468/GPGHMACSHA1--8c3c6fd12724044013c47a5371613d29a24fed0b/GPGHMACSHA1--8c3c6fd12724044013c47a5371613d29a24fed0b
-deleting annex/objects/a58/468/GPGHMACSHA1--8c3c6fd12724044013c47a5371613d29a24fed0b/
-deleting annex/objects/a58/468/
-deleting annex/objects/a58/467/GPGHMACSHA1--4e1c311a20c35239526316a3bc1b3085bce8487a/GPGHMACSHA1--4e1c311a20c35239526316a3bc1b3085bce8487a
-deleting annex/objects/a58/467/GPGHMACSHA1--4e1c311a20c35239526316a3bc1b3085bce8487a/
-deleting annex/objects/a58/467/GPGHMACSHA1--08f018d615356689d37330d622955f3522a2bcc3/GPGHMACSHA1--08f018d615356689d37330d622955f3522a2bcc3
-deleting annex/objects/a58/467/GPGHMACSHA1--08f018d615356689d37330d622955f3522a2bcc3/
-deleting annex/objects/a58/467/
-deleting annex/objects/a58/466/GPGHMACSHA1--fbf07be634ac64b0aabfa16a9453e58e10444342/GPGHMACSHA1--fbf07be634ac64b0aabfa16a9453e58e10444342
-deleting annex/objects/a58/466/GPGHMACSHA1--fbf07be634ac64b0aabfa16a9453e58e10444342/
-deleting annex/objects/a58/466/GPGHMACSHA1--9356ccce97e5bf66a136152624c0e9325db2effb/GPGHMACSHA1--9356ccce97e5bf66a136152624c0e9325db2effb
-deleting annex/objects/a58/466/GPGHMACSHA1--9356ccce97e5bf66a136152624c0e9325db2effb/
-deleting annex/objects/a58/466/
-deleting annex/objects/a58/464/GPGHMACSHA1--f52322b67d8a452527123cddaa9eb58dcec8f39c/GPGHMACSHA1--f52322b67d8a452527123cddaa9eb58dcec8f39c
-deleting annex/objects/a58/464/GPGHMACSHA1--f52322b67d8a452527123cddaa9eb58dcec8f39c/
-deleting annex/objects/a58/464/GPGHMACSHA1--f2c0f9f49168bb197fe142fb771d0d3238b1bd6c/GPGHMACSHA1--f2c0f9f49168bb197fe142fb771d0d3238b1bd6c
-deleting annex/objects/a58/464/GPGHMACSHA1--f2c0f9f49168bb197fe142fb771d0d3238b1bd6c/
-deleting annex/objects/a58/464/GPGHMACSHA1--a658a7f555520099f07e5e9535d33824be0e0f8b/GPGHMACSHA1--a658a7f555520099f07e5e9535d33824be0e0f8b
-deleting annex/objects/a58/464/GPGHMACSHA1--a658a7f555520099f07e5e9535d33824be0e0f8b/
-deleting annex/objects/a58/464/
-deleting annex/objects/a58/463/GPGHMACSHA1--e0b5f96072ab37c420e432298e4e0412792d1bad/GPGHMACSHA1--e0b5f96072ab37c420e432298e4e0412792d1bad
-deleting annex/objects/a58/463/GPGHMACSHA1--e0b5f96072ab37c420e432298e4e0412792d1bad/
-deleting annex/objects/a58/463/GPGHMACSHA1--c9e7c8ec3f83e9d3830d4589d57b200f5363ea7c/GPGHMACSHA1--c9e7c8ec3f83e9d3830d4589d57b200f5363ea7c
-deleting annex/objects/a58/463/GPGHMACSHA1--c9e7c8ec3f83e9d3830d4589d57b200f5363ea7c/
-deleting annex/objects/a58/463/GPGHMACSHA1--06867b45f24d0007fa08c624474cc8d7948dc2c9/GPGHMACSHA1--06867b45f24d0007fa08c624474cc8d7948dc2c9
-deleting annex/objects/a58/463/GPGHMACSHA1--06867b45f24d0007fa08c624474cc8d7948dc2c9/
-deleting annex/objects/a58/463/
-deleting annex/objects/a58/460/GPGHMACSHA1--32be64b3dbc2edfd1cc8455d392cfa80a62fb3a5/GPGHMACSHA1--32be64b3dbc2edfd1cc8455d392cfa80a62fb3a5
-deleting annex/objects/a58/460/GPGHMACSHA1--32be64b3dbc2edfd1cc8455d392cfa80a62fb3a5/
-deleting annex/objects/a58/460/GPGHMACSHA1--2e7efce7c67bd0721cc143bf5dcebab5cd8bbcb6/GPGHMACSHA1--2e7efce7c67bd0721cc143bf5dcebab5cd8bbcb6
-deleting annex/objects/a58/460/GPGHMACSHA1--2e7efce7c67bd0721cc143bf5dcebab5cd8bbcb6/
-deleting annex/objects/a58/460/GPGHMACSHA1--261b5143f57945f1e6c475c2969bb3f445d362df/GPGHMACSHA1--261b5143f57945f1e6c475c2969bb3f445d362df
-deleting annex/objects/a58/460/GPGHMACSHA1--261b5143f57945f1e6c475c2969bb3f445d362df/
-deleting annex/objects/a58/460/
-deleting annex/objects/a58/45c/GPGHMACSHA1--1c379eca1fd7ecc0be8bc5c36305d6229bf1ce31/GPGHMACSHA1--1c379eca1fd7ecc0be8bc5c36305d6229bf1ce31
-deleting annex/objects/a58/45c/GPGHMACSHA1--1c379eca1fd7ecc0be8bc5c36305d6229bf1ce31/
-deleting annex/objects/a58/45c/
-deleting annex/objects/a58/45b/GPGHMACSHA1--719d9d330cfb59006d734d72f06642344e5838c3/GPGHMACSHA1--719d9d330cfb59006d734d72f06642344e5838c3
-deleting annex/objects/a58/45b/GPGHMACSHA1--719d9d330cfb59006d734d72f06642344e5838c3/
-deleting annex/objects/a58/45b/
-deleting annex/objects/a58/45a/GPGHMACSHA1--8db40287caa82032565510a5219a0e9defbf4bf6/GPGHMACSHA1--8db40287caa82032565510a5219a0e9defbf4bf6
-deleting annex/objects/a58/45a/GPGHMACSHA1--8db40287caa82032565510a5219a0e9defbf4bf6/
-deleting annex/objects/a58/45a/GPGHMACSHA1--82fca2040153c331e2516bb9a9b7de69390f2354/GPGHMACSHA1--82fca2040153c331e2516bb9a9b7de69390f2354
-deleting annex/objects/a58/45a/GPGHMACSHA1--82fca2040153c331e2516bb9a9b7de69390f2354/
-deleting annex/objects/a58/45a/GPGHMACSHA1--15afc41dacb5a8aa43dec9b417813e0624b9e3c1/GPGHMACSHA1--15afc41dacb5a8aa43dec9b417813e0624b9e3c1
-deleting annex/objects/a58/45a/GPGHMACSHA1--15afc41dacb5a8aa43dec9b417813e0624b9e3c1/
-deleting annex/objects/a58/45a/
-deleting annex/objects/a58/459/GPGHMACSHA1--62b3973a6dc9c7f06ea1ad765cf82173c3e99ecf/GPGHMACSHA1--62b3973a6dc9c7f06ea1ad765cf82173c3e99ecf
-deleting annex/objects/a58/459/GPGHMACSHA1--62b3973a6dc9c7f06ea1ad765cf82173c3e99ecf/
-deleting annex/objects/a58/459/GPGHMACSHA1--206a24d12ba1b1e7460f06614d9a97f7b7a8c487/GPGHMACSHA1--206a24d12ba1b1e7460f06614d9a97f7b7a8c487
-deleting annex/objects/a58/459/GPGHMACSHA1--206a24d12ba1b1e7460f06614d9a97f7b7a8c487/
-deleting annex/objects/a58/459/GPGHMACSHA1--16e0b62ec227b78294cc5e6e944ecb5fddccfce2/GPGHMACSHA1--16e0b62ec227b78294cc5e6e944ecb5fddccfce2
-deleting annex/objects/a58/459/GPGHMACSHA1--16e0b62ec227b78294cc5e6e944ecb5fddccfce2/
-deleting annex/objects/a58/459/
-deleting annex/objects/a58/458/GPGHMACSHA1--a9f0c0e22f0e41859800f1156d634f233826dea0/GPGHMACSHA1--a9f0c0e22f0e41859800f1156d634f233826dea0
-deleting annex/objects/a58/458/GPGHMACSHA1--a9f0c0e22f0e41859800f1156d634f233826dea0/
-deleting annex/objects/a58/458/GPGHMACSHA1--87177984717ed03ec947ddd4ef64512d4aed279e/GPGHMACSHA1--87177984717ed03ec947ddd4ef64512d4aed279e
-deleting annex/objects/a58/458/GPGHMACSHA1--87177984717ed03ec947ddd4ef64512d4aed279e/
-deleting annex/objects/a58/458/
-deleting annex/objects/a58/457/GPGHMACSHA1--893a12a05dcd700a0d46e8ae94bc5d93d8ff7036/GPGHMACSHA1--893a12a05dcd700a0d46e8ae94bc5d93d8ff7036
-deleting annex/objects/a58/457/GPGHMACSHA1--893a12a05dcd700a0d46e8ae94bc5d93d8ff7036/
-deleting annex/objects/a58/457/
-deleting annex/objects/a58/456/GPGHMACSHA1--6864c7086b8633c6ec8c43a583bd5fbb47db9be5/GPGHMACSHA1--6864c7086b8633c6ec8c43a583bd5fbb47db9be5
-deleting annex/objects/a58/456/GPGHMACSHA1--6864c7086b8633c6ec8c43a583bd5fbb47db9be5/
-deleting annex/objects/a58/456/GPGHMACSHA1--156855196a4619ab3c306e77e93e2c1a2a7877aa/GPGHMACSHA1--156855196a4619ab3c306e77e93e2c1a2a7877aa
-deleting annex/objects/a58/456/GPGHMACSHA1--156855196a4619ab3c306e77e93e2c1a2a7877aa/
-deleting annex/objects/a58/456/GPGHMACSHA1--07c2c6081a25811895922c20dea472ba79d161e3/GPGHMACSHA1--07c2c6081a25811895922c20dea472ba79d161e3
-deleting annex/objects/a58/456/GPGHMACSHA1--07c2c6081a25811895922c20dea472ba79d161e3/
-deleting annex/objects/a58/456/
-deleting annex/objects/a58/455/GPGHMACSHA1--dc31fd1a96338d9b27161fe10d647bbc397fac75/GPGHMACSHA1--dc31fd1a96338d9b27161fe10d647bbc397fac75
-deleting annex/objects/a58/455/GPGHMACSHA1--dc31fd1a96338d9b27161fe10d647bbc397fac75/
-deleting annex/objects/a58/455/GPGHMACSHA1--06926b3dd937f6bb6da1e4aa70dbababe7fbb580/GPGHMACSHA1--06926b3dd937f6bb6da1e4aa70dbababe7fbb580
-deleting annex/objects/a58/455/GPGHMACSHA1--06926b3dd937f6bb6da1e4aa70dbababe7fbb580/
-deleting annex/objects/a58/455/
-deleting annex/objects/a58/454/GPGHMACSHA1--b3008e172257513bcc0903b66a5d14c77be6783e/GPGHMACSHA1--b3008e172257513bcc0903b66a5d14c77be6783e
-deleting annex/objects/a58/454/GPGHMACSHA1--b3008e172257513bcc0903b66a5d14c77be6783e/
-deleting annex/objects/a58/454/GPGHMACSHA1--a1dfca54d13d706ca03f1e68fde3d3a5b73db8b4/GPGHMACSHA1--a1dfca54d13d706ca03f1e68fde3d3a5b73db8b4
-deleting annex/objects/a58/454/GPGHMACSHA1--a1dfca54d13d706ca03f1e68fde3d3a5b73db8b4/
-deleting annex/objects/a58/454/GPGHMACSHA1--74a9d24a9a0454934d86c98eef7b77986bc8ae39/GPGHMACSHA1--74a9d24a9a0454934d86c98eef7b77986bc8ae39
-deleting annex/objects/a58/454/GPGHMACSHA1--74a9d24a9a0454934d86c98eef7b77986bc8ae39/
-deleting annex/objects/a58/454/GPGHMACSHA1--5ac6306cab63cccf33918044abaa2cde5b6924e4/GPGHMACSHA1--5ac6306cab63cccf33918044abaa2cde5b6924e4
-deleting annex/objects/a58/454/GPGHMACSHA1--5ac6306cab63cccf33918044abaa2cde5b6924e4/
-deleting annex/objects/a58/454/
-deleting annex/objects/a58/453/GPGHMACSHA1--f0cb77e2d3ce4d6f4ecb64c6127a2d956905da46/GPGHMACSHA1--f0cb77e2d3ce4d6f4ecb64c6127a2d956905da46
-deleting annex/objects/a58/453/GPGHMACSHA1--f0cb77e2d3ce4d6f4ecb64c6127a2d956905da46/
-deleting annex/objects/a58/453/
-deleting annex/objects/a58/452/GPGHMACSHA1--a42eb5dac2c02cf5c02b210ff208719e592472ce/GPGHMACSHA1--a42eb5dac2c02cf5c02b210ff208719e592472ce
-deleting annex/objects/a58/452/GPGHMACSHA1--a42eb5dac2c02cf5c02b210ff208719e592472ce/
-deleting annex/objects/a58/452/GPGHMACSHA1--276b1d8e17d2c450c904ed3b5a916323539f11f1/GPGHMACSHA1--276b1d8e17d2c450c904ed3b5a916323539f11f1
-deleting annex/objects/a58/452/GPGHMACSHA1--276b1d8e17d2c450c904ed3b5a916323539f11f1/
-deleting annex/objects/a58/452/
-deleting annex/objects/a58/451/GPGHMACSHA1--63eb1148051b3b04bd35f9a909dff50f856bf0eb/GPGHMACSHA1--63eb1148051b3b04bd35f9a909dff50f856bf0eb
-deleting annex/objects/a58/451/GPGHMACSHA1--63eb1148051b3b04bd35f9a909dff50f856bf0eb/
-deleting annex/objects/a58/451/
-deleting annex/objects/a58/450/GPGHMACSHA1--c351adbb53ea6d8b1a619942d24a060d09b43fdd/GPGHMACSHA1--c351adbb53ea6d8b1a619942d24a060d09b43fdd
-deleting annex/objects/a58/450/GPGHMACSHA1--c351adbb53ea6d8b1a619942d24a060d09b43fdd/
-deleting annex/objects/a58/450/
-deleting annex/objects/a58/44f/GPGHMACSHA1--7710555d8cdaa9b057f94ea065373a51e5192fa4/GPGHMACSHA1--7710555d8cdaa9b057f94ea065373a51e5192fa4
-deleting annex/objects/a58/44f/GPGHMACSHA1--7710555d8cdaa9b057f94ea065373a51e5192fa4/
-deleting annex/objects/a58/44f/GPGHMACSHA1--5ddbc268a5c5d231d5aaac61345db866683e8f13/GPGHMACSHA1--5ddbc268a5c5d231d5aaac61345db866683e8f13
-deleting annex/objects/a58/44f/GPGHMACSHA1--5ddbc268a5c5d231d5aaac61345db866683e8f13/
-deleting annex/objects/a58/44f/GPGHMACSHA1--4e0e4eb624762b5db3ce8cd19d8c8343a64546cd/GPGHMACSHA1--4e0e4eb624762b5db3ce8cd19d8c8343a64546cd
-deleting annex/objects/a58/44f/GPGHMACSHA1--4e0e4eb624762b5db3ce8cd19d8c8343a64546cd/
-deleting annex/objects/a58/44f/
-deleting annex/objects/a58/44c/GPGHMACSHA1--f1e316ab5b6acf4ca7f4123302014480c5ab898b/GPGHMACSHA1--f1e316ab5b6acf4ca7f4123302014480c5ab898b
-deleting annex/objects/a58/44c/GPGHMACSHA1--f1e316ab5b6acf4ca7f4123302014480c5ab898b/
-deleting annex/objects/a58/44c/GPGHMACSHA1--1670a3982fae48be18b484513986853d44172c62/GPGHMACSHA1--1670a3982fae48be18b484513986853d44172c62
-deleting annex/objects/a58/44c/GPGHMACSHA1--1670a3982fae48be18b484513986853d44172c62/
-deleting annex/objects/a58/44c/
-deleting annex/objects/a58/44b/GPGHMACSHA1--28dfcfc9c010e82284dd90a040d44d990f6efd74/GPGHMACSHA1--28dfcfc9c010e82284dd90a040d44d990f6efd74
-deleting annex/objects/a58/44b/GPGHMACSHA1--28dfcfc9c010e82284dd90a040d44d990f6efd74/
-deleting annex/objects/a58/44b/
-deleting annex/objects/a58/44a/GPGHMACSHA1--e11d314af0a76e85b41ca56126f27db729ea2f11/GPGHMACSHA1--e11d314af0a76e85b41ca56126f27db729ea2f11
-deleting annex/objects/a58/44a/GPGHMACSHA1--e11d314af0a76e85b41ca56126f27db729ea2f11/
-deleting annex/objects/a58/44a/GPGHMACSHA1--77adcf8896cd652101e6f9fa96b0eb61cf128458/GPGHMACSHA1--77adcf8896cd652101e6f9fa96b0eb61cf128458
-deleting annex/objects/a58/44a/GPGHMACSHA1--77adcf8896cd652101e6f9fa96b0eb61cf128458/
-deleting annex/objects/a58/44a/
-deleting annex/objects/a58/447/GPGHMACSHA1--ea53841a44d66255a6b0cf01db66a6364aff5150/GPGHMACSHA1--ea53841a44d66255a6b0cf01db66a6364aff5150
-deleting annex/objects/a58/447/GPGHMACSHA1--ea53841a44d66255a6b0cf01db66a6364aff5150/
-deleting annex/objects/a58/447/GPGHMACSHA1--b0e32c21b5c7c092c2caf8d6b1dce03216842960/GPGHMACSHA1--b0e32c21b5c7c092c2caf8d6b1dce03216842960
-deleting annex/objects/a58/447/GPGHMACSHA1--b0e32c21b5c7c092c2caf8d6b1dce03216842960/
-deleting annex/objects/a58/447/
-deleting annex/objects/a58/446/GPGHMACSHA1--5f7f50eea93257bbc12e4741bc37a56812a8706e/GPGHMACSHA1--5f7f50eea93257bbc12e4741bc37a56812a8706e
-deleting annex/objects/a58/446/GPGHMACSHA1--5f7f50eea93257bbc12e4741bc37a56812a8706e/
-deleting annex/objects/a58/446/GPGHMACSHA1--4373fb4b869992d6dd3002ea59817de12836b114/GPGHMACSHA1--4373fb4b869992d6dd3002ea59817de12836b114
-deleting annex/objects/a58/446/GPGHMACSHA1--4373fb4b869992d6dd3002ea59817de12836b114/
-deleting annex/objects/a58/446/
-deleting annex/objects/a58/445/GPGHMACSHA1--b57c200af53e987f7c02f08bfab7f387fdc94994/GPGHMACSHA1--b57c200af53e987f7c02f08bfab7f387fdc94994
-deleting annex/objects/a58/445/GPGHMACSHA1--b57c200af53e987f7c02f08bfab7f387fdc94994/
-deleting annex/objects/a58/445/
-deleting annex/objects/a58/443/GPGHMACSHA1--eda7815f2322f2a279df36ac25c63f6403a84fc1/GPGHMACSHA1--eda7815f2322f2a279df36ac25c63f6403a84fc1
-deleting annex/objects/a58/443/GPGHMACSHA1--eda7815f2322f2a279df36ac25c63f6403a84fc1/
-deleting annex/objects/a58/443/
-deleting annex/objects/a58/442/GPGHMACSHA1--95712c22740b110780ce15ae815b8545e642839f/GPGHMACSHA1--95712c22740b110780ce15ae815b8545e642839f
-deleting annex/objects/a58/442/GPGHMACSHA1--95712c22740b110780ce15ae815b8545e642839f/
-deleting annex/objects/a58/442/GPGHMACSHA1--3adf263bba8c06cfcf8f21fc0ac6a414964ff5c4/GPGHMACSHA1--3adf263bba8c06cfcf8f21fc0ac6a414964ff5c4
-deleting annex/objects/a58/442/GPGHMACSHA1--3adf263bba8c06cfcf8f21fc0ac6a414964ff5c4/
-deleting annex/objects/a58/442/GPGHMACSHA1--2bd7a817b46c8160a019b50676ad3abe78250b34/GPGHMACSHA1--2bd7a817b46c8160a019b50676ad3abe78250b34
-deleting annex/objects/a58/442/GPGHMACSHA1--2bd7a817b46c8160a019b50676ad3abe78250b34/
-deleting annex/objects/a58/442/
-deleting annex/objects/a58/441/GPGHMACSHA1--b4bf7e25c23ac465a3615163baa1564fd0b7c18b/GPGHMACSHA1--b4bf7e25c23ac465a3615163baa1564fd0b7c18b
-deleting annex/objects/a58/441/GPGHMACSHA1--b4bf7e25c23ac465a3615163baa1564fd0b7c18b/
-deleting annex/objects/a58/441/
-deleting annex/objects/a58/440/GPGHMACSHA1--0a00394a28f443f4160660e5740ab0242a74c4be/GPGHMACSHA1--0a00394a28f443f4160660e5740ab0242a74c4be
-deleting annex/objects/a58/440/GPGHMACSHA1--0a00394a28f443f4160660e5740ab0242a74c4be/
-deleting annex/objects/a58/440/
-deleting annex/objects/a58/43f/GPGHMACSHA1--5879c3d88fea43843b930669fc20d26df4e05070/GPGHMACSHA1--5879c3d88fea43843b930669fc20d26df4e05070
-deleting annex/objects/a58/43f/GPGHMACSHA1--5879c3d88fea43843b930669fc20d26df4e05070/
-deleting annex/objects/a58/43f/
-deleting annex/objects/a58/43e/GPGHMACSHA1--c1cc04b0ed6d9c4d3c3bb5af7253756899360721/GPGHMACSHA1--c1cc04b0ed6d9c4d3c3bb5af7253756899360721
-deleting annex/objects/a58/43e/GPGHMACSHA1--c1cc04b0ed6d9c4d3c3bb5af7253756899360721/
-deleting annex/objects/a58/43e/
-deleting annex/objects/a58/43d/GPGHMACSHA1--8bedee83511422dac5ca68349e9279219f24d8eb/GPGHMACSHA1--8bedee83511422dac5ca68349e9279219f24d8eb
-deleting annex/objects/a58/43d/GPGHMACSHA1--8bedee83511422dac5ca68349e9279219f24d8eb/
-deleting annex/objects/a58/43d/
-deleting annex/objects/a58/43c/GPGHMACSHA1--f7898cfd606c9c6af3ae0a717f189955f6c1296f/GPGHMACSHA1--f7898cfd606c9c6af3ae0a717f189955f6c1296f
-deleting annex/objects/a58/43c/GPGHMACSHA1--f7898cfd606c9c6af3ae0a717f189955f6c1296f/
-deleting annex/objects/a58/43c/
-deleting annex/objects/a58/43b/GPGHMACSHA1--78cf349532a821c7588e76c7f005b491be6667f4/GPGHMACSHA1--78cf349532a821c7588e76c7f005b491be6667f4
-deleting annex/objects/a58/43b/GPGHMACSHA1--78cf349532a821c7588e76c7f005b491be6667f4/
-deleting annex/objects/a58/43b/
-deleting annex/objects/a58/43a/GPGHMACSHA1--638ab071596595093f0017120cbff44101b64b15/GPGHMACSHA1--638ab071596595093f0017120cbff44101b64b15
-deleting annex/objects/a58/43a/GPGHMACSHA1--638ab071596595093f0017120cbff44101b64b15/
-deleting annex/objects/a58/43a/GPGHMACSHA1--1f352902cd593c491ac5f69d0f2464b12465dc3e/GPGHMACSHA1--1f352902cd593c491ac5f69d0f2464b12465dc3e
-deleting annex/objects/a58/43a/GPGHMACSHA1--1f352902cd593c491ac5f69d0f2464b12465dc3e/
-deleting annex/objects/a58/43a/
-deleting annex/objects/a58/438/GPGHMACSHA1--ab04bb336367d6be3db3ea00ed8e2568d1938652/GPGHMACSHA1--ab04bb336367d6be3db3ea00ed8e2568d1938652
-deleting annex/objects/a58/438/GPGHMACSHA1--ab04bb336367d6be3db3ea00ed8e2568d1938652/
-deleting annex/objects/a58/438/
-deleting annex/objects/a58/437/GPGHMACSHA1--65acf55cb96292a266ae586a7cba515467f0d62b/GPGHMACSHA1--65acf55cb96292a266ae586a7cba515467f0d62b
-deleting annex/objects/a58/437/GPGHMACSHA1--65acf55cb96292a266ae586a7cba515467f0d62b/
-deleting annex/objects/a58/437/
-deleting annex/objects/a58/436/GPGHMACSHA1--d335540d28169f824e93f8ba9abe01eb4a18fa17/GPGHMACSHA1--d335540d28169f824e93f8ba9abe01eb4a18fa17
-deleting annex/objects/a58/436/GPGHMACSHA1--d335540d28169f824e93f8ba9abe01eb4a18fa17/
-deleting annex/objects/a58/436/
-deleting annex/objects/a58/434/GPGHMACSHA1--45fa32412773ef9991e58dc37f1bcedb102803a5/GPGHMACSHA1--45fa32412773ef9991e58dc37f1bcedb102803a5
-deleting annex/objects/a58/434/GPGHMACSHA1--45fa32412773ef9991e58dc37f1bcedb102803a5/
-deleting annex/objects/a58/434/GPGHMACSHA1--4537638a5234f4f2e43ac144e27eb7aad01dd86a/GPGHMACSHA1--4537638a5234f4f2e43ac144e27eb7aad01dd86a
-deleting annex/objects/a58/434/GPGHMACSHA1--4537638a5234f4f2e43ac144e27eb7aad01dd86a/
-deleting annex/objects/a58/434/
-deleting annex/objects/a58/433/GPGHMACSHA1--daa7670c66a305e507f7fd2b70eca1e683fd1edc/GPGHMACSHA1--daa7670c66a305e507f7fd2b70eca1e683fd1edc
-deleting annex/objects/a58/433/GPGHMACSHA1--daa7670c66a305e507f7fd2b70eca1e683fd1edc/
-deleting annex/objects/a58/433/GPGHMACSHA1--75e5003b8ca92cd8a854ac365f4ffde9189a91f7/GPGHMACSHA1--75e5003b8ca92cd8a854ac365f4ffde9189a91f7
-deleting annex/objects/a58/433/GPGHMACSHA1--75e5003b8ca92cd8a854ac365f4ffde9189a91f7/
-deleting annex/objects/a58/433/
-deleting annex/objects/a58/432/GPGHMACSHA1--c6270f9c854d8c40be38a2ccf5ec269f36d09243/GPGHMACSHA1--c6270f9c854d8c40be38a2ccf5ec269f36d09243
-deleting annex/objects/a58/432/GPGHMACSHA1--c6270f9c854d8c40be38a2ccf5ec269f36d09243/
-deleting annex/objects/a58/432/GPGHMACSHA1--aab67a4a546e4e6780e5c1e362727efd53cb7735/GPGHMACSHA1--aab67a4a546e4e6780e5c1e362727efd53cb7735
-deleting annex/objects/a58/432/GPGHMACSHA1--aab67a4a546e4e6780e5c1e362727efd53cb7735/
-deleting annex/objects/a58/432/
-deleting annex/objects/a58/431/GPGHMACSHA1--7bff7f1ebeaf77b19c16950a8611eb3fc473aa9a/GPGHMACSHA1--7bff7f1ebeaf77b19c16950a8611eb3fc473aa9a
-deleting annex/objects/a58/431/GPGHMACSHA1--7bff7f1ebeaf77b19c16950a8611eb3fc473aa9a/
-deleting annex/objects/a58/431/GPGHMACSHA1--5651deccbce94672550d0071169f2f3e3e1b6b80/GPGHMACSHA1--5651deccbce94672550d0071169f2f3e3e1b6b80
-deleting annex/objects/a58/431/GPGHMACSHA1--5651deccbce94672550d0071169f2f3e3e1b6b80/
-deleting annex/objects/a58/431/GPGHMACSHA1--42bc0712bc04786dd1d443ac13d3e9480bd7a36a/GPGHMACSHA1--42bc0712bc04786dd1d443ac13d3e9480bd7a36a
-deleting annex/objects/a58/431/GPGHMACSHA1--42bc0712bc04786dd1d443ac13d3e9480bd7a36a/
-deleting annex/objects/a58/431/
-deleting annex/objects/a58/430/GPGHMACSHA1--6e54d17f4b6c8bcd0af227c3df6c87a4f8a347ad/GPGHMACSHA1--6e54d17f4b6c8bcd0af227c3df6c87a4f8a347ad
-deleting annex/objects/a58/430/GPGHMACSHA1--6e54d17f4b6c8bcd0af227c3df6c87a4f8a347ad/
-deleting annex/objects/a58/430/GPGHMACSHA1--396952514f72c47b07b20f3168d80d7ce15a2553/GPGHMACSHA1--396952514f72c47b07b20f3168d80d7ce15a2553
-deleting annex/objects/a58/430/GPGHMACSHA1--396952514f72c47b07b20f3168d80d7ce15a2553/
-deleting annex/objects/a58/430/
-deleting annex/objects/a58/42e/GPGHMACSHA1--fabc8ecf1db09e398a5dc913cc76637bd73b985f/GPGHMACSHA1--fabc8ecf1db09e398a5dc913cc76637bd73b985f
-deleting annex/objects/a58/42e/GPGHMACSHA1--fabc8ecf1db09e398a5dc913cc76637bd73b985f/
-deleting annex/objects/a58/42e/
-deleting annex/objects/a58/42c/GPGHMACSHA1--4a469a431a5e89690544d779b6199bd9710c9bd7/GPGHMACSHA1--4a469a431a5e89690544d779b6199bd9710c9bd7
-deleting annex/objects/a58/42c/GPGHMACSHA1--4a469a431a5e89690544d779b6199bd9710c9bd7/
-deleting annex/objects/a58/42c/GPGHMACSHA1--34bab1ace67d2f77e1d3b9885ac2a54cdd92bcad/GPGHMACSHA1--34bab1ace67d2f77e1d3b9885ac2a54cdd92bcad
-deleting annex/objects/a58/42c/GPGHMACSHA1--34bab1ace67d2f77e1d3b9885ac2a54cdd92bcad/
-deleting annex/objects/a58/42c/GPGHMACSHA1--2d4b6011366e52294aa6b3528dd0d82f61e63297/GPGHMACSHA1--2d4b6011366e52294aa6b3528dd0d82f61e63297
-deleting annex/objects/a58/42c/GPGHMACSHA1--2d4b6011366e52294aa6b3528dd0d82f61e63297/
-deleting annex/objects/a58/42c/
-deleting annex/objects/a58/42b/GPGHMACSHA1--7a857fa2e6236a52929af3d8ba55dfe21edbbeb7/GPGHMACSHA1--7a857fa2e6236a52929af3d8ba55dfe21edbbeb7
-deleting annex/objects/a58/42b/GPGHMACSHA1--7a857fa2e6236a52929af3d8ba55dfe21edbbeb7/
-deleting annex/objects/a58/42b/GPGHMACSHA1--1289fde863528b3a76e44647cd87810a852ac2cd/GPGHMACSHA1--1289fde863528b3a76e44647cd87810a852ac2cd
-deleting annex/objects/a58/42b/GPGHMACSHA1--1289fde863528b3a76e44647cd87810a852ac2cd/
-deleting annex/objects/a58/42b/GPGHMACSHA1--0e8f6d32dcc09d2ad75f6a2de236612d57aa5bff/GPGHMACSHA1--0e8f6d32dcc09d2ad75f6a2de236612d57aa5bff
-deleting annex/objects/a58/42b/GPGHMACSHA1--0e8f6d32dcc09d2ad75f6a2de236612d57aa5bff/
-deleting annex/objects/a58/42b/
-deleting annex/objects/a58/427/GPGHMACSHA1--b98323a3a50a87ee351d4ad2d25a3b1db25d692e/GPGHMACSHA1--b98323a3a50a87ee351d4ad2d25a3b1db25d692e
-deleting annex/objects/a58/427/GPGHMACSHA1--b98323a3a50a87ee351d4ad2d25a3b1db25d692e/
-deleting annex/objects/a58/427/GPGHMACSHA1--8706c90da9909b32f1653b80c1ce4e6832885f34/GPGHMACSHA1--8706c90da9909b32f1653b80c1ce4e6832885f34
-deleting annex/objects/a58/427/GPGHMACSHA1--8706c90da9909b32f1653b80c1ce4e6832885f34/
-deleting annex/objects/a58/427/GPGHMACSHA1--597b5773825df30e45054a147e100e54fc86585b/GPGHMACSHA1--597b5773825df30e45054a147e100e54fc86585b
-deleting annex/objects/a58/427/GPGHMACSHA1--597b5773825df30e45054a147e100e54fc86585b/
-deleting annex/objects/a58/427/GPGHMACSHA1--010f982de31fd002db1a25deb5140a77373979a8/GPGHMACSHA1--010f982de31fd002db1a25deb5140a77373979a8
-deleting annex/objects/a58/427/GPGHMACSHA1--010f982de31fd002db1a25deb5140a77373979a8/
-deleting annex/objects/a58/427/
-deleting annex/objects/a58/426/GPGHMACSHA1--ea4bd3701455c8390ddcecf851184280db8a78f7/GPGHMACSHA1--ea4bd3701455c8390ddcecf851184280db8a78f7
-deleting annex/objects/a58/426/GPGHMACSHA1--ea4bd3701455c8390ddcecf851184280db8a78f7/
-deleting annex/objects/a58/426/GPGHMACSHA1--ddcab01c77f05997882924d4dfb950da8c5bc1dd/GPGHMACSHA1--ddcab01c77f05997882924d4dfb950da8c5bc1dd
-deleting annex/objects/a58/426/GPGHMACSHA1--ddcab01c77f05997882924d4dfb950da8c5bc1dd/
-deleting annex/objects/a58/426/GPGHMACSHA1--cc0b781cf3d242b5980cfd76e03d951578390d57/GPGHMACSHA1--cc0b781cf3d242b5980cfd76e03d951578390d57
-deleting annex/objects/a58/426/GPGHMACSHA1--cc0b781cf3d242b5980cfd76e03d951578390d57/
-deleting annex/objects/a58/426/GPGHMACSHA1--a12a6aa2e35688a426094494b1248ae6e637b12a/GPGHMACSHA1--a12a6aa2e35688a426094494b1248ae6e637b12a
-deleting annex/objects/a58/426/GPGHMACSHA1--a12a6aa2e35688a426094494b1248ae6e637b12a/
-deleting annex/objects/a58/426/GPGHMACSHA1--962f604814f204b5dc89224085be75d97d9d891c/GPGHMACSHA1--962f604814f204b5dc89224085be75d97d9d891c
-deleting annex/objects/a58/426/GPGHMACSHA1--962f604814f204b5dc89224085be75d97d9d891c/
-deleting annex/objects/a58/426/
-deleting annex/objects/a58/425/GPGHMACSHA1--d6eaf23b63dc28c81dcb23b8188b0d2cb30b34f3/GPGHMACSHA1--d6eaf23b63dc28c81dcb23b8188b0d2cb30b34f3
-deleting annex/objects/a58/425/GPGHMACSHA1--d6eaf23b63dc28c81dcb23b8188b0d2cb30b34f3/
-deleting annex/objects/a58/425/
-deleting annex/objects/a58/424/GPGHMACSHA1--fe3888623220b2f78d6a176e9d7bdfd662144f04/GPGHMACSHA1--fe3888623220b2f78d6a176e9d7bdfd662144f04
-deleting annex/objects/a58/424/GPGHMACSHA1--fe3888623220b2f78d6a176e9d7bdfd662144f04/
-deleting annex/objects/a58/424/GPGHMACSHA1--832915e879e0181b51b4ef9c5a69d9069229748a/GPGHMACSHA1--832915e879e0181b51b4ef9c5a69d9069229748a
-deleting annex/objects/a58/424/GPGHMACSHA1--832915e879e0181b51b4ef9c5a69d9069229748a/
-deleting annex/objects/a58/424/GPGHMACSHA1--7bfa9936b234f6a1325b54eac0053d7bea5640e2/GPGHMACSHA1--7bfa9936b234f6a1325b54eac0053d7bea5640e2
-deleting annex/objects/a58/424/GPGHMACSHA1--7bfa9936b234f6a1325b54eac0053d7bea5640e2/
-deleting annex/objects/a58/424/
-deleting annex/objects/a58/423/GPGHMACSHA1--f7fb65b3877bdaedf700cfcddf3982ec67ee52ba/GPGHMACSHA1--f7fb65b3877bdaedf700cfcddf3982ec67ee52ba
-deleting annex/objects/a58/423/GPGHMACSHA1--f7fb65b3877bdaedf700cfcddf3982ec67ee52ba/
-deleting annex/objects/a58/423/
-deleting annex/objects/a58/422/GPGHMACSHA1--f4496fc6c7eb6edab29f921386fd0b702c6420bd/GPGHMACSHA1--f4496fc6c7eb6edab29f921386fd0b702c6420bd
-deleting annex/objects/a58/422/GPGHMACSHA1--f4496fc6c7eb6edab29f921386fd0b702c6420bd/
-deleting annex/objects/a58/422/GPGHMACSHA1--26d8dc0f8e2439fde44d4030f2fbcb85113023c9/GPGHMACSHA1--26d8dc0f8e2439fde44d4030f2fbcb85113023c9
-deleting annex/objects/a58/422/GPGHMACSHA1--26d8dc0f8e2439fde44d4030f2fbcb85113023c9/
-deleting annex/objects/a58/422/
-deleting annex/objects/a58/421/GPGHMACSHA1--c88edcd0529cecb8963986dfeb352d52da2012eb/GPGHMACSHA1--c88edcd0529cecb8963986dfeb352d52da2012eb
-deleting annex/objects/a58/421/GPGHMACSHA1--c88edcd0529cecb8963986dfeb352d52da2012eb/
-deleting annex/objects/a58/421/GPGHMACSHA1--bcffa9e2c46b0cb687c7804b4a94038a35324d25/GPGHMACSHA1--bcffa9e2c46b0cb687c7804b4a94038a35324d25
-deleting annex/objects/a58/421/GPGHMACSHA1--bcffa9e2c46b0cb687c7804b4a94038a35324d25/
-deleting annex/objects/a58/421/GPGHMACSHA1--647742f5095d2a4f785f08d6e6d16d28940391b2/GPGHMACSHA1--647742f5095d2a4f785f08d6e6d16d28940391b2
-deleting annex/objects/a58/421/GPGHMACSHA1--647742f5095d2a4f785f08d6e6d16d28940391b2/
-deleting annex/objects/a58/421/
-deleting annex/objects/a58/420/GPGHMACSHA1--db3baaade7b7309cc4511fbeeb63972b2feb9705/GPGHMACSHA1--db3baaade7b7309cc4511fbeeb63972b2feb9705
-deleting annex/objects/a58/420/GPGHMACSHA1--db3baaade7b7309cc4511fbeeb63972b2feb9705/
-deleting annex/objects/a58/420/GPGHMACSHA1--b0e59bde8c4eab6d56f4f34fa4a86dc2e2e55343/GPGHMACSHA1--b0e59bde8c4eab6d56f4f34fa4a86dc2e2e55343
-deleting annex/objects/a58/420/GPGHMACSHA1--b0e59bde8c4eab6d56f4f34fa4a86dc2e2e55343/
-deleting annex/objects/a58/420/GPGHMACSHA1--1609ad5394c4847c346069ca1e840cc4fb36a373/GPGHMACSHA1--1609ad5394c4847c346069ca1e840cc4fb36a373
-deleting annex/objects/a58/420/GPGHMACSHA1--1609ad5394c4847c346069ca1e840cc4fb36a373/
-deleting annex/objects/a58/420/
-deleting annex/objects/a58/41f/GPGHMACSHA1--d14e21138e0f420d97cfb9be46ed3f09ff263edc/GPGHMACSHA1--d14e21138e0f420d97cfb9be46ed3f09ff263edc
-deleting annex/objects/a58/41f/GPGHMACSHA1--d14e21138e0f420d97cfb9be46ed3f09ff263edc/
-deleting annex/objects/a58/41f/GPGHMACSHA1--697364bf48ddca3faa6db4edd55a269d259f7bf1/GPGHMACSHA1--697364bf48ddca3faa6db4edd55a269d259f7bf1
-deleting annex/objects/a58/41f/GPGHMACSHA1--697364bf48ddca3faa6db4edd55a269d259f7bf1/
-deleting annex/objects/a58/41f/
-deleting annex/objects/a58/41e/GPGHMACSHA1--917976cbf2e4986bff6e2775e74a5a6b0bfdee50/GPGHMACSHA1--917976cbf2e4986bff6e2775e74a5a6b0bfdee50
-deleting annex/objects/a58/41e/GPGHMACSHA1--917976cbf2e4986bff6e2775e74a5a6b0bfdee50/
-deleting annex/objects/a58/41e/
-deleting annex/objects/a58/41c/GPGHMACSHA1--b0c5c951ab2bcd6e42863c7d024fc49268040f15/GPGHMACSHA1--b0c5c951ab2bcd6e42863c7d024fc49268040f15
-deleting annex/objects/a58/41c/GPGHMACSHA1--b0c5c951ab2bcd6e42863c7d024fc49268040f15/
-deleting annex/objects/a58/41c/
-deleting annex/objects/a58/41b/GPGHMACSHA1--80a9ec2aca8a06da0c16b0e7e971e35ba26d1bca/GPGHMACSHA1--80a9ec2aca8a06da0c16b0e7e971e35ba26d1bca
-deleting annex/objects/a58/41b/GPGHMACSHA1--80a9ec2aca8a06da0c16b0e7e971e35ba26d1bca/
-deleting annex/objects/a58/41b/GPGHMACSHA1--74ea3eb6f2fe287e4643188a861cc647685cd9de/GPGHMACSHA1--74ea3eb6f2fe287e4643188a861cc647685cd9de
-deleting annex/objects/a58/41b/GPGHMACSHA1--74ea3eb6f2fe287e4643188a861cc647685cd9de/
-deleting annex/objects/a58/41b/
-deleting annex/objects/a58/41a/GPGHMACSHA1--5b8f2fa4733124a23a1ea9557eb602d1ee563d6e/GPGHMACSHA1--5b8f2fa4733124a23a1ea9557eb602d1ee563d6e
-deleting annex/objects/a58/41a/GPGHMACSHA1--5b8f2fa4733124a23a1ea9557eb602d1ee563d6e/
-deleting annex/objects/a58/41a/GPGHMACSHA1--05309cfa4059319e031377d5195c749526dc9d18/GPGHMACSHA1--05309cfa4059319e031377d5195c749526dc9d18
-deleting annex/objects/a58/41a/GPGHMACSHA1--05309cfa4059319e031377d5195c749526dc9d18/
-deleting annex/objects/a58/41a/
-deleting annex/objects/a58/419/GPGHMACSHA1--b86888b11f111fb176018cd3a8ea3fe026891b44/GPGHMACSHA1--b86888b11f111fb176018cd3a8ea3fe026891b44
-deleting annex/objects/a58/419/GPGHMACSHA1--b86888b11f111fb176018cd3a8ea3fe026891b44/
-deleting annex/objects/a58/419/
-deleting annex/objects/a58/418/GPGHMACSHA1--45837e92a7a9cece9aa3200252baf000c3ac9602/GPGHMACSHA1--45837e92a7a9cece9aa3200252baf000c3ac9602
-deleting annex/objects/a58/418/GPGHMACSHA1--45837e92a7a9cece9aa3200252baf000c3ac9602/
-deleting annex/objects/a58/418/
-deleting annex/objects/a58/416/GPGHMACSHA1--3b7d286a5fa51188df9efda1caa9143b6afea9b7/GPGHMACSHA1--3b7d286a5fa51188df9efda1caa9143b6afea9b7
-deleting annex/objects/a58/416/GPGHMACSHA1--3b7d286a5fa51188df9efda1caa9143b6afea9b7/
-deleting annex/objects/a58/416/GPGHMACSHA1--1319e2380f4c9eb92ecd4e4ba2823f9e6d77e189/GPGHMACSHA1--1319e2380f4c9eb92ecd4e4ba2823f9e6d77e189
-deleting annex/objects/a58/416/GPGHMACSHA1--1319e2380f4c9eb92ecd4e4ba2823f9e6d77e189/
-deleting annex/objects/a58/416/
-deleting annex/objects/a58/415/GPGHMACSHA1--5ddc2d5000916cddc9002d7cd44806c733195cb9/GPGHMACSHA1--5ddc2d5000916cddc9002d7cd44806c733195cb9
-deleting annex/objects/a58/415/GPGHMACSHA1--5ddc2d5000916cddc9002d7cd44806c733195cb9/
-deleting annex/objects/a58/415/
-deleting annex/objects/a58/414/GPGHMACSHA1--bf8faf76eb2326aa68cdbf97d806140ff682100a/GPGHMACSHA1--bf8faf76eb2326aa68cdbf97d806140ff682100a
-deleting annex/objects/a58/414/GPGHMACSHA1--bf8faf76eb2326aa68cdbf97d806140ff682100a/
-deleting annex/objects/a58/414/GPGHMACSHA1--b2a0f5399a76f9e0ac6aa66968afdf7795f3ff6e/GPGHMACSHA1--b2a0f5399a76f9e0ac6aa66968afdf7795f3ff6e
-deleting annex/objects/a58/414/GPGHMACSHA1--b2a0f5399a76f9e0ac6aa66968afdf7795f3ff6e/
-deleting annex/objects/a58/414/
-deleting annex/objects/a58/413/GPGHMACSHA1--ee370aa088cb4b37f128cb0876150481440c0885/GPGHMACSHA1--ee370aa088cb4b37f128cb0876150481440c0885
-deleting annex/objects/a58/413/GPGHMACSHA1--ee370aa088cb4b37f128cb0876150481440c0885/
-deleting annex/objects/a58/413/GPGHMACSHA1--93ada330f495af322241613a946f1fdeb7061d7e/GPGHMACSHA1--93ada330f495af322241613a946f1fdeb7061d7e
-deleting annex/objects/a58/413/GPGHMACSHA1--93ada330f495af322241613a946f1fdeb7061d7e/
-deleting annex/objects/a58/413/GPGHMACSHA1--925ab9faf085e84d7c78fadc3079b52047d432db/GPGHMACSHA1--925ab9faf085e84d7c78fadc3079b52047d432db
-deleting annex/objects/a58/413/GPGHMACSHA1--925ab9faf085e84d7c78fadc3079b52047d432db/
-deleting annex/objects/a58/413/
-deleting annex/objects/a58/411/GPGHMACSHA1--f986aca6642ba1633e703a3fcaca54eea6b84c36/GPGHMACSHA1--f986aca6642ba1633e703a3fcaca54eea6b84c36
-deleting annex/objects/a58/411/GPGHMACSHA1--f986aca6642ba1633e703a3fcaca54eea6b84c36/
-deleting annex/objects/a58/411/GPGHMACSHA1--10ca7758ce6d180399992ceff26d9cc1399dc831/GPGHMACSHA1--10ca7758ce6d180399992ceff26d9cc1399dc831
-deleting annex/objects/a58/411/GPGHMACSHA1--10ca7758ce6d180399992ceff26d9cc1399dc831/
-deleting annex/objects/a58/411/
-deleting annex/objects/a58/40f/GPGHMACSHA1--db453b034825abb21cded129e75405cfa104b0e3/GPGHMACSHA1--db453b034825abb21cded129e75405cfa104b0e3
-deleting annex/objects/a58/40f/GPGHMACSHA1--db453b034825abb21cded129e75405cfa104b0e3/
-deleting annex/objects/a58/40f/GPGHMACSHA1--c34bbe59b7fe0a48197217b8affa27d8fd3e89c2/GPGHMACSHA1--c34bbe59b7fe0a48197217b8affa27d8fd3e89c2
-deleting annex/objects/a58/40f/GPGHMACSHA1--c34bbe59b7fe0a48197217b8affa27d8fd3e89c2/
-deleting annex/objects/a58/40f/
-deleting annex/objects/a58/40e/GPGHMACSHA1--7c96f9b4ff7ec24bc7c89ac82f6352fe604a6b7d/GPGHMACSHA1--7c96f9b4ff7ec24bc7c89ac82f6352fe604a6b7d
-deleting annex/objects/a58/40e/GPGHMACSHA1--7c96f9b4ff7ec24bc7c89ac82f6352fe604a6b7d/
-deleting annex/objects/a58/40e/
-deleting annex/objects/a58/40d/GPGHMACSHA1--a51e22387fad3d70b15ff77e26b802e50afe7a46/GPGHMACSHA1--a51e22387fad3d70b15ff77e26b802e50afe7a46
-deleting annex/objects/a58/40d/GPGHMACSHA1--a51e22387fad3d70b15ff77e26b802e50afe7a46/
-deleting annex/objects/a58/40d/
-deleting annex/objects/a58/40c/GPGHMACSHA1--b82a432e11881548052114cfbb07dbc23bd6a2f2/GPGHMACSHA1--b82a432e11881548052114cfbb07dbc23bd6a2f2
-deleting annex/objects/a58/40c/GPGHMACSHA1--b82a432e11881548052114cfbb07dbc23bd6a2f2/
-deleting annex/objects/a58/40c/GPGHMACSHA1--8bc64222a6b9f74d691845b2990dcd8bc3607c53/GPGHMACSHA1--8bc64222a6b9f74d691845b2990dcd8bc3607c53
-deleting annex/objects/a58/40c/GPGHMACSHA1--8bc64222a6b9f74d691845b2990dcd8bc3607c53/
-deleting annex/objects/a58/40c/GPGHMACSHA1--3d51a6a12578c8dc47871a8c02358ea34f48343f/GPGHMACSHA1--3d51a6a12578c8dc47871a8c02358ea34f48343f
-deleting annex/objects/a58/40c/GPGHMACSHA1--3d51a6a12578c8dc47871a8c02358ea34f48343f/
-deleting annex/objects/a58/40c/
-deleting annex/objects/a58/40b/GPGHMACSHA1--dd270aa886d4c15376ad326181c990040d282f40/GPGHMACSHA1--dd270aa886d4c15376ad326181c990040d282f40
-deleting annex/objects/a58/40b/GPGHMACSHA1--dd270aa886d4c15376ad326181c990040d282f40/
-deleting annex/objects/a58/40b/
-deleting annex/objects/a58/40a/GPGHMACSHA1--c2e13979509fc921486ef72ba2c61467a53056d4/GPGHMACSHA1--c2e13979509fc921486ef72ba2c61467a53056d4
-deleting annex/objects/a58/40a/GPGHMACSHA1--c2e13979509fc921486ef72ba2c61467a53056d4/
-deleting annex/objects/a58/40a/
-deleting annex/objects/a58/409/GPGHMACSHA1--240222ad5c53cb016451fdae42c21ad30743985a/GPGHMACSHA1--240222ad5c53cb016451fdae42c21ad30743985a
-deleting annex/objects/a58/409/GPGHMACSHA1--240222ad5c53cb016451fdae42c21ad30743985a/
-deleting annex/objects/a58/409/
-deleting annex/objects/a58/408/GPGHMACSHA1--cc1d16826d643817452fe552771a9ff016a26bdb/GPGHMACSHA1--cc1d16826d643817452fe552771a9ff016a26bdb
-deleting annex/objects/a58/408/GPGHMACSHA1--cc1d16826d643817452fe552771a9ff016a26bdb/
-deleting annex/objects/a58/408/GPGHMACSHA1--3ec16720e3fe8898273e5abdad06fd39856cd50d/GPGHMACSHA1--3ec16720e3fe8898273e5abdad06fd39856cd50d
-deleting annex/objects/a58/408/GPGHMACSHA1--3ec16720e3fe8898273e5abdad06fd39856cd50d/
-deleting annex/objects/a58/408/GPGHMACSHA1--1fde349a75f9d3e8c41e9e0877cae50f38d4f56e/GPGHMACSHA1--1fde349a75f9d3e8c41e9e0877cae50f38d4f56e
-deleting annex/objects/a58/408/GPGHMACSHA1--1fde349a75f9d3e8c41e9e0877cae50f38d4f56e/
-deleting annex/objects/a58/408/
-deleting annex/objects/a58/405/GPGHMACSHA1--ca7443f8ad57d2b996e8f4a8afe8daad71f01fc4/GPGHMACSHA1--ca7443f8ad57d2b996e8f4a8afe8daad71f01fc4
-deleting annex/objects/a58/405/GPGHMACSHA1--ca7443f8ad57d2b996e8f4a8afe8daad71f01fc4/
-deleting annex/objects/a58/405/
-deleting annex/objects/a58/404/GPGHMACSHA1--bbd54e0141fef19007d61d5b8b5535af4d0f1643/GPGHMACSHA1--bbd54e0141fef19007d61d5b8b5535af4d0f1643
-deleting annex/objects/a58/404/GPGHMACSHA1--bbd54e0141fef19007d61d5b8b5535af4d0f1643/
-deleting annex/objects/a58/404/GPGHMACSHA1--8903f2b4259d0e5a9361a721b09743dcfea700c7/GPGHMACSHA1--8903f2b4259d0e5a9361a721b09743dcfea700c7
-deleting annex/objects/a58/404/GPGHMACSHA1--8903f2b4259d0e5a9361a721b09743dcfea700c7/
-deleting annex/objects/a58/404/GPGHMACSHA1--66d8456bcc884c16b0ffb1307aea93f0fdff891f/GPGHMACSHA1--66d8456bcc884c16b0ffb1307aea93f0fdff891f
-deleting annex/objects/a58/404/GPGHMACSHA1--66d8456bcc884c16b0ffb1307aea93f0fdff891f/
-deleting annex/objects/a58/404/
-deleting annex/objects/a58/403/GPGHMACSHA1--312323e3fd4c7bb9f7b757fbfdf418b8d6fa8fc6/GPGHMACSHA1--312323e3fd4c7bb9f7b757fbfdf418b8d6fa8fc6
-deleting annex/objects/a58/403/GPGHMACSHA1--312323e3fd4c7bb9f7b757fbfdf418b8d6fa8fc6/
-deleting annex/objects/a58/403/
-deleting annex/objects/a58/402/GPGHMACSHA1--02883fc6e92bd37eef17924a59ed33785df47982/GPGHMACSHA1--02883fc6e92bd37eef17924a59ed33785df47982
-deleting annex/objects/a58/402/GPGHMACSHA1--02883fc6e92bd37eef17924a59ed33785df47982/
-deleting annex/objects/a58/402/
-deleting annex/objects/a58/401/GPGHMACSHA1--1f0eb6423373a21f52e5bf66288ed61791a1ff55/GPGHMACSHA1--1f0eb6423373a21f52e5bf66288ed61791a1ff55
-deleting annex/objects/a58/401/GPGHMACSHA1--1f0eb6423373a21f52e5bf66288ed61791a1ff55/
-deleting annex/objects/a58/401/
-deleting annex/objects/a58/3ff/GPGHMACSHA1--fa03c466efb77de3a63fdfa0da4f7742c5a4129c/GPGHMACSHA1--fa03c466efb77de3a63fdfa0da4f7742c5a4129c
-deleting annex/objects/a58/3ff/GPGHMACSHA1--fa03c466efb77de3a63fdfa0da4f7742c5a4129c/
-deleting annex/objects/a58/3ff/GPGHMACSHA1--e508ac40b3ecf16264bd1eb85ac500083b7f6f69/GPGHMACSHA1--e508ac40b3ecf16264bd1eb85ac500083b7f6f69
-deleting annex/objects/a58/3ff/GPGHMACSHA1--e508ac40b3ecf16264bd1eb85ac500083b7f6f69/
-deleting annex/objects/a58/3ff/GPGHMACSHA1--a9be7525b4d169ca7042a590f6fd7a2eb375a229/GPGHMACSHA1--a9be7525b4d169ca7042a590f6fd7a2eb375a229
-deleting annex/objects/a58/3ff/GPGHMACSHA1--a9be7525b4d169ca7042a590f6fd7a2eb375a229/
-deleting annex/objects/a58/3ff/
-deleting annex/objects/a58/3fc/GPGHMACSHA1--a88f25b5301ce8ec0ac051d392552119d0c9a049/GPGHMACSHA1--a88f25b5301ce8ec0ac051d392552119d0c9a049
-deleting annex/objects/a58/3fc/GPGHMACSHA1--a88f25b5301ce8ec0ac051d392552119d0c9a049/
-deleting annex/objects/a58/3fc/GPGHMACSHA1--5925494f94b08d06e60b14ac83d27213e2b9e7cd/GPGHMACSHA1--5925494f94b08d06e60b14ac83d27213e2b9e7cd
-deleting annex/objects/a58/3fc/GPGHMACSHA1--5925494f94b08d06e60b14ac83d27213e2b9e7cd/
-deleting annex/objects/a58/3fc/GPGHMACSHA1--1f6fafd025532b83226bb2eabd3a7144d832456a/GPGHMACSHA1--1f6fafd025532b83226bb2eabd3a7144d832456a
-deleting annex/objects/a58/3fc/GPGHMACSHA1--1f6fafd025532b83226bb2eabd3a7144d832456a/
-deleting annex/objects/a58/3fc/
-deleting annex/objects/a58/3fa/GPGHMACSHA1--3489640e7f6847c971ef765e198ea2c303886525/GPGHMACSHA1--3489640e7f6847c971ef765e198ea2c303886525
-deleting annex/objects/a58/3fa/GPGHMACSHA1--3489640e7f6847c971ef765e198ea2c303886525/
-deleting annex/objects/a58/3fa/GPGHMACSHA1--1f8c42ce1f0a91da6999cd50cddd1502c3351edc/GPGHMACSHA1--1f8c42ce1f0a91da6999cd50cddd1502c3351edc
-deleting annex/objects/a58/3fa/GPGHMACSHA1--1f8c42ce1f0a91da6999cd50cddd1502c3351edc/
-deleting annex/objects/a58/3fa/
-deleting annex/objects/a58/3f9/GPGHMACSHA1--b34eb2f15b5089250e573d852e85a3d3782f1dee/GPGHMACSHA1--b34eb2f15b5089250e573d852e85a3d3782f1dee
-deleting annex/objects/a58/3f9/GPGHMACSHA1--b34eb2f15b5089250e573d852e85a3d3782f1dee/
-deleting annex/objects/a58/3f9/GPGHMACSHA1--71d0ec95dc3e0e2c843511ec6e4456244e48a6a7/GPGHMACSHA1--71d0ec95dc3e0e2c843511ec6e4456244e48a6a7
-deleting annex/objects/a58/3f9/GPGHMACSHA1--71d0ec95dc3e0e2c843511ec6e4456244e48a6a7/
-deleting annex/objects/a58/3f9/GPGHMACSHA1--7139cde294af35cf57178119a92cdf8c9220d104/GPGHMACSHA1--7139cde294af35cf57178119a92cdf8c9220d104
-deleting annex/objects/a58/3f9/GPGHMACSHA1--7139cde294af35cf57178119a92cdf8c9220d104/
-deleting annex/objects/a58/3f9/
-deleting annex/objects/a58/3f8/GPGHMACSHA1--bd7fd32c0dcaccb05b94e9707d50422548e9e375/GPGHMACSHA1--bd7fd32c0dcaccb05b94e9707d50422548e9e375
-deleting annex/objects/a58/3f8/GPGHMACSHA1--bd7fd32c0dcaccb05b94e9707d50422548e9e375/
-deleting annex/objects/a58/3f8/GPGHMACSHA1--881feef58c16e791ce4657d7637b9617a04b8be1/GPGHMACSHA1--881feef58c16e791ce4657d7637b9617a04b8be1
-deleting annex/objects/a58/3f8/GPGHMACSHA1--881feef58c16e791ce4657d7637b9617a04b8be1/
-deleting annex/objects/a58/3f8/GPGHMACSHA1--3c2b5d82e193cde1fabfc258d1233cb3fc293481/GPGHMACSHA1--3c2b5d82e193cde1fabfc258d1233cb3fc293481
-deleting annex/objects/a58/3f8/GPGHMACSHA1--3c2b5d82e193cde1fabfc258d1233cb3fc293481/
-deleting annex/objects/a58/3f8/
-deleting annex/objects/a58/3f6/GPGHMACSHA1--451c9e5ae1efdf6800e8e6d621a595ef190a22cb/GPGHMACSHA1--451c9e5ae1efdf6800e8e6d621a595ef190a22cb
-deleting annex/objects/a58/3f6/GPGHMACSHA1--451c9e5ae1efdf6800e8e6d621a595ef190a22cb/
-deleting annex/objects/a58/3f6/
-deleting annex/objects/a58/3f5/GPGHMACSHA1--42296a1d6fff2ddfc16ca27d9af19e813c0bd77f/GPGHMACSHA1--42296a1d6fff2ddfc16ca27d9af19e813c0bd77f
-deleting annex/objects/a58/3f5/GPGHMACSHA1--42296a1d6fff2ddfc16ca27d9af19e813c0bd77f/
-deleting annex/objects/a58/3f5/
-deleting annex/objects/a58/3f4/GPGHMACSHA1--c8f147dd76a7fa05c01617843b93455101dc644d/GPGHMACSHA1--c8f147dd76a7fa05c01617843b93455101dc644d
-deleting annex/objects/a58/3f4/GPGHMACSHA1--c8f147dd76a7fa05c01617843b93455101dc644d/
-deleting annex/objects/a58/3f4/GPGHMACSHA1--4674a6cabd9467df8493a8f5a3abb2644080e432/GPGHMACSHA1--4674a6cabd9467df8493a8f5a3abb2644080e432
-deleting annex/objects/a58/3f4/GPGHMACSHA1--4674a6cabd9467df8493a8f5a3abb2644080e432/
-deleting annex/objects/a58/3f4/GPGHMACSHA1--0b96ec853603cdaed97fb8ba4c131a63c4ab9bfb/GPGHMACSHA1--0b96ec853603cdaed97fb8ba4c131a63c4ab9bfb
-deleting annex/objects/a58/3f4/GPGHMACSHA1--0b96ec853603cdaed97fb8ba4c131a63c4ab9bfb/
-deleting annex/objects/a58/3f4/
-deleting annex/objects/a58/3f3/GPGHMACSHA1--0075692484ef1064429567e19ad6befd08e40972/GPGHMACSHA1--0075692484ef1064429567e19ad6befd08e40972
-deleting annex/objects/a58/3f3/GPGHMACSHA1--0075692484ef1064429567e19ad6befd08e40972/
-deleting annex/objects/a58/3f3/
-deleting annex/objects/a58/3f2/GPGHMACSHA1--244a4e561d69a591f37ba2e0b72b6063167554b2/GPGHMACSHA1--244a4e561d69a591f37ba2e0b72b6063167554b2
-deleting annex/objects/a58/3f2/GPGHMACSHA1--244a4e561d69a591f37ba2e0b72b6063167554b2/
-deleting annex/objects/a58/3f2/
-deleting annex/objects/a58/3f1/GPGHMACSHA1--e5fd17f4c1f0361296f6fb84b6feba6d38f05419/GPGHMACSHA1--e5fd17f4c1f0361296f6fb84b6feba6d38f05419
-deleting annex/objects/a58/3f1/GPGHMACSHA1--e5fd17f4c1f0361296f6fb84b6feba6d38f05419/
-deleting annex/objects/a58/3f1/
-deleting annex/objects/a58/3f0/GPGHMACSHA1--e9e5b07a64b6d13664d96d50b74947874ab1c2d0/GPGHMACSHA1--e9e5b07a64b6d13664d96d50b74947874ab1c2d0
-deleting annex/objects/a58/3f0/GPGHMACSHA1--e9e5b07a64b6d13664d96d50b74947874ab1c2d0/
-deleting annex/objects/a58/3f0/GPGHMACSHA1--7eb8c1fc1b0dd5a85048c5af87e9bf91219f8129/GPGHMACSHA1--7eb8c1fc1b0dd5a85048c5af87e9bf91219f8129
-deleting annex/objects/a58/3f0/GPGHMACSHA1--7eb8c1fc1b0dd5a85048c5af87e9bf91219f8129/
-deleting annex/objects/a58/3f0/
-deleting annex/objects/a58/3ef/GPGHMACSHA1--1739cd4196bc2e780c4b28f5b26fa62f5284280c/GPGHMACSHA1--1739cd4196bc2e780c4b28f5b26fa62f5284280c
-deleting annex/objects/a58/3ef/GPGHMACSHA1--1739cd4196bc2e780c4b28f5b26fa62f5284280c/
-deleting annex/objects/a58/3ef/
-deleting annex/objects/a58/3ee/GPGHMACSHA1--fdf34f469975908f27a9a617de8118bc59378f31/GPGHMACSHA1--fdf34f469975908f27a9a617de8118bc59378f31
-deleting annex/objects/a58/3ee/GPGHMACSHA1--fdf34f469975908f27a9a617de8118bc59378f31/
-deleting annex/objects/a58/3ee/GPGHMACSHA1--407e896996b493a3940a01d60a9728cce5af921c/GPGHMACSHA1--407e896996b493a3940a01d60a9728cce5af921c
-deleting annex/objects/a58/3ee/GPGHMACSHA1--407e896996b493a3940a01d60a9728cce5af921c/
-deleting annex/objects/a58/3ee/
-deleting annex/objects/a58/3ed/GPGHMACSHA1--cf7a58e6dc5d7b26b60818865e20856046ce7b94/GPGHMACSHA1--cf7a58e6dc5d7b26b60818865e20856046ce7b94
-deleting annex/objects/a58/3ed/GPGHMACSHA1--cf7a58e6dc5d7b26b60818865e20856046ce7b94/
-deleting annex/objects/a58/3ed/
-deleting annex/objects/a58/3ec/GPGHMACSHA1--b02eb4a5c6191102be83e8505b15e0bb5494ead7/GPGHMACSHA1--b02eb4a5c6191102be83e8505b15e0bb5494ead7
-deleting annex/objects/a58/3ec/GPGHMACSHA1--b02eb4a5c6191102be83e8505b15e0bb5494ead7/
-deleting annex/objects/a58/3ec/GPGHMACSHA1--6e5a1a75c0a10b7b97a6d2052682b103c6ea5b49/GPGHMACSHA1--6e5a1a75c0a10b7b97a6d2052682b103c6ea5b49
-deleting annex/objects/a58/3ec/GPGHMACSHA1--6e5a1a75c0a10b7b97a6d2052682b103c6ea5b49/
-deleting annex/objects/a58/3ec/GPGHMACSHA1--5bcd2f296b94b1b61e5fe3f14955fb12fd21bc28/GPGHMACSHA1--5bcd2f296b94b1b61e5fe3f14955fb12fd21bc28
-deleting annex/objects/a58/3ec/GPGHMACSHA1--5bcd2f296b94b1b61e5fe3f14955fb12fd21bc28/
-deleting annex/objects/a58/3ec/
-deleting annex/objects/a58/3eb/GPGHMACSHA1--d08024f602c0df45ae109ae64d1415037dafb7fe/GPGHMACSHA1--d08024f602c0df45ae109ae64d1415037dafb7fe
-deleting annex/objects/a58/3eb/GPGHMACSHA1--d08024f602c0df45ae109ae64d1415037dafb7fe/
-deleting annex/objects/a58/3eb/GPGHMACSHA1--55fceb15d24bfe24d6cb63829d79adbe180e8065/GPGHMACSHA1--55fceb15d24bfe24d6cb63829d79adbe180e8065
-deleting annex/objects/a58/3eb/GPGHMACSHA1--55fceb15d24bfe24d6cb63829d79adbe180e8065/
-deleting annex/objects/a58/3eb/
-deleting annex/objects/a58/3ea/GPGHMACSHA1--bc0ccd3ceadb28bfdcae8588ce501a2954b378cb/GPGHMACSHA1--bc0ccd3ceadb28bfdcae8588ce501a2954b378cb
-deleting annex/objects/a58/3ea/GPGHMACSHA1--bc0ccd3ceadb28bfdcae8588ce501a2954b378cb/
-deleting annex/objects/a58/3ea/
-deleting annex/objects/a58/3e8/GPGHMACSHA1--7a446562f98d955846e443e666f236ca31ed83d2/GPGHMACSHA1--7a446562f98d955846e443e666f236ca31ed83d2
-deleting annex/objects/a58/3e8/GPGHMACSHA1--7a446562f98d955846e443e666f236ca31ed83d2/
-deleting annex/objects/a58/3e8/GPGHMACSHA1--0cd126b3f7d9d29c0498ea46db2dfc695b4cdfd2/GPGHMACSHA1--0cd126b3f7d9d29c0498ea46db2dfc695b4cdfd2
-deleting annex/objects/a58/3e8/GPGHMACSHA1--0cd126b3f7d9d29c0498ea46db2dfc695b4cdfd2/
-deleting annex/objects/a58/3e8/
-deleting annex/objects/a58/3e7/GPGHMACSHA1--5c17f4d459e1b6bb6d4914cfcfeb06649eccfd22/GPGHMACSHA1--5c17f4d459e1b6bb6d4914cfcfeb06649eccfd22
-deleting annex/objects/a58/3e7/GPGHMACSHA1--5c17f4d459e1b6bb6d4914cfcfeb06649eccfd22/
-deleting annex/objects/a58/3e7/GPGHMACSHA1--24bff8cdcae0a2adb48ccf06f29233d3e06ad1fd/GPGHMACSHA1--24bff8cdcae0a2adb48ccf06f29233d3e06ad1fd
-deleting annex/objects/a58/3e7/GPGHMACSHA1--24bff8cdcae0a2adb48ccf06f29233d3e06ad1fd/
-deleting annex/objects/a58/3e7/GPGHMACSHA1--12f46408733a72e3c07cfeed31be142dcebc0842/GPGHMACSHA1--12f46408733a72e3c07cfeed31be142dcebc0842
-deleting annex/objects/a58/3e7/GPGHMACSHA1--12f46408733a72e3c07cfeed31be142dcebc0842/
-deleting annex/objects/a58/3e7/
-deleting annex/objects/a58/3e6/GPGHMACSHA1--f677ef99252db6ea99f7b418fdc8123de1416345/GPGHMACSHA1--f677ef99252db6ea99f7b418fdc8123de1416345
-deleting annex/objects/a58/3e6/GPGHMACSHA1--f677ef99252db6ea99f7b418fdc8123de1416345/
-deleting annex/objects/a58/3e6/GPGHMACSHA1--16cf185094c7a911ddb7b764019d99f4f568b24b/GPGHMACSHA1--16cf185094c7a911ddb7b764019d99f4f568b24b
-deleting annex/objects/a58/3e6/GPGHMACSHA1--16cf185094c7a911ddb7b764019d99f4f568b24b/
-deleting annex/objects/a58/3e6/
-deleting annex/objects/a58/3e5/GPGHMACSHA1--defdaaaa2a245befed23605e67deb230c907d619/GPGHMACSHA1--defdaaaa2a245befed23605e67deb230c907d619
-deleting annex/objects/a58/3e5/GPGHMACSHA1--defdaaaa2a245befed23605e67deb230c907d619/
-deleting annex/objects/a58/3e5/GPGHMACSHA1--d7df5ec1b874d734ec0b95ca4c990453a546a6b0/GPGHMACSHA1--d7df5ec1b874d734ec0b95ca4c990453a546a6b0
-deleting annex/objects/a58/3e5/GPGHMACSHA1--d7df5ec1b874d734ec0b95ca4c990453a546a6b0/
-deleting annex/objects/a58/3e5/GPGHMACSHA1--96656aaece6f4172d57db4c7d8910e3ea77fb824/GPGHMACSHA1--96656aaece6f4172d57db4c7d8910e3ea77fb824
-deleting annex/objects/a58/3e5/GPGHMACSHA1--96656aaece6f4172d57db4c7d8910e3ea77fb824/
-deleting annex/objects/a58/3e5/GPGHMACSHA1--8e97545269570b5a12868517fc5b14c458ab383c/GPGHMACSHA1--8e97545269570b5a12868517fc5b14c458ab383c
-deleting annex/objects/a58/3e5/GPGHMACSHA1--8e97545269570b5a12868517fc5b14c458ab383c/
-deleting annex/objects/a58/3e5/GPGHMACSHA1--5c541e81265c22dd0834527682b365828dadfbbe/GPGHMACSHA1--5c541e81265c22dd0834527682b365828dadfbbe
-deleting annex/objects/a58/3e5/GPGHMACSHA1--5c541e81265c22dd0834527682b365828dadfbbe/
-deleting annex/objects/a58/3e5/GPGHMACSHA1--1f54292f57783859d40382e012973ea930d4c67d/GPGHMACSHA1--1f54292f57783859d40382e012973ea930d4c67d
-deleting annex/objects/a58/3e5/GPGHMACSHA1--1f54292f57783859d40382e012973ea930d4c67d/
-deleting annex/objects/a58/3e5/
-deleting annex/objects/a58/3e4/GPGHMACSHA1--f46ad8b243436e1186cb821ee640f402568d6088/GPGHMACSHA1--f46ad8b243436e1186cb821ee640f402568d6088
-deleting annex/objects/a58/3e4/GPGHMACSHA1--f46ad8b243436e1186cb821ee640f402568d6088/
-deleting annex/objects/a58/3e4/GPGHMACSHA1--e82e2f9e6ce1fed17bf5820f96ebf7ceb6557caa/GPGHMACSHA1--e82e2f9e6ce1fed17bf5820f96ebf7ceb6557caa
-deleting annex/objects/a58/3e4/GPGHMACSHA1--e82e2f9e6ce1fed17bf5820f96ebf7ceb6557caa/
-deleting annex/objects/a58/3e4/
-deleting annex/objects/a58/3e3/GPGHMACSHA1--c569427bb2404b11091c0c47c7b7c1faafcc7309/GPGHMACSHA1--c569427bb2404b11091c0c47c7b7c1faafcc7309
-deleting annex/objects/a58/3e3/GPGHMACSHA1--c569427bb2404b11091c0c47c7b7c1faafcc7309/
-deleting annex/objects/a58/3e3/GPGHMACSHA1--34126a50061184ceccca13122c92ee2d1e0fcaaa/GPGHMACSHA1--34126a50061184ceccca13122c92ee2d1e0fcaaa
-deleting annex/objects/a58/3e3/GPGHMACSHA1--34126a50061184ceccca13122c92ee2d1e0fcaaa/
-deleting annex/objects/a58/3e3/
-deleting annex/objects/a58/3e2/GPGHMACSHA1--a5db222b17e55313bbbcc007d3b421eb09f31b2a/GPGHMACSHA1--a5db222b17e55313bbbcc007d3b421eb09f31b2a
-deleting annex/objects/a58/3e2/GPGHMACSHA1--a5db222b17e55313bbbcc007d3b421eb09f31b2a/
-deleting annex/objects/a58/3e2/GPGHMACSHA1--198c51669cffbf2718c670cff58f11b93ef166c5/GPGHMACSHA1--198c51669cffbf2718c670cff58f11b93ef166c5
-deleting annex/objects/a58/3e2/GPGHMACSHA1--198c51669cffbf2718c670cff58f11b93ef166c5/
-deleting annex/objects/a58/3e2/
-deleting annex/objects/a58/3e1/GPGHMACSHA1--ea6a2b40219a96f08d8becc4a112734c7b343bda/GPGHMACSHA1--ea6a2b40219a96f08d8becc4a112734c7b343bda
-deleting annex/objects/a58/3e1/GPGHMACSHA1--ea6a2b40219a96f08d8becc4a112734c7b343bda/
-deleting annex/objects/a58/3e1/
-deleting annex/objects/a58/3e0/GPGHMACSHA1--c039cc5b781f964a5b2045217200231763093ef3/GPGHMACSHA1--c039cc5b781f964a5b2045217200231763093ef3
-deleting annex/objects/a58/3e0/GPGHMACSHA1--c039cc5b781f964a5b2045217200231763093ef3/
-deleting annex/objects/a58/3e0/GPGHMACSHA1--6fec4dbcbe44ecbbc39370b7c232e240d65f2c96/GPGHMACSHA1--6fec4dbcbe44ecbbc39370b7c232e240d65f2c96
-deleting annex/objects/a58/3e0/GPGHMACSHA1--6fec4dbcbe44ecbbc39370b7c232e240d65f2c96/
-deleting annex/objects/a58/3e0/
-deleting annex/objects/a58/3de/GPGHMACSHA1--3f9daeb81e907a26d1188fe66996c2ac7c9c9c88/GPGHMACSHA1--3f9daeb81e907a26d1188fe66996c2ac7c9c9c88
-deleting annex/objects/a58/3de/GPGHMACSHA1--3f9daeb81e907a26d1188fe66996c2ac7c9c9c88/
-deleting annex/objects/a58/3de/
-deleting annex/objects/a58/3dd/GPGHMACSHA1--ada3608b08f1c9b760f36a401fa11f378e8ccae2/GPGHMACSHA1--ada3608b08f1c9b760f36a401fa11f378e8ccae2
-deleting annex/objects/a58/3dd/GPGHMACSHA1--ada3608b08f1c9b760f36a401fa11f378e8ccae2/
-deleting annex/objects/a58/3dd/
-deleting annex/objects/a58/3dc/GPGHMACSHA1--92d83c6b5b977a3d0fcf13e3b9f57a6e5401c4e3/GPGHMACSHA1--92d83c6b5b977a3d0fcf13e3b9f57a6e5401c4e3
-deleting annex/objects/a58/3dc/GPGHMACSHA1--92d83c6b5b977a3d0fcf13e3b9f57a6e5401c4e3/
-deleting annex/objects/a58/3dc/
-deleting annex/objects/a58/3da/GPGHMACSHA1--f10d6600aa7837f0ce79c35f5c253f245b5e0b64/GPGHMACSHA1--f10d6600aa7837f0ce79c35f5c253f245b5e0b64
-deleting annex/objects/a58/3da/GPGHMACSHA1--f10d6600aa7837f0ce79c35f5c253f245b5e0b64/
-deleting annex/objects/a58/3da/GPGHMACSHA1--14f6e1dc8b216df0987fd8d46dac81b7341e95a2/GPGHMACSHA1--14f6e1dc8b216df0987fd8d46dac81b7341e95a2
-deleting annex/objects/a58/3da/GPGHMACSHA1--14f6e1dc8b216df0987fd8d46dac81b7341e95a2/
-deleting annex/objects/a58/3da/
-deleting annex/objects/a58/3d7/GPGHMACSHA1--d124b6c5cbc28f4d3324edd74a36ebe4ea9c88f7/GPGHMACSHA1--d124b6c5cbc28f4d3324edd74a36ebe4ea9c88f7
-deleting annex/objects/a58/3d7/GPGHMACSHA1--d124b6c5cbc28f4d3324edd74a36ebe4ea9c88f7/
-deleting annex/objects/a58/3d7/GPGHMACSHA1--1ee83c3a03672e9ae99ea19483eea58979f81605/GPGHMACSHA1--1ee83c3a03672e9ae99ea19483eea58979f81605
-deleting annex/objects/a58/3d7/GPGHMACSHA1--1ee83c3a03672e9ae99ea19483eea58979f81605/
-deleting annex/objects/a58/3d7/
-deleting annex/objects/a58/3d6/GPGHMACSHA1--977aaeca816759b409a052716a0e339147a52103/GPGHMACSHA1--977aaeca816759b409a052716a0e339147a52103
-deleting annex/objects/a58/3d6/GPGHMACSHA1--977aaeca816759b409a052716a0e339147a52103/
-deleting annex/objects/a58/3d6/GPGHMACSHA1--7f23acb14341d1f0efe1be2da179a8c9d2769343/GPGHMACSHA1--7f23acb14341d1f0efe1be2da179a8c9d2769343
-...
-...
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2016-10-26T18:07:51Z"
- content="""
-Well these look like the names I'd expect to see used for encrypted files.
-
-If you had the assistant watching some files that were frequently changing,
-then it could lead to something like this, since many commits would be made
-of many versions of a file, and each version backed up to a new encrypted
-file in the special remote. You can take a look at `git log -S` in the git
-repository and see if there are many commits of some of your files.
-"""]]
+++ /dev/null
-### Please describe the problem.
-Often, when I `git annex get` a large file over ssh, it will hang in the middle, and I'll have to C-c to cancel it, and try again. This strategy works, but I often have to keep canceling and retrying 5-10 times for a large file. This is unfortunate. I think maybe rsync is getting overwhelmed.
-
-Request: Could you please add a flag --autoretry so that if `get` hangs, cancel and try again. This generally works, because of the rsync --partial flag, so it eventually gets to the end of the file. Thanks!
-
-### What steps will reproduce the problem?
-
-
-### What version of git-annex are you using? On what operating system?
-git-annex version: 6.20160511-1~ubuntu14.04.1~ppa1
-Ubuntu 14.04
-
-### 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 get --debug
-[2016-08-26 15:59:19.476393] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"]
-get clerk/H101-2.json [2016-08-26 15:59:19.483388] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
-[2016-08-26 15:59:19.485433] process done ExitSuccess
-[2016-08-26 15:59:19.485676] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
-[2016-08-26 15:59:19.48755] process done ExitSuccess
-[2016-08-26 15:59:19.487727] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4455cba13d289aad3c25ddc097b5ca02e7fc0ffb","--pretty=%H","-n1"]
-[2016-08-26 15:59:19.489793] process done ExitSuccess
-[2016-08-26 15:59:19.4899] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..7af97d408ed894922cd08bd2091dab5bb1cf1df9","--pretty=%H","-n1"]
-[2016-08-26 15:59:19.49133] process done ExitSuccess
-[2016-08-26 15:59:19.491939] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
-(from origin...)
-[2016-08-26 15:59:19.495688] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/voteviewdev' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'voteviewdev' 'git-annex-shell ''sendkey'' ''/srv/annex'' ''--debug'' ''SHA256E-s49892641--7390d24449d67e1d60c31306bfc8b189f7c4ed223cc44bbd0096222b8ede3b92.json'' --uuid ff59187e-f48c-47d0-b75d-320a6a4ce115 ''--'' ''remoteuuid=da1361a1-3f1a-47b8-8165-daf8c30d543d'' ''unlocked='' ''direct='' ''associatedfile=clerk/H101-2.json'' ''--'''","--","dummy:",".git/annex/tmp/SHA256E-s49892641--7390d24449d67e1d60c31306bfc8b189f7c4ed223cc44bbd0096222b8ede3b92.json"]
-[2016-08-26 15:58:37.018182] transfer start
-[2016-08-26 15:58:37.023135] call: rsync ["--server","-t","--inplace","-e.Lsf",".","--sender","../../srv/annex/.git/annex/objects/2G/fP/SHA256E-s49892641--7390d24449d67e1d60c31306bfc8b189f7c4ed223cc44bbd0096222b8ede3b92.json/SHA256E-s49892641--7390d24449d67e1d60c31306bfc8b189f7c4ed223cc44bbd0096222b8ede3b92.json"]
-SHA256E-s49892641--7390d24449d67e1d60c31306bfc8b189f7c4ed223cc44bbd0096222b8ede3b92.json
- 49,101,968 98% 46.83MB/s 0:00:00 [2016-08-26 15:59:22.809273] feed: ssh ["-S",".git/annex/ssh/voteviewdev","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","voteviewdev","git-annex-shell 'transferinfo' '/srv/annex' '--debug' 'SHA256E-s49892641--7390d24449d67e1d60c31306bfc8b189f7c4ed223cc44bbd0096222b8ede3b92.json' --uuid ff59187e-f48c-47d0-b75d-320a6a4ce115 '--' 'remoteuuid=da1361a1-3f1a-47b8-8165-daf8c30d543d' 'associatedfile=clerk/H101-2.json' '--'"]
- 49,892,641 100% 39.52MB/s 0:00:01 (xfr#1, to-chk=0/1)
-[2016-08-26 15:58:39.034666] process done ExitSuccess
-[2016-08-26 15:58:39.038811] transfer done
-[2016-08-26 15:59:23.09308] process done ExitSuccess
-(checksum...) [2016-08-26 15:59:23.093582] read: sha256sum [".git/annex/tmp/SHA256E-s49892641--7390d24449d67e1d60c31306bfc8b189f7c4ed223cc44bbd0096222b8ede3b92.json"]
-[2016-08-26 15:59:23.331872] process done ExitSuccess
-ok
-get clerk/H102-1.json (from origin...)
-[2016-08-26 15:59:23.337838] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/voteviewdev' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'voteviewdev' 'git-annex-shell ''sendkey'' ''/srv/annex'' ''--debug'' ''SHA256E-s41311329--69c3b054a3fe9676133605730d85b7fcef8696f6782d402a524e41b836253891.json'' --uuid ff59187e-f48c-47d0-b75d-320a6a4ce115 ''--'' ''remoteuuid=da1361a1-3f1a-47b8-8165-daf8c30d543d'' ''unlocked='' ''direct='' ''associatedfile=clerk/H102-1.json'' ''--'''","--","dummy:",".git/annex/tmp/SHA256E-s41311329--69c3b054a3fe9676133605730d85b7fcef8696f6782d402a524e41b836253891.json"]
-[2016-08-26 15:59:23.351903] process done ExitSuccess
-[2016-08-26 15:58:39.394898] transfer start
-[2016-08-26 15:58:39.400323] call: rsync ["--server","-t","--inplace","-e.Lsf",".","--sender","../../srv/annex/.git/annex/objects/6Z/QP/SHA256E-s41311329--69c3b054a3fe9676133605730d85b7fcef8696f6782d402a524e41b836253891.json/SHA256E-s41311329--69c3b054a3fe9676133605730d85b7fcef8696f6782d402a524e41b836253891.json"]
-SHA256E-s41311329--69c3b054a3fe9676133605730d85b7fcef8696f6782d402a524e41b836253891.json
- 1,998,848 4% 1.91MB/s 0:00:20 [2016-08-26 15:59:24.608637] feed: ssh ["-S",".git/annex/ssh/voteviewdev","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","voteviewdev","git-annex-shell 'transferinfo' '/srv/annex' '--debug' 'SHA256E-s41311329--69c3b054a3fe9676133605730d85b7fcef8696f6782d402a524e41b836253891.json' --uuid ff59187e-f48c-47d0-b75d-320a6a4ce115 '--' 'remoteuuid=da1361a1-3f1a-47b8-8165-daf8c30d543d' 'associatedfile=clerk/H102-1.json' '--'"]
- 10,616,832 25% 1.54MB/s 0:00:19
-
-
-
-# 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="Detect stalled transfer and retry or abort it"]]
-
-> [[done]], see annex.stalldetection to enable --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="adamboche@d77483462c747486c7a7341a9080d1341eeddfe6"
- nickname="adamboche"
- subject="Retry rsync on failure"
- date="2016-08-26T23:32:46Z"
- content="""
-This may be useful for providing an in-product solution to this problem.
-http://unix.stackexchange.com/a/165417/126433
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2016-10-26T18:26:35Z"
- content="""
-The most common way a network connection can stall like this is when
-moving to a different wifi network: the connection is open but
-no more data will be received. I suppose other kinds of network
-glitches could also lead to this kind of situation.
-
-ssh has some things, like ServerAliveInterval and TCPKeepAlive,
-that it can use to detect such problems. You may find them useful.
-
-----
-
-As for the retrying once a stall is detected, some transfers use
-`forwardRetry` which will automatically retry as long as the failed try
-managed to send some data. But the get/move/copy commands currently use
-`noRetry`. I can't find any justification for not always using
-`forwardRetry`; I think that it was added for the assistant originally and
-the other stuff just never switched over.
-
-Only problem I can think of is, if there actually is a ssh password
-prompt, it would prompt again on retry. But most people using git-annex
-with ssh have something in place to make ssh not prompt repeatedly for
-passwords.
-
-So, I've gone ahead and enabled `forwardRetry` for everything.
-
-----
-
-Occurs to me that git-annex could try to notice when a transfer is not
-progressing, by reusing the existing progress metering code.
-
-Since some remotes don't update the progress meter, this could
-only be used to detect stalls after the progress meter has been updated
-at least once. If the stall occurs earlier than that, it would not be able
-to be detected.
-
-It seems quite hard to come up with a good timeout value to detect a
-stalled connection. Often progress meters are updated after every small
-(eg 32kb) chunk transferred. But others might poll periodically, or might
-use a larger chunk size. It's even possible that some special remotes
-are looking at a percent output by some program, and only update the meter
-when the percent transferred changes -- in which case it could be many
-minutes in between each meter update when a large file is being
-transferred.
-
-If the timeout is too short, git-annex will stall in a new way, by
-constantly killing "stalled" connections before they can send enough data.
-
-----
-
-So it really seems better to fix the ssh connection to not stall, since
-that is not so heuristic a fix. Seems like git-annex could force
-ServerAliveInterval to be set, and perhaps lower ServerAliveCountMax from 3
-to 1. The ssh BatchMode setting sets the former to 300, so a stalled
-connection will time out after 15 minutes. But BatchMode also disables
-prompting, and git-annex should not disable that.
-
-Catch is, what if the user has configured ssh with some
-other ServerAliveInterval value? We don't want git-annex to override that.
-
-(git-annex does have a rudimentary .ssh/config parser, but it's not
-good enough to handle eg, "Host *.example.com ")
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2016-10-26T19:55:18Z"
- content="""
-On the ssh config, one way to do it is to pass -F with a config
-file that git-annex generates. It could look like:
-
- Include ~/.ssh/config
- Include /etc/ssh/ssh_config
- ServerAliveInterval 60
-
-Since ssh uses the first config setting it sees, if `~/.ssh/config`
-or `/etc/ssh/ssh_config` set a ServerAliveInterval that one will be used,
-and otherwise the value git-annex sets will be used.
-
-But.. Ssh enables TCPKeepAlive by default. You'd think that would be enough
-to detect this kind of problem.
-
-There do seem to be reasons for users to disable TCPKeepAlive;
-perhaps it causes annoying disconnects when there's a minor hiccough,
-or a firewall does not support it.
-
-If the problem is that users are disabling TCPKeepAlive, then
-having git-annex enable ServerAliveInterval makes sense.
-
-Ok; implemented this.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2016-12-13T16:05:42Z"
- content="""
-Could the original bug reporter please show what your ~/.ssh/config
-contains? As far as I can tell, ssh's TCPKeepAlive option, which is
-supposed to be enabled by default, unless you have disabled it, should
-avoid such problems.
-
-It may also help to set ServerAliveInterval.
-
-Unfortunately, my attempt to make git-annex set ServerAliveInterval
-when running ssh broke too many systems with old sshed, and I have had to
-revert it.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2018-03-29T17:36:48Z"
- content="""
-We have annex.retry etc configuration now to control retries of transfers.
-
-Stall detection would be good to have in git-annex. Currently, when a
-transfer is stalled, the progress meter stops updating, so displays
-an ETA that's wrong.
-
-Since the progress meter is already getting called periodically when
-a transfer is not stalled, a stall detector could perhaps be added
-into that, to abort stalled transfers. The tricky part being that a few
-types of transfers don't use the internal progress meters but rely on an
-external command's progress display, and the stall detection would need to
-be disabled for those.
-
-Hmm, a password prompt for eg ssh can also "stall"
-a transfer for a long time. Perhaps the thing to do is wait until
-the meter gets updated once, and only then start the stall detector.
-
-But what would the stall detector do when it does detect a stalled
-transfer? It should perhaps cancel the transfer action, but I don't know
-how to do that; the transfer action may have eg run a process, which would
-need to be canceled, or it may have a network connection open. Simply
-killing the transfer thread won't stop a process that it started.
-And when an external special remote is performing the transfer, there's
-nothing in that protocol to cancel a transfer.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-After not syncing my Android repo for a while, I tried to sync it. By some combination of starting up the assistant, killing it, running `git annex sync --content`, and killing *it*, I managed to get the Android client (operating in direct mode) to decide that I had manually deleted a whole bunch of files that had in fact just not been created yet, and to create a commit to that effect, which it promptly synced out to my other repos.
-
-I then synced in my main direct mode crippled filesystem repo with the only copy of some files, and got a bunch of messages that Git Annex was deleting files I wanted to keep. I killed that sync with a ctrl+c.
-
-My problem (***UPDATE**: solved) is: how do I revert the offending commit and restore my files?
-
-My other question (not yet solved) is: how do I prevent this happening again? Is there a way I can pre-clear commits and not accept those that delete files without manual confirmation? Or should I just stop being mean to the Android client and hope it doesn't decide to delete things it shouldn't delete again?
-
-I've tried a `git annex proxy -- git revert HASHOFBADCOMMIT`, but (as I killed Git Annex before it got through recording that it had trashed my files), I just get:
-
-```
-error: Your local changes would be overwritten by revert.
-hint: Commit your changes or stash them to proceed.
-fatal: revert failed
-```
-
-When syncing in a direct mode repo, does Git Annex happily delete the last copy of a file that appears to have been deleted somewhere else? Or does it save it until you manually clean up unused data, by moving it somewhere under .git?
-
-**UPDATE**: A `git annex sync`, of all things, in the direct mode repository seems to have brought the files and their contents back. It created a commit that undid the deleting commit, except for the deletion of a duplicate copy of one file, which I don't need to have.
-
-### What steps will reproduce the problem?
-
-It's not entirely clear. Some combination of interrupting and restarting the Android app can make it think that files have been deleted when they really have never been created.
-
-Alternately, to get the problem I really want to fix now, delete a file in one repo, sync the delete to a direct-mode repo with the only copy. Then somehow undo the delete from the direct mode repo and restore the content of the file.
-
-### What version of git-annex are you using? On what operating system?
-
-The PC has 6.20160903-g1c0b2b4 and Android has 6.20160714.
-
-### 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)
-
-
-> Direct mode was known to have some bugs that could probably have led
-> to this kind of behavior. It has been replaced, so [[done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-I ran git-annex unused on a few annexes and they dropped files that were still being used. The annexes were fully synced and git-annex list showed the files in the annex they were dropped from.
-
-### What steps will reproduce the problem?
-I'm not sure. The files lost appear to be more recently added files, so this bug must be in more recent versions. I will edit and fill this out when I know more.
-
-### What version of git-annex are you using? On what operating system?
-7.20191230-gef6d1e327 on Pop! OS 20.04 (Ubuntu based)
-
-### 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've used git-annex to maintain large file sets for years now and there is no better tool I know of.
-
-[[!tag moreinfo]]
-
-> Closing as requested information has not been provided. If you followup
-> we can reopen it. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2020-11-23T19:00:55Z"
- content="""
-There are some details missing here. Did git-annex actually drop the last copy of one of the files? Usually git annex will refuse to do this. What does `git annex fsck --fast --quiet` say?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2020-11-24T18:37:58Z"
- content="""
-> The annexes were fully synced and git-annex list showed the files in the annex they were dropped from.
-
-That statement does not make a lot of sense. If both repos have been
-synced with the other, then git-annex list could only display the file
-if it was still in the master branch. But then git-annex unused would
-certianly not have considered it unused. (Unless it has an insanely bad bug,
-but the test suite tests that it doesn't have that bug, so it seems likely
-it does not.)
-
-But also, if both repos were synced with one-another, and you had dropped the
-file from one repo, then git-annex list in other other repo would know that and
-would not show the file as still being in it.
-
-Which suggests you mean something else by "fully synced" than being fully in
-sync at that point. Or that you were mistaken about them being fully in sync.
-
-And if you were mistaken about that, it's easy to set up situations where
-two repos are not fully in sync, and so in one, the file is to all appearances
-unused, but in the other one, the file is still in use by a branch.
-
-So, without a way to reproduce this, I have to assume it's user error.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Building the latest version from source, whatever method I use eventually fails on the language-javascript-0.7.1.0 dependency. The error (stack output) below.
-
-
-
-### What steps will reproduce the problem?
-
-1. Install ghc 8.10.7 via ghcup
-2. Check out latest source
-3. Issue any of the supported build commands, watch the failure eventually happen
-
-### What version of git-annex are you using? On what operating system?
-
-git master (tag 8.20211123 has the same issue)
-
-### 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
-
-language-javascript > Configuring language-javascript-0.7.1.0...
-language-javascript > build
-language-javascript > Preprocessing library for language-javascript-0.7.1.0..
-language-javascript > happy: src/Language/JavaScript/Parser/Grammar7.y: hGetContents: invalid argument (invalid byte sequence)
-
-# 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.
-
-> Upstream bug is <https://github.com/simonmar/happy/issues/157>
-> and this cannot be fixed in git-annex, so [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-12-13T16:49:37Z"
- content="""
-Here is an upstream bug report about the same problem,
-<https://github.com/erikd/language-javascript/issues/86>
-
-Unfortunately the author of language-javascript has decided to not support
-building it except in a unicode locale. So you will need to set
-LANG or similar to a unicode locale to avoid the problem.
-
-I don't see anything I can do about this in git-annex, this is not a direct
-dependency and it is uncreasingly unusual for users to not use a unicode
-locale, so while I would rather compilers (and everything else) did not crash
-in these situations, I expect that anyone not using a unicode locale is
-going to see lots of problems like this in the future.
-"""]]
+++ /dev/null
-I did a "git annex add" of a bunch of files on a storage server with low IOPS, and saw this:
-
- git-annex: /tank/Media/Pictures/.git/annex/tmp/430_32b_SHA256E-s4464838--c1785a76ee1451f602e93c99c147e214705004e541de8256d74a3be3717d15e5.jpg.log: openBinaryFile: resource busy (file is locked)
-failed
-
-How is that even possible, when the server is doing nothing else?
-
-[[!tag moreinfo]]
-
-> Closing as I've been waiting for more information for 6 years. [[done]]
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.152.108.211"
- subject="comment 1"
- date="2013-01-05T21:13:09Z"
- content="""
-Is this a Solaris system?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
- nickname="John"
- subject="comment 2"
- date="2013-01-20T03:38:43Z"
- content="""
-No, it's CentOS 6.3 x86_64.,
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.102"
- subject="moreinfo"
- date="2014-03-19T20:49:47Z"
- content="""
-What I don't understand about this is, how does `open` fail due to a file being locked? This is Linux, it doesn't have mandatory locking that I know of, and git-annex certianly doesn't use such a thing.
-
-I really need a way to reproduce this and/or a strace. As it is, I've never seen this reported by anyone else and don't understand the failure mode at all.
-
-The relevant part of the code seems to be here:
-
-[[!format haskell \"\"\"
-setJournalFile :: JournalLocked -> FilePath -> String -> Annex ()
-setJournalFile _jl file content = do
- tmp <- fromRepo gitAnnexTmpMiscDir
- createAnnexDirectory =<< fromRepo gitAnnexJournalDir
- createAnnexDirectory tmp
- -- journal file is written atomically
- jfile <- fromRepo $ journalFile file
- let tmpfile = tmp </> takeFileName jfile
- liftIO $ do
- writeBinaryFile tmpfile content
- moveFile tmpfile jfile
-\"\"\"]]
-
-While there is some ctnl locking going on, it locks a special sentinal file, not the file it's writing to.
-"""]]
+++ /dev/null
-I may be misunderstanding the purpose of mincopies, but I found this surprising. I would expect annex to not drop the file, because doing so violates the mincopies setting:
-
-```
-luckbox:orig patmaddox$ git annex mincopies
-3
-luckbox:orig patmaddox$ git annex whereis testmincopies
-whereis testmincopies (3 copies)
- 1c09b94f-eed3-425d-9bbe-49aa5e575ed9 -- [s3]
- c2bafb10-bf48-4ae5-a1b9-d142f2bea86a -- patmaddox@luckbox.local:~/Desktop/annex_test [here]
- c8144467-348b-476d-8464-5dfe98580f0b -- patmaddox@istudo.local:~/Desktop/annex [istudo]
-ok
-luckbox:orig patmaddox$ git annex drop testmincopies
-drop testmincopies (locking istudo...) ok
-(recording state in git...)
-luckbox:orig patmaddox$ git annex whereis testmincopies
-whereis testmincopies (2 copies)
- 1c09b94f-eed3-425d-9bbe-49aa5e575ed9 -- [s3]
- c8144467-348b-476d-8464-5dfe98580f0b -- patmaddox@istudo.local:~/Desktop/annex [istudo]
-ok
-```
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-04-27T17:06:45Z"
- content="""
-Please, when filing a bug report, especially one that has the potential
-to be a major data loss bug, provide enough information to reproduce the bug
-report. This includes a version number, and ideally showing how to create a
-new repository and configure it, from scratch, so that the bug occurs.
-
-I suspect that what is happening here is, you don't have numcopies set to a
-number >= mincopies. And there's code that only checks numcopies, with the
-assumption that if it makes sure numcopies is satisfied, mincopies must be
-satisfied since it's a smaller or equal number.
-
-Of course, that's just a guess, but it was the first way I was able to
-reproduce a behavior like you show.
-
-I guess that's a bug, but it's not a major data loss bug since numcopies
-defaults to 1 it will preserve at least that many. Also, it's not a very
-wise configuration because mincopies is a new feature and if an older
-version of git-annex, that does not support it, is used with this
-repository, it will not know about mincopies and will only enforce
-numcopies.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Trying to execute an external remote shell script on windows fails.
-
-
-### What steps will reproduce the problem?
-
- $git annex initremote test type=external externaltype=rclone encryption=none
- initremote test git-annex: Cannot run git-annex-remote-rclone -- Make sure it's in your PATH and is executable.
-
-
-### What version of git-annex are you using? On what operating system?
-
-windows, using 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
-
-
-
-### Please provide any additional information below.
-
-I've also tried fooling around with the proxy, which may help with pinpointing the issue?
-
-[[!format sh """
-$ git-annex-remote-rclone
-VERSION 1
-
-$ git annex proxy -- git-annex-remote-rclone
-git-annex: git-annex-remote-rclone: createProcess: does not exist (No such file or directory)
-failed
-git-annex: proxy: 1 failed
-
-$ git annex proxy -- which git-annex-remote-rclone
-/d/bin/git-annex-remote-rclone
-
-$ git annex proxy -- /d/bin/git-annex-remote-rclone
-git-annex: D:/bin/git-annex-remote-rclone: createProcess: invalid argument (Exec format error)
-failed
-git-annex: proxy: 1 failed
-
-$ git annex proxy -- sh /d/bin/git-annex-remote-rclone
-VERSION 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)
-
-Oh yeah! This software is awesome. After getting used to having "dummy" shortcuts to content I don't currently have, with the simple ability to get/drop that content, I can't believe I haven't seen this anywhere before. If there is anything more impressive than this software, it's the support it has had from Joey over all this time. I'd have pulled my hair out long ago. :P
-
-> [[fixed|done]] although untested --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
- nickname="jason.dixon.email"
- avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
- subject="Perhaps relevant"
- date="2017-03-08T17:31:30Z"
- content="""
-Not sure if this is helpful or relevant, but it may be?
-
-https://github.com/jgm/pandoc/issues/3247#issuecomment-262036875
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-03-08T19:20:21Z"
- content="""
-git-annex on Windows already checks if external special remotes start
-with #! and tries to handle the shebang, since Windows does not do that
-natively. That was added in version 6.20160907.
-([[todo/refactor_shebang_handling_code_for_wider_use]])
-
-`git-annex proxy` does not do that, and I feel it's out of scope for it to
-do so. So the proxy stuff you tried is a red herring.
-
-It might be useful to use --debug to see what command git-annex tries to
-execute when running the external special remote program.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2017-03-08T19:36:57Z"
- content="""
-Looking into it a bit more, the problem seems to be that findShellCommand
-expects a path to a file to examine, but when it's used for an external
-special remote, it's only given the name of the command.
-
-So, I fixed it by searching for the command in the PATH.
-
-I have still not tested if this works on Windows, but probably, I think.
-As long as PATH is set on Windows at least.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
- nickname="jason.dixon.email"
- avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
- subject="re: comment 3"
- date="2017-03-08T21:58:14Z"
- content="""
-Awesome, thanks Joey. Yeah that sounds plausible. I'll check it out whenever the next version comes by. Thanks. Keep up the amazing work! :)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="datamanager"
- avatar="http://cdn.libravatar.org/avatar/7d4ca7c5e571d4740ef072b83a746c12"
- subject="I think I am having the same issue"
- date="2021-04-28T01:19:46Z"
- content="""
-Hello, I think I am having the same issue, though some particulars seem different. It's marked as solved, but what exactly is the solution?
-
-I tried running `git annex enableremote --debug google-drive`, and got this output:
-
-```
-[2021-04-28 01:11:19.033938395] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
-[2021-04-28 01:11:19.880161468] process done ExitSuccess
-[2021-04-28 01:11:19.881748395] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
-[2021-04-28 01:11:20.742986051] process done ExitSuccess
-[2021-04-28 01:11:20.760170947] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..b8c2aac9d4d666ae5c8ee2041c643052ecf7dcbe\",\"--pretty=%H\",\"-n1\"]
-[2021-04-28 01:11:21.239519332] process done ExitSuccess
-[2021-04-28 01:11:21.240506519] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..bd130925066b8c62855ac88d4640bda4b4d14afa\",\"--pretty=%H\",\"-n1\"]
-[2021-04-28 01:11:21.621569176] process done ExitSuccess
-[2021-04-28 01:11:21.627188551] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
-[2021-04-28 01:11:21.629520009] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
-enableremote google-drive [2021-04-28 01:11:22.153897457] chat: /data/data/com.termux/files/usr/bin/git-annex-remote-rclone []
-(encryption update) (to gpg keys: redacted) [2021-04-28 01:11:22.164967925] chat: /data/data/com.termux/files/usr/bin/git-annex-remote-rclone []
-
-git-annex: Cannot run /data/data/com.termux/files/usr/bin/git-annex-remote-rclone -- Make sure it's executable and that its dependencies are installed.
-failed
-[2021-04-28 01:11:22.1806623] process done ExitSuccess
-[2021-04-28 01:11:22.184542509] process done ExitSuccess
-git-annex: enableremote: 1 failed
-```
-
-This remote is configured with gpg, so I tried a test repository without encryption. I attempted to initialize it with `git annex initremote --debug google-drive type=external externaltype=rclone target=google-drive prefix=git-annex-android-test chunk=50MiB encryption=shared mac=HMACSHA512 rclone_layout=lower`, and got this output:
-
-```
-[2021-04-28 01:17:33.983261638] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
-[2021-04-28 01:17:34.314992575] process done ExitSuccess
-[2021-04-28 01:17:34.315285908] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
-[2021-04-28 01:17:34.774339919] process done ExitSuccess
-[2021-04-28 01:17:34.810030752] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..ae1ad94cc2cf05b139560772923f5196793a1015\",\"--pretty=%H\",\"-n1\"]
-[2021-04-28 01:17:35.111290491] process done ExitSuccess
-[2021-04-28 01:17:35.125354033] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
-[2021-04-28 01:17:35.129850856] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
-initremote google-drive [2021-04-28 01:17:35.690712627] chat: /data/data/com.termux/files/usr/bin/git-annex-remote-rclone []
-
-git-annex: Cannot run /data/data/com.termux/files/usr/bin/git-annex-remote-rclone -- Make sure it's executable and that its dependencies are installed.
-failed
-[2021-04-28 01:17:35.70162346] process done ExitSuccess
-[2021-04-28 01:17:35.703906741] process done ExitSuccess
-git-annex: initremote: 1 failed
-```
-
-Hopefully someone can help me, thanks!
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2021-07-13T16:58:59Z"
- content="""
-@datamanager this bug report is about a Windows-specific problem,
-and it was fixed in 2017. You seem to be using Android, unless
-Windows has gotten a termux app that I am not aware of?
-
-It seems likely to me that if you look at
-/data/data/com.termux/files/usr/bin/git-annex-remote-rclone,
-it will start with "#!/bin/bash", and perhaps your android device
-does not have a /bin/bash to run it with. Modifying the script to
-use the path to termux's bash would probably fix that.
-"""]]
+++ /dev/null
-### Please describe the problem.
-I normally use two clients with the assistant (lets call them A and B) and they are usually online at different times.
-Sometimes, after deleting a file in A, I turn on the client in B and when rescanning, instead of deleting that same file from B, it adds it back to A.
-
-I can always delete the file again, but it's a bit annoying. Anyway, it's a lot better than data loss ;)
-
-Might be worthy to mention that the computer running client B is quite slow and has a slow HD. I have 4 git-annex repositories and when I turn on the computer the rescan can easily take up a couple of hours.
-
-
-### What steps will reproduce the problem?
-B -> is turned off
-
-A -> delete file
-
-B -> turn on and wait for rescan
-
-B -> readds the file instead of deleting it
-
-
-### What version of git-annex are you using? On what operating system?
-6.20160923 (Debian Sid)
-
-### 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 years with 4 different repositories, 3 of them pretty big (> 50 GB) and I'm really happy! :)
-
-> This sounds like the git-annex assistant, and probably direct mode,
-> which was pretty buggy. Its replacement avoids those problems,
-> so I'm guessing the bug got fixed. If you still see it, please comment.
-> [[done]] --[[Joey]]
+++ /dev/null
-Apologies if this isn't the right section. I considered posting it at https://git-annex.branchable.com/tips/unlocked_files/ but thought this might be a better place.
-
-### What version of git-annex are you using? On what operating system?
-v7
-
-First of all, I want to say that I'm a *HUGE* fan of Joey and git annex. I've been using and following it for 5+ years now, and absolutely love it.
-
-Unfortunately, now for the first time I saw a change that worries me. One of the core tenets of git annex is "future proofing" in a "world that's forgotten git and git annex" and the latest changes go against that. There seems to be a lot of "magic" under the covers with smudge and clean filters, no longer using standard symlinks to identify files and instead relying on smudge filters which would make life without git and git annex _very_ painful.
-
-I understand that this is an improvement over direct mode, but I view direct mode as a crutch only for people/hosts who need it (and I've used it too). I wish the new "unlocked" files behaved the same way. Just because _one_ of my hosts needs a crutch doesn't mean the rest of them (and the git history) all need to have the data identified by a string that relies on git annex internals. /annex/objects/xx isn't too complicated, but this violates the core tenet that got me on board git annex on day 1.
-
-One more concern I have is the fact that "git add" now adds files in this mode, which is just a big no no. Not even lfs does this with all the complicated smudge/clean work it does.
-
-(On a closing note, I want to add that knowing Joey, he's probably thought through all of this and has very valid reasons it was this way.)
-
-TL;DR
-Please provide support (or better still enable as default) the following behavior:
-
-* "git add" just adds files to git, not annex
-* The v7 unlocked mode stores data in git annex(I mean the git-annex branch), and ideally uses standard mechanism like symlinks to track data, with smudge/clean filters used *only* when necessary. (My guess is that the reason it is this way now is because git probably doesn't like doing a type change of a file)
-
-
-
-> I don't think this is a bug, if you don't like unlocked files you do not
-> need to use them, or if you're using someone else's repo you can `git
-> annex adjust --lock` to convert from unlocked to locked. So [[done]]
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-18T16:11:58Z"
- content="""
-> Just because _one_ of my hosts needs a crutch doesn't mean the rest of them (and the git history) all need to have the data identified by a string that relies on git annex internals
-
-So use `git annex adjust --unlock` on that one host and the rest won't see it.
-
-> /annex/objects/xx isn't too complicated
-
-It is *exactly* as complicated as the same thing in the target of a symlink.
-It can be converted to a symlink with a small shell script.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="CandyAngel"
- avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
- subject="comment 2"
- date="2018-12-20T09:19:15Z"
- content="""
-> It is exactly as complicated as the same thing in the target of a symlink. It can be converted to a symlink with a small shell script.
-
-Err.. by definition, requiring an additional step means it is more complicated. So not \"exactly as complicated\" :P
-"""]]
+++ /dev/null
-I'm not sure if this is a bug, or if I'm just misunderstanding how to
-use `import`. Happy to move this to the forum, if that's more
-appropriate.
-
---
-
-Importing from a directory special-remote into a nested directory
-which contains existing files that are more than 1 level deep tries to
-overwrite existing files?
-
-```shell
-# Import to level 1, with existing files in level 1 - WORKS
-#export import_location=level1 && export existing_file_location=level1
-
-# Import to level 2, with existing files in level 1 - WORKS
-#export import_location=level1/level2 && export existing_file_location=level1
-
-# Import to level 2, with existing files in level 2 - DOES NOT WORK
-#export import_location=level1/level2 && export existing_file_location=level1/level2
-
-# Import to level 3, with existing files in level 1 - WORKS
-#export import_location=level1/level2/level3 && export existing_file_location=level1
-
-# Import to level 3, with existing files in level 2 - DOES NOT WORK
-#export import_location=level1/level2/level3 && export existing_file_location=level1/level2
-
-# Import to level 3, with existing files in level 3 - DOES NOT WORK
-#export import_location=level1/level2/level3 && export existing_file_location=level1/level2/level3
-
-# Import to level 4, with existing files in level 1 - WORKS
-#export import_location=level1/level2/level3/level4 && export existing_file_location=level1
-
-# Import to level 4, with existing files in level 2 - DOES NOT WORK
-#export import_location=level1/level2/level3/level4 && export existing_file_location=level1/level2
-
-# Import to level 4, with existing files in level 3 - DOES NOT WORK
-#export import_location=level1/level2/level3/level4 && export existing_file_location=level1/level2/level3
-
-# Import to level 4, with existing files in level 4 - DOES NOT WORK
-export import_location=level1/level2/level3/level4 && export existing_file_location=level1/level2/level3/level4
-
-
-mkdir remote-directory
-echo "import content" > remote-directory/import-file.txt
-
-mkdir repo
-cd repo
-git init
-git annex init
-git annex initremote myremote type=directory directory=../remote-directory encryption=none importtree=yes exporttree=yes
-
-mkdir -p ${import_location}
-echo "content" > ${existing_file_location}/existing-file.txt
-git annex add --force-large
-git commit -m "add existing file to annex"
-
-git annex import master:${import_location} --from myremote
-git annex merge myremote/master
-```
-
-This is the output of the final scenario:
-
-```shell
-$ git annex merge myremote/master
-merge myremote/master
-error: The following untracked working tree files would be overwritten by merge:
- level1/level2/level3/level4/existing-file.txt
-Please move or remove them before you merge.
-Aborting
-failed
-git-annex: merge: 1 failed
-```
-
---
-
-Running this after encountering the situation above also causes
-strange things to happen on the `myremote/master` branch:
-
-```shell
-git annex import master:${import_location} --from myremote
-git annex import master:${import_location} --from myremote
-git annex import master:${import_location} --from myremote
-git annex import master:${import_location} --from myremote
-```
-
-The `myremote/master` branch appears to be stuck in some sort of loop,
-trying to remove and add the files over and over?
-
---
-
-```shell
-$ git annex version
-git-annex version: 8.20210310
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.4 http-client-0.6.4.1 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-> [[fixed|done]], thanks for an excellent test case. --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-03-20T18:28:47Z"
- content="""
-Hi, <br>
-I don't think you should change the `import_location` for a special-remote after the first import.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="gerta"
- avatar="http://cdn.libravatar.org/avatar/35a862512e6a10052014537b0131e482"
- subject="comment 2"
- date="2021-03-21T11:56:26Z"
- content="""
-Sorry, I think the way I formatted the question made it confusing.
-
---
-
-Starting in an empty directory, and running this:
-
-```shell
-export import_location=level1/level2/level3/level4 && export existing_file_location=level1/level2/level3/level4
-
-
-mkdir remote-directory
-echo \"import content\" > remote-directory/import-file.txt
-
-mkdir repo
-cd repo
-git init
-git annex init
-git annex initremote myremote type=directory directory=../remote-directory encryption=none importtree=yes exporttree=yes
-
-mkdir -p ${import_location}
-echo \"content\" > ${existing_file_location}/existing-file.txt
-git annex add --force-large
-git commit -m \"add existing file to annex\"
-
-git annex import master:${import_location} --from myremote
-git annex merge myremote/master
-```
-
-results in the merge failing with this output:
-
-```
-$ git annex merge myremote/master
-merge myremote/master
-error: The following untracked working tree files would be overwritten by merge:
- level1/level2/level3/level4/existing-file.txt
-Please move or remove them before you merge.
-Aborting
-failed
-git-annex: merge: 1 failed
-```
-
-Should this work, or am I doing something wrong?
-
---
-
-All the other combinations of `import_location` and `existing_file_location` in the original post were other things that I tried while trying to work out if I was using `import` correctly, but each scenario was run in a clean starting directory.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-03-26T17:38:23Z"
- content="""
-It seems that git-annex import is generating a tree containing 2 subtrees
-with the same name. While ls-tree -r shows this as a tree containing
-the 2 files like we'd want to have after the import, looking at it more
-closely shows the problem:
-
- # git ls-tree -r remotes/myremote/master
- 120000 blob a180a12b4c192cb67498f67e476196050cbac770 level1/level2/level3/level4/import-file.txt
- 120000 blob 55a266f9e9629be3d8eba3ad4a65b15d8614e1f8 level1/level2/level3/level4/existing-file.txt
- # git ls-tree remotes/myremote/master
- 040000 tree d77ae5e1f666f8f13795c27ee85a55ce0d1c5136 level1
- # git ls-tree d77ae5e1f666f8f13795c27ee85a55ce0d1c5136
- 040000 tree 79300b8717445f07eee006a0ba8992fb8adee3cd level2
- 040000 tree 28092869684c815a23fb4d0d0753d598f352e9cc level2
- # git ls-tree -r 79300b8717445f07eee006a0ba8992fb8adee3cd
- 120000 blob a180a12b4c192cb67498f67e476196050cbac770 level3/level4/import-file.txt
- # git ls-tree -r 28092869684c815a23fb4d0d0753d598f352e9cc
- 120000 blob 55a266f9e9629be3d8eba3ad4a65b15d8614e1f8 level3/level4/existing-file.txt
-
-I assume this is giving git merge its trouble, although it seems to be
-failing in a highly surprising way since it's getting confused about
-what files are tracked by git in the tree this is being merged into.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-03-26T18:46:19Z"
- content="""
-Note that level1/level2 is sufficient for git-annex to generate the bad
-tree. I also saw git merge fail at that depth.
-
-I've fixed this, at least the test case given and some other similar ones
-I thought of to try.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-I have a git annex remote on s3 configured to push things to glacier rather than normal storage. Compared to regular s3 things in glacier are not immediately available and must be "restored" before they can be downloaded (the trade off is that data which is untouched long term is quite a lot cheaper per GB). I'm using the DEEP_ARCHIVE storage class (configured using the `storageclass` key in the remote's config, I didn't fiddle with the s3 bucket lifecycle at all). I think the following applies to any Glacier stored objects, the class just changes how long a restore will take.
-
-My annexed objects are > 1GB and the s3 remote is chunked at 1GB granularity.
-
-When I attempt to `git annex get` such an object the error message misleading refers to the unchunked path e.g. `/SHA256E-s6749536256--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso` rather than `/SHA256E-s6749536256-S1000000000-C1--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso` etc, which sent me down a blind alleyway for a bit. If I `git annex get -d` then I can see in the log that it tries the chunked path first and the falls back to the unchunked. It would be useful if the non-verbose error message listed the first attempt and the fallback. It would be even better if it could be aware enough of Glacier to point out that some list objects need to be manually restored in order to be retrieved.
-
-In my quest to manually restore I could not for the life of me figure out (even going into the plumbing layers of git etc) how to retrieve a list of the chunks needed. I can get the key from `git annex info` easily enough and then `aws s3api list-objects --bucket <...> --prefix` to look for chunks of objects with the `SHA256E-s6749536256` prefix which works ok so long as all objects in the annex are different sizes -- AWS CLI seems to only lets you filter by prefix not a glob. I could probably list everything and extract what I wanted with `jq` but I _think_ there are cost implications to listing everything (although I might be wrong about that, and it wouldn't be a lot of money for my use case in any event).
-
-Fixing those two minor issues (the error reporting and the ability to get the list of chunks) would be a massive improvement to the usability of S3/glacier remotes IMHO, especially if the output of the latter were consumable by scripts.
-
-I will also include my manual steps to restore in the final section, it would be amazing of git annex could learn to do all this itself though...
-
-### What steps will reproduce the problem?
-
-Given an S3/glacier remote with chunked objects in it just a `git annex get` for an object in it will do.
-
-### What version of git-annex are you using? On what operating system?
-
-8.20210223-1 on Debian, from the Debian archive.
-
-### Please provide any additional information below.
-
-Issue with `git annex get` error logging:
-
-[[!format sh """
-
-$ git annex get OBJECT.iso
-get OBJECT.iso (from s3...)
-
- HttpExceptionRequest Request {
- host = "<REDACTED>"
- port = 80
- secure = False
- requestHeaders = [("Date","Sun, 25 Apr 2021 09:42:56 GMT"),("Authorization","<REDACTED>")]
- path = "/SHA256E-s6749536256--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
- queryString = ""
- method = "GET"
- proxy = Nothing
- rawBody = False
- redirectCount = 10
- responseTimeout = ResponseTimeoutDefault
- requestVersion = HTTP/1.1
- }
- (StatusCodeException (Response {responseStatus = Status {statusCode = 404, statusMessage = "Not Found"}, responseVersion = HTTP/1.1, responseHeaders = [("x-amz-request-id","YVCPYD2RW4QEWMWN"),("x-amz-id-2","6dJY8ceWlLOSNIyTTchniLm5+cvJLovbMZL44YjNmViGwfChQSmWLl6VI6E5sFNDbMpwUeBhpbA="),("Content-Type","application/xml"),("Transfer-Encoding","chunked"),("Date","Sun, 25 Apr 2021 09:42:55 GMT"),("Server","AmazonS3")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>SHA256E-s6749536256--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso</Key><RequestId>YVCPYD2RW4QEWMWN</RequestId><HostId>6dJY8ceWlLOSNIyTTchniLm5+cvJLovbMZL44YjNmViGwfChQSmWLl6VI6E5sFNDbMpwUeBhpbA=</HostId></Error>")
-
- Unable to access these remotes: s3
-
- No other repository is known to contain the file.
-
- (Note that these git remotes have annex-ignore set: origin)
-failed
-git-annex: get: 1 failed
-
-$ git annex get -d OBJECT.iso
-[...]
-(from s3...)
-[2021-04-25 10:43:44.098104491] Path: "/SHA256E-s6749536256-S1000000000-C1--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-[...]
-[2021-04-25 10:43:44.200461839] Response status: Status {statusCode = 403, statusMessage = "Forbidden"}
-[...]
-[2021-04-25 10:43:44.238156623] Response status: Status {statusCode = 404, statusMessage = "Not Found"}
-[...]
-*** error message as above ***
-
-"""]]
-
-It's notable that the status codes differ, since the chunk is present but not currently accessible while the unchunked just isn't there.
-
-Manually fetching things:
-
-[[!format sh """
-
-: 1. Figure out the key and the prefix on it:
-
-$ git annex info OBJECT.iso
-file: OBJECT.iso
-size: 6.75 gigabytes
-key: SHA256E-s6749536256--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso
-present: false
-
-: 2. Find the number of chunks using the prefix:
-
-$ aws s3api list-objects --bucket <BUCKET> --prefix SHA256E-s6749536256 | jq '.Contents[].Key'
-"SHA256E-s6749536256-S1000000000-C1--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-"SHA256E-s6749536256-S1000000000-C2--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-"SHA256E-s6749536256-S1000000000-C3--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-"SHA256E-s6749536256-S1000000000-C4--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-"SHA256E-s6749536256-S1000000000-C5--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-"SHA256E-s6749536256-S1000000000-C6--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-"SHA256E-s6749536256-S1000000000-C7--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso"
-
-: 3. Request a restore of those chunks:
-
-$ for i in $(seq 1 7) ; do aws s3api restore-object --bucket <BUCKET> --key SHA256E-s6749536256-S1000000000-C${i}--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso --restore-request Days=1 ; done
-
-: 4. Poll for completion, for DEEP_ARCHIVE restores happen on the order of hours.
-
-$ until
- for i in $(seq 1 7) ; do aws s3api head-object --bucket <BUCKET> --key SHA256E-s6749536256-S1000000000-C${i}--f76639fa11276b4045844e6110035c15e6803acc38d77847c2e4a2be1b1850ca.iso ; done | jq -r .Restore
- git annex get OBJECT.iso
-do echo "$(date): sleeping..." ; sleep 1h; done
-
-ongoing-request="true"
-ongoing-request="true"
-...eventually becoming
-ongoing-request="false", expiry-date="Mon, 26 Apr 2021 00:00:00 GMT"
-... for all objects then the "git annex get" succeeds and the loop exits
-
-
-
-"""]]
-
-### 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 loads of stuff. It's awesome, thanks!
-
-> [[closed|done]], see my comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-04-25T11:53:29Z"
- content="""
-I think that is expected, from [[special_remotes/glacier]]: \"To deal with this, commands like \"git-annex get\" request Glacier start the retrieval process, and will fail due to the data not yet being available. \"
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="ijc@c69abafeb65fa2e784811fc549e9976a5cf4b903"
- nickname="ijc"
- avatar="http://cdn.libravatar.org/avatar/83432d9f01a0bedc575703583f7aa7c6"
- subject="comment 2"
- date="2021-05-02T17:54:56Z"
- content="""
-I don't think git-annex is starting any retrieval process, I have to do it manually. I wasn't sure if it was supposed to (it doesn't seem to try) but maybe that's an aspect of this bug too.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 3"
- date="2021-05-02T18:46:34Z"
- content="""
-Sorry, I just noticed that you are using s3 and not glacier-cli (which the [[special_remotes/glacier/]] special-remote uses). So it indeed is a bug, since git-annex doesn't handle glacier with s3 as yet far as I know. Maybe you have more luck with the glacier special-remote?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="ijc@c69abafeb65fa2e784811fc549e9976a5cf4b903"
- nickname="ijc"
- avatar="http://cdn.libravatar.org/avatar/83432d9f01a0bedc575703583f7aa7c6"
- subject="comment 4"
- date="2021-05-03T15:45:14Z"
- content="""
-Thanks Lukey. I'm not really sure how I missed (or how I found and then for some reason discounted) the glacier-cli backend but I think the fact I've started with s3 means I'm stuck with it unless I want to reupload a dozen TB of data and/or pay enormous retrieval/move fees (AIUI this is a property of the AWS end of things, not a git-annex issue, although s3 DEEP_ARCHIVE uses Glacier it's not the same objects/apis as going at glacier direct).
-
-FWIW the docs for storageclass at https://git-annex.branchable.com/special_remotes/S3/ refer one to s3cmd(1) for the list of valid values which includes DEEP_ARCHIVE, so that might be how I came to do things this way. Perhaps a pointer to glacier-cli at that point would be appropriate?
-
-I also just found https://git-annex.branchable.com/todo/wishlist__58___Restore_s3_files_moved_to_Glacier/ which is related to this but involves s3 lifecycles moving things between s3 and glacier on schedules etc which I think precludes glacier-cli. I've used that in other contexts (perhaps another reason I ended up following this path here too) but never with git-annex.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2021-10-14T16:17:14Z"
- content="""
-I have added a note to the S3 documentation about `DEEP_ARCHIVE` and the
-glacier special remote.
-
-I have made git-annex display the exception for the more likely chunked
-location, rather than the less likely unchunked location, when retrieving
-from both locations fails. Although it's still possible for there to be
-situations where the exception if displays is not for the location where
-the content actually is. Eg, if the chunk size of the remote has
-changed over time.
-
-I think that todo is basically talking about the same desire to make the S3
-remote support these glacier-style storage classes, in one way or another,
-and so I think this bug report can be closed as otherwise a duplicate of it.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-I'm seeing some inconsistent results between runs of `git annex fsck` and `git annex whereis` that I'm not able to explain. When I run `git annex fsck`, it reports a few keys that only have 1 copy, and advises me to make more copies. If I run `git annex whereis --key <key>`, git annex confirms that it only knows about 1 copy of this key. If I then use `git log --stat -S'<key>'` to find the actual file that it refers to, and run `git annex whereis <file>`, git annex report 9 copies of this file. Checking on remotes shows that these files do exist on the remote, so why does `git annex fsck` and `git annex whereis` mis-report the number of copies when querying for the key - but not for the actual filename? Additionally, `git annex find --lackingcopies 1` doesn't return any results, but should if there are actually files with not enough copies?
-
-
-### What steps will reproduce the problem?
-
-
-### What version of git-annex are you using? On what operating system?
-
-5.20151208-1build1 on Ubuntu Xenial, one remote running 5.20141024~bpo70+1 on 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
-
-[william@hactar ~/Pictures/Photo Library]$ git annex whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
-git-annex: SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 not found
-git-annex: whereis: 1 failed
-[william@hactar ~/Pictures/Photo Library]$ git annex whereis --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
-whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 (1 copy)
- 7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here]
-ok
-[william@hactar ~/Pictures/Photo Library]$ git annex fsck --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
-fsck SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
- Only 1 of 3 trustworthy copies exist of SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
- Back it up with git-annex copy.
-failed
-(recording state in git...)
-git-annex: fsck: 1 failed
-[william@hactar ~/Pictures/Photo Library]$ git log --stat -S'SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9'
-[william@hactar ~/Pictures/Photo Library]$ git annex whereis 2009/05/05/P1040890.JPG
-whereis 2009/05/05/P1040890.JPG (9 copies)
- 0e825a69-1927-4f62-b731-6f3e98bba998 -- william@marvin:/media/backup/annex/photos [marvin]
- 1b728ab5-1e32-45a6-bc11-2a4bfdc9d6ab -- backup1
- 5c0caa42-b489-467b-a612-9590fa9d5a94 -- backup2
- 7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here]
- 894b2216-72e0-40e1-8765-1386e1e9e4b4 -- backup3
- 96f19fa8-d385-4e8b-b000-61ee15993a70 -- backup3
- a862b121-d794-4af4-bb56-21adfe8962f2 -- S3
- b083f8ae-42fb-41f0-a2a3-4e7c9f93aadb -- [guide]
- bf021ce9-465b-4419-86e7-bddfd208fca4 -- git@newzaphod:~/repositories/annex/photos.git [zaphod]
-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 trust Git Annex to keep hundreds of GB of data safe, and it has never failed me - despite my best efforts
-
-> [[closing|done]] per my comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-12-13T16:42:08Z"
- content="""
-The obvious reason for this would be if the file no longer points to that
-same key. Perhaps the file got modified and the key is the old version of
-the file.
-
-That would explain everything you showed, so currently I don't see any
-bug..
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Metadata are not stored in a consistent format. It seems more like git-annex chooses the "smallest" charset able to hold the data, i.e. US-ASCII, unless there are latin1 characters, and only UTF-8 if there are UTF-8 characters that are not in latin1
-
-### What steps will reproduce the problem?
-
- % git init
- Initialized empty Git repository in /home/madduck/.tmp/cdt.GlIevu/.git/
-
- % git annex init
- init ok
- (recording state in git...)
-
- % date > a
-
- % git annex add a
- add a ok
- (recording state in git...)
-
- % git annex metadata -s one=$(echo US-ASCII | iconv -tus-ascii) a
- metadata a
- lastchanged=2016-09-25@13-18-57
- one=US-ASCII
- one-lastchanged=2016-09-25@13-18-57
- ok
- (recording state in git...)
-
- % git annex metadata -s two=$(echo lätin1 | iconv -tlatin1) a
- metadata a
- lastchanged=2016-09-25@13-19-37
- one=US-ASCII
- one-lastchanged=2016-09-25@13-18-57
- two=lätin1
- two-lastchanged=2016-09-25@13-19-37
- ok
- (recording state in git...)
-
- % git annex metadata -s three=$(echo unicode… | iconv -tutf8) a
- metadata a
- lastchanged=2016-09-25@13-19-41
- one=US-ASCII
- one-lastchanged=2016-09-25@13-18-57
- three=unicode…
- three-lastchanged=2016-09-25@13-19-41
- two=lätin1
- two-lastchanged=2016-09-25@13-19-37
- ok
- (recording state in git...)
-
- % git annex metadata -g three a | iconv -tutf8
- unicode…
-
- % git annex metadata -g two a | iconv -tutf8
- liconv: illegal input sequence at position 1
-
- % git annex metadata -g one a | iconv -tutf8
- US-ASCII
-
- % git annex metadata -g two a | iconv -flatin1 -tutf8
- lätin1
-
-### What version of git-annex are you using? On what operating system?
-
-6.20160808-1
-
-[[!tag moreinfo]]
-
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-09-26T20:50:26Z"
- content="""
-The metadata you get out should always be encoded the same as the metadata
-you put in. The encoding, or encodings used are up to you.
-
-Are you seeing metadata queries returning a different sequence of bytes
-than the sequence of bytes that were originally stored? If not, I don't
-think this is a bug.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-01-29T19:32:25Z"
- content="""
- joey@darkstar:~>echo lätin1 | iconv -tlatin1 | iconv -tutf8
- liconv: illegal input sequence at position 1
-
-This is identical to what you did, except I have replaced git-annex
-with a pipe.
-
-So, not a bug.
-"""]]
+++ /dev/null
-### Please describe the problem.
-Build error 1 during build process of git-annex on alpine 5.15 using GHC 9.0.1.
-
-### What steps will reproduce the problem?
-Build git-annex on alpine 5.15 using following APKBUILD:
-https://github.com/ayakael/aports/blob/testing/git-annex/testing/git-annex/APKBUILD
-
-### What version of git-annex are you using? On what operating system?
-git-annex: 20211123
-os: alpine linux 5.15
-ghc: 9.0.1
-cabal: 3.6.2.0
-
-### Please provide any additional information below.
-I made an attempt of fixing by reverting the first fix attempt done on line 181 by commit 2739adc. It gave the same error, but it is most likely related. I know very little of haskell, thus could not push the debugging further.
-
-[[!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
-[411 of 670] Compiling Remote.Glacier ( Remote/Glacier.hs, /var/build/aports/testing/git-annex/src/git-annex-8.20211123/dist-newstyle/build/x86_64-linux/ghc-9.0.1/git-annex-8.20211123/build/git-annex/git-annex-tmp/Remote/Glacier.o, /var/build/aports/testing/git-annex/src/git-annex-8.20211123/dist-newstyle/build/x86_64-linux/ghc-9.0.1/git-annex-8.20211123/build/git-annex/git-annex-tmp/Remote/Glacier.dyn_o )
-
-Remote/Glacier.hs:179:12: error:
- • Couldn't match type: Key
- -> MeterUpdate
- -> Maybe Utility.Hash.IncrementalVerifier
- -> (ContentSource -> Annex a0)
- -> Annex a0
- with: forall a.
- Key
- -> MeterUpdate
- -> Maybe Utility.Hash.IncrementalVerifier
- -> (ContentSource -> Annex a)
- -> Annex a
- Expected: Remote -> Retriever
- Actual: Remote
- -> Key
- -> MeterUpdate
- -> Maybe Utility.Hash.IncrementalVerifier
- -> (ContentSource -> Annex a0)
- -> Annex a0
- • In the expression: byteRetriever . retrieve'
- In an equation for ‘retrieve’: retrieve = byteRetriever . retrieve'
- |
-179 | retrieve = byteRetriever . retrieve'
- | ^^^^^^^^^^^^^^^^^^^^^^^^^
-make: *** [Makefile:58: git-annex] Error 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)
-Oh absolutely. This version compiles fine under alpine 5.14, which uses GHC 8.8.4. I've been using this software for many years without major issues, and it's a linchpin of my backup infrastructure. Thanks for the all the good work!
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="account@dc612ad075297e574ebc3eb9a5b8ab6e753510dc"
- nickname="account"
- avatar="http://cdn.libravatar.org/avatar/6a2e457685ce943a3d85b0a6d1ffb11a"
- subject="Further fix attempts"
- date="2021-12-01T03:25:35Z"
- content="""
-I made another attempt at a fix by porting whatever changes you made to stack.yaml on 2739adc to git-annex.cabal using the following patch.
-[[!format sh \"\"\"
-From 05030463daca2582f2512cf14515393971263a40 Mon Sep 17 00:00:00 2001
-From: \"build@apk-groulx\" <build@apk-groulx.praxis>
-Date: Tue, 30 Nov 2021 06:48:09 +0000
-Subject: [PATCH 1/1] Added dependency for ghc 9.0.1 for cabal
-
----
- git-annex.cabal | 6 ++++--
- 1 file changed, 4 insertions(+), 2 deletions(-)
-
-diff --git a/git-annex.cabal b/git-annex.cabal
-index 9285858cd..1a3ee52ff 100644
---- a/git-annex.cabal
-+++ b/git-annex.cabal
-@@ -330,7 +330,9 @@ Executable git-annex
- directory (>= 1.2),
- disk-free-space,
- filepath,
-- filepath-bytestring (>= 1.4.2.1.1),
-+ filepath-bytestring (>= 1.4.2.1.8),
-+ base16-bytestring (>=0.1.1.7),
-+ base64-bytestring (>=0.0.3),
- IfElse,
- monad-logger (>= 0.3.10),
- free,
-@@ -425,7 +427,7 @@ Executable git-annex
- Other-Modules: Utility.GitLFS
-
- if flag(HttpClientRestricted)
-- Build-Depends: http-client-restricted (>= 0.0.2)
-+ Build-Depends: http-client-restricted (>= 0.0.4)
- CPP-Options: -DWITH_HTTP_CLIENT_RESTRICTED
- else
- Other-Modules: Utility.HttpManagerRestricted
---
-2.34.0
-\"\"\"]]
-
-The same error occurs, unfortunately.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-12-08T19:19:38Z"
- content="""
-Seems this breakage is due to https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
-
-Fixed it.
-"""]]
+++ /dev/null
-### Please describe the problem.
-There appears to be no way of getting the current configuration of special remotes (e.g. url, keyid). Maybe there should be git-annex-showremote (or similar).
-
-### What steps will reproduce the problem?
-Configure the special remote (e.g. webdav), and then forget what settings you specified ;)
-
-### What version of git-annex are you using? On what operating system?
-7.20190129-3 (Debian)
-
-> [[done]] seems the reporter found a way to get what they wanted.
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="derobert"
- avatar="http://cdn.libravatar.org/avatar/05b48b72766177b3b0a6ff4afdb70790"
- subject="comment 1"
- date="2019-05-16T08:12:45Z"
- content="""
-Did you try `git-annex info «remote»` (where «remote» could be the name or the UUID).
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="aragilar"
- avatar="http://cdn.libravatar.org/avatar/7390f7c0dd07d43ca827a5446b65c102"
- subject="comment 2"
- date="2019-05-16T08:26:28Z"
- content="""
-Weird, I tried that on the same remote on a different system, and it gave what I wanted... I'll have to work out why that didn't work the first time. Thanks @derobert!
-"""]]
+++ /dev/null
-### Please describe the problem.
-When stall detection is enabled, debug output for transfers with external special remotes appears to be hidden.
-
-### What steps will reproduce the problem?
-
- git config annex.stalldetection true
- git annex copy file --to=externalspecialremote --debug 2>&1 | grep PROGRESS
- # no lines output
-
-### What version of git-annex are you using? On what operating system?
-
-I'm on RHEL7 and this problem is present in git master for me ever since the introduction of stall detection: 135757d64 through 4d6f74477
-
-### 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've written ESRPs and recovered many lost files =)
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-Just tried to install git-annex on a friend's Windows machine to share a repo, but a lot of the tests failed. I have no idea how to debug things on Windows, maybe someone has an idea. AFAIK Windows has only crippled file systems, I tried with NTFS and ReFS.
-
-It says "Permission denied. File is being used by another process". Maybe some kind of indexing? git annex assistant was turned off and it was the only test running.
-
-### What steps will reproduce the problem?
-
-Install git, install git-annex, run "git annex test"
-
-### What version of git-annex are you using? On what operating system?
-
-Windows 10. git 32 bit
-
-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 SKEIN
-512E 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 """
-
-PS G:\test2> git annex test
-Tests
- QuickCheck
- prop_isomorphic_deencode_git: OK (0.11s)
- +++ OK, passed 1000 tests.
- prop_isomorphic_deencode: OK (0.11s)
- +++ OK, passed 1000 tests.
- prop_isomorphic_fileKey: OK (0.04s)
- +++ OK, passed 1000 tests.
- prop_isomorphic_key_encode: OK (0.06s)
- +++ OK, passed 1000 tests.
- prop_isomorphic_key_decode: OK (0.04s)
- +++ OK, passed 1000 tests.
- prop_isomorphic_shellEscape: OK (0.05s)
- +++ OK, passed 1000 tests.
- prop_isomorphic_shellEscape_multiword: OK (1.61s)
- +++ OK, passed 1000 tests.
- prop_isomorphic_configEscape: OK (0.04s)
- +++ OK, passed 1000 tests.
- prop_parse_show_Config: OK (0.11s)
- +++ OK, passed 1000 tests.
- prop_upFrom_basics: OK (0.04s)
- +++ OK, passed 1000 tests.
- prop_relPathDirToFile_basics: OK (0.09s)
- +++ OK, passed 1000 tests.
- prop_relPathDirToFile_regressionTest: OK
- +++ OK, passed 1000 tests.
- prop_cost_sane: OK
- +++ OK, passed 1000 tests.
- prop_matcher_sane: OK
- +++ OK, passed 1000 tests.
- prop_HmacSha1WithCipher_sane: OK
- +++ OK, passed 1000 tests.
- prop_TimeStamp_sane: OK
- +++ OK, passed 1000 tests.
- prop_addMapLog_sane: OK
- +++ OK, passed 1000 tests.
- prop_verifiable_sane: OK (0.14s)
- +++ OK, passed 1000 tests.
- prop_segment_regressionTest: OK
- +++ OK, passed 1000 tests.
- prop_read_write_transferinfo: OK (0.05s)
- +++ OK, passed 1000 tests.
- prop_read_show_inodecache: OK (0.02s)
- +++ OK, passed 1000 tests.
- prop_parse_show_log: OK (2.05s)
- +++ OK, passed 1000 tests.
- prop_read_show_TrustLevel: OK
- +++ OK, passed 1000 tests.
- prop_parse_show_TrustLog: OK
- +++ OK, passed 1000 tests.
- prop_hashes_stable: OK
- +++ OK, passed 1000 tests.
- prop_mac_stable: OK
- +++ OK, passed 1000 tests.
- prop_schedule_roundtrips: OK (0.02s)
- +++ OK, passed 1000 tests.
- prop_past_sane: OK
- +++ OK, passed 1000 tests.
- prop_duration_roundtrips: OK
- +++ OK, passed 1000 tests.
- prop_metadata_sane: OK (6.90s)
- +++ OK, passed 1000 tests.
- prop_metadata_serialize: OK (6.37s)
- +++ OK, passed 1000 tests.
- prop_branchView_legal: OK (10.22s)
- +++ OK, passed 1000 tests.
- prop_viewPath_roundtrips: OK (0.11s)
- +++ OK, passed 1000 tests.
- prop_view_roundtrips: OK (1.28s)
- +++ OK, passed 1000 tests.
- prop_viewedFile_rountrips: OK (0.04s)
- +++ OK, passed 1000 tests.
- prop_b64_roundtrips: OK
- +++ OK, passed 1000 tests.
- prop_standardGroups_parse: OKInit Tests
- init:
- +++ OK, passed 1000 tests.
- Unit Tests v6 unlocked
- add dup: 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 (1.32s)
- add: OK (1.12s)
-
-All 2 tests passed (2.44s)
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.33s)
- add extras: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.46s)
- shared clone: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (0.94s)
- log: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-+ Sun, 30 Jul 2017 02:07:24 Mitteleurop├Áische Sommerzeit foo | ccfb8066-6f33-425e-9459-7fda7a8b9117 -- test repo [origi
-n]
-OK (0.94s)
- import: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-git-annex: MoveFileEx "C:\\Users\\<username>\\AppData\\Local\\Temp\\importtest.0\\import1\\f" "import1\\f": permission denie
-d (Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.)
-FAIL (4.98s)
- import failed
- reinject: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-git-annex: MoveFileEx "tmpfile" ".git\\annex\\objects\\ecb\\0b5\\SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa\\SHA
-1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa": permission denied (Der Prozess kann nicht auf die Datei zugreifen, da
-sie von einem anderen Prozess verwendet wird.)
-FAIL (3.55s)
- reinject failed
- unannex (no copy): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.20s)
- unannex (with copy): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.51s)
- drop (no remote): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.81s)
- drop (with remote): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-numcopies 2 ok
-(recording state in git...)
-numcopies 1 ok
-(recording state in git...)
-OK (2.31s)
- drop (untrusted remote): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.73s)
- get: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.86s)
- get (ssh remote): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-Der Befehl "git-annex-shell" ist entweder falsch geschrieben oder
-konnte nicht gefunden werden.
-rsync: safe_read failed to read 4 bytes [Receiver]: Connection reset by peer (104)
-rsync error: error in rsync protocol data stream (code 12) at io.c(276) [Receiver=3.1.1]
-FAIL (1.21s)
- get of file failed
- move: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (3.05s)
- move (ssh remote): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-Der Befehl "git-annex-shell" ist entweder falsch geschrieben oder
-konnte nicht gefunden werden.
-rsync: safe_read failed to read 4 bytes [Receiver]: Connection reset by peer (104)
-rsync error: error in rsync protocol data stream (code 12) at io.c(276) [Receiver=3.1.1]
-FAIL (1.19s)
- move --from of file failed
- copy: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (2.56s)
- lock: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (3.44s)
- lock (v6 --force): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-FAIL
- Exception: removeDirectoryRecursive: does not exist (Das System kann die angegebene Datei nicht finden.)
- edit (no pre-commit): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (2.22s)
- edit (pre-commit): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (2.07s)
- partial commit: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (2.03s)
- fix: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.11s)
- direct: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.57s)
- trust: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (2.59s)
- fsck (basics): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-numcopies 2 ok
-(recording state in git...)
- Only 1 of 2 trustworthy copies exist of foo
- Back it up with git-annex copy.
- Only 1 of 2 trustworthy copies exist of sha1foo
- Back it up with git-annex copy.
-numcopies 1 ok
-(recording state in git...)
-OK (3.09s)
- fsck (bare): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.45s)
- fsck (local untrusted): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Only these untrusted locations may have copies of foo
- 3a088e2e-d913-45c7-a6f4-187c6c23d52d -- .t\tmprepo26 [here]
- ccfb8066-6f33-425e-9459-7fda7a8b9117 -- test repo [origin]
- Back it up to trusted locations with git-annex copy.
- Only these untrusted locations may have copies of sha1foo
- ccfb8066-6f33-425e-9459-7fda7a8b9117 -- test repo [origin]
- Back it up to trusted locations with git-annex copy.
-OK (2.05s)
- fsck (remote untrusted): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-numcopies 2 ok
-(recording state in git...)
- Only 1 of 2 trustworthy copies exist of foo
- Back it up with git-annex copy.
- The following untrusted locations may also have copies:
- ccfb8066-6f33-425e-9459-7fda7a8b9117 -- test repo [origin]
- Only 1 of 2 trustworthy copies exist of sha1foo
- Back it up with git-annex copy.
- The following untrusted locations may also have copies:
- ccfb8066-6f33-425e-9459-7fda7a8b9117 -- test repo [origin]
-OK (2.21s)
- fsck --from remote: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.38s)
- migrate: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- MoveFileEx ".git\\annex\\misctmp\\t.0\\t" ".git\\annex\\objects\\6cd\\e82\\SHA256E-s20--e394a389d787383843decc5d3d99b6
-d184ffa5fddeec23b911f9ee7fc8b9ea77\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77": perm
-ission denied (Zugriff verweigert)
-FAIL (2.41s)
- migrate annexedfile failed
- migrate (via gitattributes): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- MoveFileEx ".git\\annex\\misctmp\\t.0\\t" ".git\\annex\\objects\\6cd\\e82\\SHA256E-s20--e394a389d787383843decc5d3d99b6
-d184ffa5fddeec23b911f9ee7fc8b9ea77\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77": perm
-ission denied (Zugriff verweigert)
-FAIL (2.56s)
- migrate annexedfile failed
- unused: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- bloomfilter capacity too large to represent; falling back to sane value
-Unlink of file 'foo' failed. Should I try again? (y/n) y
-Unlink of file 'foo' failed. Should I try again? (y/n) y
-Unlink of file 'foo' failed. Should I try again? (y/n) y
-Unlink of file 'foo' failed. Should I try again? (y/n) y
-Unlink of file 'foo' failed. Should I try again? (y/n) y
-Unlink of file 'foo' failed. Should I try again? (y/n) y
-Unlink of file 'foo' failed. Should I try again? (y/n) n
-fatal: git rm: 'foo': Invalid argument
-FAIL (129.88s)
- git rm failed
- describe: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.83s)
- find: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-foo
-foo
-sha1foo
-sha1foo
-dir/subfile
-OK (2.89s)
- merge: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (0.96s)
- info: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- bloomfilter capacity too large to represent; falling back to sane value
- bloomfilter capacity too large to represent; falling back to sane value
-{"transfers in progress":[],"local annex keys":0,"available local disk space":"840.12 gigabytes (+1 megabyte reserved)",
-"annexed files in working tree":2,"file":null,"trusted repositories":[],"size of annexed files in working tree":"45 byte
-s","local annex size":"0 bytes","command":"info","untrusted repositories":[],"semitrusted repositories":[{"description":
-"web","here":false,"uuid":"00000000-0000-0000-0000-000000000001"},{"description":"bittorrent","here":false,"uuid":"00000
-000-0000-0000-0000-000000000002"},{"description":".t\\tmprepo35","here":true,"uuid":"1493e4c5-cbc7-4571-9c87-696e2a91861
-b"},{"description":"test repo [origin]","here":false,"uuid":"ccfb8066-6f33-425e-9459-7fda7a8b9117"}],"success":true,"blo
-om filter size":"32 mebibytes (0% full)","backend usage":{"SHA1":1,"SHA256E":1},"repository mode":"indirect"}
-OK (1.13s)
- version: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-git-annex version: 6.20170611-gb493ac8
-build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParse
-r 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 SH
-A3_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: 2 3 4 5
-operating system: mingw32 i386
-OK (0.97s)
- sync: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-On branch adjusted/master(unlocked)
-Your branch is up-to-date with 'origin/adjusted/master(unlocked)'.
-nothing to commit, working tree clean
-Counting objects: 10, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (9/9), done.
-Writing objects: 100% (10/10), 1.11 KiB | 0 bytes/s, done.
-Total 10 (delta 2), reused 0 (delta 0)
-To G:/test2/.t\repo
- * [new branch] git-annex -> synced/git-annex
- * [new branch] master -> synced/master
-foo
-wanted . ok
-(recording state in git...)
-On branch adjusted/master(unlocked)
-Your branch and 'origin/adjusted/master(unlocked)' have diverged,
-and have 2 and 2 different commits each, respectively.
- (use "git pull" to merge the remote branch into yours)
-nothing to commit, working tree clean
-Counting objects: 8, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (7/7), done.
-Writing objects: 100% (8/8), 764 bytes | 0 bytes/s, done.
-Total 8 (delta 2), reused 0 (delta 0)
-To G:/test2/.t\repo
- d94bd7a..4751eeb git-annex -> synced/git-annex
-foo
-On branch adjusted/master(unlocked)
-Your branch and 'origin/adjusted/master(unlocked)' have diverged,
-and have 2 and 2 different commits each, respectively.
- (use "git pull" to merge the remote branch into yours)
-nothing to commit, working tree clean
-Counting objects: 5, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (4/4), done.
-Writing objects: 100% (5/5), 522 bytes | 0 bytes/s, done.
-Total 5 (delta 1), reused 0 (delta 0)
-To G:/test2/.t\repo
- 4751eeb..68a9352 git-annex -> synced/git-annex
-OK (4.66s)
- union merge regression: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 11, done.
-remote: Compressing objects: 100% (9/9), done.
-remote: Total 11 (delta 3), reused 0 (delta 0)
-Unpacking objects: 100% (11/11), done.
-From ../../.t\tmprepo39
- * [new branch] adjusted/master(unlocked) -> r2/adjusted/master(unlocked)
- * [new branch] git-annex -> r2/git-annex
- * [new branch] master -> r2/master
-remote: Counting objects: 9, done.
-remote: Compressing objects: 100% (8/8), done.
-remote: Total 9 (delta 3), reused 0 (delta 0)
-Unpacking objects: 100% (9/9), done.
-From ../../.t\tmprepo38
- * [new branch] adjusted/master(unlocked) -> r1/adjusted/master(unlocked)
- * [new branch] git-annex -> r1/git-annex
- * [new branch] master -> r1/master
-Counting objects: 30, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (26/26), done.
-Writing objects: 100% (30/30), 2.87 KiB | 0 bytes/s, done.
-Total 30 (delta 12), reused 0 (delta 0)
-To ../../.t\tmprepo39
- * [new branch] git-annex -> synced/git-annex
- * [new branch] master -> synced/master
-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.
-Counting objects: 30, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (26/26), done.
-Writing objects: 100% (30/30), 2.83 KiB | 0 bytes/s, done.
-Total 30 (delta 13), reused 0 (delta 0)
-To ../../.t\tmprepo38
- * [new branch] git-annex -> synced/git-annex
- * [new branch] master -> synced/master
-To ../../.t\tmprepo38
- ! [rejected] master -> master (non-fast-forward)
-error: failed to push some refs to '../../.t\tmprepo38'
-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.
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Automatic merge failed; fix conflicts and then commit the result.
-[detached HEAD cd6b062] git-annex automatic merge conflict fix
-Updating 75480f7..672d8f6
-error: Your local changes to the following files would be overwritten by merge:
- foo
-Please commit your changes or stash them before you merge.
-Aborting
-remote: Counting objects: 4, done.
-remote: Compressing objects: 100% (4/4), done.
-remote: Total 4 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (4/4), done.
-From ../../.t\tmprepo40
- * [new branch] adjusted/master(unlocked) -> r3/adjusted/master(unlocked)
- * [new branch] git-annex -> r3/git-annex
- * [new branch] master -> r3/master
- * [new branch] synced/master -> r3/synced/master
-From ../../.t\tmprepo38
- * [new branch] adjusted/master(unlocked) -> r1/adjusted/master(unlocked)
- * [new branch] git-annex -> r1/git-annex
- * [new branch] master -> r1/master
- * [new branch] synced/git-annex -> r1/synced/git-annex
- * [new branch] synced/master -> r1/synced/master
-Merge made by the 'recursive' strategy.
- bar.c | 1 -
- foo | 1 -
- sha1foo | 1 -
- 3 files changed, 3 deletions(-)
- delete mode 100644 bar.c
- delete mode 120000 foo
- delete mode 120000 sha1foo
-Updating 75480f7..2773470
-error: Your local changes to the following files would be overwritten by merge:
- foo
-Please commit your changes or stash them before you merge.
-Aborting
-Counting objects: 9, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (9/9), done.
-Writing objects: 100% (9/9), 954 bytes | 0 bytes/s, done.
-Total 9 (delta 5), reused 0 (delta 0)
-To ../../.t\tmprepo40
- 9588f09..b8df995 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-Counting objects: 9, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (9/9), done.
-Writing objects: 100% (9/9), 954 bytes | 0 bytes/s, done.
-Total 9 (delta 5), reused 0 (delta 0)
-To ../../.t\tmprepo38
- 9588f09..b8df995 master -> synced/master
-FAIL (8.41s)
- sync failed in .t\tmprepo39
- adjusted branch merge regression: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-Already on 'adjusted/master(unlocked)'
-M foo
-[adjusted/master(unlocked) 22ff3ea] git-annex in .t\tmprepo41
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor
-remote: Counting objects: 11, done.
-remote: Compressing objects: 100% (10/10), done.
-remote: Total 11 (delta 3), reused 0 (delta 0)
-Unpacking objects: 100% (11/11), done.
-From ../../.t\tmprepo42
- * [new branch] adjusted/master(unlocked) -> r2/adjusted/master(unlocked)
- * [new branch] git-annex -> r2/git-annex
- * [new branch] master -> r2/master
-Counting objects: 18, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (16/16), done.
-Writing objects: 100% (18/18), 1.72 KiB | 0 bytes/s, done.
-Total 18 (delta 7), reused 0 (delta 0)
-To ../../.t\tmprepo42
- * [new branch] git-annex -> synced/git-annex
- * [new branch] master -> synced/master
-Already on 'adjusted/master(unlocked)'
-D conflictor
-M foo
-[adjusted/master(unlocked) b0c16b3] git-annex in .t\tmprepo42
- 2 files changed, 2 insertions(+), 2 deletions(-)
-remote: Counting objects: 5, done.
-remote: Compressing objects: 100% (5/5), done.
-remote: Total 5 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (5/5), done.
-From ../../.t\tmprepo41
- * [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
-Counting objects: 9, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (8/8), done.
-Writing objects: 100% (9/9), 806 bytes | 0 bytes/s, done.
-Total 9 (delta 4), reused 0 (delta 0)
-To ../../.t\tmprepo41
- 6f2f330..2f4c792 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating 6f2f330..2f4c792
-Fast-forward
- conflictor | 2 +-
- foo | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-Updating a6b8bec..222127f
-Fast-forward
- conflictor | 2 +-
- foo | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-remote: Counting objects: 5, done.
-remote: Compressing objects: 100% (5/5), done.
-remote: Total 5 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (5/5), done.
-From ../../.t\tmprepo42
- + 75480f7...62cd69f adjusted/master(unlocked) -> r2/adjusted/master(unlocked) (forced update)
- 14acc87..16ac4ee git-annex -> r2/git-annex
- 6f2f330..2f4c792 master -> r2/master
- 6f2f330..2f4c792 synced/master -> r2/synced/master
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 5, done.
-remote: Compressing objects: 100% (5/5), done.
-remote: Total 5 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (5/5), done.
-From ../../.t\tmprepo41
- + a6b8bec...29bc72f adjusted/master(unlocked) -> r1/adjusted/master(unlocked) (forced update)
-OK (7.19s)
- adjusted branch subtree regression: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-Already on 'adjusted/master(unlocked)'
-M foo
-[adjusted/master(unlocked) dd3d179] git-annex in .t\tmprepo43
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 a/b/c/d
-[adjusted/master(unlocked) 543a653] git-annex in .t\tmprepo43
- 1 file changed, 1 insertion(+)
- create mode 100644 a/b/x/y
-Switched to branch 'master'
-OK (2.58s)
- conflict resolution: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 5cb38e6] git-annex in .t\tmprepo44
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) dbe9298] git-annex in .t\tmprepo45
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 5), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-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 sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Auto-merging conflictor
-CONFLICT (add/add): Merge conflict in conflictor
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD 106cd9d] git-annex automatic merge conflict fix
-Updating 085b7b5..5a26f64
-Fast-forward
- conflictor.variant-75dc | 1 +
- conflictor => conflictor.variant-a507 | 2 +-
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-75dc
- rename conflictor => conflictor.variant-a507 (98%)
-Counting objects: 23, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (22/22), done.
-Writing objects: 100% (23/23), 2.27 KiB | 0 bytes/s, done.
-Total 23 (delta 10), reused 0 (delta 0)
-To ../../.t\tmprepo45
- b9ebb44..106cd9d master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating b9ebb44..106cd9d
-Fast-forward
- conflictor | 1 -
- conflictor.variant-75dc | 1 +
- conflictor.variant-a507 | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 5 files changed, 4 insertions(+), 3 deletions(-)
- delete mode 120000 conflictor
- create mode 120000 conflictor.variant-75dc
- create mode 120000 conflictor.variant-a507
-Updating 834afb8..a855bbb
-Fast-forward
- conflictor => conflictor.variant-75dc | 2 +-
- conflictor.variant-a507 | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- rename conflictor => conflictor.variant-75dc (98%)
- create mode 100644 conflictor.variant-a507
-From ../../.t\tmprepo44
- * [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
-[adjusted/master(unlocked) a544d12] git-annex in .t\tmprepo44
- 1 file changed, 1 insertion(+), 1 deletion(-)
-From ../../.t\tmprepo45
- + 834afb8...ba3658e adjusted/master(unlocked) -> r2/adjusted/master(unlocked) (forced update)
-Counting objects: 1, done.
-Writing objects: 100% (1/1), 191 bytes | 0 bytes/s, done.
-Total 1 (delta 0), reused 0 (delta 0)
-To ../../.t\tmprepo45
- 106cd9d..55808e6 master -> synced/master
-conflictor.variant-a507
-conflictor.variant-75dc
-conflictor.variant-a507
-conflictor.variant-75dc
-OK (8.56s)
- conflict resolution (adjusted branch): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) c828dc1] git-annex in .t\tmprepo46
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) f2a9fab] git-annex in .t\tmprepo47
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-Already on 'adjusted/master(unlocked)'
-M conflictor
-M foo
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 5), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo47
- * [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 sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Auto-merging conflictor
-CONFLICT (add/add): Merge conflict in conflictor
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD 5c75014] git-annex automatic merge conflict fix
-Updating 21164f0..40932a6
-Fast-forward
- conflictor.variant-75dc | 1 +
- conflictor => conflictor.variant-a507 | 2 +-
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-75dc
- rename conflictor => conflictor.variant-a507 (98%)
-Counting objects: 23, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (22/22), done.
-Writing objects: 100% (23/23), 2.31 KiB | 0 bytes/s, done.
-Total 23 (delta 9), reused 0 (delta 0)
-To ../../.t\tmprepo47
- f48a2ad..5c75014 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-[adjusted/master(unlocked) 5582940] git-annex in .t\tmprepo47
- 2 files changed, 2 insertions(+), 2 deletions(-)
-Removing conflictor
-Merge made by the 'recursive' strategy.
- conflictor | 1 -
- conflictor.variant-75dc | 1 +
- conflictor.variant-a507 | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 5 files changed, 4 insertions(+), 3 deletions(-)
- delete mode 120000 conflictor
- create mode 120000 conflictor.variant-75dc
- create mode 120000 conflictor.variant-a507
-Updating 5582940..95b64c3
-Fast-forward
- conflictor => conflictor.variant-75dc | 2 +-
- conflictor.variant-a507 | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- rename conflictor => conflictor.variant-75dc (98%)
- create mode 100644 conflictor.variant-a507
-remote: Counting objects: 6, done.
-remote: Compressing objects: 100% (6/6), done.
-remote: Total 6 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (6/6), done.
-From ../../.t\tmprepo46
- * [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
-Counting objects: 2, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (2/2), done.
-Writing objects: 100% (2/2), 407 bytes | 0 bytes/s, done.
-Total 2 (delta 0), reused 0 (delta 0)
-To ../../.t\tmprepo46
- 5c75014..0be7ee2 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-[adjusted/master(unlocked) e579d2b] git-annex in .t\tmprepo46
- 1 file changed, 1 insertion(+), 1 deletion(-)
-Already up-to-date!
-Merge made by the 'recursive' strategy.
-Updating e579d2b..5dc5ec6
-Fast-forward
- conflictor.variant-a507 | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-remote: Counting objects: 6, done.
-remote: Compressing objects: 100% (6/6), done.
-remote: Total 6 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (6/6), done.
-From ../../.t\tmprepo47
- + 844c7ad...1d42500 adjusted/master(unlocked) -> r2/adjusted/master(unlocked) (forced update)
- 5c75014..0be7ee2 master -> r2/master
- 5c75014..0be7ee2 synced/master -> r2/synced/master
-Counting objects: 2, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (2/2), done.
-Writing objects: 100% (2/2), 334 bytes | 0 bytes/s, done.
-Total 2 (delta 1), reused 0 (delta 0)
-To ../../.t\tmprepo47
- 0be7ee2..b481b8e master -> synced/master
-conflictor.variant-a507
-conflictor.variant-75dc
-conflictor.variant-a507
-conflictor.variant-75dc
-OK (9.46s)
- conflict resolution movein regression: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 98268ad] git-annex in .t\tmprepo48
- 2 files changed, 2 insertions(+), 2 deletions(-)
-remote: Counting objects: 14, done.
-remote: Compressing objects: 100% (11/11), done.
-remote: Total 14 (delta 4), reused 0 (delta 0)
-Unpacking objects: 100% (14/14), done.
-From ../../.t\tmprepo49
- * [new branch] adjusted/master(unlocked) -> r2/adjusted/master(unlocked)
- * [new branch] git-annex -> r2/git-annex
- * [new branch] master -> r2/master
-Counting objects: 33, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (27/27), done.
-Writing objects: 100% (33/33), 3.04 KiB | 0 bytes/s, done.
-Total 33 (delta 9), reused 0 (delta 0)
-To ../../.t\tmprepo49
- * [new branch] git-annex -> synced/git-annex
- * [new branch] master -> synced/master
-To ../../.t\tmprepo49
- ! [rejected] master -> master (non-fast-forward)
-error: failed to push some refs to '../../.t\tmprepo49'
-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.
-[adjusted/master(unlocked) 4839b05] git-annex in .t\tmprepo49
- 2 files changed, 2 insertions(+), 2 deletions(-)
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Automatic merge failed; fix conflicts and then commit the result.
-foo: needs merge
-[detached HEAD 4d9c158] git-annex automatic merge conflict fix
-Updating 4839b05..941b7f7
-Fast-forward
- foo.variant-0b0e | 1 +
- foo => foo.variant-bc25 | 2 +-
- sha1foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 foo.variant-0b0e
- rename foo => foo.variant-bc25 (98%)
-remote: Counting objects: 4, done.
-remote: Compressing objects: 100% (4/4), done.
-remote: Total 4 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (4/4), done.
-From ../../.t\tmprepo48
- * [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
-Counting objects: 10, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (10/10), done.
-Writing objects: 100% (10/10), 1.18 KiB | 0 bytes/s, done.
-Total 10 (delta 2), reused 0 (delta 0)
-To ../../.t\tmprepo48
- dcae980..4d9c158 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating dcae980..4d9c158
-Fast-forward
- foo | 1 -
- foo.variant-0b0e | 1 +
- foo.variant-bc25 | 1 +
- sha1foo | 2 +-
- 4 files changed, 3 insertions(+), 2 deletions(-)
- delete mode 120000 foo
- create mode 120000 foo.variant-0b0e
- create mode 120000 foo.variant-bc25
-Updating 93aeb67..c5dd322
-Fast-forward
- foo => foo.variant-0b0e | 2 +-
- foo.variant-bc25 | 1 +
- sha1foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- rename foo => foo.variant-0b0e (98%)
- create mode 100644 foo.variant-bc25
-remote: Counting objects: 5, done.
-remote: Compressing objects: 100% (4/4), done.
-remote: Total 5 (delta 1), reused 0 (delta 0)
-Unpacking objects: 100% (5/5), done.
-From ../../.t\tmprepo49
- + 75480f7...834d96c adjusted/master(unlocked) -> r2/adjusted/master(unlocked) (forced update)
- 2411485..288a846 git-annex -> r2/git-annex
- + 685e9b5...4d9c158 master -> r2/master (forced update)
- dcae980..4d9c158 synced/master -> r2/synced/master
-OK (8.20s)
- conflict resolution (mixed directory and file): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 77f9c58] git-annex in .t\tmprepo50
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) e1fa8b8] git-annex in .t\tmprepo51
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor/subfile
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 25, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 25 (delta 4), reused 0 (delta 0)
-Unpacking objects: 100% (25/25), done.
-From ../../.t\tmprepo51
- * [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 sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Adding conflictor/subfile
-CONFLICT (file/directory): There is a directory with name conflictor in refs/remotes/r2/master. Adding conflictor as con
-flictor~HEAD
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD 724aad5] git-annex automatic merge conflict fix
-Updating 7ceb7ad..1c51b66
-Fast-forward
- conflictor => conflictor.variant-cc12 | 2 +-
- conflictor/subfile | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- rename conflictor => conflictor.variant-cc12 (98%)
- create mode 100644 conflictor/subfile
-Counting objects: 22, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (21/21), done.
-Writing objects: 100% (22/22), 2.15 KiB | 0 bytes/s, done.
-Total 22 (delta 10), reused 0 (delta 0)
-To ../../.t\tmprepo51
- f4b3387..724aad5 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating f4b3387..724aad5
-Fast-forward
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 120000 conflictor.variant-cc12
-Updating 98b13e3..6ab96da
-Fast-forward
- conflictor.variant-cc12 | 1 +
- conflictor/subfile | 2 +-
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-cc12
-From ../../.t\tmprepo50
- * [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
-conflictor/subfile
-conflictor.variant-cc12
-conflictor/subfile
-conflictor.variant-cc12
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) de2bac8] git-annex in .t\tmprepo52
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) eb3a2f9] git-annex in .t\tmprepo53
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor/subfile
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 3), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo52
- * [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
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Adding conflictor/subfile
-CONFLICT (directory/file): There is a directory with name conflictor in HEAD. Adding conflictor as conflictor~refs_remot
-es_r1_master
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD 80b8489] git-annex automatic merge conflict fix
-Updating f4714af..8c0e1af
-Fast-forward
- conflictor.variant-cc12 | 1 +
- conflictor/subfile | 2 +-
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-cc12
-Counting objects: 24, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (22/22), done.
-Writing objects: 100% (24/24), 2.34 KiB | 0 bytes/s, done.
-Total 24 (delta 9), reused 0 (delta 0)
-To ../../.t\tmprepo52
- c785d3b..80b8489 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating c785d3b..80b8489
-Fast-forward
- conflictor | 1 -
- conflictor.variant-cc12 | 1 +
- conflictor/subfile | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 5 files changed, 4 insertions(+), 3 deletions(-)
- delete mode 120000 conflictor
- create mode 120000 conflictor.variant-cc12
- create mode 120000 conflictor/subfile
-Updating f9dc04b..83e640a
-Fast-forward
- conflictor => conflictor.variant-cc12 | 2 +-
- conflictor/subfile | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- rename conflictor => conflictor.variant-cc12 (98%)
- create mode 100644 conflictor/subfile
-From ../../.t\tmprepo53
- * [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
-conflictor/subfile
-conflictor.variant-cc12
-conflictor/subfile
-conflictor.variant-cc12
-OK (15.63s)
- conflict resolution symlink bit: OK
- conflict resolution (uncommitted local file): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 4cfaea2] git-annex in .t\tmprepo54
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-Untracked files:
- conflictor
-
-nothing added to commit but untracked files present
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 5), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo54
- * [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
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Automatic merge failed; fix conflicts and then commit the result.
-[detached HEAD 2a880d5] git-annex automatic merge conflict fix
-Updating 75480f7..c84a79d
-error: The following untracked working tree files would be overwritten by merge:
- conflictor
-Please move or remove them before you merge.
-Aborting
-Already up-to-date.
-Updating 75480f7..4acfac6
-error: The following untracked working tree files would be overwritten by merge:
- conflictor
-Please move or remove them before you merge.
-Aborting
-Counting objects: 18, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (18/18), done.
-Writing objects: 100% (18/18), 1.77 KiB | 0 bytes/s, done.
-Total 18 (delta 10), reused 0 (delta 0)
-To ../../.t\tmprepo54
- bda2c4e..5fd3f84 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) a7ba016] git-annex in .t\tmprepo56
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor/file
-On branch adjusted/master(unlocked)
-Untracked files:
- conflictor
-
-nothing added to commit but untracked files present
-remote: Counting objects: 25, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 25 (delta 3), reused 0 (delta 0)
-Unpacking objects: 100% (25/25), done.
-From ../../.t\tmprepo56
- * [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
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Automatic merge failed; fix conflicts and then commit the result.
-[detached HEAD f13554c] git-annex automatic merge conflict fix
-Updating 75480f7..01da6d6
-error: The following untracked working tree files would be overwritten by merge:
- conflictor
-Please move or remove them before you merge.
-Aborting
-Already up-to-date.
-Updating 75480f7..2b83f70
-error: The following untracked working tree files would be overwritten by merge:
- conflictor
-Please move or remove them before you merge.
-Aborting
-Counting objects: 18, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (18/18), done.
-Writing objects: 100% (18/18), 1.76 KiB | 0 bytes/s, done.
-Total 18 (delta 10), reused 0 (delta 0)
-To ../../.t\tmprepo56
- 363622c..0103a78 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-OK (10.59s)
- conflict resolution (removed file): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) e7f1054] git-annex in .t\tmprepo58
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 4), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo58
- * [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
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Automatic merge failed; fix conflicts and then commit the result.
-[detached HEAD 55cc242] git-annex automatic merge conflict fix
-Updating 75480f7..bfe5776
-Fast-forward
- conflictor | 1 +
- foo | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor
-Counting objects: 14, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (14/14), done.
-Writing objects: 100% (14/14), 1.42 KiB | 0 bytes/s, done.
-Total 14 (delta 8), reused 0 (delta 0)
-To ../../.t\tmprepo58
- 34511ad..55cc242 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-[adjusted/master(unlocked) 937a71e] git-annex in .t\tmprepo58
- 1 file changed, 1 deletion(-)
- delete mode 100644 conflictor
-Merge made by the 'recursive' strategy.
- foo | 2 +-
- sha1foo | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-Updating 937a71e..e992316
-Fast-forward
- foo | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-remote: Counting objects: 10, done.
-remote: Compressing objects: 100% (9/9), done.
-remote: Total 10 (delta 2), reused 0 (delta 0)
-Unpacking objects: 100% (10/10), done.
-From ../../.t\tmprepo59
- * [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
-Counting objects: 4, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (4/4), done.
-Writing objects: 100% (4/4), 482 bytes | 0 bytes/s, done.
-Total 4 (delta 2), reused 0 (delta 0)
-To ../../.t\tmprepo59
- 55cc242..f01e945 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-[adjusted/master(unlocked) d60d0d5] git-annex in .t\tmprepo59
- 1 file changed, 1 insertion(+), 1 deletion(-)
-CONFLICT (modify/delete): conflictor deleted in refs/heads/synced/master and modified in HEAD. Version HEAD of conflicto
-r left in tree.
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD af662a3] git-annex automatic merge conflict fix
-Updating d60d0d5..2584833
-Fast-forward
- conflictor => conflictor.variant-0cbf | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
- rename conflictor => conflictor.variant-0cbf (98%)
-remote: Counting objects: 4, done.
-remote: Compressing objects: 100% (4/4), done.
-remote: Total 4 (delta 0), reused 0 (delta 0)
-Unpacking objects: 100% (4/4), done.
-From ../../.t\tmprepo58
- + 8291a6a...c7986fa adjusted/master(unlocked) -> r1/adjusted/master(unlocked) (forced update)
- b2dee3f..5c73f12 git-annex -> r1/git-annex
- 55cc242..f01e945 master -> r1/master
- 55cc242..f01e945 synced/master -> r1/synced/master
-Counting objects: 5, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (5/5), done.
-Writing objects: 100% (5/5), 680 bytes | 0 bytes/s, done.
-Total 5 (delta 1), reused 0 (delta 0)
-To ../../.t\tmprepo58
- b2dee3f..5c73f12 git-annex -> synced/git-annex
- f01e945..af662a3 master -> synced/master
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating f01e945..af662a3
-Fast-forward
- conflictor.variant-0cbf | 1 +
- 1 file changed, 1 insertion(+)
- create mode 120000 conflictor.variant-0cbf
-Updating c7986fa..2965015
-Fast-forward
- conflictor.variant-0cbf | 1 +
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor.variant-0cbf
-remote: Counting objects: 5, done.
-remote: Compressing objects: 100% (4/4), done.
-remote: Total 5 (delta 1), reused 0 (delta 0)
-Unpacking objects: 100% (5/5), done.
-From ../../.t\tmprepo59
- + e665450...49f18da adjusted/master(unlocked) -> r2/adjusted/master(unlocked) (forced update)
- 5c73f12..317f667 git-annex -> r2/git-annex
- f01e945..af662a3 master -> r2/master
- f01e945..af662a3 synced/master -> r2/synced/master
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 4933941] git-annex in .t\tmprepo60
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 3), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo60
- * [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
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Automatic merge failed; fix conflicts and then commit the result.
-[detached HEAD a57143f] git-annex automatic merge conflict fix
-Updating 75480f7..b8f5d68
-Fast-forward
- conflictor | 1 +
- foo | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor
-Counting objects: 14, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (14/14), done.
-Writing objects: 100% (14/14), 1.46 KiB | 0 bytes/s, done.
-Total 14 (delta 7), reused 0 (delta 0)
-To ../../.t\tmprepo60
- 41acfd6..a57143f master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-[adjusted/master(unlocked) 5f6a63e] git-annex in .t\tmprepo61
- 1 file changed, 1 insertion(+), 1 deletion(-)
-Counting objects: 8, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (7/7), done.
-Writing objects: 100% (8/8), 853 bytes | 0 bytes/s, done.
-Total 8 (delta 2), reused 0 (delta 0)
-To ../../.t\tmprepo60
- 261f2b0..0908b36 git-annex -> synced/git-annex
- a57143f..828e91b master -> synced/master
-[adjusted/master(unlocked) fdcc819] git-annex in .t\tmprepo60
- 1 file changed, 1 deletion(-)
- delete mode 100644 conflictor
-CONFLICT (modify/delete): conflictor deleted in HEAD and modified in refs/heads/synced/master. Version refs/heads/synced
-/master of conflictor left in tree.
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD 4151827] git-annex automatic merge conflict fix
-Updating fdcc819..975b799
-Fast-forward
- conflictor.variant-0cbf | 1 +
- foo | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor.variant-0cbf
-remote: Counting objects: 10, done.
-remote: Compressing objects: 100% (9/9), done.
-remote: Total 10 (delta 1), reused 0 (delta 0)
-Unpacking objects: 100% (10/10), done.
-From ../../.t\tmprepo61
- * [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
-Counting objects: 5, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (5/5), done.
-Writing objects: 100% (5/5), 695 bytes | 0 bytes/s, done.
-Total 5 (delta 1), reused 0 (delta 0)
-To ../../.t\tmprepo61
- 828e91b..4151827 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating 828e91b..4151827
-Fast-forward
- conflictor | 1 -
- conflictor.variant-0cbf | 1 +
- 2 files changed, 1 insertion(+), 1 deletion(-)
- delete mode 120000 conflictor
- create mode 120000 conflictor.variant-0cbf
-Updating 8780774..c4c9055
-Fast-forward
- conflictor => conflictor.variant-0cbf | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
- rename conflictor => conflictor.variant-0cbf (98%)
-From ../../.t\tmprepo60
- + 7ceafed...f885d4b adjusted/master(unlocked) -> r1/adjusted/master(unlocked) (forced update)
- 0908b36..45e8d64 git-annex -> r1/git-annex
- 828e91b..4151827 master -> r1/master
- 828e91b..4151827 synced/master -> r1/synced/master
-OK (18.00s)
- conflict resolution (nonannexed file): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 4438cd9] git-annex in .t\tmprepo62
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) 7d984b7] git-annex in .t\tmprepo63
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 17, done.
-remote: Compressing objects: 100% (15/15), done.
-remote: Total 17 (delta 2), reused 0 (delta 0)
-Unpacking objects: 100% (17/17), done.
-From ../../.t\tmprepo63
- * [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 sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Auto-merging conflictor
-CONFLICT (add/add): Merge conflict in conflictor
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD ddbc6a3] git-annex automatic merge conflict fix
-Updating c42b305..90fd358
-Fast-forward
- conflictor | 2 +-
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-cc12
-Counting objects: 22, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (21/21), done.
-Writing objects: 100% (22/22), 2.25 KiB | 0 bytes/s, done.
-Total 22 (delta 9), reused 0 (delta 0)
-To ../../.t\tmprepo63
- 6ae609a..ddbc6a3 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating 6ae609a..ddbc6a3
-Fast-forward
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 120000 conflictor.variant-cc12
-Updating 8714c6e..d884f3f
-Fast-forward
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor.variant-cc12
-From ../../.t\tmprepo62
- * [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
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 99fd1b3] git-annex in .t\tmprepo64
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) 30452d4] git-annex in .t\tmprepo65
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 4), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo64
- * [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
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Auto-merging conflictor
-CONFLICT (add/add): Merge conflict in conflictor
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD 46ec327] git-annex automatic merge conflict fix
-Updating 818dce1..9788dab
-Fast-forward
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor.variant-cc12
-Counting objects: 18, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (17/17), done.
-Writing objects: 100% (18/18), 1.69 KiB | 0 bytes/s, done.
-Total 18 (delta 10), reused 0 (delta 0)
-To ../../.t\tmprepo64
- 6ae34c0..46ec327 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating 6ae34c0..46ec327
-Fast-forward
- conflictor | 2 +-
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 4 files changed, 4 insertions(+), 3 deletions(-)
- mode change 120000 => 100644 conflictor
- create mode 120000 conflictor.variant-cc12
-Updating aa27001..eb304ba
-Fast-forward
- conflictor | 2 +-
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-cc12
-From ../../.t\tmprepo65
- * [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
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 34af785] git-annex in .t\tmprepo66
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) d1ad368] git-annex in .t\tmprepo67
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 17, done.
-remote: Compressing objects: 100% (15/15), done.
-remote: Total 17 (delta 1), reused 0 (delta 0)
-Unpacking objects: 100% (17/17), done.
-From ../../.t\tmprepo67
- * [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 sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Auto-merging conflictor
-CONFLICT (add/add): Merge conflict in conflictor
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD b6643ac] git-annex automatic merge conflict fix
-Updating 58a264d..7f1e818
-Fast-forward
- conflictor | 2 +-
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-cc12
-Counting objects: 22, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (21/21), done.
-Writing objects: 100% (22/22), 2.30 KiB | 0 bytes/s, done.
-Total 22 (delta 8), reused 0 (delta 0)
-To ../../.t\tmprepo67
- ad93099..b6643ac master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating ad93099..b6643ac
-Fast-forward
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 120000 conflictor.variant-cc12
-Updating f042552..0b591c1
-Fast-forward
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor.variant-cc12
-From ../../.t\tmprepo66
- * [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
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) aabedb4] git-annex in .t\tmprepo68
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) 0666b67] git-annex in .t\tmprepo69
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 4), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo68
- * [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
-Auto-merging sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Auto-merging conflictor
-CONFLICT (add/add): Merge conflict in conflictor
-Automatic merge failed; fix conflicts and then commit the result.
-conflictor: needs merge
-[detached HEAD 15337ba] git-annex automatic merge conflict fix
-Updating d8e1daa..2bdecc4
-Fast-forward
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
- create mode 100644 conflictor.variant-cc12
-Counting objects: 18, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (17/17), done.
-Writing objects: 100% (18/18), 1.69 KiB | 0 bytes/s, done.
-Total 18 (delta 10), reused 0 (delta 0)
-To ../../.t\tmprepo68
- 0322df0..15337ba master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating 0322df0..15337ba
-Fast-forward
- conflictor | 2 +-
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- sha1foo | 2 +-
- 4 files changed, 4 insertions(+), 3 deletions(-)
- mode change 120000 => 100644 conflictor
- create mode 120000 conflictor.variant-cc12
-Updating f638189..62dac7e
-Fast-forward
- conflictor | 2 +-
- conflictor.variant-cc12 | 1 +
- foo | 2 +-
- 3 files changed, 3 insertions(+), 2 deletions(-)
- create mode 100644 conflictor.variant-cc12
-From ../../.t\tmprepo69
- * [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
-OK (25.61s)
- conflict resolution (nonannexed symlink): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (7.43s)
- conflict resolution (mixed locked and unlocked file): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-[adjusted/master(unlocked) 6c05187] git-annex in .t\tmprepo78
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-[adjusted/master(unlocked) 3968c28] git-annex in .t\tmprepo79
- 1 file changed, 1 insertion(+)
- create mode 100644 conflictor
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-remote: Counting objects: 23, done.
-remote: Compressing objects: 100% (21/21), done.
-remote: Total 23 (delta 4), reused 0 (delta 0)
-Unpacking objects: 100% (23/23), done.
-From ../../.t\tmprepo79
- * [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 sha1foo
-CONFLICT (add/add): Merge conflict in sha1foo
-Auto-merging foo
-CONFLICT (add/add): Merge conflict in foo
-Auto-merging conflictor
-CONFLICT (add/add): Merge conflict in conflictor
-Automatic merge failed; fix conflicts and then commit the result.
-[detached HEAD 54748a5] git-annex automatic merge conflict fix
-Updating 0cafe66..1f3fc72
-Fast-forward
- conflictor | 2 +-
- foo | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-Counting objects: 24, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (22/22), done.
-Writing objects: 100% (24/24), 2.07 KiB | 0 bytes/s, done.
-Total 24 (delta 14), reused 0 (delta 0)
-To ../../.t\tmprepo79
- 9223b4e..54748a5 master -> synced/master
- * [new branch] git-annex -> synced/git-annex
-On branch adjusted/master(unlocked)
-nothing to commit, working tree clean
-Updating 9223b4e..54748a5
-Fast-forward
- conflictor | 2 +-
- foo | 2 +-
- sha1foo | 2 +-
- 3 files changed, 3 insertions(+), 3 deletions(-)
-Updating 592ec16..001733a
-Fast-forward
- conflictor | 2 +-
- foo | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-From ../../.t\tmprepo78
- * [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
-[adjusted/master(unlocked) 43e95b6] git-annex in .t\tmprepo78
- 1 file changed, 1 insertion(+), 1 deletion(-)
-From ../../.t\tmprepo79
- + 592ec16...7fbe351 adjusted/master(unlocked) -> r2/adjusted/master(unlocked) (forced update)
-Counting objects: 1, done.
-Writing objects: 100% (1/1), 191 bytes | 0 bytes/s, done.
-Total 1 (delta 0), reused 0 (delta 0)
-To ../../.t\tmprepo79
- 54748a5..a15aa8c master -> synced/master
-conflictor
-conflictor
-OK (7.72s)
- map: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.25s)
- uninit: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.63s)
- uninit (in git-annex branch): Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
- Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-Switched to branch 'git-annex'
-OK (1.49s)
- upgrade: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (0.99s)
- whereis: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (2.34s)
- hook remote: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (0.97s)
- directory remote: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (2.65s)
- rsync remote: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (3.92s)
- bup remote: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OKgpg testing not implemented on Windows
- (0.99s)
- crypto: OK
- preferred content: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-wanted . ok
-(recording state in git...)
-group . ok
-(recording state in git...)
-wanted . ok
-(recording state in git...)
-group . ok
-(recording state in git...)
-wanted . ok
-(recording state in git...)
-OK (5.19s)
- add subdirs: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-OK (1.96s)
- addurl: Detected a filesystem without fifo support.
- Disabling ssh connection caching.
- Detected a crippled filesystem.
-curl: (37) Couldn't open file /test2/.t/tmprepo91/myurl
-removeDirectoryRecursive: permission denied (Zugriff verweigert)
-sleeping 10 seconds and will retry directory cleanup
-FAIL
- Exception: removeDirectoryRecursive: permission denied (Zugriff verweigert)
- Unit Tests v5 direct
- add dup: Init Tests
- init: 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.
- adjusted branch adjusted/master(unlocked) already exists.
- Aborting because that branch may have changes that have not yet reached master
- You can check out the adjusted branch manually to enter it, or delete the adjusted branch and re-run this command.
- Failed to enter adjusted branch!
-FAIL (0.59s)
- git annex direct failed
- add: FAIL (0.18s)
- foo is not a (crippled) symlink
-
-2 out of 2 tests failed (0.76s)
-FAIL
- Exception: init tests failed! cannot continue
- add extras: FAIL
- Exception: init tests failed! cannot continue
- shared clone: FAIL
- Exception: init tests failed! cannot continue
- log: FAIL
- Exception: init tests failed! cannot continue
- import: FAIL
- Exception: init tests failed! cannot continue
- reinject: FAIL
- Exception: init tests failed! cannot continue
- unannex (no copy): FAIL
- Exception: init tests failed! cannot continue
- unannex (with copy): FAIL
- Exception: init tests failed! cannot continue
- drop (no remote): FAIL
- Exception: init tests failed! cannot continue
- drop (with remote): FAIL
- Exception: init tests failed! cannot continue
- drop (untrusted remote): FAIL
- Exception: init tests failed! cannot continue
- get: FAIL
- Exception: init tests failed! cannot continue
- get (ssh remote): FAIL
- Exception: init tests failed! cannot continue
- move: FAIL
- Exception: init tests failed! cannot continue
- move (ssh remote): FAIL
- Exception: init tests failed! cannot continue
- copy: FAIL
- Exception: init tests failed! cannot continue
- lock: FAIL
- Exception: init tests failed! cannot continue
- lock (v6 --force): FAIL
- Exception: init tests failed! cannot continue
- edit (no pre-commit): FAIL
- Exception: init tests failed! cannot continue
- edit (pre-commit): FAIL
- Exception: init tests failed! cannot continue
- partial commit: FAIL
- Exception: init tests failed! cannot continue
- fix: FAIL
- Exception: init tests failed! cannot continue
- direct: FAIL
- Exception: init tests failed! cannot continue
- trust: FAIL
- Exception: init tests failed! cannot continue
- fsck (basics): FAIL
- Exception: init tests failed! cannot continue
- fsck (bare): FAIL
- Exception: init tests failed! cannot continue
- fsck (local untrusted): FAIL
- Exception: init tests failed! cannot continue
- fsck (remote untrusted): FAIL
- Exception: init tests failed! cannot continue
- fsck --from remote: FAIL
- Exception: init tests failed! cannot continue
- migrate: FAIL
- Exception: init tests failed! cannot continue
- migrate (via gitattributes): FAIL
- Exception: init tests failed! cannot continue
- unused: FAIL
- Exception: init tests failed! cannot continue
- describe: FAIL
- Exception: init tests failed! cannot continue
- find: FAIL
- Exception: init tests failed! cannot continue
- merge: FAIL
- Exception: init tests failed! cannot continue
- info: FAIL
- Exception: init tests failed! cannot continue
- version: FAIL
- Exception: init tests failed! cannot continue
- sync: FAIL
- Exception: init tests failed! cannot continue
- union merge regression: FAIL
- Exception: init tests failed! cannot continue
- adjusted branch merge regression: FAIL
- Exception: init tests failed! cannot continue
- adjusted branch subtree regression: FAIL
- Exception: init tests failed! cannot continue
- conflict resolution: FAIL
- Exception: init tests failed! cannot continue
- conflict resolution (adjusted branch): FAIL
- Exception: init tests failed! cannot continue
- conflict resolution movein regression: FAIL
- Exception: init tests failed! cannot continue
- conflict resolution (mixed directory and file): FAIL
- Exception: init tests failed! cannot continue
- conflict resolution symlink bit: FAIL
- Exception: init tests failed! cannot continue
- conflict resolution (uncommitted local file): FAIL
- Exception: init tests failed! cannot continue
- conflict resolution (removed file): FAIL
- Exception: init tests failed! cannot continue
- conflict resolution (nonannexed file): FAIL
- Exception: init tests failed! cannot continue
- conflict resolution (nonannexed symlink): FAIL
- Exception: init tests failed! cannot continue
- conflict resolution (mixed locked and unlocked file): FAIL
- Exception: init tests failed! cannot continue
- map: FAIL
- Exception: init tests failed! cannot continue
- uninit: FAIL
- Exception: init tests failed! cannot continue
- uninit (in git-annex branch): FAIL
- Exception: init tests failed! cannot continue
- upgrade: FAIL
- Exception: init tests failed! cannot continue
- whereis: FAIL
- Exception: init tests failed! cannot continue
- hook remote: FAIL
- Exception: init tests failed! cannot continue
- directory remote: FAIL
- Exception: init tests failed! cannot continue
- rsync remote: FAIL
- Exception: init tests failed! cannot continue
- bup remote: FAIL
- Exception: init tests failed! cannot continue
- crypto: FAIL
- Exception: init tests failed! cannot continue
- preferred content: FAIL
- Exception: init tests failed! cannot continue
- add subdirs: FAIL
- Exception: init tests failed! cannot continue
- addurl: FAIL
- Exception: init tests failed! cannot continue
-
-74 out of 165 tests failed (406.30s)
- (This could be due to a bug in git-annex, or an incompatibility
- with utilities, such as git, installed on this system.)
-PS G:\test2>
-
-# 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)
-
-Of course! On Linux, it runs perfectly. I manage all my data with git-annex.
-
-> The test suite passes on windows 10 on the autobuilder used to build
-> git-annex. Given the age of this bug, I don't think it's useful to keep
-> it open, so [[done]] --[[Joey]]
+++ /dev/null
-Hello,
-
-### Please describe the problem.
-I am unable to create a gcrypt remote with encryption=shared set. It allways complains with: "git-annex: cannot use gcrypt remote without encryption enabled", however the same setup works when using encryption=hybrid instead.
-
-### What steps will reproduce the problem?
-$ git annex initremote test type=gcrypt encryption=shared gitrepo=../annex-target
-
-### What version of git-annex are you using? On what operating system?
-I tried it with:
-The Version in Debian Buster (6.20180913), latest stable and daily build.
-
-### Please provide any additional information below.
-
-Transcript:
-[[!format sh """
-
-xxx@xxx:~/Documents$ mkdir annex-test
-xxx@xxx:~/Documents$ cd annex-test/
-xxx@xxx:~/Documents/annex-test$ git init
-Initialized empty Git repository in /home/xxx/Documents/annex-test/.git/
-xxx@xxx:~/Documents/annex-test$ git annex init test
-init test ok
-(recording state in git...)
-xxx@xxx:~/Documents/annex-test$ cd ..
-xxx@xxx:~/Documents$ git init --bare annex-target
-Initialized empty Git repository in /home/xxx/Documents/annex-target/
-xxx@xxx:~/Documents$ cd annex-test/
-xxx@xxx:~/Documents/annex-test$ touch test
-xxx@xxx:~/Documents/annex-test$ git annex add test
-add test ok
-(recording state in git...)
-xxx@xxx:~/Documents/annex-test$ git annex sync
-commit
-[master (root-commit) 4f63e05] git-annex in test
- 1 file changed, 1 insertion(+)
- create mode 120000 test
-ok
-
-# This fails
-xxx@xxx:~/Documents/annex-test$ git annex initremote test type=gcrypt encryption=shared gitrepo=../annex-target
-initremote test (encryption setup) (encryption key stored in git repository)
-git-annex: cannot use gcrypt remote without encryption enabled
-failed
-git-annex: initremote: 1 failed
-xxx@xxx:~/Documents/annex-test$ git annex initremote test type=gcrypt encryption=hybrid gitrepo=../annex-target keyid=30C027C6B72964DD
-
-git-annex: There is already a remote named "test"
-failed
-git-annex: initremote: 1 failed
-xxx@xxx:~/Documents/annex-test$ git remote remove test
-
-# But this works
-xxx@xxx:~/Documents/annex-test$ git annex initremote test type=gcrypt encryption=hybrid gitrepo=../annex-target keyid=30C027C6B72964DD
-initremote test (encryption setup) (to gpg keys: 30C027C6B72964DD) gcrypt: Repository not found: ../annex-target
-gcrypt: Repository not found: ../annex-target
-gcrypt: Setting up new repository
-gcrypt: Remote ID is :id:aHvfIDaNhjyLzBgYnmII
-Enumerating objects: 10, done.
-Counting objects: 100% (10/10), done.
-Compressing objects: 100% (7/7), done.
-Total 10 (delta 1), reused 0 (delta 0)
-gcrypt: Encrypting to: -r 30C027C6B72964DD
-gcrypt: Requesting manifest signature
-To gcrypt::../annex-target
- * [new branch] git-annex -> git-annex
-ok
-(recording state in git...)
-xxx@xxx:~/Documents/annex-test$
-
-
-# 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 git-annex is awesome. It already helps me managing the limited diskspace on my laptop and its possibilities seem endless.
-
-> This was fixed over a year ago in
-> [[!commit 8401b09e32b9378fa4c02515255a743d8f0ad4b1]] [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="lukasstraub2@bbbb2ef261a0994edda5f5f55999dfac5998d4e5"
- nickname="lukasstraub2"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="Workaround"
- date="2018-12-04T19:37:37Z"
- content="""
-As a workaround, I can include a \"gnupg\" Directory in the Repo and point the GNUPGHOME environment Variable at it. Then I simply create a single Key there and add the gcrypt Repo with encryption=hybrid. Altough I have to add the following to the gpg.conf (in the gnupg Directory inside the Repo) to prevent gpg from writing to the directory afterwards:
-pinentry-mode loopback
-no-auto-check-trustdb
-no-random-seed-file
-no-permission-warning
-quiet
-
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Utility/libkqueue.h is missing from git-annex-8.20210127.tar.gz as hosted on hackage.
-
-```
-SHA256 (/usr/ports/distfiles/hackage/git-annex-8.20210127.tar.gz) = 636f439420f28a92a8250b9f8b422567e439315f3f2d23cb0bea3b0a0e5755c3
-% tar ztf /usr/ports/distfiles/hackage/git-annex-8.20210127.tar.gz | grep libkqu
-git-annex-8.20210127/Utility/libkqueue.c
-```
-
-### What steps will reproduce the problem?
-
-Building on `(! os(solaris) && ! os(gnu) && ! os(linux))` causes a complaint about this file missing.
-
-### What version of git-annex are you using? On what operating system?
-
-git-annex-8.20210127 on OpenBSD 6.8-current amd64
-
-### Please provide any additional information below.
-
-[[!format sh """
-$ doas pkg_add libmagic
-$ cabal get git-annex-8.20210127
-$ cabal v2-build --extra-include-dirs=/usr/local/include --extra-lib-dirs=/usr/local/lib
-...
- checking UPGRADE_LOCATION... not available
- checking git... yes
- checking git version... 2.30.0
- 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... gpg
- checking lsof... not available
- checking git-remote-gcrypt... not available
- checking ssh connection caching... yes
-fatal: not a git repository (or any parent up to mount point /)
-Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
-Configuring git-annex-8.20210127...
-setup: Missing dependency on a foreign library:
-* Missing (or bad) header file: Utility/libkqueue.h
-...
-"""]]
-
-### Have you had any luck using git-annex before?
-
-Nope, but hopefully packaging up the file will make it a little easier for me to try the next time :)
-
-
-> [[fixed|done]] in git for next release --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-```
-> git annex get Narnia/
-get Narnia/Course of a Generation/01 Sail Around the World.mp3 (from Seagate...)
-SHA256E-s8395599--2fea961006a279f0765c45755b35a06f0a4fc6bfbab6118182ebc693d7b47a91.mp3
- 8,395,599 100% 29.65MB/s 0:00:00 (xfr#1, to-chk=0/1)
-(checksum...) ^C⏎
-```
-
-```
-> mpv ~/Music/sorted/Narnia/Course\ of\ a\ Generation/
-Playing: /home/philip/Music/sorted/Narnia/Course of a Generation/
-[file] This is a directory - adding to playlist.
-
-Playing: /home/philip/Music/sorted/Narnia/Course of a Generation/01 Sail Around the World.mp3
-Failed to recognize file format.
-
-Playing: /home/philip/Music/sorted/Narnia/Course of a Generation/02 When the Stars Are Falling.mp3
-```
-
-```
-> git annex version
-git-annex version: 6.20161012
-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: 6
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-operating system: linux x86_64
-```
-
-Any consecutive `git annex get` commands don’t notice that the file is not completely transferred and leave it in a broken state.
-`git annex get --failed` does not correct the problem.
-
-
-### 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 (kind of) works for keeping my music library in sync.
-
-> [[closing|done]] as it's not clear there's really a bug here. Please
-> followup to my comment with more information if you disagree.
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-11-16T18:36:34Z"
- content="""
-Thing is, git-annex get does not update the file in place. Only once the
-entire file is downloaded, and its content is verified correct is it moved
-into a place where you can access it.
-
-So, it seems much more likely to me that the content of the file, as
-originally added to git-annex, was bad, and the it had just finished
-verifying the content and moving it into place when you interruped the
-command.
-
-Please check with `git annex fsck` on the file and see if it determines
-it has the content git-annex expects it to have.
-
-However, I notice you're using a v6 repository. Is the file an unlocked
-file? It's possible that in that specific case there could be a bug.
-I've interrupted `git annex get` on a nearly daily basis for years, but
-v6 is still experimental and not as well tested.
-"""]]
+++ /dev/null
-### Please describe the problem.
-After successfully adding tags to files, I'm unable to view them. I paste the input and output to reproduce the problem below.
-
-### What steps will reproduce the problem?
-
- $ git annex init
- init
- Detected a filesystem without fifo support.
-
- Disabling ssh connection caching.
-
- Detected a crippled filesystem.
- (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...)
-
- $ touch test-file.txt
-
- $ git annex add .
- add test-file.txt
- ok
- (recording state in git...)
-
- $ git commit -a -m "Adds a file."
- warning: LF will be replaced by CRLF in test-file.txt.
- The file will have its original line endings in your working directory
- [adjusted/master(unlocked) b19bcbb] Adds a file.
- 1 file changed, 1 insertion(+)
- create mode 100644 test-file.txt
-
- $ git annex metadata test-file.txt -t a -t b -t c
- metadata test-file.txt
- lastchanged=2021-03-17@18-31-54
- tag=a
- tag=b
- tag=c
- tag-lastchanged=2021-03-17@18-31-54
- ok
- (recording state in git...)
-
- $ git annex view tag=*
- view (searching...) fatal: Unable to create 'D:\test-dir\.git\annex\viewindex.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: failed to read sha from git write-tree
- CallStack (from HasCallStack):
- error, called at .\Git\Sha.hs:23:15 in main:Git.Sha
- failed
- git-annex: view: 1 failed
-
-### What version of git-annex are you using? On what operating system?
-
- $ git annex version
- git-annex version: 8.20200815-g335aae266
- 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.4 feed-1.2.0.1 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.1
- 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 BLAKE2B256EBLAKE2B512E 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 X*
- remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
- operating system: mingw32 x86_64
- supported repository versions: 8
- upgrade supported from repository versions: 2 3 4 5 6 7
- local repository version: 8
-
-And I'm using the Git Bash terminal on Windows 10 Pro.
-
-### 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'm pretty hyped about git annex. I finally sat down and started backing up my data on different drives and git annex is about the perfect solution. Or at least it does everything I want it to (especially if the above tagging issue can be resolved). I've even thought about writing little cli apps over it, like an ejournal or recipe organizer.
-
-
-> [[fixed|done]] already some time ago --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-03-20T17:33:31Z"
- content="""
-Hi, <br>
-This is already fixed in version 8.20201103. However, the windows build seems to be outdated. You can try the latest [autobuild](http://datasets.datalad.org/datalad/packages/windows/) instead.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-03-22T14:18:03Z"
- content="""
-The published windows build uses that autobuild and is up-to-date.
-The bug reporter just needs to upgrade.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 3"
- date="2021-03-22T17:19:37Z"
- content="""
-Hmm, on the [[windows install page|https://git-annex.branchable.com/install/Windows/]], the 2nd link \"Then, install git-annex: Windows 7+ download\" leads to [this](https://downloads.kitenet.net/git-annex/windows/7/current/), which says \"Last modified: 2020-09-08\".
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-03-22T17:51:08Z"
- content="""
-Oh I see, forgot that page still linked to the windows 7 build. We lost
-that autobuilder and with windows 7 fairly EOL only the windows 10 build is
-being updated. I've changed the link now.
-"""]]
+++ /dev/null
-### Please describe the problem.
-When `git-annex add`ing files with multiple dots in them, the `SHA256E`, `MD5E` (and presumably other `*E`) backends take the extension from the second-to-last dot, instead of the last dot.
-This annoyed me because I have some photographs with names like `YYYY-mm-dd HH.MM.SS.jpg`. However, it might be intentional considering a `file.tar.gz` would have `tar.gz`.
-
-### What steps will reproduce the problem?
-[[!format sh """
-$ touch a a.b a.b.c a.b.c.d
-$ git-annex add .
-add a ok
-add a.b ok
-add a.b.c ok
-add a.b.c.d ok
-$ git-annex lookupkey *
-SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
-SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.b
-SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.b.c
-SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.c.d
-"""]]
-
-### What version of git-annex are you using? On what operating system?
-[[!format sh """
-$ git-annex version
-git-annex version: 6.20170101+gitg93d69b1-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: 5
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-operating system: linux x86_64
-"""]]
-
-NeuroDebian's `git-annex-standalone` package on Xubuntu 16.04. (Also with a Debian sid chroot with their own `git-annex 6.20161210-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)
-
-I'm trying to analyze and organize my huge `Photos` folder into a neat git-annex repository (with yet another [project of mine](https://www.github.com/alpernebbi/albumin)). It's a huge mess.
-
-Keep up the great work! Also thanks for fixing [my UTF-8 problem](https://git-annex.branchable.com/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/) as well.
-
-> [[Closing|done]] per my comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-02-20T15:53:29Z"
- content="""
-It is indeed to support things like `.tar.gz`, `.pdf.gz` etc.
-
-There's really no way to distinguish between what's desired to be part of
-the extension and not, other than heuristics. The heuristics for this are
-fairly narrow. Other than not allowing purely numeric parts in extenssions,
-or only taking the last extension, I don't see any change that could help
-with this case.
-
-Bear in mind that the only reason the extension is included at all is
-because some strange programs, especially on OSX, follow symlinks and look
-at the symlink of the link destination to try to guess what kind of file it
-is. There's no good reason for a program to do that, and if you're not
-using programs with that problem, you can just use the SHA256 backend and
-leave off the extensions.
-
-Bearing in mind that the extension is part of a big long ugly key name that
-you don't generally need to do anything with, including an extra short
-possibly not-really-extension part doesn't seem like a usability problem.
-The only real problem would be if you had two files with the same content,
-but different "extensions", since this would prevent them being
-deduplicated to the same key.
-"""]]
+++ /dev/null
-### Please describe the problem.
-Unlocking a large file on the Synology NAS results in "Cannot handle files this big" errors with every following other git command (git status, git diff, ... and hereby git annex status/sync etc.).
-
-Unfortunately I miss the technical understanding how the pointer files are hidden from git - I've seen the smudge/clean filters though.
-
-How does it work?
-After a file is unlocked, it is physically part of the working tree and also part of the git history, so a git status/diff will naturally try to index/check that file without running the annex filter, which then results in this error message, right?
-So how should these unlocked pointer files be hidden technically to not be indexed and checked by git?
-
-
-### What steps will reproduce the problem?
- $ git init
- Initialized empty Git repository in /volume1/homes/admin/git-annex/test3/.git/
- $ git annex init --version 8
- init (scanning for unlocked files...)
- ok
- (recording state in git...)
- $ ls -lah
- total 12K
- drwxr-xr-x 3 admin users 4.0K May 16 17:00 .
- drwxr-xr-x 8 admin users 4.0K May 16 17:00 ..
- drwxr-xr-x 9 admin users 4.0K May 16 17:01 .git
- -rw-r--r-- 1 admin users 20G May 16 17:00 output
- $ git annex add output
- add output
- $ git annex sync
- $ git annex unlock output
- $ git annex status
- fatal: Cannot handle files this big
- git-annex: git status failed
- $ git status
- fatal: Cannot handle files this big
- $ git diff
- fatal: Cannot handle files this big
-
-Why does git even feel responsible to load this file?
-
-
-### What version of git-annex are you using? On what operating system?
-
-Synology NAS
-
- git-annex version: 8.20200331-g111b747be
- 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.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 git-lfs hook external
- operating system: linux arm
- supported repository versions: 8
- upgrade supported from repository versions: 0 1 2 3 4 5 6 7
- local repository version: 8
-
- git version 2.26.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
-
-
-# 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)
-
-Unlocking files (with thin set to true) seems to be the perfect solution for me - I just have to understand what's going on under the hood ;)
-
-> [[closing|done]] because this appears to be a git problem if anything,
-> there does not seem to be anything in git-annex that could be changed
-> to avoid it --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2020-05-19T17:03:09Z"
- content="""
-git is configured to filter the file through git-annex, so git does not
-need to deal with the large content of the file.
-
-But this error message seems to come from part of git that just stats the
-file, and looks at its size. So there's nothing git-annex is configuring
-wrong, and using git-lfs would likewise make git fail the same.
-
-I don't think this is a bug in git-annex. It should be reported to the git
-developers. The error comes from `xsize_t`, and according to git's commit
-dc49cd769b5fa6b7e0114b051c34a849828a7603 it was intended to detect cases
-where git can't possibly malloc enough memory for a file, because `size_t`
-is not wide enough, compared with `off_t`.
-
-On linux amd64, both are 8. On linux i386 and arm, both are 4. So I don't
-think any usual linux systems are affected by this, only unusual systems
-that use different sizes for them.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="braun.markus89@51b521a42cc994db864df308627bd6454f9c309d"
- nickname="braun.markus89"
- avatar="http://cdn.libravatar.org/avatar/c11d06a0d9db6a9472b05ee01c342ca4"
- subject="comment 2"
- date="2020-05-20T13:54:23Z"
- content="""
-Thanks for your answer.
-
-Short follow up question.
-When I do exactly the same for a 2G file, something similar happens:
-
- $ git annex sync --debug
- [2020-05-20 15:48:19.441795963] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
- [2020-05-20 15:48:19.459542967] process done ExitSuccess
- [2020-05-20 15:48:19.460055539] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
- [2020-05-20 15:48:19.47249456] process done ExitSuccess
- [2020-05-20 15:48:19.473466546] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..9655aad25802451eb83141096fb9275aa36fe810\",\"--pretty=%H\",\"-n1\"]
- [2020-05-20 15:48:19.487917815] process done ExitSuccess
- [2020-05-20 15:48:19.489243941] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
- [2020-05-20 15:48:19.490737137] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
- commit
- [2020-05-20 15:48:19.506415618] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit\",\"-a\",\"-m\",\"git-annex in admin@Paintower:~/git-annex/test\"]
- fatal: mmap failed: Cannot allocate memory
-
-So why does the \"git commit\" allocate so much memory? It seems like it tries to handle the file content itself? Or is it a malloc failure caused by git annex smudge?
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2020-05-21T16:54:48Z"
- content="""
-I don't think there's any reason why git should need to allocate memory for
-the whole file. All it's doing is reading the file and sending it over a
-pipe, and git-annex actually hangs up the pipe before reading anything.
-So git could read a few bytes, try to send them, and give up.
-
-The last time I looked at it, in [[!commit a96972015dd76271b46432151e15d5d38d7151ff]]
-having git-annex close the pipe immediately did avoid git overallocating
-memory. I don't know what else git-annex could do to avoid any bad behavior
-from git.
-
-If your git is older than 2.5, it would certainly explain it, since the
-above workaround needed git 2.5.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="braun.markus89@51b521a42cc994db864df308627bd6454f9c309d"
- nickname="braun.markus89"
- avatar="http://cdn.libravatar.org/avatar/c11d06a0d9db6a9472b05ee01c342ca4"
- subject="comment 4"
- date="2020-05-25T11:06:05Z"
- content="""
-git version is 2.26.1, so this should be fine.
-
-I guess, git-annex couldn't do it any better, still git tries to overallocate memory.
-My Synology NAS only got 1gb of memory (at least 600mb are used all the time), so I wonder why \"hanging up\" the pipe works when unlocking 1gb file but not for 2gb. But the Synology linux is a little bit weird, so I have to give up on debugging there. The 1gb memory spec of my NAS is ridiculously low (maybe too low for git anyways) and cannot be upgraded....
-
-For the sake of documentation for other synology users with a low-spec NAS
-
-Workaround that did work
-
-* create a user with uid/gid matching the NAS user and mount via NFSv3. On the client system the memory is sufficient to run every git-annex command.
-
-Workarounds that did not work out
-
-* NFSv4 with idmapping (configuring the Kerberos authentication would have taken a lot of time and not even sure if it would have worked out in the end)
-* SSHFS (the sshfs server provided by Synology seems to be broken, resulting in broken symlinks on my linux client system -> which is obviously a no go for git annex ;-) )
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="braun.markus89@51b521a42cc994db864df308627bd6454f9c309d"
- nickname="braun.markus89"
- avatar="http://cdn.libravatar.org/avatar/c11d06a0d9db6a9472b05ee01c342ca4"
- subject="comment 5"
- date="2020-05-25T11:07:07Z"
- content="""
-so, thank you once again, Joey, in particular for this great tool ;-)
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-someone kinda could consider it a 'feature' but it complicates use of the output since then progressbar should jump down and some progressbar libraries
-do not "support" that
-
-### What steps will reproduce the problem?
-
-initiate download, interrupt it, try to redownload it... I guess in some cases redownload doesn't start at the point where it was previously interrupted but somewhat before, or restarts altogether. But annex first reports in --json-progress the size of previously downloaded portion and then goes down. see below
-
-so, my life would be easier, if annex did not report "unconfirmed initial progress" at all I guess
-
-### What version of git-annex are you using? On what operating system?
-
-6.20170307+gitg24ade8a25-1~ndall+1
-
-### Please provide any additional information below.
-
-[[!format sh """
-$> ls -l .git/annex/tmp; k=$(/bin/ls .git/annex/tmp | head -n 1); [ -z "$k" ] || git annex get --json --json-progress --key $k
-total 3796
--rw------- 1 yoh yoh 3887104 Mar 24 17:06 MD5E-s4108657--e055fc250b37b313c0904f3687bbed1c
-{"byte-progress":3887104,"action":{"command":"get","note":"from origin...","key":"MD5E-s4108657--e055fc250b37b313c0904f3687bbed1c","file":null},"total-size":4108657,"percent-progress":"94.61%"}
-{"byte-progress":2068480,"action":{"command":"get","note":"from origin...","key":"MD5E-s4108657--e055fc250b37b313c0904f3687bbed1c","file":null},"total-size":4108657,"percent-progress":"50.34%"}
-{"command":"get","note":"checksum...","success":true,"key":"MD5E-s4108657--e055fc250b37b313c0904f3687bbed1c","file":null}
-
-"""]]
-
-
-> [[Closing|done]] since it seems I fixed the most egrarious case where
-> this could happen, and since it does seem that, in general, it's ok for
-> git-annex to report progress that is not strictly increasing. --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-05-25T17:56:48Z"
- content="""
-That looks like a git remote accessed perhaps by rsync, or perhaps locally?
-
-I'd be surprised if a rsync transfer did this, because AFAIK all progress
-updates come from rsync's own progress display, and that does not jump
-backward.
-
-Local file copies (when not using rsync), and some other types of remotes,
-poll the size of the temp file to determine how much data has been
-received, and so if the transfer doesn't resume, they will do this. **I've
-made it avoid reporting the file size until the file size has changed once,
-which avoids the problem in this case.**
-
-Another way it could happen is when a transfer fails partway and git-annex
-immediately retries and the retry fails to resume. In
-this case, the progress would go to some percent for the first transfer,
-and then could reset to a lower percent for the retry, and that
-reflects what's really happening. Eg, 50% of it transferred and now
-we've unfortunately started over at 0%.
-
-I could make the reported progress always be monotonically increasing, but
-then in that retry cases it would just seem to stall, perhaps for a long
-period of time. Not sure that's better than a progress display that while
-annoying, reflects what's really going on.
-"""]]
+++ /dev/null
-Without this patch, building on OpenBSD fails with a type error in `Utility/DirWatcher/Kqueue.hs`.
-
-I'm running OpenBSD current. This patch is against master (commit 7d18153955).
-
-```
-diff --git a/Utility/DirWatcher/Kqueue.hs b/Utility/DirWatcher/Kqueue.hs
-index 4a1c55ae9..0c84f67c1 100644
---- a/Utility/DirWatcher/Kqueue.hs
-+++ b/Utility/DirWatcher/Kqueue.hs
-@@ -133,7 +133,7 @@ removeSubDir dirmap dir = do
- mapM_ Posix.closeFd $ M.keys toremove
- return rest
- where
-- (toremove, rest) = M.partition (dirContains dir . dirName) dirmap
-+ (toremove, rest) = M.partition (dirContains (toRawFilePath dir) . toRawFilePath . dirName) dirmap
-
- findDirContents :: DirMap -> FilePath -> [FilePath]
- findDirContents dirmap dir = concatMap absolutecontents $ search
-```
-
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="falsifian"
- avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
- subject="tests mostly pass"
- date="2021-01-31T05:07:16Z"
- content="""
-FYI, `git annex test` has just a few failures, which can all be blamed on my setup.
-
-(git-annex is not in PATH seen by commands run via ssh, so I get a bunch of failures like \"/bin/sh: git-annex-shell: not found\". In practice I work around this by setting remote.xxx.annex-shell=/home/falsifian/bin/git-annex-shell in other repos.)
-
-PS if you want to credit me in a commit message, I'm `James Cook <falsifian@falsifian.org>`.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-02-01T15:54:22Z"
- content="""
-Thank you, I've applied that.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-git-annex has issues when trying to deal with SSH (and possibly other kinds) of URLs which have the form:
-
-```
-ssh://user@host/~
-```
-
-When git-annex tries to perform tilde-expansion the path part of the URL on the remote side,
-it runs into problems because the function responsible for doing this (`expandTilde` in `Git/Construct.hs`)
-does not correctly handle the expansion of home directory paths which do not end in a slash,
-such as `~` or `/~`. It will correctly handle strings like `/~/` or `~/`, which is why SSH
-URLs of the form `ssh://user@host/~/` *will* work.
-
-Examining the definition of `expandTilde` makes it clear why this is true:
-
-```haskell
-expandTilde :: FilePath -> IO FilePath
-#ifdef mingw32_HOST_OS
-expandTilde = return
-#else
-expandTilde = expandt True
- where
- expandt _ [] = return ""
- expandt _ ('/':cs) = do
- v <- expandt True cs
- return ('/':v)
- expandt True ('~':'/':cs) = do
- h <- myHomeDir
- return $ h </> cs
- expandt True ('~':cs) = do
- let (name, rest) = findname "" cs
- u <- getUserEntryForName name
- return $ homeDirectory u </> rest
- expandt _ (c:cs) = do
- v <- expandt False cs
- return (c:v)
- findname n [] = (n, "")
- findname n (c:cs)
- | c == '/' = (n, cs)
- | otherwise = findname (n++[c]) cs
-```
-
-The expression `expandTilde "~"` will eventually match the fourth pattern for `expandt`.
-Since `cs == ""` in this context, `name` will also evaluate to `""`.
-This means that `getUserEntryForName` will be called with the null string as an argument.
-Since there is no user on the system with the null string as a username,
-`getUserEntryForName` will throw an exception.
-This will cause git-annex to spit out an error message:
-
-```
-get testfile (from origin...)
-git-annex-shell: getUserEntryForName: does not exist (no such user)
-rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
-rsync error: error in rsync protocol data stream (code 12) at io.c(235) [Receiver=3.1.3]
-
- rsync failed -- run git annex again to resume file transfer
-
- Unable to access these remotes: origin
-
- Try making some of these repositories available:
- 1f5118ff-a50e-4bf1-a372-960774bce0ab -- user@A:~/ [origin]
-failed
-git-annex: get: 1 failed
-```
-
-Fixing the problem is simple enough.
-All that needs to be done is to add an equation for `expandt` to handle the case where `~` appears at the end of a string.
-See the following patch:
-
-```
-From 680873923197f5eec15365b3e47e3fa05b9573be Mon Sep 17 00:00:00 2001
-From: Grond <grond66@riseup.net>
-Date: Thu, 14 Jan 2021 18:16:31 -0800
-Subject: [PATCH] Fix expandTilde so that it can handle tildes at the end of
- it's input
-
----
- Git/Construct.hs | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/Git/Construct.hs b/Git/Construct.hs
-index 8b63ac480..a369bc4a6 100644
---- a/Git/Construct.hs
-+++ b/Git/Construct.hs
-@@ -187,6 +187,7 @@ expandTilde = expandt True
- expandt True ('~':'/':cs) = do
- h <- myHomeDir
- return $ h </> cs
-+ expandt True "~" = myHomeDir
- expandt True ('~':cs) = do
- let (name, rest) = findname "" cs
- u <- getUserEntryForName name
---
-2.20.1
-
-```
-
-### What steps will reproduce the problem?
-
-1. Create `testfile` in a git-annex repo of your home directory on host `A`
-2. Run `git annex add testfile` in the repo on `A`
-3. Run `git commit`
-4. Clone your home directory on `A` onto host `B` using `git clone ssh://me@A/~ homedir_A`
-5. `cd` into `homedir_A`
-6. Run `git annex get testfile`
-7. Watch git-annex fail to fetch the file
-8. Run `git remote set-url origin ssh://me@A/~/` to set the remote URL to be something git-annex can deal with
-9. Run `git annex get testfile` again
-10. Watch git-annex suddenly succeed
-
-### What version of git-annex are you using? On what operating system?
-
-I'm running Debian 10.7.
-
-The output of `git annex version` is:
-
-```
-git-annex version: 7.20190129
-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
-```
-
-### 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)
-
-Definitely! I'm currently writing some personal file synchronization software that uses git-annex for myself, which is how I noticed this bug.
-
-> Thanks for a perfect bug report and patch. [[done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-`cabal v2-install` produces many lines like this in the build log:
-
- /bin/sh: ./Build/mdwn2man: cannot execute - Permission denied
-
-and the man pages don't get copied to `~/.cabal/store/...`.
-
-My guess is that Cabal is losing the file mode during some tarring/untarring.
-
-Here's a patch that fixes it. (It makes the `#/usr/bin/env perl` at the start of the file redundant; not sure if you want to delete it.)
-
-```
-diff --git a/Build/Mans.hs b/Build/Mans.hs
-index 9fb29d4a3..672dcd71c 100644
---- a/Build/Mans.hs
-+++ b/Build/Mans.hs
-@@ -38,7 +38,8 @@ buildMans = do
- if (Just srcm > destm)
- then do
- r <- system $ unwords
-- [ "./Build/mdwn2man"
-+ [ "perl"
-+ , "Build/mdwn2man"
- , progName src
- , "1"
- , src
-```
-
-(Related question: is the installation supposed to put the man pages anywhere other than `~/.cabal/store/ghc-XXX/git-annex-XXX`? I.e. is it up to the user to either add that directory to `MANPATH` or copy them somewhere from there?)
-
-### What version of git-annex are you using? On what operating system?
-
-OpenBSD current
-
-Cabal 3.4.0.0
-
-git-annex master (commit `4e5a27841`)
-
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-02-08T18:20:31Z"
- content="""
-Reproduced by running `cabal unpack git-annex`. While the tarball on
-hackage does have execute bits, somehow cabal is not preserving them.
-Applied your patch, thanks.
-
-Cabal's ability to install anything more than a command into PATH is very
-limited, and also there's not really a good way to install man pages
-in a user's home directory in a way that will make man find them (ie,
-there's probably one way or less per OS, and all different).
-So it's best to use the Makefile (from a git clone of the repo)
-if you want to install git-annex in a more complete manner,
-ie system wide or generating a package of its files.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="falsifian"
- avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
- subject="comment 2"
- date="2021-02-12T03:52:37Z"
- content="""
-Thanks for the tip. (FYI: I'm working on packaging it for OpenBSD. Currently we just have a hack in place that manually runs the mdwn2man script after the cabal build. The Cabal packaging module it's built on probably isn't designed to call a Makefile but there may be some way to do it. In any case, it seems to work, so we might just leave it as is.)
-"""]]
+++ /dev/null
-This is a satellite issue the one on [strange mimetype driven addition](http://git-annex.branchable.com/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/?updated)
-
-We do get report on addition of the file twice (when it switches from annex to git?)
-
-[[!format sh """
-(git)smaug:/mnt/btrfs/scrap/tmp/SIMON[master]data_BIDS
-$> rm -f TEST.txt; cat BADFILE.txt >| TEST.txt; file --mime TEST.txt; git annex add TEST.txt
-TEST.txt: text/plain; charset=utf-8
-add TEST.txt ok
-(recording state in git...)
-
-$> rm -f TEST.txt; sed -e 's,[{}],,g' BADFILE.txt >| TEST.txt; file --mime TEST.txt; git annex add TEST.txt
-TEST.txt: text/plain; charset=utf-8
-add TEST.txt (non-large file; adding content to git repository) ok
-add TEST.txt (non-large file; adding content to git repository) ok
-(recording state in git...)
-
-"""]]
-
-and here is that run with `--debug`:
-
-[[!format sh """
-$> rm -f TEST.txt; sed -e 's,[{}],,g' BADFILE.txt >| TEST.txt; file --mime TEST.txt; git annex add --debug TEST.txt
-TEST.txt: text/plain; charset=utf-8
-[2019-04-26 09:57:45.451632679] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","symbolic-ref","-q","HEAD"]
-[2019-04-26 09:57:45.455061047] process done ExitSuccess
-[2019-04-26 09:57:45.455134123] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","show-ref","refs/heads/master"]
-[2019-04-26 09:57:45.466478693] process done ExitSuccess
-[2019-04-26 09:57:45.466612578] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","TEST.txt"]
-[2019-04-26 09:57:45.471421295] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","ls-files","--modified","-z","--","TEST.txt"]
-[2019-04-26 09:57:45.479659995] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
-[2019-04-26 09:57:45.479997471] read: git ["--version"]
-[2019-04-26 09:57:45.482476867] process done ExitSuccess
-add TEST.txt (non-large file; adding content to git repository) ok
-[2019-04-26 09:57:45.494729569] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--","TEST.txt"]
-[2019-04-26 09:57:45.498615035] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch"]
-[2019-04-26 09:57:45.499023359] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
-add TEST.txt (non-large file; adding content to git repository) ok
-(recording state in git...)
-[2019-04-26 09:57:45.509449016] feed: xargs ["-0","git","--git-dir=../.git","--work-tree=..","--literal-pathspecs","add","--"]
-[2019-04-26 09:57:45.54937333] process done ExitSuccess
-[2019-04-26 09:57:45.550142214] process done ExitSuccess
-[2019-04-26 09:57:45.550690643] process done ExitSuccess
-[2019-04-26 09:57:45.551282227] process done ExitSuccess
-
-
-"""]]
-
-annex 7.20190219+git191-g2d6a364d4-1~ndall+1
-
-> [[fixed|done]] this affected v5 repos but was fixed in v6 and above.
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-05-06T16:30:41Z"
- content="""
-This is because git-annex add makes multiple passes looking for files in
-different situations. In particular, the withFilesMaybeModified and
-withFilesOldUnlocked passes both find the file.
-
-I don't immediately see a way to improve it. But it is avoided in v6 mode.
-
-(I'm fairly sure someone, possibly even you, has reported this same issue
-before, so it's probably still open somewhere.)
-"""]]
+++ /dev/null
-In some occasions `annex.adjustedbranchrefresh` is ignored when `git annex sync` is run in a branch created with `adjust --unlock-present`.
-
-If `annex.adjustedbranchrefresh` is set to 1, one would expect git-annex to automatically adjust the branch once a file has been `git annex add`-ed or the repository is `git annex sync`-ed. However this does not happen and a manual `git annex adjust --unlock-present` is required.
-
-Is this a bug or am I misunderstanding how `annex.adjustedbranchrefresh` is supposed to work?
-
-> It is a bug --[[Joey]]
-
-The following script reproduces this bug.
-
-```
-#!/bin/bash
-
-set -eux
-
-rm -Rvf /tmp/an-repo.git && mkdir /tmp/an-repo.git && cd /tmp/an-repo.git
-git init --bare
-n=$(date +%s) ; mkdir /tmp/ga-$n && cd /tmp/ga-$n
-git clone --no-local --no-hardlinks /tmp/an-repo.git
-cd an-repo/
-
-git config user.email "email@example.com" ; git config user.name "Name Name"
-git config annex.thin true
-git config annex.adjustedbranchrefresh 1
-git config remote.origin.annex-ignore true
-
-# 8.20201117 is the version in the standalone tarball of 8.20201127
-~/Applications/git-annex/8.20201117-ga314537cd/runshell bash -c '
-git annex init foobar
-
-echo "aaaa" > a && echo "bbbb" > b
-git annex add a b
-git annex sync
-
-git annex adjust --unlock-present
-git annex sync
-
-echo "cccc" > c && echo "dddd" > d
-git annex add c d
-
-echo "## before sync"
-stat -c "%n: %F" a b c d
-
-git annex sync
-echo "## after sync"
-stat -c "%n: %F" a b c d # should show four regular files, but shows two files and two symlinks
-
-git annex sync --content;
-echo "## after sync --content"
-stat -c "%n: %F" a b c d # ibid
-'
-```
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-01-04T20:57:22Z"
- content="""
-So I think the whole problem is that, git-annex add (and import, addurl,
-etc) should add the files unlocked when in an unlockpresent branch.
-
-I don't think git-annex sync needs to deal with this, problably.
-
-Don't think this really has anything to do with adjustedbranchrefresh.
-That's about updates after getting/dropping files, and that's not been done
-in this case.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-01-25T17:46:03Z"
- content="""
-Oh, git-annex add already adds it unlocked in an adjusted unlocked branch,
-so that just needs to be done for this new type of branch too.
-"""]]
+++ /dev/null
-### Please describe the problem.
-git-annex doesn't seem to honor the remote.\<name\>.annex-rsync-upload-options or annex.rsync-upload-options anymore. The problem seems to be on the server side. I noticed it when upgrading the ancient git-annex on my server from the version in stretch (6.20170101, --bwlimit worked fine with that) to the version in stretch-backports (7.20190129, --bwlimit broken). On the client I'm running bullseye and git-annex version 8.20210223. I then upgraded git-annex on the server to 8.20210903, the rsync-options don't work with that either.
-
-### What steps will reproduce the problem?
-
-#### Client:
-
- root@dition:/mnt/sneakerdisk9# mkdir testannex
- root@dition:/mnt/sneakerdisk9# cd testannex
- root@dition:/mnt/sneakerdisk9/testannex# git init
- hint: Using 'master' as the name for the initial branch. This default branch name
- hint: is subject to change. To configure the initial branch name to use in all
- hint: of your new repositories, which will suppress this warning, call:
- hint:
- hint: git config --global init.defaultBranch <name>
- hint:
- hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
- hint: 'development'. The just-created branch can be renamed via this command:
- hint:
- hint: git branch -m <name>
- Initialized empty Git repository in /mnt/sneakerdisk9/testannex/.git/
- root@dition:/mnt/sneakerdisk9/testannex# git annex init dition
- init dition (scanning for unlocked files...)
- ok
- (recording state in git...)
- root@dition:/mnt/sneakerdisk9/testannex# dd if=/dev/random of=bigtestfile bs=1MiB count=500
- 500+0 records in
- 500+0 records out
- 524288000 bytes (524 MB, 500 MiB) copied, 6.00526 s, 87.3 MB/s
- root@dition:/mnt/sneakerdisk9/testannex# git annex add bigtestfile
- add bigtestfile
- ok
- (recording state in git...)
-
-#### Server:
-
- dition@holm:/mnt/btrfs/testannex.git$ git init --bare
- Initialized empty Git repository in /mnt/btrfs/testannex.git/
-
-#### Client:
- root@dition:/mnt/sneakerdisk9/testannex# git remote add holm ssh://dition@holm:1322/mnt/btrfs/testannex.git
- root@dition:/mnt/sneakerdisk9/testannex# git push --all holm
- Enumerating objects: 10, done.
- Counting objects: 100% (10/10), done.
- Delta compression using up to 4 threads
- Compressing objects: 100% (7/7), done.
- Writing objects: 100% (10/10), 871 bytes | 217.00 KiB/s, done.
- Total 10 (delta 0), reused 0 (delta 0), pack-reused 0
- To ssh://holm:1322/mnt/btrfs/testannex.git
- * [new branch] git-annex -> git-annex
-
-#### Server:
-
- dition@holm:/mnt/btrfs/testannex.git$ git annex init holm
- init holm ok
- (recording state in git...)
-
-#### Client:
- root@dition:/mnt/sneakerdisk9/testannex# git config --add annex.rsync-upload-options "--bwlimit 1024"
- root@dition:/mnt/sneakerdisk9/testannex# git annex sync
- commit
- [master (root-commit) d0f28fe] git-annex in dition
- Committer: root <root@dition.tulpe>
- Your name and email address were configured automatically based
- on your username and hostname. Please check that they are accurate.
- You can suppress this message by setting them explicitly. Run the
- following command and follow the instructions in your editor to edit
- your configuration file:
-
- git config --global --edit
-
- After doing this, you may fix the identity used for this commit with:
-
- git commit --amend --reset-author
-
- 1 file changed, 1 insertion(+)
- create mode 120000 bigtestfile
- ok
- pull holm
- 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), 363 bytes | 121.00 KiB/s, done.
- From ssh://holm:1322/mnt/btrfs/testannex
- 5ace97f..70df03f git-annex -> holm/git-annex
- ok
- (merging holm/git-annex into git-annex...)
- push holm
- Enumerating objects: 3, done.
- Counting objects: 100% (3/3), done.
- Delta compression using up to 4 threads
- Compressing objects: 100% (2/2), done.
- Writing objects: 100% (3/3), 314 bytes | 314.00 KiB/s, done.
- Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
- To ssh://holm:1322/mnt/btrfs/testannex.git
- * [new branch] git-annex -> synced/git-annex
- * [new branch] master -> synced/master
- ok
- root@dition:/mnt/sneakerdisk9/testannex# git annex copy --to holm bigtestfile
- copy bigtestfile (to holm...)
- 4% 19.27 MiB 3 MiB/s 2m31s
-
-### What version of git-annex are you using? On what operating system?
-#### Server:
-Debian stretch amd64 with git-annex from the neurodebian repo
-
- dition@holm:/mnt/btrfs/testannex.git$ git annex version
- git-annex version: 8.20210903-1~ndall+1
- build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
- dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1
- persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
- key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 S
- HA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B51
- 2 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256
- BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WOR
- M URL X*
- remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg
- hook external
- operating system: linux x86_64
- supported repository versions: 8
- upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-
-#### Client:
-
-Debian bullseye arm64
-
- root@dition:/mnt/sneakerdisk9# git annex version
- git-annex version: 8.20210223
- build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
- dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
- remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
- operating system: linux aarch64
- supported repository versions: 8
- upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-
-I can also reproduce this with a debian buster client on amd64 with git-annex 8.20200330
-
-### Please provide any additional information below.
-
-As mentioned, the problem was introduced somewhere between 6.20170101 and 7.20190129.
-
-annex.rsync-download-options "--bwlimit 1024" is ignored as well:
-
- root@dition:/mnt/sneakerdisk9/testannex# git config --add annex.rsync-download-options "--bwlimit 1024"
- root@dition:/mnt/sneakerdisk9/testannex# git annex get --from holm bigtestfile
- get bigtestfile (from holm...)
- 10% 51.82 MiB 19 MiB/s 23s
-
-### 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 many years with great success. It's a pleasure to use, I don't know how I ever managed to get by without it!
-
-> Closing as a duplicate of the bwlimit todo. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-09-21T17:24:59Z"
- content="""
-Since that old version of git-annex, it has changed to using a different
-protocol than rsync for transfers over ssh. So the rsync options no longer
-apply to that. They are still used when git-annex does use rsync, either a
-rsync special remote or a server with too old a version of git-annex to use
-the new protocol.
-
-I think the main thing lost by this is bandwidth throttling.
-There is an open todo at [[todo/bwlimit]] to implement that in a way that
-will work more broadly than rsync's --bwlimit.
-
-Maybe also --ipv4/--ipv6, but ssh configs can probably be used to
-accomplish the same thing as that.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-09-22T19:30:15Z"
- content="""
-I've now implemented remote.name.annex-bwlimit, which works for most
-remotes, and can be used instead of the rsync options for git remotes
-that no longer use rsync.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="weinzwang"
- avatar="http://cdn.libravatar.org/avatar/e73d7d9e358f3b974d283fb0834cc5d9"
- subject="comment 3"
- date="2021-09-23T21:40:50Z"
- content="""
-Awesome, thank you!
-"""]]
+++ /dev/null
-The assistant's git-annex repair sometimes happens when git fsck does not
-actually detect any problems.
-
-See [[Git_repos_corrupt_themselves]] of which this was part of the cause,
-although the data loss part of that was solved.
-
-I saw this happen on my sister's laptop, in a freshly cloned repo,
-with a git-annex version that fixed that data loss.
-assistant was set up to fsck and on the very first fsck it started git
-repair. git fsck reported no problems at all. --[[Joey]]
-
-> .git/annex/fsckresults/$uuid was empty, which means that
-> writeFsckResults was called with FsckFailed. So apparently
-> the fsck exited nonzero for some reason, but did not detect
-> any misssing shas.
->
-> Reproed on my own laptop, with the family annex. This reproduces it about
-> 50% of the time: Clone over ssh; git-annex init;
-> git remote rm origin; git annex schedule here 'fsck self 30m every day at
-> any time'; git annex assistant; kill git-annex fsck process
->
-> Confirmed that it's getting FsckFailed.
->
-> Hypothesis: Maybe fsck is failing due to some other change
-> that is being made to the git repo by the assistant
-> at the same time it's running?
-> I noticed some files being downloaded from the web at the same
-> time the failed fsck was running.
->
-> Fsck output to stdout is empty, stderr is:
->
-> missing commit 4da14c19140e4c240358af4518d83661713ab044
->
-> Intriguingly, that commit is present. It is a commit on the git-annex
-> branch. And fscking again succeeds. So, fsck found a reference to a
-> commit object that had not yet been written to disk. This feels like a
-> bug in git, because if it were interrupted there the repo would be left
-> in a bad state.
->
-> Anyway, git-annex verifies that the commit is present, to double-check
-> it understood fsck correctly. And it is. So it is not considered a
-> problem. But, fsck still exits nonzero because it thinks there was a
-> problem. And that's the problem.
->
-> Fixed by making git-annex assistant ignore fsck nonzero
-> exit status when it does not find any missing objects.
-> Since any actual failure that makes fsck do that can't
-> be distinguished from a false positive. I left git-annex repair
-> unchanged, because if the user knows the repo is badly broken and explictly
-> runs it, they would be surprised if it didn't repair.
->
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-When running the assistant, it seems to want to drop all files in the worktree from my NAS which is in the transfer group. This fails because of numcopies thankfully but it strikes me as very odd and potentially dangerous for it to do this when it knows that it can't drop these files.
-
-It also unnecessarily spams the logs.
-
-### What steps will reproduce the problem?
-
-```
-git annex assistant --stop
-git annex assistant
-```
-
-### What version of git-annex are you using? On what operating system?
-
-```
-git-annex version: 8.20210428
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.4 http-client-0.6.4.1 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.1
-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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-https://github.com/Atemu/nixpkgs/tree/498831397e77a265c240cf8f8a7d15e738f2f05b
-
-
-### 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
-drop SOTERIA path/to/file (unsafe)
- Could only verify the existence of 1 out of 2 necessary copies
-
- Maybe add some of these git remotes (git remote add ...):
- d7d728f7-891a-4035-a758-c7ee80a8017a -- MB-<redacted>
-
- (Use --force to override this check, or adjust numcopies.)
-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)
-
-
-> notabug per my comment; [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-05-10T14:53:34Z"
- content="""
-Currently the assistant simply tries to drop when it thinks it's possible
-that the content may be droppable. It doesn't check if the drop is allowed
-before trying to drop. Because that would be redundant with the check
-that's done when actually dropping.
-
-I don't see anything dangerous about this, same as running `git annex drop`
-on lots of files and having them be preserved by numcopies is not
-dangerous.
-
-If it's a bug at all, it's only that it should be silent if
-it is unable to perform the drop due to numcopies. However,
-making it silent about that also seems like it would make it harder to
-figure out what is preventing things from being dropping in situations
-where you do expect drops to happen.
-
-As in, ironically, your specific case! You have a transfer remote, which is
-having files pile up on it, despite them apparently having been transferred
-from it to both of the repos you want it to transfer them to. Since your
-local repo cannot access the other repo, it cannot verify it has the
-content and so leaves a copy on the transfer remote.
-
-If you had a problem with that transfer remote filling up, and nothing was
-ever logged about why it was not dropping from it, it would be hard to
-understand what was going on and how to fix it (eg by trusting the other
-repo, or adding it as a remote, or lowering numcopies to 1).
-
-So the logging seems like a good thing to me.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Atemu"
- avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
- subject="comment 2"
- date="2021-05-18T16:23:09Z"
- content="""
-That is true indeed; thanks for pointing it out!
-
-Though I'd prefer if it printed a summary like: \"Warning: Couldn't perform drop of n files because the necessary copies' existence could not be verified. Make your remotes reachable by this repo or adjust numcopies.\"; that'd be a lot clearer.
-"""]]
+++ /dev/null
-### Please describe the problem.
-borg special remote is apparently ignoring WORM and URL key content (probably all content without hashes?)
-
-### What steps will reproduce the problem?
-archive a repo containing WORM or URL keys with borg and sync it with git annex like in the example https://git-annex.branchable.com/special_remotes/borg/
-
-doing `git annex list --not -i borg` later shows all WORM and URL keys not recognized being in borg
-
-### What version of git-annex are you using? On what operating system?
-git-annex version: 8.20210310
-on NixOS 20.09
-
-### 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)
-Thank you for including borg, and for fixing gcrypt remotes! This is great!
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="git-annex@6f13b739194f758abc0b86556b7ce966c1bf3c00"
- nickname="git-annex"
- avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6"
- subject="/ vs. % in key"
- date="2021-03-24T10:07:26Z"
- content="""
-the substitution of path elements (\"/\" in key to \"%\" in file) seems to be related:
-
-
- $ git annex whereis --key WORM-s781040400-m1574160315--cd%therootsofsepultura.cdr
- whereis WORM-s781040400-m1574160315--cd%therootsofsepultura.cdr (0 copies)
- The following untrusted locations may also have copies:
- 91fd7b0a-493b-408c-aa07-c8520210f6a6 -- [borg]
- failed
- git-annex: whereis: 1 failed
-
- $ git annex whereis --key WORM-s781040400-m1574160315--cd/therootsofsepultura.cdr
- whereis WORM-s781040400-m1574160315--cd/therootsofsepultura.cdr (1 copy)
- 3340887b-e3b3-4a88-9de4-a8b60116cc66 -- [here]
- ok
-
-The first one should be within the second one.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="git-annex@6f13b739194f758abc0b86556b7ce966c1bf3c00"
- nickname="git-annex"
- avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6"
- subject="borg hardlinks"
- date="2021-03-24T10:29:12Z"
- content="""
-Also not recognized by git-annex are hardlinks in borg, which show up in `borg list` like
-
- hr--r--r-- woffs 1000 0 Sun, 2014-08-03 23:04:27 annex-objects/jP/40/SHA256E-s698785--bbe23f87e576cd7ab3a87c0ef8d82c99044515c63a83977d1ac870d82b88f8b4.jpg/SHA256E-s698785--bbe23f87e576cd7ab3a87c0ef8d82c99044515c63a83977d1ac870d82b88f8b4.jpg link to otherdir/sdcard/dcim/Camera/2014-07-28_13-07-42_306.jpg
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-03-26T16:05:49Z"
- content="""
-I've fixed this bug. Note that, git-annex won't re-scan borg archives that
-it's already scanned, so you will need to make a new borg backup in order
-to add a new archive, and then git-annex will notice the files it missed
-before.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-03-26T16:14:56Z"
- content="""
-Fixed the hard link bug.
-"""]]
+++ /dev/null
-When I tried running `git annex sync borg` on a large (~6T) borg repo with many archives, git-annex spun until it used 52G of
-memory, then got OOM-killed.
-
-I don't know if this is a memory leak or just trying to load too much, but it seems like this is a thing you should be able to do on
-a machine with 64G of RAM.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 10"""
- date="2021-10-06T17:09:50Z"
- content="""
-There is still a big PINNED spike though. I measured this memory use:
-
- 115344 post listContents
- 133816 post importKeys
- 236676 post recordImportTree
-
-listContents produces an `ImportableContents (ContentIdentifier, ByteSize)`
-and that gets transformed through importKeys
-to `ImportableContents (Either Sha Key)`. The GC should be able to
-free up the first as it's being traversed, but PINNED still goes up during
-that, and memory increases by 20% or so.
-
-Then recordImportTree calls mktreeitem and treeItemsToTree, which between
-then double the memory.
-
-So I think I understand where the memory use is, although why it's PINNED
-is still not clear, and unpinning could still help. I did try converting
-TopFilePath to ShortByteString, since TreeItems contain them, but it didn't
-reduce the amount PINNED and actually used more memory.
-
-To avoid the allocation entirely, it seems that borg's
-listImportableContents would need to generate a Tree itself, rather than
-using ImportableContents. And it could, probably fairly efficiently, but it
-would not be able to reuse the tree import interface as it does now.
-
-(borg could return a `ImportableContents (Either Sha Key)` more easily,
-and still reuse part of the interface, but the conversion to that only
-uses 20% or so of memory so it's not a big enough win. Also when I looked
-at it, it was still not going to be an easy refactoring.)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 11"""
- date="2021-10-06T18:03:23Z"
- content="""
-@tomdhunt the tree is being stored in git, so the natural way
-to do something like a difference encoding would be a series of trees
-in a commit sequence.
-
-The tree import interface does support that, but borg remote
-doesn't bother and puts all the items in a single tree. But even if it did,
-it would still populate the same ImportableContents data structure with
-the same amount of data just a different layout.
-
-But maybe this line of thinking does point toward a solution.. Suppose that
-there was a way for listImportableContents to generate an
-ImportableContentsChunk that contained a subtree, and a continuation to get
-the next subtree. Then each subtree's worth of ImportableContents would be
-passed through to recordImportTree (a version omitting the parts of it that
-commit the tree), and only one subtree at a time would occupy memory. At
-the end a tree would be constucted containing all the subtrees, and
-committed.
-
-For borg, each archive would be a subtree; 500k filenames will fit in memory
-or at least fit better than `365*500k`.
-
-This is a promising idea! Started working on it in a `borgchunks` branch.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 12"""
- date="2021-10-08T17:06:05Z"
- content="""
-I've fixed this problem, my test case tops out at 160 mb now, and adding more
-archives to the borg repo no longer increases memory use. Memory use is now
-proportional to the number of annexed objects in a borg archive.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-10-05T15:12:33Z"
- content="""
-I'd expect the amount of memory git-annex uses to increase with the number
-of archives in the borg repo that contain a git-annex repository. So I am
-curious how many such archives there are in your borg repo.
-
-The memory use also scales with the number of annex object files in the git-annex
-repository. So I'm curious how many such files there are in one of the
-borg archives.
-
-If there are say, 1000 archives of a git-annex repository that
-contains 1000 annex objects, that's a million items. I'd estimate a couple
-hundred megabytes memory for for that. The length of the path to the
-git-annex repository and the archive name are included in each item, so more
-when those are long.
-
-If it could only include one item for each git-annex key, that would avoid
-needing so much memory. But I don't think it can, because an archive can
-be deleted, and if the one item it included was in the deleted archive,
-it would not be able to retrieve the object from other archives that still
-exists, without a rescan.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-10-05T15:55:27Z"
- content="""
-I tried making a borg repo with 100 archives of a 1000 object git-annex
-repo. The length of each item was 142 bytes, so all the items should
-need about 15 mb of memory. git-annex sync used more than 2 gb
-of memory. So that's a test case for this bug.
-
-Looks like around 500 mb is used listing the repo contents.
-
-Then after all the borg list is complete, it uses much more memory
-building the git tree.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="tomdhunt"
- avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
- subject="comment 3"
- date="2021-10-05T19:08:23Z"
- content="""
-The repo in question is my daily backup repository. It keeps an archive for each day going back a year or so, so on order of hundreds of archives. The underlying data is about 8TB, but it only changes small amounts, so the whole borg repo is also about 8TB. Each archive has a git-annex folder in it. (I specified the subdir option to point directly to the folder.) The annex has many small files; total number of keys is about 500k.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-10-05T17:39:29Z"
- content="""
-A heap profile shows that the problem is an accumulation of PINNED memory.
-Both the memory used by borg list and by constructing the git tree.
-
-At least the borg list part seems very similar to the problem described here.
-<https://well-typed.com/blog/2020/08/memory-fragmentation/>
-The borg list gets read into a lazy bytestring, then it's split up
-and copied into strict bytestring chunks. But those get bundled
-back up into larger memory allocations as explained there. Then the files
-that are not git-annex objects are filtered out, resulting in memory
-fragmentation.
-
-I tried throwing in some S.copy in the borg list and filter part. Didn't
-help.
-
-I converted ImportLocation to use a ShortByteString, and that solved,
-or at least improved, the borg list part of the problem. With 20 borg
-archives with 10000 annex objects each, the heap profile which had
-showed around 90 mb, mostly PINNED during that first stage, went down
-to 8 mb, none PINNED. (Although looking at the git-annex process
-from outside, it still allocated 120 mb or so.)
-
-That leaves the memory use when constructing the git tree.
-Which would also probably affect importtree special remotes,
-when they have a large number of files.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-10-05T19:26:49Z"
- content="""
-I've tried most types of heap profiles and saw only PINNED.
-But a retainer profile (-hr) told more.
-
-<img src="https://tmp.joeyh.name/prof.png">
-
-Note that 8602 is really getImportableContents, and 14913 is importKeys.
-(Found in git-annex.prof which tells the call stack for each set.)
-
-I think that buildImportTrees's allocation is due to needing to hash
-git-annex symlinks and retain the shas. (mktreeitem) Unless there's also memory
-fragmentation happening there.
-
-treeItemsToTree might be the real problem, but it's hard to see how to
-improve it. Maybe stop using it and use a temporary index file to build
-up the tree?
-
-Notice that the 30mb spike shown in the profile is only a fraction of the
-300+ mb that run actually grew to consume. Which gets back to PINNED and fragmentation,
-I'm afraid..
-
-Looking at git-annex from outside, I collected these RSS
-values:
-
- 101508 early borg list
- 209704 before mktreeitem
- 261724 before treeItemsToTree
- 327260 after treeItemsToTree
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2021-10-05T20:53:24Z"
- content="""
-@tomdhunt so your repo has in the order of 182 million
-items for git-annex to track. I do think that is probably too many to be
-practical even if this memory problem gets resolved. A list of that many
-items is at least 25 gigabytes in size. Add some memory for data structures
-and it's hard to see it working with even your enviable 64 gb.
-
-This brings me back to the idea of only including one item for each key...
-Only the item from the most recent archive.
-If the oldest archives always are deleted first, that would never leave a
-key present in the borg repo without git-annex having a record of the
-archive that contained it.
-
-But if you used borg prune to delete some
-intermediate archives, git-annex could no longer know of any existing
-archive that contains a key, so getting from the borg repo would fail,
-until it re-scanned the whole repo.
-git-annex sync could notice when such an intermediate archive
-has been deleted, and trigger the re-scan.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="tomdhunt"
- avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
- subject="comment 7"
- date="2021-10-05T21:30:03Z"
- content="""
-Yeah, I'm not familiar with the internal architecture but both borg and git-annex handle this dataset fine on their own, so it seems that the intersection between the two should also be doable.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 7"""
- date="2021-10-05T23:00:18Z"
- content="""
-I tried converting Ref to use ShortByteString. Memory use did not improve
-and the -hc profile is unchanged. So the pinned memory is not in refs.
-
-Also tried converting Key to use ShortByteString. That was a win!
-My 20 borg archive test case is down from 320 mb to 242 mb.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="tomdhunt"
- avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
- subject="comment 8"
- date="2021-10-05T22:07:44Z"
- content="""
-If it's just a matter of storing the whole set of keys present in each individual archive, you might be able to handle it via difference encoding. The whole list for the first archive, then just sets of added/removed for each archive after that.
-
-This adds a runtime cost to getting the whole set for any archive after the first one, but even with a few thousand archives it seems that should be relatively small. (I assume that it's more likely to have huge numbers of items in an archive, than huge numbers of archives in a repository.)
-"""]]
+++ /dev/null
-### Please describe the problem.
-Hello Joey, <br>
-I added a private special remote (great feature BTW!) some time ago and everything seemed to work fine. Today I wanted to change the preferred content expression for another repo, but the repo that syncs with the special remote refused to accept the new expression and always showed (and used) the old one.
-
-It looked like git-annex on the affected repo still used the `preferred-content.log` from the private journal and didn't merge it with the one from the git-annex branch.
-
-As a workaround I manually merged both versions, put the result in `.git/annex/journal-private/preferred-content.log` and that solved the issue.
-
-### What steps will reproduce the problem?
-[[!format sh """
-#!/bin/bash -x
-
-# Initialize repo a and clone it to b
-git init a
-cd a
-git annex init a
-touch a
-git annex add a
-git annex sync
-cd ..
-git clone a b
-cd b
-git annex init b
-git annex wanted b nothing
-git annex sync
-cd ../a
-git remote add b ../b
-git annex sync
-
-# Add private special remote
-mkdir ../special
-git annex initremote --private special type=directory directory=../special encryption=none exporttree=yes importtree=no
-git config remote.special.annex-tracking-branch master
-git annex wanted special anything
-git annex sync
-
-# change preferred content expression for b
-git annex wanted b anything
-
-git annex wanted b
-# preferred content expression for b is still "nothing"
-
-cd ../b
-git annex sync
-git annex wanted b
-# In the other repo it's correct
-
-
-# End of transcript or log.
-"""]]
-
-### What version of git-annex are you using? On what operating system?
-
-
-### 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)
-
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-10-25T10:25:05Z"
- content="""
-Update: It also seems to confuse location tracking in the affected repo. For example for a recently added file:
-[[!format sh \"\"\"
-# On the affected repo
-# \"gigaset\" is the private special remote
-$ git annex whereis --key SHA256E-s8073298--5b19e75adce5f4a90205ab47ce3d5a96b0a7b7f3fd465b8323a84946c652ba08.mp3
-whereis SHA256E-s8073298--5b19e75adce5f4a90205ab47ce3d5a96b0a7b7f3fd465b8323a84946c652ba08.mp3 (1 copy)
- 0500a119-8fa9-47d7-ba6f-36a0ddde829e -- [gigaset]
-
- The following untrusted locations may also have copies:
- c40ae4eb-1737-49ad-8781-c37d8d7d4f86 -- luklap [here]
-ok
-
-# And now on another repo
-$ git annex whereis --key SHA256E-s8073298--5b19e75adce5f4a90205ab47ce3d5a96b0a7b7f3fd465b8323a84946c652ba08.mp3
-whereis SHA256E-s8073298--5b19e75adce5f4a90205ab47ce3d5a96b0a7b7f3fd465b8323a84946c652ba08.mp3 (3 copies)
- 173e456f-b72b-4557-8570-6c3737fe864c -- WD40EFRX-68W
- d1368ba2-6c20-4b51-815e-87a47d8cc67a -- Seagate_BUP [here]
- da266c97-5af7-4f50-a596-0fedfec89bb9 -- lapserv [origin]
-
- The following untrusted locations may also have copies:
- 452d0592-bf98-4c2b-af86-f8d03327e10b -- pandora
- c40ae4eb-1737-49ad-8781-c37d8d7d4f86 -- luklap
-ok
-
-
-\"\"\"]]
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-10-26T16:11:53Z"
- content="""
-Easily reproduced this, thanks for a great bug report.
-
-What I see after the setup is:
-
- joey@darkstar:~/tmp/bench2/a>git show git-annex:preferred-content.log
- 5cf4b197-9d7a-4c97-b492-74daf50a17d7 anything timestamp=1635264591.115678237s
- joey@darkstar:~/tmp/bench2/a>cat .git/annex/journal-private/preferred-content.log
- 5cf4b197-9d7a-4c97-b492-74daf50a17d7 nothing timestamp=1635264500.401941428s
- d8bcb9f8-2ae2-4e3b-8e7b-fe536a4b53f3 anything timestamp=1635264558.726745148s
-
-Where b is 5cf and the private remote is d8b.
-
-So, it is ignoring the newer log line that is available in the git-annex
-branch, and only loading the older value from the private log, which is only
-included the private log because it was written in passing when the actually
-private information was recorded there.
-
-In fact, when the private log file exists, it only reads it, ignoring
-the log in the git-annex branch. (But not ignoring non-private files
-that are in the journal but have not made it to the branch yet.)
-So even if the private log file only
-included a line for the private remote, it would not see the information
-that's in the git-annex branch.
-
-So, the real root cause is that, when a journal file is available, git-annex
-uses it, rather than reading from the git-annex branch. Normally this is not
-a problem because when journal files are written, the current value from the
-branch is included in them, and anyway the journal gets written to the branch
-fairly quickly and deleted. But the private journal lingers around forever.
-So, it needs to read from the git-annex branch in addition to the private
-journal.
-
-Fixed this. Since the bug did not actually cause the wrong information to
-be written to anywhere, all you need to do to recover is upgrade.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-I am running `git-annex test`, it stops on an NFS mount with exhausted resources (too many open FDs).
-
-Then I try to remove the `.t` directory with `rm -rf .t` and get many errors like:
-
-```
-rm: cannot remove `.t/tmprepo61/.git/annex/objects/96/qw/SHA256E-s10--bcc2eba25d48be76c9d968f2d818196b0e10e13476dcff75371fc0ca4910450c/SHA256E-s10--bcc2eba25d48be76c9d968f2d818196b0e10e13476dcff75371fc0ca4910450c': Permission denied
-```
-
-The permissions on those files look normal (they are mine).
-
-### What steps will reproduce the problem?
-
-see above
-
-### What version of git-annex are you using? On what operating system?
-
-git HEAD (self-built). On 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
-
-
-# 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)
-
-On /tmp the self-test works. Maybe it is related to NFS?
-
-> Turns out that git-annex was keeping files in .t open in some
-> circumstances after deleting them. I have fixed some of this. Possibly
-> not all.
->
-> Since there was no followup for 5 years, I'm closing this. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-01-29T17:20:38Z"
- content="""
-`chmod -R u+w` will let you delete the directory.
-
-`git-annex test` normally takes care of removing the directory for you.
-Only because it crashed did it not in this case. It would be helpful if you
-could show the actual result of running it, including the real error
-message. Perhaps there's something that could be improved.
-"""]]
+++ /dev/null
-Found a case where the associated files in the keys db end up out-of-date.
-Make a repo with an locked file, clone it to a second repo, and set up a
-conflict involving that file in both repos, using git-annex add to add the
-conflicting version, committing, and not running other git-annex commands
-after that, before pulling the conflicting branch. When the associated
-files db gets updated in the conflict situation, only 1 key has the
-conflicting file associated with it, rather than 2 or 3.
-
-The original key before the conflict has the file associated with it, but
-the new local key and new remote key do not.
-
-The result is that a drop of another file that uses the same key may not
-honor the preferred content of the file that is in conflict.
-
-Once the conflict is resolved, git-annex will recover, the problem only
-occurs while there's an unmerged conflict, and only when git-annex did not
-get a change to notice the local modification before the conflict happened.
-
-This only affected locked files, because when an unlocked file is staged,
-git-annex updates the keys db. So, one solution to this bug will be for
-git-annex to also update the keys db when staging locked files.
-(Unfortunately this would make mass adds somewhat slower.)
-
-Or, possibly, for reconcileStaged to not use git diff --cached in this case,
-but git diff with -1 and -3. That lets both sides of the merge conflict be
-accessed, and it could then add the file to both keys. As well as not
-slowing down git-annex add, this would let it honor the preferred content
-of the conflicting file for all 3 keys. --[[Joey]]
-
-> On second thought, it's not really necessary that all 3 keys have the
-> conflicted file associated with them. The original key doesn't because
-> the user has already changed the file to use the new key. The new remote
-> key does not really need to, and there might not even be any effect if it
-> did. The new local key is the one that this bug is really about.
->
-> Consider that checkDrop uses catKeyFile to double-check the associated
-> files. And that will see the file pointing to the new local key. So
-> if the original key or new remote key are also associated with the file,
-> it will ignore them and drop anyway. And that's ok, from the user's
-> perspective the one it needs to retain is the one that the file in the
-> working tree uses, which is the new local key.
->
-> > Hmm, -1 and -3 are not what's needed to get the new local key.
-> > It's using `git diff oldtree --cached`, and the code preserves the old
-> > key when it sees a merge conflict. Using instead
-> > `git diff HEAD --cached` has the new key as the src sha, and nullsha as
-> > the dst sha.
-> >
-> > However, the diff with the old tree is needed to incrementally
-> > update when it's not in the middle of a merge conflict.
-> > So what can be done is do the diff as now; when it sees a merge
-> > conflict, run diff a second time with `HEAD --cached` to get the new
-> > key.
-> >
-> > > [[done]] --[[Joey]]
+++ /dev/null
-git-annex commands that take a file path as argument but really operate on the key corresponding to the file's contents, when given an unlocked file that has been modified, will operate on the original key, not the key corresponding to the file's current contents. For example, [[`git-annex-whereis`|git-annex-whereis]] can show that there are several copies of the contents, even though there is only one (and only in the working copy).
-
-> [[closing|done]] as not a bug --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-01-29T17:12:50Z"
- content="""
-I don't think this has anything to do with unlocked files really,
-and I think a v5 repo would have behaved the same way. A repo with the
-smudge filter disabled certainly seems to:
-
- joey@darkstar:/tmp/bbb>rm .git/info/attributes
- joey@darkstar:/tmp/bbb>date > bar
- joey@darkstar:/tmp/bbb>git annex add bar
- add bar
- ok
- (recording state in git...)
- ijoey@darkstar:/tmp/bbb>git commit -m add
- [master 342b357] add
- 1 file changed, 1 insertion(+)
- create mode 120000 bar
- joey@darkstar:/tmp/bbb>git annex copy bar --to origin
- copy bar (to origin...)
- (checksum...) iok
- (recording state in git...)
- joey@darkstar:/tmp/bbb>git annex whereis bar
- whereis bar (2 copies)
- 4f1d49f8-aeea-47fc-8982-b17b6b2f136f -- joey@darkstar:/tmp/aaa [origin]
- 5861485c-0e5f-4eec-91b5-166dbb999c81 -- joey@darkstar:/tmp/bbb [here]
- ok
- joey@darkstar:/tmp/bbb>rm bar
- joey@darkstar:/tmp/bbb>date > bar
- joey@darkstar:/tmp/bbb>git annex whereis bar
- whereis bar (2 copies)
- 4f1d49f8-aeea-47fc-8982-b17b6b2f136f -- joey@darkstar:/tmp/aaa [origin]
- 5861485c-0e5f-4eec-91b5-166dbb999c81 -- joey@darkstar:/tmp/bbb [here]
- ok
-
-And this is consistent with git-annex working on information that is staged
-in git, not on unstaged changes in the working tree.
-
- joey@darkstar:/tmp/bbb>mv bar bar2
- joey@darkstar:/tmp/bbb>git annex whereis bar2
- joey@darkstar:/tmp/bbb>
-
-So, I don't think this is a bug.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Git-annex commit 7550ef9a2 doesn't compile on Windows without a small patch.
-
-### What steps will reproduce the problem?
-
-`stack setup && stack build`
-
-### What version of git-annex are you using? On what operating system?
-
-[[!format sh """
-git-annex version: 8.20210804-g7550ef9a2
-build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: mingw32 x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 2 3 4 5 6 7
-"""]]
-
-Windows version 21H1 (build 19043.1165), 64 bit.
-
-### Please provide any additional information below.
-
-Relevant parts of the build log:
-
-[[!format sh """
-jkniiv@AINESIS MINGW64 /c/annx
-$ tail -n 25 /c/Projektit/git-annex.branchable.com/git-annex--BUILD-210813-7550ef9a2/stack.build.LOG~102
-[333 of 665] Compiling Annex.Content.LowLevel
-[334 of 665] Compiling Annex.Content.PointerFile
-[335 of 665] Compiling Annex.ChangedRefs
-[336 of 665] Compiling RemoteDaemon.Types
-[337 of 665] Compiling Assistant.Types.RemoteControl
-[338 of 665] Compiling RemoteDaemon.Transport.Ssh.Types
-[339 of 665] Compiling P2P.Protocol
-[340 of 665] Compiling P2P.IO
-[341 of 665] Compiling CmdLine.GitRemoteTorAnnex
-[342 of 665] Compiling Annex.CheckIgnore
-[343 of 665] Compiling Annex.CheckAttr
-[344 of 665] Compiling Backend
-[345 of 665] Compiling Annex.Verify
-
-Annex\Verify.hs:151:50: error:
- Not in scope: type constructor or class `TMVar'
- |
-151 | tailVerify :: IncrementalVerifier -> FilePath -> TMVar () -> IO Bool
-
- | ^^^^^
-
-
--- While building package git-annex-8.20210803 (scroll up to its section to see the error) using:
- C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-210813-7550ef9a2\.stack-work\dist\29cc6475\setup\setup --builddir=.stack-work\dist\29cc6475 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
- Process exited with code: ExitFailure 1
-
-# End of transcript.
-"""]]
-
-The change I made was the following:
-
-[[!format diff """
-diff --git a/Annex/Verify.hs b/Annex/Verify.hs
-index 39ef45981..f43e20db1 100644
---- a/Annex/Verify.hs
-+++ b/Annex/Verify.hs
-@@ -36,6 +36,8 @@ import Types.Key
- import qualified System.INotify as INotify
- import Control.Concurrent.STM
- import qualified Data.ByteString as S
-+#else
-+import Control.Concurrent.STM
- #endif
-
- data VerifyConfig = AlwaysVerify | NoVerify | RemoteVerify Remote | DefaultVerify
-"""]]
-
-This then compiled cleanly and completed the test suite 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)
-
-Git Annex is great. It works with multi-gigabyte backup files (largest around 180GB) via the BLAKE2B160E backend just dandy :)
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-Git-annex commit 9595a247a doesn't compile on Windows without a small patch.
-Commit [[!commit 6329997ac44691937f1d7fe6a71da3184237b13b]] introduces a change for `mingw32_HOST_OS`
-that is not needed (function pattern gains an extra _ parameter). I guess the change was a leftover
-from earlier testing.
-
-### What steps will reproduce the problem?
-
-`stack setup && stack build`
-
-### What version of git-annex are you using? On what operating system?
-
-[[!format sh """
-git-annex version: 8.20210804-g9595a247a
-build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: mingw32 x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 2 3 4 5 6 7
-"""]]
-
-Windows 10 version 21H1 (build 19043.1165), 64 bit.
-
-### Please provide any additional information below.
-
-Relevant parts of the build log:
-
-[[!format sh """
-jkniiv@AINESIS MINGW64 /c/annx
-$ tail -n 25 /c/Projektit/git-annex.branchable.com/git-annex--BUILD-210902-9595a247a/stack.build.LOG~102
-[428 of 665] Compiling Remote.GitLFS
-[429 of 665] Compiling Remote.Bup
-[430 of 665] Compiling Assistant.Gpg
-[431 of 665] Compiling Annex.Environment
-[432 of 665] Compiling Annex.Init
-
-Annex\Init.hs:261:1: error:
- * Couldn't match type `(Bool, [a0])' with `[String]'
- Expected type: m (Bool, [String])
- Actual type: p0 -> (Bool, (Bool, [a0]))
- * The equation(s) for probeCrippledFileSystem' have four arguments,
- but its type `RawFilePath
- -> Maybe (RawFilePath -> m ())
- -> Maybe (RawFilePath -> m ())
- -> m (Bool, [String])'
- has only three
- |
-261 | probeCrippledFileSystem' _ _ _ _ = return (True, [])
-
- | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-
--- While building package git-annex-8.20210803 (scroll up to its section to see the error) using:
- C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-210902-9595a247a\.stack-work\dist\29cc6475\setup\setup --builddir=.stack-work\dist\29cc6475 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
- Process exited with code: ExitFailure 1
-
-# End of transcript.
-"""]]
-
-The change I made was a simple revertion, as follows:
-
-[[!format diff """
-diff --git a/Annex/Init.hs b/Annex/Init.hs
-index 30c4f9753..1193e0b24 100644
---- a/Annex/Init.hs
-+++ b/Annex/Init.hs
-@@ -258,7 +258,7 @@ probeCrippledFileSystem'
- -> Maybe (RawFilePath -> m ())
- -> m (Bool, [String])
- #ifdef mingw32_HOST_OS
--probeCrippledFileSystem' _ _ _ _ = return (True, [])
-+probeCrippledFileSystem' _ _ _ = return (True, [])
- #else
- probeCrippledFileSystem' tmp freezecontent thawcontent = do
- let f = tmp P.</> "gaprobe"
-"""]]
-
-This then compiled cleanly and completed the test suite 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)
-
-Git Annex is great. It works quite nicely with my multi-gigabyte backup files (largest around 180GB) via the BLAKE2B160E backend :)
-
-[[!meta author=jkniiv]]
-
-> Thank you! [[done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-Git-annex commit f0754a61f doesn't compile on Windows without a small patch.
-
-### What steps will reproduce the problem?
-
-`stack setup && stack build`
-
-### What version of git-annex are you using? On what operating system?
-
-[[!format sh """
-git-annex version: 8.20210804-gf0754a61f
-build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: mingw32 x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 2 3 4 5 6 7
-"""]]
-
-Windows 10 version 21H1 (build 19043.1165), 64 bit.
-
-### Please provide any additional information below.
-
-Relevant parts of the build log:
-
-[[!format sh """
-jkniiv@AINESIS MINGW64 /c/annx
-$ tail -n 25 /c/Projektit/git-annex.branchable.com/git-annex--BUILD-210817-f0754a61f/stack.build.LOG~102
-[343 of 665] Compiling Annex.CheckIgnore
-[344 of 665] Compiling Annex.CheckAttr
-[345 of 665] Compiling Backend
-[346 of 665] Compiling Annex.Verify
-
-Annex\Verify.hs:129:22: error:
- Not in scope: `S.hGetSome'
- No module named `S' is imported.
- |
-129 | b <- S.hGetSome h chunk
-
- | ^^^^^^^^^^
-
-Annex\Verify.hs:130:20: error:
- Not in scope: `S.null'
- No module named `S' is imported.
- |
-130 | if S.null b
-
- | ^^^^^^
-
-
--- While building package git-annex-8.20210803 (scroll up to its section to see the error) using:
- C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-210817-f0754a61f\.stack-work\dist\29cc6475\setup\setup --builddir=.stack-work\dist\29cc6475 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
- Process exited with code: ExitFailure 1
-
-# End of transcript.
-"""]]
-
-The change I made was with an import, as follows:
-
-[[!format diff """
-diff --git a/Annex/Verify.hs b/Annex/Verify.hs
-index c41a793f6..ad9866800 100644
---- a/Annex/Verify.hs
-+++ b/Annex/Verify.hs
-@@ -33,9 +33,9 @@ import Types.WorkerPool
- import Types.Key
-
- import Control.Concurrent.STM
-+import qualified Data.ByteString as S
- #if WITH_INOTIFY
- import qualified System.INotify as INotify
--import qualified Data.ByteString as S
- import qualified System.FilePath.ByteString as P
- #endif
-
-"""]]
-
-This then compiled cleanly and completed the test suite 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)
-
-Git Annex is great. It works quite nicely with my multi-gigabyte backup files (largest around 180GB) via the BLAKE2B160E backend :)
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="jkniiv@b330fc3a602d36a37a67b2a2d99d4bed3bb653cb"
- nickname="jkniiv"
- avatar="http://cdn.libravatar.org/avatar/419f2eee8b0c37256488fabcc2737ff2"
- subject="commit 492036622a6326852c29e23608f3959f63e55685 fixes this"
- date="2021-08-18T21:10:51Z"
- content="""
-Commit 492036622 fixes also the Windows build so this bug can be closed. Thank you Joey!
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-The borg special remote is awesome and works perfectly if the borg repo is local. However, fetching content (e.g., with `git annex get` or `git annex sync --content`) seems to fail if the borg repo is accessed over ssh.
-
-### What steps will reproduce the problem?
-
-On remote host:
-
-[[!format sh """
-# Init borg repo
-borg init --encryption=none /home/remote_user/borg_repo
-"""]]
-
-On local host:
-
-[[!format sh """
-# Set environment variable for clarity
-export BORG_REPO=remote_user@remote_host:/home/remote_user/borg_repo
-
-# Init git-annex repo on local host and add borg repo as semitrusted remote
-git init git_repo && cd git_repo
-git annex init git_repo
-git annex initremote borg type=borg borgrepo=$BORG_REPO appendonly=yes
-
-# Commit content to git-annex, create borg archive, and sync
-echo content > file.txt
-git annex add file.txt
-git commit -m init
-borg create $BORG_REPO::archive_name .
-git annex sync borg
-
-# Drop content from git-annex
-git annex drop file.txt
-
-# NOTE: Up to this point, everything is fine.
-
-# Now, attempt to retrieve content from borg
-git annex get file.txt
-"""]]
-
-The final step results in error. Please see the output below in the additional information section.
-
-### What version of git-annex are you using? On what operating system?
-
-- git-annex version: 8.20210428
-- operation system: linux x86_64 (NixOS 21.05)
-
-(NOTE: This was also tested on an old macOS machine with the same results.)
-
-### Please provide any additional information below.
-
-The following output shows an apparent concatenation of the local git-annex repo path with the remote borg repo path:
-
-[[!format sh """
-$ git annex get file.txt
-get file.txt (from borg...)
-Repository /home/local_user/git_repo/remote_user@remote_host:/home/remote_user/borg_repo does not exist.
-
- user error (borg ["extract","/home/local_user/git_repo/remote_user@remote_host:/home/remote_user/borg_repo::archive_name",".git/annex/objects/QV/p6/SHA256E-s8--12a61f4e173fb3a11c05d6471f74728f76231b4a5fcd9667cef3af87a3ae4dc3.txt/SHA256E-s8--12a61f4e173fb3a11c05d6471f74728f76231b4a5fcd9667cef3af87a3ae4dc3.txt"] exited 2)
-
- Unable to access these remotes: borg
-
- No other repository is known to contain the file.
-failed
-get: 1 failed
-exit 1
-"""]]
-
-NOTE: I tried several variations of the ssh url syntax, but they all resulted in the same 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)
-
-Definitely. I love git-annex. I LOVE it. It has no equal and is the secret to my productivity, not to mention peace of mind in this epoch. Much, much respect.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-07-15T16:20:33Z"
- content="""
-Thanks for a good repo recipe. I only needed to add a "borg init
-$BORG_REPO -e none" to see the bug.
-
-The bug is because it had to make the path to the borg repo absolute,
-since it's running borg inside a temp directory. And the case of a ssh
-location was not considered when doing that.
-
-Fixed and cleaned up the BorgRepo data type to avoid this kind of dumb
-mistake in the future. ;-)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="alt"
- subject="comment 2"
- date="2021-07-16T12:37:47Z"
- content="""
-Thank you for the amazingly quick fix!
-"""]]
+++ /dev/null
-A copy --to a local git remote that gets interrupted and is run again does
-not resume where it left off, but copies all the data again.
-
-This does not affect git remotes accessed over ssh.
-
-It's kind of hard to notice this, because normally a resume, has to read
-the src file and dest file, in order for incremental verification to
-get started. But it is somewhat slower to do that than it is to re-write
-the dest file from the start. And when annex.verify = false, it's a lot
-slower.
-
-Looks like it's due to copyCoW unlinking the dest file. Since the first
-file copy trues copyCoW to probe if that's supported, that happens.
-And when resuming an interrupted copy, that probe will generally happen
-with the file it was interrupted on.
-
-So, the solution seems like it would be to copyCoW to some other temp file,
-and if it succeeds, rename it to the dest.
---[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-A seemingly harmless script causes data loss by dropping last copy of file content.
-
-In my test this script only drops file content on Windows. On Linux it's working good, even on a crippled filesystem.
-
-### What steps will reproduce the problem?
-run the following script test.sh:
-[[!format sh """
-mkdir a
-cd a
-git init
-git annex init first
-mkdir folder
-echo foo > folder/1.txt
-git annex add .
-git annex sync
-cd ..
-git clone a b
-cd b
-git annex init second
-git annex sync
-cd ../a
-git remote add second ../b
-git annex sync
-git annex move --to second
-git annex sync
-mv folder folder1
-git annex add
-git annex sync
-cd ../b
-git annex sync
-"""]]
-
-### What version of git-annex are you using? On what operating system?
-git-annex version: 6.20161231-gc8eeb17
-
-Windows 10.0.14393 and also Windows 8
-
-### Please provide any additional information below.
-
-[[!format sh """
-# a complete transcript of the problem occurring.
-$ ./test.sh
-Initialized empty Git repository in A:/a/.git/
-init first
- Detected a filesystem without fifo support.
-
- Disabling ssh connection caching.
-
- Detected a crippled filesystem.
-
- Enabling direct mode.
-ok
-(recording state in git...)
-add folder/1.txt ok
-(recording state in git...)
-commit ok
-Cloning into 'b'...
-done.
-init second
- 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...)
-
- Enabling direct mode.
-ok
-(recording state in git...)
-commit ok
-pull origin
-ok
-push origin
-Counting objects: 6, done.
-Delta compression using up to 8 threads.
-Compressing objects: 100% (5/5), done.
-Writing objects: 100% (6/6), 664 bytes | 0 bytes/s, done.
-Total 6 (delta 0), reused 0 (delta 0)
-To A:/a
- * [new branch] git-annex -> synced/git-annex
-ok
-commit ok
-pull second
-From ../b
- * [new branch] annex/direct/master -> second/annex/direct/master
- * [new branch] git-annex -> second/git-annex
- * [new branch] master -> second/master
- * [new branch] synced/master -> second/synced/master
-ok
-move folder/1.txt (to second...)
-1.txt
- 4 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
-(checksum...) ok
-(recording state in git...)
-commit ok
-pull second
-remote: Counting objects: 5, done.
-remote: Compressing objects: 100% (4/4), done.
-remote: Total 5 (delta 1), reused 0 (delta 0)
-Unpacking objects: 100% (5/5), done.
-From ../b
- fd774cb..1aba4de git-annex -> second/git-annex
-ok
-(merging second/git-annex into git-annex...)
-(recording state in git...)
-push second
-Counting objects: 10, done.
-Delta compression using up to 8 threads.
-Compressing objects: 100% (8/8), done.
-Writing objects: 100% (10/10), 827 bytes | 0 bytes/s, done.
-Total 10 (delta 3), reused 0 (delta 0)
-To ../b
- * [new branch] git-annex -> synced/git-annex
-ok
-add folder1/1.txt ok
-(recording state in git...)
-commit (recording state in git...)
-ok
-pull second
-ok
-push second
-Counting objects: 7, done.
-Delta compression using up to 8 threads.
-Compressing objects: 100% (5/5), done.
-Writing objects: 100% (7/7), 687 bytes | 0 bytes/s, done.
-Total 7 (delta 0), reused 0 (delta 0)
-To ../b
- 7ba3e8a..ee8025b git-annex -> synced/git-annex
- 0758cf9..6e91185 annex/direct/master -> synced/master
-ok
-commit ok
-merge synced/master
-Updating 0758cf9..6e91185
-Fast-forward
- {folder => folder1}/1.txt | 0
- 1 file changed, 0 insertions(+), 0 deletions(-)
- rename {folder => folder1}/1.txt (100%)
-error: duplicate parent 6e91185c7c64569b275a09be1a104a1d8955e1fb ignored
-ok
-pull origin
-From A:/a
- 0758cf9..6e91185 annex/direct/master -> origin/annex/direct/master
- fd774cb..ee8025b git-annex -> origin/git-annex
- 0758cf9..6e91185 master -> origin/master
- 0758cf9..6e91185 synced/master -> origin/synced/master
-ok
-push origin
-Counting objects: 1, done.
-Writing objects: 100% (1/1), 185 bytes | 0 bytes/s, done.
-Total 1 (delta 0), reused 0 (delta 0)
-To A:/a
- fd774cb..ee8025b git-annex -> synced/git-annex
- 6e91185..a886805 annex/direct/master -> synced/master
-ok
-
-$ # script done here
-$ cd b
-$ git annex whereis
-whereis folder1/1.txt (1 copy)
- 2a9ef292-1729-4533-ac50-f68d2d0badb6 -- second [here]
-ok
-
-$ cat folder1/1.txt
-../.git/annex/objects/W5/55/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.txt/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.txt
-
-$ git annex get
-get folder1/1.txt (not available)
- No other repository is known to contain the file.
-failed
-git-annex: get: 1 failed
-
-
-# End of transcript or log.
-"""]]
-
-
-### Conclusion
-
-I'm so attracted to git-annex's idea, but so sad it's still not robust enough to use on Windows platform - v5 direct mode repo is as far as I can get, yet it still throws away my data like this...
-
-> [[done]]; this was apparently a bug with direct mode. --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-05-03T12:12:17Z"
- content="""
-I tested it with the latest git-annex version (8.20210331-g1fb59a63a) and can't reproduce the bug. So I guess this can be closed.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-05-03T16:23:16Z"
- content="""
-Thanks for checking up on this old bug.
-
-I think it makes sense that the bug was in the direct mode code, and so
-closing.
-"""]]
+++ /dev/null
-A default cabal install on OS X in a sandbox of git-annex 6.20160511 will result in no S3 support, as reported to Homebrew in the following two issues:
-https://github.com/Homebrew/homebrew-core/issues/1268
-https://github.com/Homebrew/legacy-homebrew/issues/47737
-
-The underlying cause is that aws-0.13.0 lacks commit https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d, which allows data-default 0.6.
-
-I attempted to mitigate the issue using --flags="s3", but that does not seem to help (nor does it force the build to fail): still no s3 support. I'd expect that either to constrain data-default to 0.5.3 and produce a build with s3 support, or fail the build, but for some reason it doesn't. Is this not working because we're in a sandbox or some other reason?
-
-Currently, I'm planning to just patch aws with https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d rather than resorting to a fixed configuration (e.g., lts-5.5 or whatever), as you can see here:
-https://github.com/Homebrew/homebrew-core/pull/1307
-
-It would be great if git-annex could work around the issue itself, though.
-
-Meanwhile, I have also pinged aws to request a 0.13.1 release, which would solve the problem "the right way":
-https://github.com/aristidb/aws/issues/202
-
-> I see this got fixed the "right way" in aws back then, so [[done]]
-> --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-annex.delayadd doesn't seem to do anything.
-
-### What steps will reproduce the problem?
-
-```
-git init test
-cd test
-git annex init
-git annex assistant
-git config annex.delayadd 9999999
-echo `date` > test
-git log
-cat test
-```
-
-The commit shouldn't happen until about ~4 months from now but it happens almost instantly (git log date and date in file are the same).
-
-### What version of git-annex are you using? On what operating system?
-
-```
-git-annex version: 8.20210428
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.4 http-client-0.6.4.1 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.1
-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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-### 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]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-05-19T15:08:44Z"
- content="""
-The assistant scans on startup for changes that happened while it was not
-running, and delayadd does not affect those. It only affects changes while
-the assistant is running.
-
-I don't think it would be possible to make the startup scan respect
-delayadd in general. It could look at mtime, but eg, renaming a file
-does not affect its mtime.
-
-Also, the only reason the feature exists is that it can be annoying, when
-the assistant is running, to have every little change you make to a file
-be recorded; a short delay can let such changes be bundled together.
-
-I will document this and close it.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Atemu"
- avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
- subject="comment 2"
- date="2021-05-19T16:54:19Z"
- content="""
-Hi Joey, this isn't about startup behaviour.
-
-My use case (and the repro steps) have the assistant up and running before any modifications are done.
-
-My issue is that assistant is commiting my changes instantly with no delay while I'd rather have it bunch up things when I save multiple files in quick succession which is precisely what delayadd is supposed to help with (as you said).
-
-Weirdly however, it just ..doesn't do anything? The date in the file is the exact same as the automatic commit's.
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-05-21T15:28:22Z"
- content="""
-Your test case sets the git config after the assistant is running. The
-assistant does not notice git config changes made while it's
-running, it has to be restarted to pick them up.
-
-I tried setting the config before starting the assistant, and it works
-fine.
-
-I assume your real problem does not involve setting the config at the wrong
-point in time, so I'll wait for a corrected test case..
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Atemu"
- avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
- subject="comment 4"
- date="2021-05-22T09:55:31Z"
- content="""
-You are quite correct, the minimal test case works just as expected when the config is applied *before* running the daemon.
-
-`delayadd` has been in my actual repo's config for many months now and has seen countless daemon restarts however, so that can't be my actual problem unfortunately.
-
-Now that I have a working repo, I will try to break it like I did with my regular repo.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Atemu"
- avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
- subject="comment 5"
- date="2021-05-22T10:20:35Z"
- content="""
-I found the culprit: largefiles.
-
-I use
-```
-* annex.largefiles=mimeencoding=binary
-```
-
-in my documents repo because I need to efficiently store lots of text and diff, merge etc. properly.
-
-Here are the revised repro steps:
-
-```
-git init test
-cd test
-git annex init
-git config annex.delayadd 5
-echo '* annex.largefiles=mimeencoding=binary' > .gitattributes
-git add .
-git commit -m \"gitattributes: largefiles\"
-git annex assistant
-echo `date` > test
-git log --patch
-```
-
-The date of the commit should be the date in the file +5s.
-"""]]
+++ /dev/null
-### Please describe the problem.
-I have a strange problem with diff driver.
-I wrote a diff driver which normally works, but one of my repo
-it comes up with an error that it can open `.git/annex/objects/SHA256E-s4545--9715...`.
-Indeed there is no such file, the file being not directly under `.git/annex/objects` but under `.git/annex/objects/mz/Px`.
-Also when I examine the file in git its value is `.git/annex/objects/SHA256E-s4545--9715...` but I thought it should have been `.git/annex/objects/mz/PX/SHA256E-s4545--9715...`.
-
-
-### What steps will reproduce the problem?
-
-Just use `git diff HEAD` on my corrupted repo.
-
-
-### What version of git-annex are you using? On what operating system?
-
-Version 7. I don't remember which version was used to create the repo.
-
-
-### 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 diff HEAD . [20:10:33]
-1:dumps/pages.sql
-2:/tmp/gwSIvM_pages.sql
-3:1bb7ca74a6701b1ea0d4f12ae64cfc3e83e22bad
-4:100644
-5:dumps/pages.sql
-6:0000000000000000000000000000000000000000
-7:100644
-------- /tmp/gwSIvM_pages.sql-
-head: cannot open '.git/annex/objects/SHA256E-s4542--9715a9ca90cad176f69fb91ed650a02afb2885c96975064d49e85230513c2d9e.sql' for reading: No such file or directory
--------- $ target
---
--- PostgreSQL database dump
---
-
--- Dumped from database version 13.3
--- Dumped by pg_dump version 13.3
-
- ❯ cat ~/.local/bin/mydiff.sh [20:16:07]
-echo 1:$1
-echo 2:$2
-echo 3:$3
-echo 4:$4
-echo 5:$5
-echo 6:$6
-echo 7:$7
-if [ "$5" = "/dev/null" ]
-then
- echo "NULL"
- target=$1
-else
- target=$5
-fi
-#echo $@
-echo "------- $2-"
-head .git$(cat $2)
-echo "-------- $target"
-head $target
-echo "-------- DIFF"
-#colordiff $1 $2
-
-#git --no-pager diff --color=auto --word-diff --no-ext-diff --no-index "$2" "$target"
-echo diff -d --color=always $2 $target
-#git --no-pager diff --color=auto --no-ext-diff --no-index -U0 "$2" "$5"
-
-
-# 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 and it works really well (and my diff driver works on other repos too).
-
-
-> [[notabug|done]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-09-24T18:17:59Z"
- content="""
-I think the file in your repo is unlocked. An unlocked file is represented
-in git as a pointer file, the pointer contains `"/annex/objects/<key>"`.
-
-Note that git-annex diffdriver exists to let a diff driver work with
-annexed files. I think you might want to use it. Amusingly
-I forgot about unlocked files in the implementation of it too;
-that got fixed in version 8.20210428.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="bmx007@171b90624bc8f788a2a925a00b98aef5942e4787"
- nickname="bmx007"
- avatar="http://cdn.libravatar.org/avatar/d3a5bd12fe6d876527a3cf4ac0de5fc6"
- subject="comment 2"
- date="2021-09-24T20:08:22Z"
- content="""
-I am using `git annex diff-driver`. What do you mean by unlocked ?
-The file `$1` is unlocked indeed but it works, the problem is `$2` which is from `HEAD`.
-I'm not sure how a file from the git history could be unlocked ?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-09-27T16:07:35Z"
- content="""
-Your script contains:
-
- head .git$(cat $2)
-
-How is this using `git-annex diffdriver`? If you were using that,
-you would expect `$2` to be the path to the actual location of the annexed
-file. So you would not need to cat it, or to append `.git` to it.
-
-Files in the git history can be unlocked, that is a feature that was
-introduced in git-annex version 7. See the documentation
-<https://git-annex.branchable.com/git-annex-unlock/>
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-it seems that git-annex/linux/current/git-annex-standalone-amd64.tar.gz which is claimed in the last commit to be 8.20210804 is really a 8.20210715-g6e67ea5d7
-
-
-### What steps will reproduce the problem?
-
-```
-(git-annex)lena:~datalad/distributions/downloads.kitenet.net[master]git-annex
-$> git log git-annex/linux/current/git-annex-standalone-amd64.tar.gz | head
-commit 9670be5007ab9a084e9f7a47c9d315555b477ca0
-Author: Joey Hess <joeyh@joeyh.name>
-Date: Tue Aug 3 12:30:46 2021 -0400
-
- publishing git-annex 8.20210804
-
-commit 780e402a5f0fd188e2edef61303db023f492459c
-Author: Joey Hess <joeyh@joeyh.name>
-Date: Wed Jul 14 12:33:03 2021 -0400
-
-$> ls -l git-annex/linux/current/git-annex-standalone-amd64.tar.gz
-lrwxrwxrwx 1 yoh yoh 215 Aug 6 17:35 git-annex/linux/current/git-annex-standalone-amd64.tar.gz -> ../../../.git/annex/objects/9q/67/SHA256E-s51281961--c2419981d633d598b760c89f5a309d1ec7ec66f5b8a1e734a7239b2d4c7a3d21.tar.gz/SHA256E-s51281961--c2419981d633d598b760c89f5a309d1ec7ec66f5b8a1e734a7239b2d4c7a3d21.tar.gz
-
-$> tar -xzf git-annex/linux/current/git-annex-standalone-amd64.tar.gz
-
-$> lst
-total 4
-drwx------ 1 yoh yoh 472 Aug 6 17:48 git-annex.linux/
-...
-
-$> ./git-annex.linux/git-annex version | head
-git-annex version: 8.20210715-g6e67ea5d7
-...
-```
-
-also note that it is "publishing git-annex 8.20210804" (on 0803) and there is no `8.20210804` version but there is
-
-```
-$> git tag | grep 202108
-8.20210803
-```
-
-so it seems odd
-
-> [[notabug|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-08-09T16:11:54Z"
- content="""
-6e67ea5d7 is 2 commits away from the tag for 8.20210803.
-The two commits are whitespace changes and the commit that increased the
-version number.
-
-I can either push the release to git and bless the builds current at the
-same time, or wait some amount of time after the release tag for the builds
-to catch up. That could be some arbitrary amount of time, because builds
-fail for various reasons outside my control, or are slow.
-
-It would also need a separate build process than the autobuilds of master,
-to build against release tags. Which adds even more ways for things to go
-wrong or be delayed.
-
-Therefore, I have chosen this compromise. It is not new, and if you
-consider it a bug, well, you can build against the release tag if you wish.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-08-09T16:23:35Z"
- content="""
-As far as the git commit message goes, I usually don't have a new changelog
-entry for an unreleased version opened when I run the release updating
-script, but did in this case. Only the commit message is affected. I've
-fixed the cause of that problem.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="standalone build version vs standard release version"
- date="2021-08-09T17:28:31Z"
- content="""
-Sorry if I'm being dense here, but the version mismatch issue also [[affects|forum/standalone_tarballs_for_specific_versions]] the [[conda build|install/conda]], so I want to better understand the underlying issue. What makes it necessary for the standalone version to be built from a different git commit than the standard version? If \"The two commits are whitespace changes and the commit that increased the version number\", could these commits be made before the official release is tagged?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="yarikoptic"
- avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
- subject="comment 4"
- date="2021-08-09T17:34:39Z"
- content="""
-> ... you can build against the release tag if you wish.
-
-well, FWIW we do that AFAIK in https://github.com/datalad/git-annex , but those are non-official builds. And echoing Ilya, this issue was about an official distribution repository which is used for conda-forge \"no proper build, just grab a standalone\" version of a package.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2021-08-09T19:20:36Z"
- content="""
-Ilya, you have misunderstood what I said. The autobuild happened. I
-then updated the changelog, made one other commit that didn't affect
-the code, and tagged the release. I could then either wait for the next
-autobuild, or I could ship what was in the last autobuild. I did the
-latter, for the reasons described in comment #1.
-
-If this is not clear, my advice would be you either review the code that I
-use for builds and releases, which is all public, until you understand it,
-or you don't use my builds. I tire of this.
-"""]]
+++ /dev/null
-### Please describe the problem.
-If a repository path contains a space, git-annex can't copy to it
-
-### What steps will reproduce the problem?
-1. Create a new remote in a directory with a space in the path: `git annex initremote encryptedbackup type=gcrypt gitrepo='/run/media/volume name with a space/repo' keyid=$mykey`
-2. Try to copy data: `git annex copy --to=encryptedbackup file.mkv`
-
-### 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
-
-$ git annex copy --to=encryptedbackup file.mkv
-copy file.mkv (unable to check encryptedbackup) 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)
-
-> [[fixed|done]] --[[Joey]]
-
+++ /dev/null
-### Please describe the problem.
-
-I am trying to use git-annex to keep files in sync between a server and my music player. I don't want everything on the server to go to the music player, so I have a "wanted" expression defined: `exclude=*/archive/* and (include=ASMR/* or include=Music/* or include=Mods/* or include=Playlists/*)`. My expectation was that `git annex sync` would ignore any files that didn't match wanted on the remote, and indeed the first time I run it it does. However, the second time I run it, it deletes any local files that aren't on the remote. Presumably git-annex thinks those files were deleted on the remote because its tracking branch is descended from the branch in which the files were created.
-
-### What steps will reproduce the problem?
-
-1. Create a directory special remote with `exporttree=yes importtree=yes`
-2. Set `remote.<remote>.annex-tracking-branch` to some branch where you have files.
-3. Set a preferred-content expression that excludes some of the files.
-4. Run `git annex sync --content`
-5. Run `git annex sync --content` a second time.
-
-You will see that the files that weren't exported get deleted.
-
-### What version of git-annex are you using? On what operating system?
-
-```
-git-annex version: 8.20201130-gf1a9e88c9
-build flags: Assistant Webapp Pairing Inotify TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-Debian Buster
-
-### 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 use git-annex for all kinds of stuff. I love it!
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-01-28T15:52:03Z"
- content="""
-Note that there's not data loss here, you can still check
-out branches with the deleted files, or revert the merge.
-
-Seems like importtree should add to the imported tree all files that
-were in the export but were not preferred content.
-
-Hmm, in Annex.Import.addBackExportExcluded, it tries to do just that. The
-implementation uses a log file in .git/annex/export.ex that lists the
-previously excluded files. There must be a bug in that.
-
-I can easily reproduce this bug:
-
- joey@darkstar:/tmp/bench2>mkdir d
- joey@darkstar:/tmp/bench2>git init r
- joey@darkstar:/tmp/bench2>cd r
- joey@darkstar:/tmp/bench2/r>git annex init
- joey@darkstar:/tmp/bench2/r>git annex initremote d type=directory directory=../d exporttree=yes importtree=yes encryption=none
- joey@darkstar:/tmp/bench2/r>git annex wanted d 'exclude=*.mp3'
- joey@darkstar:/tmp/bench2/r>date > foo.bar
- joey@darkstar:/tmp/bench2/r>date > foo.mp3
- joey@darkstar:/tmp/bench2/r>git annex add
- joey@darkstar:/tmp/bench2/r>git commit -m add
- joey@darkstar:/tmp/bench2/r>git annex export master --to d
- export d foo.bar ok
- joey@darkstar:/tmp/bench2/r>git annex import master --from d
- list d ok
- update refs/remotes/d/master ok
- (recording state in git...)
- joey@darkstar:/tmp/bench2/r>git merge d/master
- Updating f818c13..b1a0434
- Fast-forward
- foo.mp3 | 1 -
- 1 file changed, 1 deletion(-)
- delete mode 120000 foo.mp3
- joey@darkstar:/tmp/bench2/r>cat .git/annex/export.ex/72c8d14c-af03-408c-845d-cac418d49e61
- 120000 blob 64c3e1f1f81026cb8ab5a6593d4120a1d73044c3 foo.mp3
-
-So it seems adding back the exported file from the log is where the bug lies.
-And specifically, it seems when it tries to read this log, it silently fails
-to parse it, and so adds nothing back.
-
-Aha! -- The parser is expecting a tab in the git ls-tree like log, but it's
-written with a space instead. It did used to work but the parser got rewritten
-for speed and was changed to only accept tab, not both space and tab.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="seanl@fe5df935169a5440a52bdbfc5fece85cdd002d68"
- nickname="seanl"
- avatar="http://cdn.libravatar.org/avatar/082ffc523e71e18c45395e6115b3b373"
- subject="Thanks! And yes, no data loss."
- date="2021-01-29T06:55:42Z"
- content="""
-I should have realized it wasn't a fundamental issue, because I was using it this way a couple years back without problems. Indeed there was no data loss; I just checked the files out from the commit before the merge.
-
-Thanks for fixing it so quickly!
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-started to happen in https://github.com/datalad/git-annex/actions/runs/750505573
-
-looked only at "normal" run
-```
- export_import: FAIL (0.93s)
- ./Test/Framework.hs:57:
- export to dir failed (transcript follows)
- export foo bar.c okexport foo foo /home/runner/.t/tmprepo4/dir/foo6874-4.tmp: openBinaryFile: resource busy (file is locked)failedexport foo sha1foo /home/runner/.t/tmprepo4/dir/sha1foo6874-7.tmp: openBinaryFile: resource busy (file is locked)failed(recording state in git...)git-annex: export: 2 failed
-
- export_import: FAIL (0.58s)
- ./Test/Framework.hs:57:
- export to dir failed (transcript follows)
- export foo bar.c okexport foo foo /home/runner/.t/tmprepo98/dir/foo45594-4.tmp: openBinaryFile: resource busy (file is locked)failedexport foo sha1foo /home/runner/.t/tmprepo98/dir/sha1foo45594-7.tmp: openBinaryFile: resource busy (file is locked)failed(recording state in git...)git-annex: export: 2 failed
-...
- export_import: FAIL (0.52s)
- ./Test/Framework.hs:57:
- export to dir failed (transcript follows)
- export foo bar.c okexport foo foo /home/runner/.t/tmprepo192/dir/foo75699-4.tmp: openBinaryFile: resource busy (file is locked)failedexport foo sha1foo /home/runner/.t/tmprepo192/dir/sha1foo75699-7.tmp: openBinaryFile: resource busy (file is locked)failed(recording state in git...)git-annex: export: 2 failed
-```
-
-so actually looks like the same test in various scenarios.
-
-probably relates to the tune ups to make importtree work with CoW
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-04-20T15:10:59Z"
- content="""
-Indeed it was, file handle left open. Fixed.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-All my files added to my archive repo over the past few months seem to fail git annex fsck.
-
-### What steps will reproduce the problem?
-
-- Add a file to the repo
-- Fsck it
-
-### What version of git-annex are you using? On what operating system?
-
-8.20211012-geb95ed486 on Arch Linux directly downloaded from this website
-I was using some older version from 2020 previously
-
-### 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
-
- jookia@titan:/data/jookia/archive% head -c1024 /dev/urandom > RANDOM.TEST (exited 130) (1 jobs) 05:27
- jookia@titan:/data/jookia/archive% git annex add RANDOM.TEST (1 jobs) 05:27
- add RANDOM.TEST
- ok
- (recording state in git...)
- jookia@titan:/data/jookia/archive% git commit -m RANDOM.TEST (1 jobs) 05:27
- [main 2e9f2429018] RANDOM.TEST
- 1 file changed, 1 insertion(+)
- create mode 120000 RANDOM.TEST
- jookia@titan:/data/jookia/archive% git annex fsck RANDOM.TEST (1 jobs) 05:27
-
- Remote black cannot currently be accessed.
- Warning: Fscking a repository that is currently marked as dead.
- fsck RANDOM.TEST (checksum...)
- ** No known copies exist of RANDOM.TEST
- These dead repositories used to have copies
- e62ad85d-368d-4ea5-a85c-e94598904a50 -- T400 laptop [here]
- failed
- (recording state in git...)
- fsck: 1 failed
- jookia@titan:/data/jookia/archive% ls -l RANDOM.TEST (exited 130) (1 jobs) 05:28
- lrwxrwxrwx 1 jookia jookia 194 Nov 15 05:27 RANDOM.TEST -> .git/annex/objects/K4/jV/SHA256E-s1024--0dedc9e7fb3fa053982201c2166fc1265ebd64d41ab91fe1c348c2df46f50167.TEST/SHA256E-s1024--0dedc9e7fb3fa053982201c2166fc1265ebd64d41ab91fe1c348c2df46f50167.TEST
- jookia@titan:/data/jookia/archive% sha256sum RANDOM.TEST (1 jobs) 05:28
- 0dedc9e7fb3fa053982201c2166fc1265ebd64d41ab91fe1c348c2df46f50167 RANDOM.TEST
-# 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've been using it for years. It's a robust and reliable piece of software. :)
-
-> This output does not seem unclear. The local repository being fscked is
-> marked as dead, and of course git-annex treats dead repositories as not
-> containing any content. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="contact@ee563aaec1e9de7a4e8d748992963dba79178e9c"
- nickname="contact"
- avatar="http://cdn.libravatar.org/avatar/4aa4d7a441bd4e6948fc0012c7229d01"
- subject="comment 1"
- date="2021-11-14T18:35:45Z"
- content="""
-I'm confused as to why it says random data is in an old repository.
-numcopies 0 seems to 'fix' this?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="contact@ee563aaec1e9de7a4e8d748992963dba79178e9c"
- nickname="contact"
- avatar="http://cdn.libravatar.org/avatar/4aa4d7a441bd4e6948fc0012c7229d01"
- subject="comment 2"
- date="2021-11-14T18:37:04Z"
- content="""
-Uh, addendum 2: I signed in with my email which is contact@jookia.org , but it's created a user named 'contact'. Sorry for eating up this username. :)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="contact@ee563aaec1e9de7a4e8d748992963dba79178e9c"
- nickname="contact"
- avatar="http://cdn.libravatar.org/avatar/4aa4d7a441bd4e6948fc0012c7229d01"
- subject="comment 3"
- date="2021-11-14T18:41:18Z"
- content="""
-Sorry for the comment spam. It looks like 'Warning: Fscking a repository that is currently marked as dead.' is what was happening here.
-The error message is confusing making it seem like the checksum failed and that the file existed elsewhere, not that there's no copies.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 4"
- date="2021-11-14T20:11:35Z"
- content="""
-Well, you somehow marked the repo you're working in as dead. Usually you only mark a repo that is irretrievably lost (due to drive failure for example) as dead so git-annex knows that none of the data in it exists anymore and doesn't count it as a copy anymore. That's exactly what you're seeing here.
-"""]]
+++ /dev/null
-### Please describe the problem.
-We use git annex and found an issue where one machine that had run 'git annex sync' and 'git annex sync --content' was not reporting any issues, but any other machines were reporting 99 issues when running 'git annex get'.
-
-The message for each file was that it was not known to exist on any repo. Doing some searching I found 'git annex fsck' so ran that in the following fashion on the 'broken' machines: 'git annex fsck --from=LocalMirrorName --fast'. During this we saw git was updating the location log for nearly all the missing files. Running 'git annex get' afterwards resolved the issue and got the files. We found we had to repeat this on all affected machines.
-
-### What steps will reproduce the problem?
-We've not been able to reproduce a brand new stance of the problem (and don't want to, rightly so). Some other machines still have this issue where we have not run the fsck.
-
-### What version of git-annex are you using? On what operating system?
-The machine that did the original sync was running git 2.7.4 on Ubuntu 16 and other
-machines were either running the same, or 2.17.1 on Ubuntu 18.
-
-### Please provide any additional information below.
-A test I also tried: I copied one annex file from inside the .git folder of the original machine that ran the sync, and added it to the same location on a broken machine, then ran sync and get, and it reported 98 issues instead.
-
-Does this seem like a bug with git annex? Is there a possible gap in the way that git annex reports that all is fine - perhaps to do with the index? Or does this seem to be more likely an issue we created ourselves? Would there have been any other commands we could have run to resolve this issue or should have tried out first? (Apart from just deleting each of our clones and starting again)
-
-### 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 works for us the majority of the time and solves a lot of space issues for us in a unique way. We do get confused by it sometimes, but that's probably our implementation of it and not knowing enough about it across our team (seems to be a set and forget approach).
-
-> Closing as it's not clear this was a bug rather than user error as
-> explained in my comment. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-02-05T18:45:10Z"
- content="""
-I'm not sure there's a bug here. It sounds like your repository's git-annex
-branch was out of date, and so it did not know about a change to the
-location of the files.
-
-For example, I can replicate the error message like this:
-
- joey@darkstar:/tmp> git init A
- joey@darkstar:/tmp> cd A
- joey@darkstar:/tmp/A> git annex init
- joey@darkstar:/tmp/A> touch file
- joey@darkstar:/tmp/A> git annex add file
- joey@darkstar:/tmp/A> git commit -m added
- joey@darkstar:/tmp/A> cd ..
- joey@darkstar:/tmp> git clone A B
- joey@darkstar:/tmp> cd B
- joey@darkstar:/tmp/B> git annex move --from origin
- joey@darkstar:/tmp/B> git annex get # this succeeds
- joey@darkstar:/tmp/B> cd ..
- joey@darkstar:/tmp> cd A
- joey@darkstar:/tmp/A> git annex get
- get file (not available)
- No other repository is known to contain the file.
- failed
- git-annex: get: 1 failed
-
-Here repo A has out-of-date information in its git-annex branch;
-it doesn't know that the file content was moved to repo B.
-Running `git annex sync` in A does not improve matters, because A has
-no connection to repo B. But once the updated git-annex branch does
-reach repo A, it will again know:
-
- joey@darkstar:/tmp/A> cd ../B
- joey@darkstar:/tmp/B> git annex sync
- joey@darkstar:/tmp/B> cd ../A
- joey@darkstar:/tmp/B>cd ../A
- joey@darkstar:/tmp/A>git annex get
- get file (not available)
- Try making some of these repositories available:
- b7bc6700-0009-457c-b490-0531bb830d80 -- joey@darkstar:/tmp/B
-
-
-Here running git-annex sync in B was enough to get the git-annex branch
-synced up, because B has a connection to A, but in your situation,
-depending on the topology of your repositories, you may need to do
-something else.
-"""]]
+++ /dev/null
-`git annex fsck` of an encrypted s3 remote fails when using multiple jobs.
-
-Version info:
-
-```
-$ git annex version
-git-annex version: 8.20210310
-build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.4 http-client-0.7.6 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: darwin x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-transcript:
-
-[[!format sh """
-# failed
-
-$ git annex fsck -f s3 --fast
-fsck 50MB_3
-fsck testmincopies (checking s3...) ok
-fsck 50MB_3 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s
-fsck chicken (checking s3...) ok
-fsck hellothere (checking s3...) ok
-fsck 50MB_4 (user error (gpg ["--quiet","--trust-model","always","--decrypt"] exited 2)) failed
-fsck pig (checking s3...) ok
-fsck baz (checking s3...) ok
-fsck sawka.wav (checking s3...) ok
-fsck clap_tape.wav (user error (gpg ["--quiet","--trust-model","always","--decrypt"] exited 2)) failed
-fsck supa_kick.wav (checking s3...) ok
-fsck 50MB (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck 50MB_3 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck whatisthis (checking s3...) ok
-fsck 50MB_5 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck drums/clap.wav (checking s3...) ok
-fsck kindabig (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck drums/big_kick_2.wav (checking s3...) ok
-fsck dmd2_chstkck4.wav (checking s3...) ok
-fsck drums/big_kick.wav (checking s3...) ok
-fsck 50MB_2 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck MB100 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-(recording state in git...)
-git-annex: fsck: 2 failed
-luckbox:orig patmaddox$
-
-
-
-
-# success
-
-$ git annex fsck -f s3 --fast -J 1
-fsck 50MB (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck 50MB_2 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck 50MB_3 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck 50MB_4 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck 50MB_5 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck MB100 (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck baz (checking s3...) ok
-fsck chicken (checking s3...) ok
-fsck clap_tape.wav (checking s3...) ok
-fsck dmd2_chstkck4.wav (checking s3...) ok
-fsck drums/big_kick.wav (checking s3...) ok
-fsck drums/big_kick_2.wav (checking s3...) ok
-fsck drums/clap.wav (checking s3...) ok
-fsck hellothere (checking s3...) ok
-fsck kindabig (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) (checking s3...) ok
-fsck pig (checking s3...) ok
-fsck sawka.wav (checking s3...) ok
-fsck supa_kick.wav (checking s3...) ok
-fsck testmincopies (checking s3...) ok
-fsck whatisthis (checking s3...) ok
-(recording state in git...)
-"""]]
-
-### 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 over all working very well for me. I am able to do some things that I've wanted to be able to do for years. I believe I have worked it out well enough that I can stop testing it and start using it for real.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-04-27T16:20:41Z"
- content="""
-The command that you show failing does not seem to have concurrency
-enabled. Then you explicitly disable concurrency with -J 1 and it succeeds.
-Do you have annex.jobs set, and if so, to what?
-
-There is something very odd about "(checking s3...) (checking s3...)
-(checking s3...)" etc. I suspect you also have chunking enabled, and it is
-displaying that once per chunk, in which case it's probably not much of a
-clue about the problem. However, it highlights that you have really not
-explained how this remote is set up; it would be useful to provide enough
-information to reproduce the bug from scratch.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="pat"
- avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
- subject="comment 2"
- date="2021-04-27T18:34:30Z"
- content="""
-Ah yes, sorry about that. I have `annex.jobs=cpus` by default. Here's the annex info. I don't remember if I explicitly set chunking.
-
-```
-$ git annex info s3
-uuid: 941b57e7-4144-43a8-8cc7-a4be920ee48f
-description: [s3]
-trust: semitrusted
-remote: s3
-cost: 250.0
-type: S3
-creds: embedded in git repository (gpg encrypted)
-bucket: patmaddox-annex-test
-endpoint: s3-us-west-2.amazonaws.com
-port: 80
-protocol: http
-storage class: STANDARD
-partsize: unlimited
-public: no
-versioning: no
-encryption: hybrid (to gpg keys: A52F3B969AFE6C9F)
-chunking: 1.05 megabyteschunks
-remote annex keys: 17
-remote annex size: 367.93 megabytes
-```
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-04-27T19:25:49Z"
- content="""
-I was able to reproduce this as follows:
-
- git annex initremote dr type=directory directory=d encryption=hybrid chunk=1MB keyid=(my gpg key id)
-
-Copy 8 different 50 mb files to the remote, then git-annex fsck --from dr -J8
-
-Happens intermittently, I saw it twice out of the first several runs,
-but have been having difficulty getting it to happen any more now.
-
- fsck 50mb2
- fsck 50mb6 (user error (gpg ["--quiet","--trust-model","always","--decrypt"] exited 2)) failed
-
-Hard to know why gpg is failing since it does not output any error message.
-I tried enabling gpg's debugging, and found this in its debug output:
-
- gpg: DBG: chan_5 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Joey+Hess+<joeyh@joeyh.name>%22%0A4096-
- gpg: DBG: chan_5 <- OK^M
- gpg: DBG: chan_5 -> PKDECRYPT^M
- gpg: DBG: chan_5 <- S INQUIRE_MAXLEN 4096^M
- gpg: DBG: chan_5 <- INQUIRE CIPHERTEXT^M
- gpg: DBG: chan_5 -> (omitted out of fear some bytes are key material -- JEH)^M
- gpg: DBG: chan_5 -> END^M
- gpg: DBG: chan_5 <- ERR 16810070 Cannot allocate memory <gcrypt>
- ...
- gpg: decryption failed: No secret key
-
-Seems pretty likely this is really a gpg bug. Gpg should be able to decrypt
-two things concurrently, and generally can without failing. This seemed to
-occur when gpg was talking to gpg-agent to access the user's secret key, so
-a concurrency bug in the gpg-agent interface seems likely.
-
-Aha, here's a post to the gpg list about what looks like the same bug:
-<https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html>
-<https://dev.gnupg.org/T3027> this bug claims it was fixed in libgcrypt 1.7.7,
-but my gpg uses 1.8.7. From the bug, I'm somewhat doubtful they really fixed it.
-
-The lack of --batch in the gpg command line makes me think that the thing
-gpg is decrypting there is not the content of a file, but the hybrid encryption
-cipher from the git-annex branch. (Also IIRC it failed pretty early on.)
-Normally the cipher only gets decrypted once and then cached
-in memory, but there is a race possible that could decrypt it concurrently.
-Not usually a problem, although I suppose it could also result in a double
-password prompt when not using the gpg agent.
-
-If this is a gpg bug, fixing that race in git-annex would mostly
-avoid it. Concurrent git-annex processes might still trip over such a gpg bug,
-but so could any concurrent processes.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-04-27T20:33:41Z"
- content="""
-I've implemented the race protection. Pretty sure this fixes it, at least
-to the extent it can be fixed if it's a gpg bug that any 2 concurrent
-password prompts can sometimes trigger. I'll run git-annex fsck in a
-loop for an hour or so to be more sure.
-
-It would be nice if someone wants to file a bug on gpg, but I don't have
-time right now.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-every sync (without --content) to a gcrypt remote uploads huge amount of data (>100MB) when doing
-
- gcrypt: Requesting manifest signature
-
-It seems to upload a special git object every time, even if this object is apparently unchanged. An unencrypted, regular git remote is much faster and does not transfer such amounts of data.
-
-I wonder if this can be changed, because it renders that gcrypt remote almost unusable via ADSL upstream. In my case the sync duration was 36 Minutes, uploading ~250MB.
-
-### What steps will reproduce the problem?
-
-Have a (bare) gcrypt remote and a rather big (mine has 77668 keys, annexing 769GB of files) git-annex repository. Sync with the gcrypt remote. When pushing, the message "gcrypt: Requesting manifest signature" appears, and a very large amount of data is transferred to the remote, while the process chain
-
- git-remote-gcrypt mygcrypt ssh://mygcrypt/home/my/annex
- git push --quiet -f ssh://mygcrypt/home/my/annex refs/gcrypt/gitception+:refs/heads/master
- ssh mygcrypt git-receive-pack '/home/my/annex'
- git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset -q
-
-is running. The upload of the actual changeset starts after this, the processes look the same, transferring again a more or less big amount of data (depending on the changeset size, I guess).
-
-### What version of git-annex are you using? On what operating system?
-
-6.20170101-1 on Debian Stretch (9.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)
-
-git-annex is great and revolutionized my file organization and backup structure (if they were even existing before)
-
-[[!meta title="gcrypt special remotes should support rsync:// and perhaps also sftp://"]]
-
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 10"""
- date="2021-03-09T18:10:38Z"
- content="""
-Actually, it supports rsync urls already. But git-annex treats the url as
-literally the rsync protocol, so it will run rsync with an url like
-rsync://localhost/foo. Which will mostly fail unless there's actually a
-rsync server running.
-git-remote-gcrypt treats the same url as rsync over ssh.
-
-See [[!commit 3e079cdcd1ac4f52ceb1c3ad483917d7c6133d0b]] for when that was
-added in 2013. Although I'm doubtful if it actually worked; it seems like
-initremote supported it, but it was never implemented the rest of
-the way.
-
-If anyone has been using that, it seems git-annex and git-remote-gcrypt
-would be accessing the server in different ways, so the same server must
-support rsync over ssh too, or git pushes to the remote would fail. So, it
-seems all that's needed is for git-annex to treat that url as rsync over
-ssh, and finish the incomplete implementation of rsync urls.
-
-Ok, done!
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2017-04-05T15:44:47Z"
- content="""
-I don't think this is a bug in git-annex. That is the behavior of
-`git-remote-gcrypt`. Could you please file a bug on that program instead?
-
-(I've also wondered about this; it could be that it's re-uploading the
-manifest every time for good security reasons, or it could be that a better
-file structure would allow more incremental uploads. It certianly
-seems like it could avoid re-uploading when nothing has changed!)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="git-annex@6f13b739194f758abc0b86556b7ce966c1bf3c00"
- nickname="git-annex"
- avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6"
- subject="git-remote-gcrypt recommends rsync:// or sftp:// transports"
- date="2017-04-05T16:16:25Z"
- content="""
-spwhitton says on <https://github.com/spwhitton/git-remote-gcrypt>:
-
-> \"Using an arbitrary <giturl> requires uploading the entire repository history with
-> each push. If your repository history is large or you are pushing over a slow link, consider using
-> either the rsync:// or sftp:// transports, which perform incremental pushes\"
-
-So it's a known performance. Would be great if rsync:// could be used when combining git-annex with
-git-remote-gcrypt?
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2017-04-05T18:35:30Z"
- content="""
-It should be possible for git-annex to support rsync:// for gcrypt special
-remotes; that would just need to reuse the rsync special remote for the
-git-annex objects. Retitling this bug report appropriately.
-
-In the meantime, it should work to set up a gcrypt git remote (not a
-git-annex special remote) using rsync:// or sftp:// and then use a
-git-annex rsync special remote on the same server to store the annex
-objects.
-
-But that doesn't help with large pushes to gcrypt remotes
-when git hosting providers are being used, which is a main
-use case for using gcrypt (though generally not the gcrypt special remote).
-The lack of incrementals there seems like something worth finding a way to
-fix in gcrypt.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 4"
- date="2017-04-05T22:28:10Z"
- content="""
-git-remote-gcrypt maintainer here.
-
-As Joey recommends for the meantime, I am successfully using an `rsync://` gcrypt remote plus a separate encrypted git-annex rsync remote to work around these performance issues.
-
-git-remote-gcrypt relies on rsync to implement the incremental upload, so the README is wrong to suggest that using an `sftp://` remote would work around this issue -- git-remote-gcrypt invokes curl for the sftp transaction, which as far as I know does nothing incremental (that's presumably why rsync exists). I've just updated the README.
-
-If we wanted the gitception gcrypt remote to be incremental, we would need to implement rsync-like incremental uploads on top of the structure of git commits, such that we could push a git commit that represents the changes to the gcrypt packfiles and manifest since the previous commit. But I don't think this is possible for binary files -- I don't think git can represent the deltas efficiently.
-
-I've come to think that git-remote-gcrypt's gitception mode is not actually very useful, simply due to the design of git. But perhaps there is an alternative way to represent the manifest and packfiles that would be compatible with incremental git pushes.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="woffs"
- avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6"
- subject="comment 5"
- date="2017-04-06T07:29:14Z"
- content="""
-I remember having tried this (gcrypt rsync:// git remote + rsync encrypted git-annex specialremote) but I was disappointed because git-annex-sync does not pull/push the git remote and I had to do this separately every time.
-
-Anyway, thank you for caring. :-)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="woffs"
- avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6"
- subject="comment 6"
- date="2017-04-06T08:28:06Z"
- content="""
-I was wrong. git-annex-sync DOES pull/push to the gcrypt rsync remote. So seems fine. Thank you. :)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="gcrypt, git-annex and rsync requires absolute path"
- date="2017-12-05T13:49:42Z"
- content="""
-I struggled to get git-annex sync working for some time with gcrypt and the rsync transport protocol. It turns out I was using a relative path to my repo instead of an absolute path. In my .git/config with a url like this: `gcrypt::rsync://username@servername:relative-path-to-git-repo` where relative path is relative to my user's home directory, git push would work fine, but git-annex sync would complain it couldn't find the repository. Changing my url to an absolute path like `gcrypt::rsync://username@servername:absolute-path-to-git-repo` now allows both git-annex sync and git push to work. Andrew.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="git-annex.branchable.com@79d6855760f61f7fbe0a401b45d8c791ef49b500"
- nickname="git-annex.branchable.com"
- avatar="http://cdn.libravatar.org/avatar/4bf61f9feda20e8b4fc09d52ee48af39"
- subject="comment 8"
- date="2020-08-02T23:41:32Z"
- content="""
-Is it possible to convert an existing `gcrypt::ssh://host/path` gcrypt special remote to one on top of rsync transport protocol to work around these performance issues? The existing remote is obviously quite large, and re-uploading the content would take a very long time.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 9"""
- date="2020-08-10T16:55:36Z"
- content="""
-You can just change the url of the remote in .git/config. And `git-annex
-enableremote` can be used to change the gitrepo parameter stored there.
-
-But, git-annex will not be able to use the remote once you switch it to
-rsync, since it does not yet support gcrypt over rsync. That is what this
-bug report is open waiting to be implemented.
-"""]]
+++ /dev/null
-### Please describe the problem.
-git-remote-gcrypt supports repositories using the rsync:// protocol, but translates these into accessing rsync over SSH. When git-annex sees such a repository, it retains the rsync:// URL, which the rsync program interprets as contacting an rsync daemon. Usually the destination host is not running an rsync daemon and shouldn't be; SSH is the correct way to access rsync for this use case. For rsync to use rsync-over-SSH, the URL passed to rsync should be of the form user@host:path, rather than rsync://user@host/path. However, specifying rsync://user@host/path is necessary for git-remote-gcrypt to use the rsync transport, which is also basically necessary for decent performance on large repositories.
-
-### What steps will reproduce the problem?
-1. Create a new gcrypt repository using the rsync:// transport: `git annex initremote encryptedrepo type=gcrypt gitrepo=rsync://my.server/home/me/encryptedrepo keyid=$mykey`
-2. watch as it spews dumb errors rather than doing the right thing
-
-### What version of git-annex are you using? On what operating system?
-```
-$ git annex version
-git-annex version: 8.20210223-gd670346b2
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.4 http-client-0.7.6 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-### 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
-
-tom@breitenfeld:~/bigdata$ git annex --verbose --debug initremote gnubee type=gcrypt gitrepo=rsync://archive@gnubee/data2/bigdata keyid='bigdata annex'
-[2021-03-08 11:20:28.43570846] process [1836653] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
-[2021-03-08 11:20:28.437076646] process [1836653] done ExitSuccess
-[2021-03-08 11:20:28.437336263] process [1836654] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
-[2021-03-08 11:20:28.438352774] process [1836654] done ExitSuccess
-[2021-03-08 11:20:28.485166314] process [1836655] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..c672ed2317b98c1032999289ec4e1b183929c456","--pretty=%H","-n1"]
-[2021-03-08 11:20:28.486558553] process [1836655] done ExitSuccess
-[2021-03-08 11:20:28.486818678] process [1836656] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..ebf2e73c12961f885263f6c8db6c1f8441c867f1","--pretty=%H","-n1"]
-[2021-03-08 11:20:28.488292936] process [1836656] done ExitSuccess
-[2021-03-08 11:20:28.488737925] process [1836657] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
-[2021-03-08 11:20:28.48889119] process [1836658] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
-initremote gnubee (encryption setup) [2021-03-08 11:20:28.494908908] process [1836659] read: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--with-colons","--list-public-keys","bigdata annex"]
-[2021-03-08 11:20:28.502271475] process [1836659] done ExitSuccess
-[2021-03-08 11:20:28.502611678] process [1836660] read: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--gen-random","--armor","2","512"]
-[2021-03-08 11:20:28.532237247] process [1836660] done ExitSuccess
-[2021-03-08 11:20:28.532645683] process [1836661] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--recipient","BDF1CB2C01162329","--encrypt","--no-encrypt-to","--no-default-recipient","--force-mdc","--n
-o-textmode"]
-[2021-03-08 11:20:28.538503457] process [1836661] done ExitSuccess
-(to gpg keys: BDF1CB2C01162329) [2021-03-08 11:20:28.538836053] process [1836662] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","remote","add","gnubee","gcrypt::rsync://archive@gnubee/data2/bigdata"]
-[2021-03-08 11:20:28.541052772] process [1836662] done ExitSuccess
-[2021-03-08 11:20:28.541416821] process [1836663] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","remote.gnubee.gcrypt-participants","BDF1CB2C01162329"]
-[2021-03-08 11:20:28.542184041] process [1836663] done ExitSuccess
-[2021-03-08 11:20:28.542323969] process [1836664] read: git ["config","--null","--list"]
-[2021-03-08 11:20:28.542984011] process [1836664] done ExitSuccess
-[2021-03-08 11:20:28.543292096] process [1836665] read: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--with-colons","--list-secret-keys","--fixed-list-mode"]
-[2021-03-08 11:20:28.594671548] process [1836665] done ExitSuccess
-[2021-03-08 11:20:28.594934831] process [1836667] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","remote.gnubee.gcrypt-signingkey","BDF1CB2C01162329"]
-[2021-03-08 11:20:28.595815576] process [1836667] done ExitSuccess
-[2021-03-08 11:20:28.596017072] process [1836668] read: git ["config","--null","--list"]
-[2021-03-08 11:20:28.59666746] process [1836668] done ExitSuccess
-[2021-03-08 11:20:28.597098155] process [1836669] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","remote.gnubee.gcrypt-publish-participants","true"]
-[2021-03-08 11:20:28.597876696] process [1836669] done ExitSuccess
-[2021-03-08 11:20:28.598024485] process [1836670] read: git ["config","--null","--list"]
-[2021-03-08 11:20:28.598652173] process [1836670] done ExitSuccess
-[2021-03-08 11:20:28.598794394] process [1836671] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","fetch","gnubee"]
-gcrypt: Decrypting manifest
-gpg: Signature made Mon 08 Mar 2021 11:18:04 AM MST
-gpg: using RSA key 06EA8DF161EE4445B95E4560BDF1CB2C01162329
-gpg: Good signature from "bigdata annex <tom@tomhunt.email>" [ultimate]
-gcrypt: Remote ID is :id:wAwSE2kqUs9HLuq1usaP
-From gcrypt::rsync://archive@gnubee/data2/bigdata
- * [new branch] synced/git-annex -> gnubee/synced/git-annex
- * [new branch] synced/master -> gnubee/synced/master
- * [new branch] master -> gnubee/master
- * [new branch] git-annex -> gnubee/git-annex
-[2021-03-08 11:20:35.683175088] process [1836671] done ExitSuccess
-[2021-03-08 11:20:35.683408275] process [1836914] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","gnubee","refs/heads/git-annex"]
-gcrypt: Decrypting manifest
-gpg: Signature made Mon 08 Mar 2021 11:18:04 AM MST
-gpg: using RSA key 06EA8DF161EE4445B95E4560BDF1CB2C01162329
-gpg: Good signature from "bigdata annex <tom@tomhunt.email>" [ultimate]
-Everything up-to-date
-[2021-03-08 11:20:39.0774672] process [1836914] done ExitSuccess
-[2021-03-08 11:20:39.077675135] process [1837131] read: git ["config","--null","--list"]
-[2021-03-08 11:20:39.078358634] process [1837131] done ExitSuccess
-[2021-03-08 11:20:39.079257145] process [1837132] call: rsync ["-e","'ssh' '-S' '.git/annex/ssh/rsync' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T'","rsync://archive@gnubee/data2/bigdata/config",".git/annex/tmp/rsynctmp.0/con
-fig"]
-rsync error: syntax or usage error (code 1) at clientserver.c(1223) [Receiver=3.2.3]
-rsync: did not see server greeting
-rsync error: error starting client-server protocol (code 5) at main.c(1814) [Receiver=v3.2.3]
-[2021-03-08 11:20:40.410745083] process [1837132] done ExitFailure 5
-
-git-annex: Failed to connect to remote to set it up.
-failed
-[2021-03-08 11:20:40.999149788] process [1837170] read: ssh ["-O","stop","-S","rsync","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
-[2021-03-08 11:20:41.001923533] process [1837170] done ExitSuccess
-[2021-03-08 11:20:41.002479963] process [1836657] done ExitSuccess
-[2021-03-08 11:20:41.002660104] process [1836658] done ExitSuccess
-git-annex: initremote: 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)
-
-git-annex is a wonderful thing that works wonderfully, so long as you're using normal SSH or directory remotes
-
-> There is already a bug about this,
-> [here](https://git-annex.branchable.com/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/)
-> [[done]] --[[Joey]]
->
+++ /dev/null
-### Please describe the problem.
-I'm trying to set up a gcrypt remote using the rsync backend because it can do incremental pushes. I know I won't be able to put annexed files on this remote, but even with `annex-ignore` set, the error arises.
-
-### What steps will reproduce the problem?
-[[!format sh """
-% git remote add cryptremote gcrypt::rsync://host:repo
-% git annex sync cryptremote
-
-"""]]
-
-### What version of git-annex are you using? On what operating system?
-6.20181011-g426f0f3f4 on Arch Linux
-
-### Please provide any additional information below.
-
-[[!format sh """
-git-annex: bad url rsync://host:repo
-CallStack (from HasCallStack):
- error, called at ./Git/Construct.hs:101:15 in main:Git.Construct
-
-"""]]
-
--- Lykos
-
-> Closing as
-> <https://git-annex.branchable.com/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/>
-> is a later discussion of this with more detail about why it should be
-> supported. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="andrew"
- avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
- subject="comment 1"
- date="2018-11-01T12:02:59Z"
- content="""
-I was [never able to get relative path's to my repo working with the gcrypt remote and rsync](http://git-annex.branchable.com/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/#comment-9aebc8b168c58568c668f91bd6b19d11). Have you tried entering an absolute path instead of just `repo`?
-
-"""]]
+++ /dev/null
-Creating a gcrypt remote on a remote bare repository fails: it tries to modify the config file in the wrong path:
-
-(problem is in last line)
-
-```
-$ git annex initremote qech type=gcrypt encryption=hybrid gitrepo=~/astro.git keyid=0BA74AC5B9494715
-initremote qech (encryption setup) (hybrid cipher with gpg key 0BA74AC5B9494715) gcrypt: Development version -- Repository format MAY CHANGE
-gcrypt: Decrypting manifest
-gpg: Signature made Son 13 Sep 2015 19:37:16 CEST using RSA key ID B9494715
-gpg: Good signature from "Arian Sanusi <arian@sanusi.ch>"
-gpg: aka "Arian Sanusi <arian@sanusi.de>"
-gpg: aka "Arian Sanusi <asanusi@student.ethz.ch>"
-gpg: aka "Arian Sanusi <arian@guave.org>"
-gpg: aka "Arian Sanusi <asanusi@ethz.ch>"
-gpg: aka "Arian Sanusi <arian@semioptimal.net>"
-gcrypt: Remote ID is :id:1+DP8KgrbsvpSycQ5QKO
-Von gcrypt::/home/arian-debian-ssd/astro
- * [neuer Branch] git-annex -> qech/git-annex
-gcrypt: Development version -- Repository format MAY CHANGE
-gcrypt: Decrypting manifest
-gpg: Signature made Son 13 Sep 2015 19:37:16 CEST using RSA key ID B9494715
-gpg: Good signature from "Arian Sanusi <arian@sanusi.ch>"
-gpg: aka "Arian Sanusi <arian@sanusi.de>"
-gpg: aka "Arian Sanusi <asanusi@student.ethz.ch>"
-gpg: aka "Arian Sanusi <arian@guave.org>"
-gpg: aka "Arian Sanusi <asanusi@ethz.ch>"
-gpg: aka "Arian Sanusi <arian@semioptimal.net>"
-Everything up-to-date
-error: could not lock config file /home/arian-debian-ssd/astro.git/.git/config: Datei oder Verzeichnis nicht gefunden
-git-annex: git [Param "config",Param "core.gcrypt-id",Param ":id:1+DP8KgrbsvpSycQ5QKO"] failed
-```
-
-debian stretch *pre gcc5* on amd64 here:
-
-```
-i git 1:2.5.1-1 amd64
-ii git-annex 5.20150812-2 amd64
-ii git-remote-gcrypt 0.20130908-7 all
-```
-
-> I've improved the docs to mention that the git repo for the remote needs
-> to already exist before initremote. I don't think it's necessary or
-> really a good idea for initremote to create it. So, [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-09-18T16:56:42Z"
- content="""
-So, the missing bit of data needed to reproduce this is that
-~/astro.git didn't exist at all before this initremote call.
-
-If you `git init --bare ~/astro.git` first, it works fine.
-
-The documentation says, of gitrepo:
-
- This repository should be either empty, or an existing gcrypt repositry.
-
-So, I don't know if this is really a bug, you're not doing what the
-documentation says to do.
-
-I suppose git-annex initremote could create a bare repository when none exists
-in this case, but it would then have to parse the gitrepo parameter, normalize
-it, use the approptiate protocol (file, ssh, rsync) to check if it exists or
-create it, etc, instead of simply passing it to gcrypt.
-
-(What is actually going on here is, gcrypt supports remotes that are not git repositories at all.
-When the repo doesn't exist, it assumes such a remote is wanted and makes one.
-But, git-annex does not support working with that kind of gcrypt remote.)
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-So this happened today: I did a `git-annex sync --content` over a git repository that is *also* (sorry!) synchronized by syncthing. Not the best idea, I know, but I *do* avoid synchronizing the `.git` directory to avoid going completely nuts. This has actually worked surprisingly well so far: I can add stuff in one repository and it trickles to the other either with syncthing (on my ebook reader, which doesn't have git-annex) or git-annex (on my other desktops).
-
-What happened here is that syncthing was faster than git-annex and copied the files over first. For new files, that wasn't much of a problem: git freaked out, but just skipped the files; I didn't get corruption on that front.
-
-For calibre's infamous `metadata.db`, however, it was another story. I ended up in this weird state where it found a conflict on the file, because it is binary:
-
- warning: Cannot merge binary files: metadata.db (HEAD vs. refs/remotes/origin/master)
-
-So it left a `metadata.variant-1b96.db` file around. But the interesting thing here (and why I open a bug report instead of just moving on) is that the variant is actually *identical* to the other file:
-
- anarcat@curie:books(master)$ ls -al metadata*db
- -rw-r--r-- 1 anarcat anarcat 1 696 768 2021-09-07 09:40 metadata.db
- -rw-r--r-- 1 anarcat anarcat 1 696 768 2021-09-05 21:39 metadata.variant-1b96.db
- anarcat@curie:books(master)$ diff metadata*db
- anarcat@curie:books(master)$
-
-Now I understand git-annex wants to be careful about merging binary data, but surely this is a low-hanging fruit that could be figured out?
-
-Similarly, the already present file could be merged as well, but I understand that this is also a hard problem in git itself: it doesn't like dirty work trees...
-
-And I understand if this entire thing would be closed as "ugh, sorry, this is how git works, #wontfix", of course. :) I'm kind of doing crazy stuff with git-annex all the time and I understand if this won't be fixed, I can deal with the occasional trouble...
-
-### What steps will reproduce the problem?
-
-It's not exactly clear to me how to reproduce this. I think the trick is to:
-
- 1. create a git-annex repository (A) with some content
- 2. synchronize it to a new, second repository (B)
- 3. create a binary file, on repo A
- 4. synchronize it on repo B, once
- 5. modify the binary file on repo A
- 6. copy it by hand, behind git-annex's back, to repo B
- 7. synchronize both repos again
-
-I suspect you might be able to reproduce the issue without binary files with:
-
- 1. create a git-annex repository (A) with some content
- 2. synchronize it to a new, second repository (B)
- 3. create a new file, on repo A
- 4. copy it by hand, behind git-annex's back, to repo B
- 5. synchronize both repos again
-
-### What version of git-annex are you using? On what operating system?
-
-This is git-annex 8.20210223-2 on Debian bullseye, on both ends. Syncthing is running on both ends as well, and on my Kobo Clara HD e-reader.
-
-### Please provide any additional information below.
-
-This is the first crash, which occured under `myrepos` supervision:
-
-[[!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
-mr update: /home/anarcat/books
-(recording state in git...)
-[master 29a49c9c48] git-annex in anarcat@curie:~/books
- 1 file changed, 0 insertions(+), 0 deletions(-)
- rewrite metadata.db (100%)
-commit ok
-remote: Enumerating objects: 103, done.
-remote: Counting objects: 100% (103/103), done.
-remote: Compressing objects: 100% (80/80), done.
-remote: Total 83 (delta 48), reused 0 (delta 0)
-Dépaquetage des objets: 100% (83/83), 11.26 Kio | 23.00 Kio/s, fait.
-Depuis anarc.at:/srv/books
- 2a75cab2ba..b368a4b963 master -> origin/master
- 3ddac40b17..f59c826035 git-annex -> origin/git-annex
- 3ddac40b17..b46273adfc synced/git-annex -> origin/synced/git-annex
- 2a75cab2ba..b368a4b963 synced/master -> origin/synced/master
-error: Les fichiers suivants non suivis de la copie de travail seraient effacés par la fusion :
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/Medicine for Mountaineering & Other Wilder - James A. Wilkerson.epub
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/cover.jpg
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/metadata.opf
-Veuillez renommer ou effacer ces fichiers avant la fusion.
-Abandon
-error: Les fichiers suivants non suivis de la copie de travail seraient effacés par la fusion :
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/Medicine for Mountaineering & Other Wilder - James A. Wilkerson.epub
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/cover.jpg
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/metadata.opf
-Veuillez renommer ou effacer ces fichiers avant la fusion.
-Abandon
-pull origin failed
-(merging origin/git-annex origin/synced/git-annex into git-annex...)
-(recording state in git...)
-error: Les fichiers suivants non suivis de la copie de travail seraient effacés par la fusion :
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/Medicine for Mountaineering & Other Wilder - James A. Wilkerson.epub
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/cover.jpg
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/metadata.opf
-Veuillez renommer ou effacer ces fichiers avant la fusion.
-Abandon
-error: Les fichiers suivants non suivis de la copie de travail seraient effacés par la fusion :
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/Medicine for Mountaineering & Other Wilder - James A. Wilkerson.epub
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/cover.jpg
- James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/metadata.opf
-Veuillez renommer ou effacer ces fichiers avant la fusion.
-Abandon
-copy metadata.db (to origin...) ok
-pull origin failed
-(recording state in git...)
-push origin
-Énumération des objets: 23, fait.
-Décompte des objets: 100% (21/21), fait.
-Compression par delta en utilisant jusqu'à 4 fils d'exécution
-Compression des objets: 100% (15/15), fait.
-Écriture des objets: 100% (15/15), 1.94 Kio | 1.94 Mio/s, fait.
-Total 15 (delta 6), réutilisés 0 (delta 0), réutilisés du pack 0
-remote: PWD: /srv/books/.git
-remote: running git annex merge in /srv/books
-remote: Already up to date.
-remote: calling /srv/books/.git/hooks/calibre-hack
-remote: running /srv/books/.git/hooks/calibre-hack
-remote: fixing perms for calibre
-remote: + chown :media metadata.calibre metadata.db metadata_db_prefs_backup.json
-remote: + chmod g+w metadata.calibre metadata.db metadata_db_prefs_backup.json
-remote: + sudo service calibre-server restart
-To anarc.at:/srv/books
- b46273adfc..de2a69481a git-annex -> synced/git-annex
- ! [rejected] master -> synced/master (non-fast-forward)
-error: impossible de pousser des références vers 'anarc.at:/srv/books'
-astuce: Les mises à jour ont été rejetées car la pointe de la branche courante est derrière
-astuce: son homologue distant. Extrayez cette branche et intégrez les changements distants
-astuce: (par exemple 'git pull ...') avant de pousser à nouveau.
-To anarc.at:/srv/books ! [rejected] master -> master (non-fast-forward)error: impossible de pousser des références vers 'anarc.at:/srv/books'astuce: Les mises à jour ont été rejetées car la pointe de la branche courante est derrièreastuce: son homologue distant. Intégrez les changements distants (par exemple 'git pull ...')astuce: avant de pousser à nouveau.astuce: Voir la 'Note à propos des avances rapides' dans 'git push --help' pour plus d'information.push origin
- Pushing to origin failed.
-failed
-git-annex: sync: 3 failed
-mr update: command failed
-
-
-# End of transcript or log.
-"""]]
-
-Notice the mojibake in the french. It seems like the `é` characters are getting double-encoded. `LANG=fr_CA.UTF-8`. But that's another story. ;)
-
-Also note that the `metadata.db` here is not yet corrupt. That happened on the second run:
-
-[[!format sh """
-anarcat@curie:books(master)$ git annex sync --content -J2
-Sur la branche master
-Votre branche et 'origin/master' ont divergé,
-et ont 1 et 2 commits différents chacune respectivement.
- (utilisez "git pull" pour fusionner la branche distante dans la vôtre)
-
-Fichiers non suivis:
- (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)
- .stversions/
-
-aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)
-commit ok
-remote: Enumerating objects: 9, done.
-remote: Counting objects: 100% (9/9), done.
-remote: Compressing objects: 100% (5/5), done.
-remote: Total 5 (delta 3), reused 0 (delta 0)
-Dépaquetage des objets: 100% (5/5), 441 octets | 73.00 Kio/s, fait.
-Depuis anarc.at:/srv/books
- de2a69481a..f5fc20c433 git-annex -> origin/git-annex
-warning: Cannot merge binary files: metadata.db (HEAD vs. refs/remotes/origin/master)
-Fusion automatique de metadata.db
-CONFLIT (contenu) : Conflit de fusion dans metadata.db
-La fusion automatique a échoué ; réglez les conflits et validez le résultat.
-pull origin (recording state in git...)
-
- Merge conflict was automatically resolved; you may want to examine the result.
-[master 01adc3214c] git-annex automatic merge conflict fix
-Déjà à jour.
-ok
-(merging origin/git-annex into git-annex...)
-get James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/cover.jpg (from origin...) ok
-get James A. Wilkerson/Medicine for Mountaineering & Other Wilderness Activities (1583)/Medicine for Mountaineering & Other Wilder - James A. Wilkerson.epub (from origin...) ok
-pull origin ok
-(recording state in git...)
-push origin
-Énumération des objets: 22, fait.
-Décompte des objets: 100% (22/22), fait.
-Compression par delta en utilisant jusqu'à 4 fils d'exécution
-Compression des objets: 100% (13/13), fait.
-Écriture des objets: 100% (13/13), 2.08 Kio | 2.08 Mio/s, fait.
-Total 13 (delta 7), réutilisés 0 (delta 0), réutilisés du pack 0
-remote: PWD: /srv/books/.git
-remote: running git annex merge in /srv/books
-remote: Updating b368a4b96..01adc3214
-remote: Fast-forward
-remote: metadata.variant-1b96.db | 1 +
-remote: 1 file changed, 1 insertion(+)
-remote: create mode 100644 metadata.variant-1b96.db
-remote: running .git//hooks/calibre-hack
-remote: fixing perms for calibre
-remote: + chown :media metadata.calibre metadata.db metadata.variant-1b96.db metadata_db_prefs_backup.json
-remote: + chmod g+w metadata.calibre metadata.db metadata.variant-1b96.db metadata_db_prefs_backup.json
-remote: + sudo service calibre-server restart
-remote: calling /srv/books/.git/hooks/calibre-hack
-remote: running /srv/books/.git/hooks/calibre-hack
-remote: fixing perms for calibre
-remote: + chown :media metadata.calibre metadata.db metadata.variant-1b96.db metadata_db_prefs_backup.json
-remote: + chmod g+w metadata.calibre metadata.db metadata.variant-1b96.db metadata_db_prefs_backup.json
-remote: + sudo service calibre-server restart
-To anarc.at:/srv/books
- de2a69481a..34a3c2ebf1 git-annex -> synced/git-annex
-push origin 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)
-
-I am a total fan, thanks for your awesome work, as usual. ;) -- [[anarcat]]
-
-> [[notabug|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-09-08T15:56:35Z"
- content="""
-The french output is by git, not git-annex. It looks like the standard
-message about there being a merge conflict. One part of the git
-output is not translated and it happens to be the part that explains
-what is going on.
-
- warning: Cannot merge binary files: metadata.db (HEAD vs. refs/remotes/origin/master)
-
-So metadata.db is a binary file, so it is not stored in git-annex,
-but is checked directly into git. Or at least it is on one side of
-the merge conflict.
-
-I think that one repository added metadata.db to git-annex, and the other
-added it to directly into git. So then the merge conflict is between
-the binary content of the file and the git-annex symlink. Which is an
-actual merge conflict, even though the content of the file is the same.
-
-That kind of merge conflict is when `git-annex sync` resolves the merge
-conflict with a single `.variant` file for the annexed version along side the
-regular file as stored in git. Which is what your ls showed.
-You can resolve the merge conflict by either deleting the annexed
- `.variant` file or renaming it over the file stored in git.
-
-You can avoid this kind of merge conflict by configuring annex.largefiles
-the same in both repositories, so when a file like metadata.db gets added
-separately in each repository, the same annex link will be added.
-
-Or you can set annex.resolvemerge to false for sync to avoid resolving merge
-conflicts, and then just resolve them yourself.
-
-I don't see a bug here, this is all documented.
-"""]]
+++ /dev/null
-Hi Joey,
-
-
-### Please describe the problem.
-`git annex fromkey` on Windows fails with `git-annex: System.PosixCompat.Files.createSymbolicLink: not supported: illegal operation`
-
-I guess it should create a unlocked file instead on Windows.
-
-### What steps will reproduce the problem?
-
- mkdir test
- cd test
- git init
- git annex init test
- touch file
- git annex add file
- git annex sync
- git annex fromkey SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 file2
-
-### What version of git-annex are you using? On what operating system?
-git version 2.31.1.windows.1 <br>
-git annex 8.20210331-g1fb59a63a <br>
-Windows 10 Pro 1903 <br>
-
-### 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 really great and there is nothing else like it.
-
-> [[fixed|done]] by making it create an unlocked file when used on an
-> unlocked adjusted branch. --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-`git-annex-fsck --all` fails when a key marked as [[dead|git-annex-dead]] is missing from a remote set to [[require|git-annex-required]] all content.
-
-### What steps will reproduce the problem?
-
-
-### What version of git-annex are you using? On what operating system?
-
-[[!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
-(ga-env) ~/ilya-quest/ancestry/tagsnps [02:53:06]$ git annex version
-git-annex version: 8.20210224-gf951847c6
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.\
-1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 BLAKE\
-2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE\
-2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E\
- MD5 WORM URL X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso bor\
-g hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-(ga-env) ~/ilya-quest/ancestry/tagsnps [02:55:11]$ uname -a
-Linux job-G190bQQ0JKFvFvX7KFXZ037g 4.4.0-1122-aws #136-Ubuntu SMP Tue Feb 16 22:44:38 UTC 2021 x86_64 x86_64 x86_64 G\
-NU/Linux
-
-# End of transcript or log.
-"""]]
-
-### 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)
-
-Thanks again for git-annex, I keep finding new uses for it.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-03-22T18:47:00Z"
- content="""
-Your transcript does not show the bug, but I was able to reproduce it eventually.
-
- # git annex required here anything
- # git annex add foo
- # git annex drop --force foo
- # git rm foo
- # git annex fsck --all
- fsck SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
- ** No known copies exist of SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
-
- (Avoid this check by running: git annex dead --key )
- # git-annex dead --key SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
- # git annex fsck --all
- fsck SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
- This key is dead, skipping.
- ok
- #
-
-So far this is operating as expected. But then clone this repo to another
-one, and in the other one:
-
- # git annex fsck --all --from origin
- fsck SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
- ** Required content SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is missing from these repositories:
- 56b59085-83b0-4b98-82c3-1baacd93d3e2 -- joey@darkstar:/tmp/test [origin]
-
- This key is dead, skipping.
- failed
- (recording state in git...)
- git-annex: fsck: 1 failed
-
-So fsck --from --all is verifying required content when it should not,
-because a) matching required content with --all mostly doesn't make sense
-(considering things like "include=" can be in it and can't be matched)
-and b) it's not done without --all.
-
-(I don't think dead keys are actually involved, I mean if a particular file
-is set as required content of a repo, and is not present in it, fsck should
-complain about that, even if the key is dead.)
-"""]]
+++ /dev/null
-git-annex-import currently refuses to import any files under the repo dir, saying to use git-add instead. I think it should treat git-ignored files as if they were outside the repo. I often have a dir under the repo that is gitignored, and acts as a temp work area; git-annex-import should treat the files there as if they were outside the repo.
-
-> git-annex import --no-check-gitignore option implemented [[done]]
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-03-18T17:20:11Z"
- content="""
-I don't think this is a bug, at best it's a wishlist todo.
-
-I'm reluctant to complicate git-annex import with this unusual use case,
-when `git annex add --force`, or renaming the files to the desired
-non-gitignored location and `git annex add` work just fine.
-"""]]
+++ /dev/null
-### Please describe the problem.
-brew/cabal fails to build git-annex 8.20210330 on macOS
-
-cabal errors out with (full log [here](https://github.com/Homebrew/homebrew-core/pull/74213/checks?check_run_id=2231233411#step:7:1547)):
-
-```
-Database/Handle.hs:257:20: error:
- Variable not in scope: askLogFunc :: m LogFunc
- |
-257 | logFunc <- askLogFunc
- | ^^^^^^^^^^
-cabal: Failed to build git-annex-8.20210330. See the build log above for
-details.
-```
-
-
-
-### What steps will reproduce the problem?
-```
-# brew install --verbose --build-bottle git-annex
-```
-
-### What version of git-annex are you using? On what operating system?
-macOS 10.15.7
-
-### 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)
-
-git-annex has been great helping us "version control" a myriad of LARGE binary assets (from VM and FS snapshots, to archives, to deliverable content)
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-04-01T16:04:56Z"
- content="""
-A quick fix is to pin the haskell library persistent to a version older
-than 2.12.0.1, which is the new version that broke the build. An easy way
-to do that is to build using stack, which automatically pins all library
-dependencies to known-working versions. By building with cabal you
-choose to help me learn about new breakage the hard way, which is
-appreciated if it is your intent. ;)
-
-I've fixed this in master.
-"""]]
+++ /dev/null
-If the journal contains a newer version of a log file than the git-annex
-branch, and annex.alwayscommit=false so the branch is not getting updated,
-the value from the journal can be ignored when reading that log file.
-
-In CmdLine.Seek, there is some code that precaches location logs as an
-optimisation (when using eg --copies). That streams info from the
-git-annex branch into the cache. But it never checks for a journal file
-with newer information.
-
-> fixed this
-
-Also in Cmdline.Seek, there is a LsTreeRecursive over the branch to handle
-`--all`, and I think again that would mean it doesn't notice location
-logs that are only in the journal.
-Before that optimisation, it was using Logs.Location.loggedKeys,
-which does look at the journal.
-
-> fixed
-
-(This is also a blocker for [[todo/hiding_a_repository]].)
-
-[[done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-git-annex info shows wrong remote sizes. This is fairly clearly visible as the list of remotes is ordered by size, but the reported size does not match the actual size for repositories which appear to have (nearly) exactly 2 TB. Apparently, git-annex rounds the integer places independently from the decimal places, and stumbles when rounding.
-
-
-### What steps will reproduce the problem?
-
-run `git annex info .` with remotes having nearly "unit-full" usage, as in, exactly 1 or 2 tb data
-
-### What version of git-annex are you using? On what operating system?
-
-git-annex 8.20200330-1~bpo10+1 on a Debian buster rpi4 arm64
-
-### Please provide any additional information below.
-
-[[!format sh """
-
-$ git annex info .
-directory: .
-local annex keys: 83900
-[...]
-repositories containing these files: 23
-[...]
- 2.04 TB: 00000000-0000-0000-0000-0redacted000 -- media30
- 2.03 TB: 00000000-0000-0000-0000-0redacted000 -- media21
- 1.1 TB: 00000000-0000-0000-0000-0redacted000 -- media39
- 1.1 TB: 00000000-0000-0000-0000-0redacted000 -- media29
- 1.99 TB: 00000000-0000-0000-0000-0redacted000 -- media45
- 1.99 TB: 00000000-0000-0000-0000-0redacted000 -- media20
- 1.98 TB: 00000000-0000-0000-0000-0redacted000 -- media46
-[...]
-$ git annex find --in media29 --format '${bytesize}\n' | awk '{i+=$1}END{printf "%i\n", i}'
-2147483647
-$ echo $[2147483647/1024.]
-2097151.9990234375
-$ echo $[2147483647/1024./1024]
-2047.9999990463257
-$ echo $[2147483647/1024./1024/1024]
-1.9999999990686774
-"""]]
-
-All remotes above sit on 2tb disk drives, which are filled as much as possible. For media39 and media29, apparently the integer places round downward, but the decimal places upwards, and then the rounded-to "1" which should increment the integer place, instead gets printed as decimal 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)
-
-
-Thank you for all your time creating and maintaining such a usefull software!
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-07-30T12:59:46Z"
- content="""
-I am confused by the output you show, because 2147483647 is not any number
-of terabytes. It is a couple of gigabytes. This makes me suspect you
-arrived at that number in some mistaken way.
-
-Also, when git-annex displays "TB", it's talking about TeraBytes, not
-TebiBytes (TiB). But your divisions by 1024 is calulating the latter, not the
-former. (Well, actually it's calculating gibibytes..)
-
-If there is a bug, it's presumably in Utility.HumanNumber.showImprecise,
-which does some tricky rounding of decimals.
-
-Here's a few simple tests:
-
- # ghci Utility/DataUnits.hs
- ghci> roughSize storageUnits True 1000000000000
- "1 TB"
- ghci> roughSize storageUnits True 1099511627776
- "1.1 TB"
-
-Those are the correct results for an even terabyte and a tebibyte,
-displayed as terabytes. Now trying the number you provided to see what
-git-annex info will display:
-
- ghci> roughSize storageUnits True 2147483647
- "2.15 GB"
-
-units confirms that is the correct value, after rounding the decimal:
-
- # units
- You have: 2147483647 bytes
- You want: gigabytes
- * 2.1474836
- / 0.46566129
-
-aIt's also almost exactly 2 gibibytes:
-
- You have: 2147483647 bytes
- You want: gibibytes
- * 2
- / 0.5
-
-The actual value is 1 byte less than 2, if I do my manual math correctly:
- 2^30*2 = 2147483648 = 2147483647+1
-
-Asking git-annex for the same using memoryUnits which are the SI units:
-
- ghci> roughSize memoryUnits False 2147483647
- "1.1 gibibytes"
-
-Well, this final result looks wrong, and indeed what's going on is
-similar to what you hypothesized:
-
- ghci> roughSize' memoryUnits False 10 2147483647
- "1.9999999991 gibibytes"
- ghci> showImprecise 10 1.9999999990686774
- "1.9999999991"
- ghci> showImprecise 2 1.9999999990686774
- "1.1"
- ghci> round 0.9999999990686774 * (10^2)
- 100
-
-So indeed showImprecise is forgetting to carry the 1.
-
-Excellent diagnosis, but next time, show your work. ;-)
-"""]]
+++ /dev/null
-### Please describe the problem.
-One of my annexes has duplicate entries in one of the older trees. This causes git-annex repair to attempt to repair it.
-
-### What version of git-annex are you using? On what operating system?
-6.20161027-g27d824e (standalone x86_64 tarball) on ArchLinux latest as of 29th of Oct 2016 x86_64.
-
-### Please provide any additional information below.
-
-[[!format sh """
-[0 zerodogg@firefly annexed]$ git annex version
-git-annex version: 6.20161027-g27d824e
-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: 6
-supported repository versions: 3 5 6
-upgrade supported from repository versions: 0 1 2 3 4 5
-operating system: linux x86_64
-[0 zerodogg@firefly annexed]$ git annex info
-repository mode: indirect
-trusted repositories: 0
-semitrusted repositories: 23
-# …snip
-untrusted repositories: 0
-transfers in progress: none
-available local disk space: 47.89 gigabytes (+500 megabytes reserved)
-local annex keys: 2300
-local annex size: 1.72 gigabytes
-annexed files in working tree: 2492
-size of annexed files in working tree: 1.89 gigabytes
-bloom filter size: 32 mebibytes (0.5% full)
-backend usage:
- SHA256E: 2492
-[0 zerodogg@firefly annexed]$ git fsck
-Checking object directories: 100% (256/256), done.
-error in tree 3818a8ea201197ed355aa87133a718afca7c4a49: duplicateEntries: contains duplicate file entries
-error in tree 255f43cff847013439117a3fc4cfa517a90f38cb: duplicateEntries: contains duplicate file entries
-error in tree 404b4124800ece4772296d1f7559d982d0bc4cbd: duplicateEntries: contains duplicate file entries
-Checking objects: 100% (334784/334784), done.
-Checking connectivity: 334784, done.
-[4 zerodogg@firefly annexed]$ git annex repair -d
-Running git fsck ...
-[2016-10-29 09:55:24.652234] read: git ["--version"]
-[2016-10-29 09:55:24.668729] process done ExitSuccess
-[2016-10-29 09:55:24.668879] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","fsck","--no-dangling","--no-reflogs"]
-[2016-10-29 09:55:34.306776] process done ExitFailure 4
-Unpacking all pack files.
-[2016-10-29 09:55:34.307446] call: mv ["-f",".git/objects/pack/pack-18d920ca3181f59af68dc6b0061ca2430884a9bb.pack","/tmp/packsFokxCF/pack-18d920ca3181f59af68dc6b0061ca243
-0884a9bb.pack1804289383846930886.tmp"]
-[2016-10-29 09:55:34.334238] process done ExitSuccess
-[2016-10-29 09:55:34.336992] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","unpack-objects","-r"]
-Unpacking objects: 100% (334784/334784), done.
-[2016-10-29 09:56:39.505888] process done ExitSuccess
-[2016-10-29 09:56:39.560473] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show","10c1cc2127a7be7cf3ce4a0d69ed53e4c375f888"]
-[2016-10-29 09:56:39.607717] process done ExitSuccess
-# ^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)
-I use it for everything, around 3TB of data at the moment. It is awesome.
-
-> [[fixed|done]], although the root cause of the problem is
-> [[git_fsck_duplicateEntries_errors_when_using_adjusted_branch]]
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-10-31T17:07:43Z"
- content="""
-This was supposed to be dealt with in version 6.20161027. But, I see now
-that the parser I thought was triggering on those missing object lines,
-was not really (`extractSha` does not match in this case because of the
-colon after the sha).
-
-Instead, the problem seems to be that `git fsck` is exiting nonzero. So it
-assumes that fsck is failing without printing out any shas, which is a
-condition that calls for repairs.
-
-About all I can think to do is, if fsck outputs "duplicateEntries" and
-no other lines at all, and exits nonzero, treat this as a success.
-This risks ignoring other reasons fsck might exit nonzero, but hopefully
-it would output something else in such a case. I've implemented this.
-
----
-
-I am interested in getting at the root cause of the problem of
-duplicate directory entries. It seems pretty likely to result from using
-adjusted branches.
-
-It would be useful to get more information about the trees that fsck
-is warning about; are they part of existing or past adjusted branches
-or not? Are they merge commits?
-
-(Previously: [[forum/how_to_disaster_recovery]])
-
-Leaving this bug open since we really need to get at the root cause of
-the problem.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="EskildHustvedt"
- avatar="http://cdn.libravatar.org/avatar/0be1310904ded29624b9edb4824d451b"
- subject="comment 2"
- date="2016-11-04T07:34:30Z"
- content="""
-Ok, first off, the latest release no longer wants to release, so at least the symptom is fixed.
-
-Here's a quick look at the problem:
-
-[[!format sh \"\"\"
-[0 zerodogg@firefly annexed]$ git fsck
-Checking object directories: 100% (256/256), done.
-error in tree 3818a8ea201197ed355aa87133a718afca7c4a49: duplicateEntries: contains duplicate file entries
-error in tree 255f43cff847013439117a3fc4cfa517a90f38cb: duplicateEntries: contains duplicate file entries
-error in tree 404b4124800ece4772296d1f7559d982d0bc4cbd: duplicateEntries: contains duplicate file entries
-Checking objects: 100% (347890/347890), done.
-Checking connectivity: 347890, done.
-[4 zerodogg@firefly annexed]$ GIT_PAGER=cat git show 3818a8ea201197ed355aa87133a718afca7c4a49
-tree 3818a8ea201197ed355aa87133a718afca7c4a49
-
-Diverse/
-Dokument/
-Dokument/
-NBGI/
-Politikk/
-Skule/
-btfixie.ods
-endless space/
-monolith productions/
-my games/
-[4 zerodogg@firefly annexed]$ GIT_PAGER=cat git ls-tree 404b4124800ece4772296d1f7559d982d0bc4cbd
-040000 tree 2efffc4a0eb7df3fde68e7a222926ff4b91ede4a Diverse
-040000 tree cd854aba649cee8855ec72579f4c98100471f7cf Dokument
-040000 tree 1ae499997746c8e976cf02edc2276532978dafc5 Dokument
-040000 tree ec8256eb106836a356aa7818f5b579f78393820e NBGI
-040000 tree 384904d7414811bd41ee36b4d2ae2555192bd49f Politikk
-040000 tree 0ac0cf99f02852d45518ffcbd42a0edc9e07dfd4 Skule
-040000 tree a20b8cc805d1612b60d0dfab69a49788e0467ca6 endless space
-040000 tree 9463eeb6cfcaa87491bf7aec03d10cf5edd1ac7d monolith productions
-040000 tree 0ce07221be630cbbf038d8a5f8534cb599d0daf4 my games
-\"\"\"]]
-
-From here I'm not sure how to figure out where to go. I do have a copy of the original working copy where the problem first appeared (it has now propagated to all copies), if you want a copy to dig around in. I'll also be happy to provide more information if you specify what you need.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-01-29T19:14:53Z"
- content="""
-hmm, so tree 3818a8ea201197ed355aa87133a718afca7c4a49 has 2 Dokument
-entries. Interesting.
-
-If you still have that repo, it would be interesting to compare trees
-cd854aba649cee8855ec72579f4c98100471f7cf and 1ae499997746c8e976cf02edc2276532978dafc5
-
-[[git_fsck_duplicateEntries_errors_when_using_adjusted_branch]] dates
-from 2018, so I think I was right about my guess that it was something
-about adjusted branches that led to this. I'll merge this bug into that
-one.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-On my Windows laptop I upgraded to git 2.34 via Scoop and after that two conflict resolution unit tests
-started to fail. Presumably this is due to the new `ort` merge strategy that has been made default
-in this new release of git. (Ostensibly Recursive's Twin isn't perhaps quite yet what it claims to be.)
-
-### What steps will reproduce the problem?
-
-Install git version 2.34.0.windows.1. Then optionally build your git-annex with `stack setup && stack build`
-if you don't have a binary already. Then copy the binary to `C:\annxtmp1` and while situated in said directory
-in (Git) Bash say:
-```
-./git-annex test -p 'conflict resolution ' 2>&1 | tee git-annex..specific-test-01.LOG~202
-```
-Observe two out of nine tests failing.
-
-`test -p QuickCheck` was fine as were the other v8 unit tests.
-
-### What version of git-annex are you using? On what operating system?
-
-Two versions definitely exhibited this issue: 8.20211029-g9d3ce224e and 8.20211117-gc3af94eff (=released version).
-`git-annex version` output of the former below:
-
-[[!format sh """
-git-annex version: 8.20211029-g9d3ce224e
-build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.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 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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: mingw32 x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 2 3 4 5 6 7
-"""]]
-
-Windows version 21H1 (build 19043.1348), 64 bit.
-
-### Please provide any additional information below.
-
-_Under Windows with 8.20211029-g9d3ce224e:_
-
-[[!format sh """
-jkniiv@AINESIS MINGW64 /c/annxtmp1
-$ ./git-annex test -p 'conflict resolution ' 2>&1 | tee git-annex..specific-test-01.LOG~201
-[...]
-jkniiv@AINESIS MINGW64 /c/annxtmp1
-$ cat git-annex..specific-test-01.LOG~201
-Tests
- Unit Tests v8 adjusted unlocked branch
- conflict resolution (adjusted branch): Init Tests
- init: OK (5.64s)
- add: OK (7.85s)
-
-All 2 tests passed (13.49s)
-OK (46.59s)
- conflict resolution movein regression: OK (51.06s)
- conflict resolution (mixed directory and file): FAIL (37.66s)
- Test.hs:1378:
- r1 conflictor variant file missing in: ["sha1foo","foo","conflictor~HEAD.variant-cc12","conflictor","bar.c",".git","..","."]
- Use -p '/conflict resolution /&&/conflict resolution (mixed directory and file)/' to rerun this test only.
- conflict resolution symlink bit: OK
- conflict resolution (uncommitted local file): OK (53.99s)
- conflict resolution (removed file): OK (106.99s)
- conflict resolution (nonannexed file): FAIL (26.74s)
- .\\Test\\Framework.hs:57:
- sync failed (transcript follows)
- commit
- On branch adjusted/master(unlocked)
- nothing to commit, working tree clean
- ok
- pull r2
- (Merging into master...)
- CONFLICT (distinct types): conflictor had different types on each side; renamed one of them so each can be recorded somewhere.
- Automatic merge failed; fix conflicts and then commit the result.
- (recording state in git...)
-
- Merge conflict was automatically resolved; you may want to examine the result.
- U conflictor~refs_remotes_r2_master
- (Merging into master...)
- CONFLICT (distinct types): conflictor had different types on each side; renamed one of them so each can be recorded somewhere.
- Automatic merge failed; fix conflicts and then commit the result.
- (recording state in git...)
-
- Merge conflict was automatically resolved; you may want to examine the result.
- U conflictor~refs_remotes_r2_synced_master
- failed
- (merging r2/git-annex into git-annex...)
- (recording state in git...)
- push r2
-
- failed
- From ../../.t\tmprepo15
- * [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
- error: Committing is not possible because you have unmerged files.
- hint: Fix them up in the work tree, and then use 'git add/rm <file>'
- hint: as appropriate to mark resolution and make a commit.
- fatal: Exiting because of an unresolved conflict.
- error: Committing is not possible because you have unmerged files.
- hint: Fix them up in the work tree, and then use 'git add/rm <file>'
- hint: as appropriate to mark resolution and make a commit.
- fatal: Exiting because of an unresolved conflict.
- To ../../.t\tmprepo15
- * [new branch] git-annex -> synced/git-annex
- ! [rejected] master -> synced/master (non-fast-forward)
- error: failed to push some refs to '../../.t\tmprepo15'
- 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\tmprepo15
- ! [rejected] master -> master (non-fast-forward)
- error: failed to push some refs to '../../.t\tmprepo15'
- 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 r2 failed.
- sync: 2 failed
-
- Use -p '/conflict resolution /&&/conflict resolution (nonannexed file)/' to rerun this test only.
- conflict resolution (nonannexed symlink): OK (22.07s)
- conflict resolution (mixed locked and unlocked file): OK (41.50s)
-
-2 out of 9 tests failed (400.13s)
- (Failures above 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)
-
-Yeah sure, I'm a believer. :) Using it with my multigigabyte backup files just fine most of the time.
-I'm also building select versions of git-annex for both Windows native and WSL1/2 use following the
-development on master. A fine piece of software it definitely is.
-
-[[!meta author=jkniiv]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="kyle"
- avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
- subject="re: git 2.34: some conflict resolution unit tests fail"
- date="2021-11-21T21:41:36Z"
- content="""
-I see similar failures on GNU/Linux with Git 2.34.
-
-```
-$ git version
-git version 2.34.0
-$ git annex version | grep version:
-git-annex version: 8.20211118-ga0e9a059a
-
-$ git annex test -p 'conflict resolution '
-Tests
- Unit Tests v8 adjusted unlocked branch
- conflict resolution (adjusted branch): Init Tests
- init: OK (0.12s)
- add: OK (0.42s)
-
-All 2 tests passed (0.54s)
-OK (2.30s)
- conflict resolution movein regression: OK (2.18s)
- conflict resolution (mixed directory and file): FAIL (1.71s)
- Test.hs:1378:
- r1 conflictor variant file missing in: [\".\",\"..\",\"conflictor~HEAD.variant-cc12\",\"conflictor\",\"sha1foo\",\"foo\",\"bar.c\",\".git\"]
- Use -p '/conflict resolution /&&/Unit Tests v8 adjusted unlocked branch.conflict resolution (mixed directory and file)/' to rerun this test only.
- conflict resolution symlink bit: OK
-[... 206 lines ...]
- conflict resolution (mixed locked and unlocked file): FAIL (1.51s)
- Test.hs:1611:
- r1 not exactly 0 variant files in: [\".\",\"..\",\"conflictor.variant-cc12\",\"conflictor~refs_remotes_r2_master.variant-cc12\",\"conflictor\",\"sha1foo\",\"foo\",\"bar.c\",\".git\"]
- Use -p '/conflict resolution /&&/Unit Tests v8 locked.conflict resolution (mixed locked and unlocked file)/' to rerun this test only.
-
-8 out of 27 tests failed (53.21s)
- (Failures above could be due to a bug in git-annex, or an incompatibility
- with utilities, such as git, installed on this system.)
-```
-
-> Presumably this is due to the new ort merge strategy that has been
-> made default in this new release of git.
-
-Yes, that looks to be it. The above failure goes away if I force
-git-annex to merge with the old recursive strategy:
-
-[[!format diff \"\"\"
-
-diff --git a/Git/Merge.hs b/Git/Merge.hs
-index b88d9a00f..c50672a3d 100644
---- a/Git/Merge.hs
-+++ b/Git/Merge.hs
-@@ -39,7 +39,8 @@ merge' extraparams branch mergeconfig commitmode r
- go [Param $ fromRef branch]
- | otherwise = go [Param \"--no-edit\", Param $ fromRef branch]
- where
-- go ps = merge'' (sp ++ [Param \"merge\"] ++ qp ++ ps ++ extraparams) mergeconfig r
-+ go ps = merge'' (sp ++ [Param \"merge\"] ++ [Param \"-srecursive\"] ++
-+ qp ++ ps ++ extraparams) mergeconfig r
- sp
- | commitmode == AutomaticCommit =
- [Param \"-c\", Param \"commit.gpgsign=false\"]
-
-\"\"\"]]
-
-```
-$ git version
-git version 2.34.0
-$ git annex version | grep version:
-git-annex version: 8.20211118-g30580a4e7
-
-$ git annex test -p 'conflict resolution '
-Tests
- Unit Tests v8 adjusted unlocked branch
- conflict resolution (adjusted branch): Init Tests
- init: OK (0.17s)
- add: OK (0.41s)
-
-All 2 tests passed (0.59s)
-OK (2.18s)
- conflict resolution movein regression: OK (2.24s)
-[... 37 lines ...]
-All 27 tests passed (67.12s)
-```
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-11-22T16:32:10Z"
- content="""
-The difference in behavior, when there's a conflict between a directory and a
-file, is that the recursive strategy leaves the directory in "added by them"
-conflict state, as well as adding the file with a different name
-(and oddly, not staging it at all), while
-the ort strategy leaves does not flag the directory as in conflict,
-and makes the file be in "added by them" conflict state.
-
-`git-annex sync` resolves such a conflict adequately, with the new version
-of git, but the name of the file turns out different, eg
-"foo~refs_remotes_origin_master.variant-b66a"
-or "foo~HEAD.variant-b66a" rather than
-"foo.variant-b66a". That happens only in such a mixed conflict,
-a conflict between two annexed files still gets the shorter name
-like "foo.variant-b66a".
-
-There's a small problem with a lack of a stable name being used, as shown
-above the name of the branch being merged from or to is used by git as part
-of the filename. So two people who resolve a merge this way would end up
-with two different names for the file. git-annex's merge conflict
-resolution is designed to yield a stable result no matter where it's run,
-so this behavior is a bit of a shame, but it's git's decision to behave
-that way, and I guess the same thing can happen when not using git-annex,
-if you commit what the new resolver stages. So this can be considered not a
-git-annex problem.
-
-I've adjusted the mixed conflict resolution test to accept these new names
-while also still working with the old names. That fixes that one. The other
-test is still failing.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-11-22T17:31:54Z"
- content="""
-On to the second test failure. When there's a conflict between
-a symlink and a regular file, the ort resolver uses
-the names `foo` and `foo~<ref>`.
-(Again not using stable naming, alas), and
-the files are staged in conflict, one "added by us"
-and the other "added by them".
-
-The old resolver's behavior is to leave a single file
-`foo` in conflict state "both added" and containing the content of the
-file; the content of the symlink is staged as added by them.
-
-git-annex's merge conflict resolution does not deal with this well,
-because it doesn't know those two files are related. So it sees
-a file eg `foo~HEAD` that is in conflict, but the conflict does
-not involve an annexed file. So it does not try to resolve that merge,
-because resolving a merge not involving an annexed file is out of scope.
-
-Ugh. I think something has to be done about this, making the test suite
-use the old resolver is not sufficient because git-annex is supposed to
-recover from this kind of merge conflict.
-
-Bear in mind that a non-annexed file with a name like `foo~HEAD`
-that is in "added by us" state can also happen when a file is modified by
-us, and deleted by them. So resolving such a file by adding it makes a
-decision that git-annex does not want to make about a non-annexed file.
-
-So, it seems that to fix this, git-annex will have to somehow learn
-that `foo` and `foo~<ref>` are the two sides of a merge
-conflict. It would have to base that on the filenames that git uses
-and the fact that one is a symlink and the other is a normal file.
-
-Ok, done..
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jkniiv"
- avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
- subject="comment 4"
- date="2021-11-23T21:46:43Z"
- content="""
-Thanks Joey for investigating this issue thoroughly. Also, my thanks to kyle for expanding my initial report
-with Linux-related details I didn't have time to prepare.
-"""]]
+++ /dev/null
-From [git-annex-config](https://git-annex.branchable.com/git-annex-config/):
-
-> annex.securehashesonly
->
-> Set to true to indicate that the repository should only use cryptographically secure hashes (SHA2, SHA3) and not insecure hashes (MD5, SHA1) for content.
-
-From my computer:
-
-```
-$ git annex config --set annex.securehashesonly true
-git-annex: annex.securehashesonly is not a configuration setting that can be stored in the git-annex branch
-```
-
-So either the documentation is incorrect, or something isn't working right.
-
-macOS 10.15.7
-
-```
-$ git annex version
-git-annex version: 8.20210310
-build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.4 http-client-0.7.6 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: darwin x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-### 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's great!
-
-> Ooops, it seems I implemented everything needed for that except
-> forgot to add it to the list of allowed configs. Fixed now, and tested to
-> work. [[done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-`git annex config --set <option> <value>` interprets a value with a leading dash as if it were an option. Adding `--` doesn't help.
-
-
-### What steps will reproduce the problem?
-
-`git annex config --set annex.youtube-dl-options -x`
-
-### What version of git-annex are you using? On what operating system?
-
-```
-git-annex version: 8.20201130-g75988a790
-build flags: Assistant Webapp Pairing Inotify TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-Debian Buster
-
-### 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'm using git-annex to manage all my media files, photos, and archives. My largest repository is 2.8 terabytes. One of my repositories has over a million files in it. Performance is great when dealing exclusively with locked files.
-
-> [[notabug|done]] per kyle's comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="kyle"
- avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
- subject="comment 1"
- date="2021-01-25T14:52:54Z"
- content="""
-> `git annex config --set <option> <value>` interprets a value with a
-> leading dash as if it were an option. Adding `--` doesn't help.
-
-I can get by the \"Invalid option\" error using `--`:
-
-```
-$ git annex config --set annex.youtube-dl-options -x
-Invalid option `-x' [...]
-
-$ git annex config --set annex.youtube-dl-options -- -x
-git-annex: annex.youtube-dl-options is not a configuration setting that can be stored in the git-annex branch
-
-$ git annex version --raw
-8.20201129
-```
-
-`annex.youtube-dl-options` isn't one of the limited set of options that `git annex config` supports though:
-
-```
-globalConfigs =
- [ annexConfig \"autocommit\"
- , annexConfig \"synccontent\"
- , annexConfig \"synconlyannex\"
- , annexConfig \"resolvemerge\"
- , annexConfig \"largefiles\"
- , annexConfig \"dotfiles\"
- , annexConfig \"addunlocked\"
- ]
-```
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="seanl@fe5df935169a5440a52bdbfc5fece85cdd002d68"
- nickname="seanl"
- avatar="http://cdn.libravatar.org/avatar/082ffc523e71e18c45395e6115b3b373"
- subject="-- works between the value and the option"
- date="2021-01-26T16:10:22Z"
- content="""
-I had been putting the `--` between `--set` and the value rather than between the value and the option. As I understand it, the traditional meaning of `--` is \"all arguments after this point are positional\", which would mean it should work anywhere as long as it's after the last option argument. So I guess the title of this bug should be \"-- only works just in front of the value\"?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="seanl@fe5df935169a5440a52bdbfc5fece85cdd002d68"
- nickname="seanl"
- avatar="http://cdn.libravatar.org/avatar/082ffc523e71e18c45395e6115b3b373"
- subject="Unless the key is the argument to set"
- date="2021-01-26T16:12:31Z"
- content="""
-I guess if the key is actually an argument to --set and not a positional argument, then `--` shouldn't be expected to work there. In which case maybe it would be good to add `[--]` between the key and value in the man page?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-02-01T16:10:02Z"
- content="""
-Hmm, other git-annex man pages don't show use of -- before eg,
-filenames, which seem more likely to need it than any value a config could
-be set to. Highly unlikely something like annex.youtube-dl-options would
-ever be supported here, as it would invite security holes. So I'm inclined
-to feel mentioning the -- on the man page is clutter, the same way
-it's eg not mentioned on the man page for `ls`. Although I suppose that
-does raise the question of how anyone ever learns about -- .. I forget how
-I did.
-
-Anyway, yes, the current implementation is really --set=value, and due to
-that implementation detail, -- can't come before the the value.
-"""]]
+++ /dev/null
-### Please describe the problem.
-After adding a `gcrypt::rsync://` remote, `git-annex-sync` and `git-annex-info` crash with:
-
- git-annex: bad url rsync://192.168.178.241:test
- CallStack (from HasCallStack):
- error, called at ./Git/Construct.hs:107:15 in main:Git.Construct
-
-### What steps will reproduce the problem?
- git init
- git annex init test
- git remote add test gcrypt::rsync://192.168.178.241:test
- git annex sync
-
-### What version of git-annex are you using? On what operating system?
-git-annex version: 8.20201127
-
-> [[done]], it will no longer crash, and git-annex sync will work
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-01-18T14:11:44Z"
- content="""
-I want to use such a remote just for storing the git repo, no need to support it as a (special-)remote for storing annexed files. But full support would be cool too.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 2"
- date="2021-01-18T14:31:06Z"
- content="""
-git-annex crashes with `gcrypt::sftp://` too. And probably with `gcrypt::rclone://`, but I didn't test.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-01-18T16:45:35Z"
- content="""
-Also discussed in these:
-<https://git-annex.branchable.com/bugs/gcrypt_rsync_remotes_don__39__t_work/>
-<https://git-annex.branchable.com/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/>
-
-Some users there report that git-annex sync does work, as far as running
-git push and pull. I think the form of your url is the problem,
-gcrypt::rsync://192.168.178.241:test seems like it's trying to mix url
-and rsync location syntax. Urls don't normally end with ":test",
-that's not a valid url, and so the parse fails.
-(Verified using Network.URI.parseURI same as git-annex does.)
-
-Something like
-gcrypt::rsync://192.168.178.241/home/you/test will work, or at least not
-crash at that point.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 4"
- date="2021-01-18T17:05:55Z"
- content="""
-The `gcrypt::rsync://host:path` syntax is documented in the git-remote-gcrypt manpage and manual push/pull works find.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2021-01-18T17:46:38Z"
- content="""
-Oh, that format is unfortunately what git-remote-gcrypt uses:
-
- rsync URIs
- Note that the URI format for the rsync backend is, regretably,
- non-standard. git-remote-gcrypt uses rsync://user@host:path
- whereas plain rsync uses either user@host:path or
- rsync://user@host/path.
-
-Also, all git-annex commands crash due to the malformed/nonstandard url.
-Even git-annex init, or other things that don't need to access the remote at all.
-
-So this definitely needs fixing, to at least not crash on that.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2021-02-01T16:41:34Z"
- content="""
-Note that I also got git-remote-gcrypt patched, so it supports a
-more standard uri form, eg rsync://192.168.178.241/test
-"""]]
+++ /dev/null
-### Please describe the problem.
-`git annex fix` doesn't fix up broken symlinks afer moving a file.
-
-### What steps will reproduce the problem?
-
- git init
- git annex init
- mkdir dir
- touch dir/a
- git annex add .
- git annex sync
- mv dir/a .
- git annex fix a
- ls -alh
-
-### What version of git-annex are you using? On what operating system?
-8.20201127 (I know I know... One year old version :)
-
-> not a bug [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-01-04T17:43:31Z"
- content="""
-git-annex silently skips files that are not checked into git, and after you
-run "mv", the file is not checked into git.
-
-So add the file (or just use `git mv` to move it) and then it will work.
-
-Note that, annex.skipunknown can be set to false to make git-annex not
-silently skip files and instead complain. That is scheduled to become the
-default in 1 year, because I know the current behavior can be confusing.
-"""]]
+++ /dev/null
-In unusual circumstances, `git-annex forget` being used in a repo
-can confuse updating exporttree remotes.
-
-The export.log contains refs to trees that have been exported. Those trees
-get grafted into the git-annex branch to ensure the tree object does not
-get garbage collected and is available in clones. But forget rewrites the
-branch and those historical versions that include the grafting of the trees
-are not included.
-
-Now, this is not normally a problem because the same tree object tends to
-get merged into the master branch -- or is the master or other branch that
-was exported. And so remains available despite the copy from the git-annex
-branch having been garbage collected. But, it is possible for that not to
-be the case.
-
-So, the tree object can be garbage collected, and it might be possible for
-something involving tree import or export to fail to access it. When that
-happens in the same repo that was accessing that exporttree remote,
-I'm not sure if that really is a problem, since the export database still
-contains the information.
-
-So far, I have only produced the problem by making a clone from the
-original repo, and then in the clone the tree object is not accessible,
-and it fails like this:
-
- git annex get foo --from dir
- get foo (from dir...) fatal: bad object 7cb908c2a9aa7703a39b6c9f10ccb63bf903135b
-
- unknown export location
- failed
-
-To cause this problem, I first exported master to dir, the I moved
-a file and did a git commit --amend, to change the tree object for master.
-Then `git annex forget`. Then I cloned the repo, over ssh (a local
-clone still got a copy of the now dangling tree object). After enableremote,
-get fails as shown. --[[Joey]]
-
-A solution might be for the branch transition code to preserve old commits
-that add/remove export.tree. Or, the branch transition code could examine
-the export.log to find the trees that it refers to, and re-graft those back
-into the new git-annex branch.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-`git annex fsck --time-limit=` is broken. <br>
-For one, there is a large delay between the specified time limit until something actually happens. With 20 seconds, `git annex fsck` always runs more than 5 minutes. And then something of the following happens: <br>
-Sometimes it works as intended. <br>
-Sometimes it prints "Time limit (20s) reached!" but hangs without exiting. <br>
-Sometimes it prints "Time limit (20s) reached!" but continues fscking. <br>
-
-### What steps will reproduce the problem?
-In a sufficiently large repo run `git annex fsck --time-limit=20s`.
-
-### What version of git-annex are you using? On what operating system?
-8.20201127
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-01-04T17:50:55Z"
- content="""
-All of this is explained by --time-limit being implemented as a
-hack that throws an exception. Problem being that, the new streaming seeker
-checks matchers in a separate thread and having that thread die of an
-exception probably causes the hang. Also, since it checks the matcher
-before streaming through git, there's a buffer of perhaps many files
-that builds up before the time limit is reached, so those can go on to be
-processed, even after it's said the time limit is reached. Aaad, since it
-runs cleanup actions, this might leave fsck with its database closed
-but trying to use it.
-
---time-limit could be removed from git-annex entirely. The `timeout`
-command can be used with git-annex. But fsck db flush and close doesn't
-happen when git-annex gets SIGINT and do with --time-limit. So this would
-need maybe a SIGINT handler that runs cleanup actions? And then git-annex
-would run some perhaps expensive cleanup actions whenever ctrl-c'd, which
-might not be desirable since normally that's not necessary.
-
-Or, it needs to not be implemented in this hackish way, but as another
-check that's done before starting processing a seeked file.
-"""]]
+++ /dev/null
-### Please describe the problem.
-I've a type=directory remote, with exporttree=yes on a USB disk. when running `git annex --content` git annex list a long list of `export cibox-usb toto ok` lines for file it already exported before. I’ve check some of those file, and their content are correct.
-
-Those line hide real new export, and I wonder if it doesn’t slow the process.
-
-There seem to be no way to tell git-annex that those file are already ok, and it should try again to export them.
-`
-
-### What steps will reproduce the problem?
-
-Just running `git annex --content name-of-the-remote`
-
-
-### What version of git-annex are you using? On what operating system?
-git annex from Debian :
-
- git-annex version: 8.20211011
- build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
- dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
- remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
- operating system: linux x86_64
- supported repository versions: 8
- upgrade supported from repository versions: 0 1 2 3 4 5 6 7
- local repository version:
-
-### 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’s only a bug on what git-annex display. It does the asked work: the file are correctly exported where I look for them.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-11-29T17:32:33Z"
- content="""
-I think that the most likely reason for this to happen is if the
-particular file is not checked into git-annex, but into git.
-
-Since files stored in git are small, re-uploading them is not likely to be
-very expensive.
-
-However, I found a way to prevent it doing so. So this is fixed assuming
-I guessed right about the cause of it for you.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-git checkout is very slow to checkout unlocked files.
-
-### What steps will reproduce the problem?
-
-Setup:
-
-```
-for i in {1..1000}; do echo $i > $i; done
-git init
-git annex init
-git config annex.addunlocked true
-git annex add .
-git commit -m .
-git annex lock .
-git reset .
-```
-
-Doing a `git checkout .` at this point took about a minute. In comparison doing a `git annex unlock . && git status` took 30 seconds.
-
-### What version of git-annex are you using? On what operating system?
-
-8.20210428 in Linux.
-
-### Please provide any additional information below.
-
-The relevance of this problem is that I tried to go from a lock-adjusted branch to its basis with about 50000 unlocked files with `git checkout`. It was taking longer than expected and there were many warnings about a cosmetic problem and advised me to run `git update-index -q --refresh <path>`. Eventually I deleted the entire working tree, did `git reset --hard` to recreate the unlocked file stubs, locked every file and unlocked them again.
-
-> [[dup|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-Concurrent operations fail due to .git/index.lock being held.
-
-### What steps will reproduce the problem?
-git annex fromkey , under high concurrency . Maybe more retries could be added, before failing?
-
-### What version of git-annex are you using? On what operating system?
-(master_env_py27_v28) [11:57 AM /data/ilya-work]$ git annex version
-git-annex version: 7.20181031-g43f0718
-build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify 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-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: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-local repository version: 5
-(master_env_py27_v28) [12:00 PM /data/ilya-work]$ uname -a
-Linux ip-172-31-80-119 4.14.77-70.82.amzn1.x86_64 #1 SMP Mon Dec 3 20:01:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
-(master_env_py27_v28) [12:00 PM /data/ilya-work]$
--
-
-### 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
-
-2018-12-06 01:22:20,410 - workflow_utils:183:_run - INFO - running command: git annex fromkey --force MD5E-s19330--3541df84bcd805aa205\
-f9ffdca6cc21a.fasta pipelines/dxfailed/analysis-FKPG5480Z3yz3yG21G7F47z1/files/originalInput/stage-4.reference_genome_fasta/0/ref-ebov\
--makona_C15.fasta cwd=/data/ilya-work
-fatal: Unable to create '/data/ilya-work/.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)
-T
-
-
-# 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)
-
-It's become an indispensable tool. E.g. I just used it to moved data from more-expensive to less-expensive storage, without needing to worry about getting it back when needed; this frees up not just disk space but mental space :)
-
-> [[closing|done]] for reasons explained in my comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2018-12-09T15:05:20Z"
- content="""
-This is the same as concurrent `git add` (with or without git-annex)
-failing due to git only allowing one writer to the index at a time.
-
-Since this is a fundamental limitation of git, I feel that git-annex should
-not try to work around it for things involving the worktree's index file,
-except for within the same command as it does for `git annex add -J`.
-
-`git annex fromkey` obviously does need to update the worktree's index
-file. I suggest you run it in --batch mode and serialize the changes to it
-that way.
-
-(git-annex does of course work around the problem for the git-annex branch's index
-file, but that's very different than the worktree index; it doesn't matter if
-one process stages and commits another process's git-annex branch changes).
-"""]]
+++ /dev/null
-### Please describe the problem.
-I just upgraded one of my repositories to v7. Now, git status takes ages. The "Refresh index" count increments every second, so it will take ~12 hours to complete. With such slow operations I really fear the moment when v7 becomes default.
-
-I've got ~1000 unlocked files.
-
-### What steps will reproduce the problem?
-
-[[!format sh """
-$ git status
-Refresh index: 0% (49/43974)
-"""]]
-
-### What version of git-annex are you using? On what operating system?
-
-[[!format sh """
-$ git annex version
-git-annex version: 7.20190819-g972fd11f4e
-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: 5 7
-upgrade supported from repository versions: 0 1 2 3 4 5 6
-local repository version: 7
-
-"""]]
-
-> [[closing|done]] as the bug report lacks information to reproduce the
-> problem and similar problems are known to have been fixed --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
- nickname="lykos"
- avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
- subject="comment 1"
- date="2019-09-18T20:20:33Z"
- content="""
-OK so after processing the unlocked files, it got a lot faster. Will it be like that on every new clone and with every new unlocked file?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-09-20T16:25:25Z"
- content="""
-Once git has learned that the unlocked files are unmodified, it won't check
-them again.
-
-When you clone a repository, git checks out all the unlocked files
-as pointer files, and so git's index contains their inodes, and so
-no, git status is not slow in that situation.
-
-I think you must have unlocked 1000 files, and then ran git status.
-Then it would run git-annex 1000 times to smudge them all.
-([[todo/git_smudge_clean_interface_suboptiomal]]).
-I benchmarked that scenario to take around 28 seconds on an SSD.
-
-Perhaps you have an old version of git before 2.5? It used to force
-the entire content of each large file through a pipe to git-annex.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2019-10-22T17:08:11Z"
- content="""
-This bug needs to have instructions for how to reproduce a problem in order
-for me to do anything about it. As it is, I can only guess.
-
-[[git_keeps_refreshing_index]] was another report likely the same problem.
-There I diagnosed and fixed a case that would cause this behavior. I do not
-know if it is the case that you are reporting here, or a different one.
-I guess probably the same one. So if there's no followup, I'll probably
-close this bug report..
-"""]]
+++ /dev/null
-Apparently, if a http git remote is on a local network address,
-uuid discovery fails. The error message does not mention that
-annex.security.allowed-ip-addresses has to be set, but setting it solves
-the problem.
-
-There needs to be a better error message, or possibly don't apply
-annex.security.allowed-ip-addresses to uuid discovery -- which does not
-seem like it would involve the kind of security problem that config exists
-to prevent. --[[Joey]]
-
-> While I think it would be safe to bypass
-> annex.security.allowed-ip-addresses in this case, it seemed complicated
-> to implement that, and also getting that wrong would be a security hole.
-> Since this is a pretty unusual case, I think it's ok to need that to be
-> set.
->
-> So, I've improved the error message in this case. (And a few other
-> cases.) [[done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-When I use importfeed to get my podcasts after an update, it's starts to fail on some items and the metadata doesn't get generated. The error given is hPut: invalid argument (invalid character).
-
-### What steps will reproduce the problem?
-
-1. importfeed of a previously working podcast feed
-
-I also noticed that this tends to happen more often when using genmetadata but it still happens when that's not used.
-
-### What version of git-annex are you using? On what operating system?
-
-I'm on Ubuntu 20.04 (just upgraded from 18.04) with git-annex installed from nix.
-
- git-annex version: 8.20211011
- build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
- dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.6.4.1 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.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 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 X*
- remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
- operating system: linux x86_64
- supported repository versions: 8
- upgrade supported from repository versions: 0 1 2 3 4 5 6 7
- local repository version: 8
-
-I've had the same problem on my Synology NAS:
-
- git-annex version: 8.20211012-geb95ed486
- build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
- dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
- remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
- operating system: linux x86_64
- supported repository versions: 8
- upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-
-
-This is a relatively recent issue for me. I (maybe foolishly) updated my laptop and synology versions at the same time. The NAS was on git-annex-standalone-amd64-7.20191115. I was able to rollback nix to find the last working version and it seems it was:
-
- git-annex version: 8.20210330
- build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
- dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.4 http-client-0.6.4.1 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.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 X*
- remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
- operating system: linux x86_64
- supported repository versions: 8
- upgrade supported from repository versions: 0 1 2 3 4 5 6 7
- local repository version: 8
-
-### 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 -b main test && cd test && git annex init && git config annex.genmetadata true
-$ git-annex importfeed --template='new/${feedtitle}/${itempubdate}-${itemtitle}${extension}' --relaxed --fast https://files.manager-tools.com/files/public/feeds/career_tools_podcasts.xml
-[...]
-addurl https://traffic.libsyn.com/secure/manager-tools/career-tools-2020-12-24.mp3 (to new/Career_Tools/2020-12-24-MT_Goals_Examples_-_HOF_2020.mp3) git-annex: .git/annex/othertmp/a42_240_URL-s18703819--https&c%%traffic.libsyn.com%secu-da948bd01d45574da2155e03220b1a96.log.met: hPut: invalid argument (invalid character)
-
-$ echo $?
-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)
-
-I've been using git annex for a few years now primarily as a podcatcher. I've also been using it to manage my ebooks and devices. I'm slowly starting to use it for managing my personal (non-text) records and documents.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-11-15T16:04:31Z"
- content="""
-To reproduce this, I had to set LANG=C. Using a unicode locale avoids
-the problem.
-
-The `.met` file indicates it's a problem with encoding of metadata
-that is being imported from the feed, and so it must be the
-itemid that is causing the problem.
-
- <item>
- ...
- <guid>http://www.manager-tools.com/2014/01/choosing-a-company-work-chapter-7-–-questions/</guid>
- </item>
-
-A file with the feed edited down to just that item is enough to reproduce it.
-Notice the unicode in the guid "chapter-7-–-questions".
-That ENDASH character is causing the crash.
-
-Also I noticed that the next time it runs, it skips the item, since it got
-far enough to add the file for it and record the url before the metadata itemid
-write crashed it. Explains why it's failing on different items in different runs.
-
-While this looks like one of the old Handle output encoding problems, it is not,
-because a) the itemid is written as a ByteString so encoding does not matter,
-b) those were fixed comprehensively by forcing all handles to use filesystem
-enconding, and c) just printing out the length of the itemid also causes a crash:
-
- + liftIO $ print (L.length (journalableByteString content))
-
- git-annex: recoverEncode: invalid argument (invalid character)
-
-Looking at what the feed library parses:
-
- LANG=C ghci Utility/FileSystemEncoding.hs
- ghci> Just f <- Text.Feed.Import.parseFeedFromFile "career_tools_podcasts.xml"
- ghci> Just (_, x) = Text.Feed.Query.getItemId (Text.Feed.Query.feedItems f !! 0)
- ghci> x
- "http://www.manager-tools.com/2014/01/choosing-a-company-work-chapter-7-\8211-questions/"
- ghci> encodeBS (Data.Text.unpack x)
- "*** Exception: recoverEncode: invalid argument (invalid character)
-
-So the problem is that Text parses the feed as unicode, leading to this
-non-ascii Char that is not encoded using the filesystem encoding
-(which would encode it as "\56546\56448\56467").
-And `encodeBS "\8211"` crashes in LANG=C.
-
-Which is a reversion of sorts; before [[!commit fa62c98910]] encodeBS did
-not crash. Although it also didn't round-trip this value properly,
-producing "M" for it. Since this only affects strings that are not input in
-the filesystem encoding, I think the new encodeBS is still ok to use
-generally; I'm not going to revert that commit.
-
-Instead, Text values originating from Feed need to be converted to
-String in some other way, producing a value encoded
-using the filesystem encoding. encodeUtf8 looks like it will
-do the right thing in this case.
-"""]]
+++ /dev/null
-Consider if file `foo` uses key K, and file `archive/bar` uses the same key K.
-Using standard client preferred content settings, `git annex drop --auto`
-will want to drop `archive/bar`, but `git annex get --auto` will want to get
-`foo`. `git annex sync --content` will do both operations, getting and then
-dropping the key. Running these commands repeatedly churns unncessarily.
-
-In the preferred content expressions for standard groups, the only
-place this bug can be triggered involves archive directories of
-repositories in the client group. A file both in the archive directory and
-in another directory has indeterminite status.
-
-Fixing this needs a map from key to files using it. Then, when checking
-preferred content of `archive/bar`, it can see that `foo` also uses the
-key. Since `foo` is wanted, it should not drop the key, even though
-`archive/bar` is not wanted.
-
-Such a map exists, in the keys database, but only in v7 mode repositories.
-So, this seems solvable in v7 repositories, but not in v5.
-Also, the associated files map may not be accurate at all times, so that's
-a wrinkle to using it for this. Also, only unlocked files get into the
-associated files map. --[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 10"""
- date="2021-05-21T18:14:18Z"
- content="""
-There must also be the same problem for required content, and that should
-also be fixed. Will be easy to do once the information is gathered
-into the keys database.
-
-Actually, in the drop --auto case, required content is automatically
-handled correctly, because when checking preferred content it also checks
-required content.
-
-However, drop without --auto normally honors required content, but if the
-same content is used by 2 files, one required and the other not, dropping
-the latter file will drop the content of the first, violating required
-content settings. This seems like it ought to be fixed.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 11"""
- date="2021-05-21T20:26:39Z"
- content="""
-Started a branch `trackassociated` for this. So far, I've gotten the
-associated files to be kept updated with changes to locked files as well as
-unlocked files, and when files are removed it deletes the old associated
-files which did not happen reliably before. Performance impact of this is
-TBD, but it should only slow it down in situations where a large change has
-been made to the index -- eg checking out a very different branch, or
-adding a large number of files.
-
-There is a problem though:
-
- $ git config annex.addunlocked true
- $ touch n
- $ git annex add n
- $ echo 'select * from associated;' | sqlite3 .git/annex/keysdb/db
- SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855|n
- $ git mv n n2
- $ git annex add n2
- $ echo 'select * from associated;' | sqlite3 .git/annex/keysdb/db
- 1|SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855|n
- 2|SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855|n2
-
-The old filename does not get removed in this case. What happened here
-is that the first git-annex add recorded the associated file itself,
-but no index tree was recorded yet. So when the second git-annex
-runs reconcileStaged, it diffs from the empty tree to the index that
-contains only n2. So the removal of n is not noticed.
-
-This may not be a blocker for fixing preferred content, it just
-means that the list of associated files can include files that have since
-been deleted. The list could be double-checked once a punative second
-file has been found, with catKey. So it would only slow things down in
-the cases this bug is about and not generally. Still, it seems a shame
-that this case exists, because otherwise my recent changes have made old
-associated files get removed, and it would be nice to be able to trust
-that the associated files list is accurate.
-
-Also, bloating the keys db with stale associated files could happen.
-Well, it could already happen, indeed it was much worse, but that was
-limited to unlocked files, now it can also happen for locked files.
-
-Only fix I can think of is to make commands like git add that register
-an associated file to also update the cached index tree. That would let
-it diff from the previous index to the current one, and so notice the
-deletion. But it would have to be done at git-annex shutdown, and so if it
-were interrupted the problem could still happen. (Or, the database
-could have something added to it to indicate when an associated file
-has been added but has not been seen in the index yet, and the next update
-from the index could clear those flags, and remove any files still with the
-flag. This seems race-prone and it would need a change to the database
-schema.)
-
-Also, git commit currently fails, problem with index locking inside the smudge
-filter, which prevents git write-tree from working. Should be fixable by
-detecting when the index is locked and avoiding updating then. (Fixed now.)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 12"""
- date="2021-05-24T20:25:03Z"
- content="""
-This is about ready to be merged, and is fully working.
-
-Except.. `git annex drop --auto --branch=foo` seems likely to do something
-confusing, since it will check the associated files, which may not be on
-that branch. That combination of options doesn't really make a lot of sense
-anyway? Also consider `git-annex drop --all --auto`
-
-Ahh, not a problem after all, that option combo is already disallowed!
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="defining preferred content state"
- date="2021-05-23T20:39:23Z"
- content="""
-Thanks @joeyh for working on this.
-
-Is the following understanding of preferred content expressions accurate:
-
-* the expression is a predicate on file paths, not on keys. Expressions that check the property of a key (e.g. numcopies) are evaluated for each file path on the key it uses.
-* a given key is wanted in a repo if the preferred content expression is true for *any* file path which uses the key
-
-Also, if the above if correct, is \"any file path which uses the key\" defined the same way as in [[git-annex-unused]]?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 14"""
- date="2021-05-24T20:33:16Z"
- content="""
-@Ilya, it's different than git-annex unused because that looks at other
-branches and tags. Preferred content only relates to the currently checked
-out branch.
-
-The only preferred contents expressions that this bug affects are include=
-and exclude= ones. For an expression like copies=1, the key's content is
-present or not, no matter how many files in the working tree might use that
-key.
-
-> * a given key is wanted in a repo if the preferred content expression is true for *any* file path which uses the key
-
-Well not exactly, if foo and bar use the same content, and preferred
-content is set to include=foo, and I run `git annex get --auto bar`, it
-will not get the content despite bar's key also being used by foo, which is
-preferred content. I only asked the command to act on bar. That is not
-going to change. When the content is present, `git annex drop --auto bar`
-will, once this is fixed, avoid dropping the content because it knows foo
-also uses it.
-
-I don't think this needs to change user's understanding of how preferred
-content works. It's just git-annex being smart enough to prevent a situation
-where repeated `git annex get --auto; git-annex drop --auto` would continually
-do work, rather than reaching a stable point.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="clarifying preferred content expressions"
- date="2021-05-30T19:40:50Z"
- content="""
-Thanks Joey for clarifying. \"Preferred content only relates to the currently checked out branch\" -- what about repos with no \"currently checked out branch\", e.g. bare repos or special remotes, or those with more than one checked out branch (using [[git-worktree|tips/Using_git-worktree_with_annex]])? I had thought that e.g. setting the required content setting of an S3 special remote to `anything` would ensure that it gets a copy of every file ever annexed, but sounds like that might not be true.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 16"""
- date="2021-05-31T21:50:35Z"
- content="""
-By "currently checked out branch", I meant in the repository where
-git-annex is running. It might be copying to a special remote or whatever,
-but the filename matched by include= or exclude= in a preferred content
-expression comes from the branch it's run in.
-
-When run in a bare git repo (or with --all), include= and exclude= are
-documented not to match.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="kirelagin@6d93475882c55a329fedae6be1971868a775ec7e"
- nickname="kirelagin"
- avatar="http://cdn.libravatar.org/avatar/325af9a946cb4337c6640f0e95044be1"
- subject="Workaround?"
- date="2019-06-08T13:03:49Z"
- content="""
-Just got bitten by this. I guess it is not a very rare situation, so I was wondering, are there any known workarounds?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="EvanDeaubl"
- avatar="http://cdn.libravatar.org/avatar/00804f84646da416472678b573fd9d30"
- subject="One possible workaround"
- date="2021-02-22T16:23:40Z"
- content="""
-I ran into this exact situation trying to split content across multiple repos by directory, and ran into a couple of files with many duplicate keys throughout the repo. I worked around it by applying a tag to the offending key, and including that tag as part of the preferred content expression:
-
-```
-git annex metadata -t common-signature $FILE_WITH_DUP_KEY
-git annex wanted . 'include=\"foo/*\" or include \"bar/*\" or metadata=tag=common-signature'
-```
-
-This would result in a file possibly being included in a repo where it wouldn't be otherwise (if it wasn't in one of the include directories to begin with), but in my case, the common files were few and small (2, both less than 100K).
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-04-16T17:49:18Z"
- content="""
-See also:
-<https://git-annex.branchable.com/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/>
-Which needs the same information.
-
-Occurs to me one way to make sure git-annex has the information up-to-date
-would be to stat the index file, and if it's changed since last time,
-use `git ls-files --cached` to find all annexed files and update the keys
-database. But this could be quite slow.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="updating the keys database incrementally"
- date="2021-04-17T22:23:45Z"
- content="""
-\"stat the index file, and if it's changed since last time, use git ls-files --cached to find all annexed files and update the keys database. But this could be quite slow.\" -- could you instead record the tree-ish for which the database is valid (e.g. from the last commit or checkout), and then use [`git-diff`](https://git-scm.com/docs/git-diff)/[`git-diff-index`](https://git-scm.com/docs/git-diff-index)/[`git-status`](https://git-scm.com/docs/git-status) to update just the keys that changed?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 5"
- date="2021-04-17T22:54:34Z"
- content="""
-P.S. There might be some more uses for a keys-to-paths db. E.g. when operating on all keys, [[git-annex-matching-options]] could support matching by filename. When storing to a (non-exporttree) remote, path could be given as a hint to use for the storage path.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="semantics of preferred content expressions"
- date="2021-04-18T22:03:02Z"
- content="""
-It seems the underlying issue is that preferred content expressions are defined as predicates on *files*, but then used to determine preferred state of *keys*. The name \"preferred *content*\" suggests they're predicates on *keys*. The set of paths that use a key is a property of a key, like a special metadata field `_path`. Suppose `includeifany=glob` was true for a key if *any* value in `_path` matched `glob`, while `includeifall=glob` was true if *all* values in `_path` did. Treat `include=glob` as `includeifany=glob` and `exclude=glob` as `not includeifall=glob`. Then `include=* and exclude=archive/*` unambiguously means \"include all keys except those used only under `archive/`\". (This has the problem that `include=glob` is not the same as `not exclude=glob`. But the meaning seems to match the typical current usage of `include` and `exclude`?)
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="comment 7"
- date="2021-04-19T15:38:37Z"
- content="""
-I guess, simplest to just say that preferred content expressions are predicates on files (as now), and a key is preferred if any file using the key is preferred. Maybe clarify that in the docs?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 8"""
- date="2021-05-21T17:05:48Z"
- content="""
-I think Ilya is on the right track with recording the last treeish scanned
-for keys and diffing to the current treeish. This seems worth implementing.
-
-So, plan:
-
-* When dropping a file, after checking that it's not preferred content,
- or when needed for <https://git-annex.branchable.com/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/>
-* When the stat of the index differs from the last recorded stat
-* Generate a tree from the index with `git write-tree`, and when it
- differs from the last recorded such tree
-* `git diff-index --cached` with the last recorded tree, parse and cat
- the links, and update the keys database associated files with the keys
- it found. Note that it can also remove associated files when files get
- deleted, which is currently not done.
-* Then, look up in the keys database the associated files of the key, and
- also check if the preferred content matches any of those other files.
- So in the example above, it won't drop `archive/bar` because `foo` is
- still preferred content.
-
-This would not notice if a file was moved or deleted but that was not
-staged in the index yet. I think that's ok -- If the file is moved and not
-staged yet, it's not been added to git, so it's acceptable for git-annex to
-not try to keep content around for it (git-annex unused would not either
-in similar situations). If the file is deleted, git-annex might not drop
-the content yet because it's still present in the index, but the same
-happens if you delete a file and then `git annex drop .`, because it skips
-over the deleted file whether or not it's staged in the index.
-
-It seems sufficient to only do this when dropping a file, not in other
-commands. That means the associated files database remains incomplete
-for other commands, not including recent changes to locked files.
-Since this is only a problem for dropping, and the associated files
-database is not needed for locked files generally, that seems ok, although
-it would certianly be a nice simplification if the database was always
-kept up-to-date. Since the update could be a pretty expensive operation,
-probably best to keep it for the drops that really need it.
-
-Note that the `git write-tree` would mean that using git-annex could
-create these tree objects, which never end up getting used. gc would
-eventually delete them, but there might be a situation where doing this
-a lot bloats the repo.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 9"""
- date="2021-05-21T17:53:21Z"
- content="""
-There is overlap in the above plan with Database.Keys.reconcileStaged.
-That already stats the index, and updates associated files for changes
-made in the index. It does not handle locked files, and it only diffs
-from the index to HEAD, so when git checkout is used, it does not
-see those changes. (git runs the git-annex clean filter for those,
-and that updates the associated files database, but that also only handles
-unlocked files, not locked files).
-
-reconcileStaged is run every time the keys db is opened,
-so it runs perhaps more frequently than is needed for this. Although it
-does not run in every command, or even most commands. Eg, find and whereis
-do not use the keys db. It might be acceptable performance to do the
-additional work there.
-
-Also, handleDropsFrom queries the keys database for associated files
-already, and actually already checks if the key is preferred content of
-other files. So `git-annex sync --content`, which uses that, already
-avoids the problem for unlocked files, but not for locked files.
-`git annex drop` does not use that.
-"""]]
+++ /dev/null
-Clone a repository containing an unlocked file, and `git annex get` it. The
-object is transferred, but the pointer file does not get populated.
-(`git annex fsck` will then notice and correct the problem.)
-
-If any other git-annex command is run before the get, it avoids the
-problem. So the problem has to do with autoinit followed by reading
-associated files from the keys db.
-
-Bisected to [[!commit 428c91606b434512d1986622e751c795edf4df44]] --[[Joey]]
-
-It seems that reconcileStaged is populating the
-associated files, but later when they're queried, the query returns an
-empty list. So something to do with database write caching.
-
-Somehow, not having init call `scanAnnexedFiles` makes this bug go away.
-
-> fixed --[[Joey]]
-
-----
-
-I have reopened this bug, it seems the previous fix was not right.
-See [[!commit b3c4579c7907147a496bdf2c73b42238d8b239d6]] for that
-fix, which had doubts at the time in the commit message. --[[Joey]]
-
-Here is a test case:
-
- git init foo
- cd foo
- git annex init
- echo 1 > foo
- echo 2 > bar
- echo 3 > baz
- git annex add
- git annex unlock
- git commit -m add
- cd ..
- git clone foo bar
- cd bar
- git-annex get
- cat *
-
-This outputs 1 for foo, followed by annex pointer files for files bar and baz.
-
-The previous fix attempt did make foo get populated, before that none
-of the files were populated.
-
-----
-
-`GIT_TRACE=1` shows that git only runs the smudge filter on the first
-file, not the other two. And indeed, restagePointerFile is only called
-on the first file.
-
-Added debugging to Database.Keys.reconcileStaged, and it adds all 3 files to
-the associated files table, but only adds the inode cache of foo.
-And that's what I see in the db after the fact too. Which is
-not itself a problem, to the extent that the other files are not
-populated, and only populated files have an inode cache recorded.
-
-So, Database.Keys.reconcileStaged is called after it gets foo,
-but before the other files are present, and in reconcilepointerfile it
-calls populatePointerFile and records the inode cache for foo.
-That is how foo gets populated.
-
-But, the other 2 files do not have populatePointerFile run on them.
-In moveAnnex, it calls getAssociatedFiles and somehow that returns
-`[]`, for all 3 files. This does not matter for foo, because it gets
-populated by reconcileStaged as explained above. But for the other 2, with
-no known associated files of course it fails to populate them.
-
-So: Why is getAssociatedFiles returning `[]`? Those calls come
-after Database.Keys.reconcileStaged has added the associated files,
-but are somehow not seeing the changes it made.
-
-Ah.. The keys db is opened in MultiWriter mode.
-See the comment above the definition of MultiWriter,
-which explains that a write to a MultiWriter database,
-followed by a flushDbQueue may not be visible when reading
-from that same database.
-
-Verified this by making it re-open the db after reconcileStaged,
-which did fix the problem.
-
-A better fix is possible: Make MultiWriter mode not have this hidden
-gotcha, by re-opening the db after writing to it always. [[done]]
---[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-
-### What steps will reproduce the problem?
-
-Run "git-annex initremote" from an environment (cron, CI, etc.) where /dev/tty doesn't exist.
-
-### What version of git-annex are you using? On what operating system?
-
-git-annex version: 6.20160613-g35dbe35 on debian jessie
-
-### Please provide any additional information below.
-
-Example of the error @ https://gitlab.com/DanielDent/git-annex-remote-rclone/builds/2166644
-
-Error:
-gpg: cannot open tty `/dev/tty': No such device or address
-
-failed
-
-Rumour on the internets is that the "--no-tty" parameter to GPG may fix the problem.
-
-### 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 great!
-
-> Well, no followup to my request for more information, so [[done]]
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-07-05T13:28:12Z"
- content="""
-I tried running initremote without a tty, and it worked ok,
-using the following test case:
-
- #!/bin/sh
- set -e
- cd /tmp/r
- pwd
- git annex initremote test type=directory directory=../d encryption=hybrid keyid=2512E3C7 --fast --debug >/dev/null
-
-So, I need more information to reproduce this.
-
-It seems likely that, if gpg is trying to read from the tty, it needs to
-prompt for your key's passphrase for some reason. In which case setting
---batch would only make it fail differently. If you want to script
-something that needs access to your gpg secret key, you need to configure
-gpg to use a gpg agent.
-"""]]
+++ /dev/null
-### Please describe the problem.
-This can be easily reproduced using the latest [[standalone|https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz]] build.
-
-### What steps will reproduce the problem?
-
- git init test
- cd test
- git annex init test
- git annex assistant
- cat .git/annex/daemon.log
-
-### Please provide any additional information below.
-
-[[!format sh """
-
-$ cat .git/annex/daemon.log
-[2021-05-11 12:58:04.142576914] main: starting assistant version 8.20210128-g4fc0c58e2
-[2021-05-11 12:58:04.192323786] Cronner: You should enable consistency checking to protect your data.
-git-annex: internal error: evacuate: strange closure type 63367248
- (GHC version 8.8.4 for x86_64_unknown_linux)
- Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
-
-$ sha256sum git-annex-standalone-amd64.tar.gz
-18866ab90823695a65952041ca174fe2df2d82d8dd11d972eceef192358953c3 git-annex-standalone-amd64.tar.gz
-
-$ git annex version
-git-annex version: 8.20210331-g1fb59a63a
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-
-"""]]
-
-### 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]] in git-annex by avoiding using forkProcess.
-> If the root cause is a ghc bug it's still unfixed there, but it won't
-> affect git-annex. --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-05-12T17:09:06Z"
- content="""
-I'm seeing this too, although sometimes it seems to crash out before that
-gets written to the log. And sometimes it manages to get running and seems
-to run ok.
-
-It does not happen with --foreground AFAICS.
-
-Reproduced it with that most recent standalone release, and also with a
-local dev build, also with ghc 8.8.4.
-
-This would usually be a ghc or library bug, as there's no code in git-annex
-low-level enough to cause this kind of memory corruption or whatever it is.
-
-But, the assistant does one really funky thing for a haskell program, and that
-is forking to the background. It seems just possible that doing that has
-started confusing the garbage collector in some way.
-
-forkProcess is really problimatic with its handling of threads etc,
-and this may be the signal that git-annex needs to stop using it.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-05-12T17:53:04Z"
- content="""
-This might also affect git-annex remotedaemon, although it's running ok in
-my tests. However, that could only be due to luck.
-"""]]
+++ /dev/null
-Running `git-annex lookupkey` while in a subdirectory of a git-annex repository does not work, regardless of whether the supplied path is relative to the current directory or the root of the repository.
-
-### What steps will reproduce the problem?
-
-[[!format sh """
-git init
-git-annex init
-git-annex addurl --file latex/lshort.pdf https://tobi.oetiker.ch/lshort/lshort.pdf
-cd latex
-git-annex lookupkey lshort.pdf # Fails!
-git-annex lookupkey latex/lshort.pdf # Fails!
-cd ..
-git-annex lookupkey latex/lshort.pdf # Succeeds
-"""]]
-
-
-### What version of git-annex are you using? On what operating system?
-
-8.20211011 on macOS 11.6
-
-[[!meta author=jwodder]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
- nickname="asakurareiko"
- avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
- subject="comment 1"
- date="2021-10-24T21:23:56Z"
- content="""
-Broken since [[!commit 9012fa01877a78542c64f104bd60a80825ce3c86]] where the output became like this
-
-```
-~/test-annex/a$ git annex lookupkey a
-(\"f'\",\"a\",\"..\",False)
-```
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-10-26T18:11:52Z"
- content="""
-Well, I did later remove that stray debug print. But that commit did
-introduce the bug.
-
-Root cause though is that `dirContains ".." "foo" == False`, which is
-wrong.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jkniiv"
- avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
- subject="comment 3"
- date="2021-10-26T23:55:12Z"
- content="""
-I was about to report a similar bug with the `git-annex info <file>` on Windows
-with recent builds but
-[[!commit b2c48fb86bfa3d8e26062f76f7a669ffcf1b2209]] fixed that too.
-Thanks, jwodder, for reporting this. And many thanks to Joey for fixing dirContains.
-"""]]
+++ /dev/null
-When setting file metadata using `git-annex metadata --batch --json --json-error-messages`, if the "fields" field of an input line is not 100% an object whose values are arrays of strings, then git-annex will silently ignore the "fields" field and act as though the user simply requested the metadata for the given file/key. It would be more useful if, whenever the input contains a "fields" field that does not match the required schema, git annex treats it as an error. This would make it easier for users to figure out that they are doing something wrong.
-
-[[!meta author=jwodder]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-11-01T17:49:43Z"
- content="""
-For example with this input:
-
- {"file":"foo","fields":{"author":[true]}}
-
-It leaves the author field set to whatever it was before.
-
-Fixed.
-"""]]
+++ /dev/null
-Even in a newly created annex, git annex fsck fails. Furthermore, the suggested solution apparently does not work. Maybe the warning is simply spurious. Does this occur in the latest release?
-
-[[!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
-
-r0lf@work:/tmp/tmp$ dpkg -l git-annex
-Desired=Unknown/Install/Remove/Purge/Hold
-| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
-|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
-||/ Name Version Architecture Description
-+++-==============-============-============-===============================================================
-ii git-annex 8.20200226-1 amd64 manage files with git, without checking their contents into git
-
-r0lf@work:/tmp/tmp$ git init;git annex init
-Initialized empty Git repository in /tmp/tmp/.git/
-init (scanning for unlocked files...)
-ok
-(recording state in git...)
-
-r0lf@work:/tmp/tmp$ echo "test" > test.txt
-
-r0lf@work:/tmp/tmp$ git annex add test.txt
-add test.txt
-ok
-(recording state in git...)
-
-r0lf@work:/tmp/tmp$ git commit -m "test commit"
-[master (root-commit) d2e64c0] test commit
- 1 file changed, 1 insertion(+)
- create mode 120000 test.txt
-
-r0lf@work:/tmp/tmp$ git annex fsck test.txt
-fsck test.txt (checksum...)
- test.txt: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E test.txt
-ok
-(recording state in git...)
-
-r0lf@work:/tmp/tmp$ git annex migrate --backend=SHA256E test.txt
-migrate test.txt (checksum...) (checksum...) ok
-(recording state in git...)
-
-r0lf@work:/tmp/tmp$ git annex fsck test.txt
-fsck test.txt (checksum...)
- test.txt: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E test.txt
-ok
-(recording state in git...)
-
-# End of transcript or log.
-"""]]
-
-> closing since it does not affect the current version
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://launchpad.net/~r0lf"
- nickname="r0lf"
- avatar="http://cdn.libravatar.org/avatar/aa82122557e706df7ba83bd1983eb79ef1ba2e51350217850176d4f9a1bb2bc0"
- subject="comment 1"
- date="2021-04-26T12:22:43Z"
- content="""
-I was unable to verify the problem with the latest standalone package. Neither a freshly created annex nor the one created in focal gave any problems when tested with fsck.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://launchpad.net/~r0lf"
- nickname="r0lf"
- avatar="http://cdn.libravatar.org/avatar/aa82122557e706df7ba83bd1983eb79ef1ba2e51350217850176d4f9a1bb2bc0"
- subject="comment 2"
- date="2021-04-26T13:05:15Z"
- content="""
- Standalone package from NeuroDebian is not affected.
- Hirsute package is not affected.
- Groovy package is not affected.
- Focal package is affected.
-
-As it looks like this was fixed between focal and groovy, it would be great to pinpoint a particular commit so it can be backported to the Ubuntu LTS.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-04-26T17:27:25Z"
- content="""
-[[!commit bbe977a2b6b439b7ce767aae935d4ec98ee67a91]]
-"""]]
+++ /dev/null
-### Please describe the problem.
-not work: Git annex addurl existing file without redownloading, use URL-backend (not any hashkey-backend)
-
-### What steps will reproduce the problem?
-File copied to git (git-annex) repo's dir (did not 'git add' 'git annex add')
-name: 'f.mp4'
-Now run 'git annex addurl --file=f.mp4 --raw --relaxed https://www.youtube.com/watch?v=U33dsEcKge ' (via Python, see below)
-
-RESULT:
-failed "f.mp4 already exists; not overwriting"
-
-(same if run in Python)
-File "/opt/anaconda3/lib/python3.7/subprocess.py", line 512, in run
- output=stdout, stderr=stderr)
-subprocess.CalledProcessError: Command '['git', 'annex', 'addurl', '--file=f.mp4', '--raw', '--relaxed', 'https://www.youtube.com/watch?v=U33dsEcKgeQ']' returned non-zero exit status 1.
-
-Above command would work after doing 'git annex add f.mp4' first
- but it results in a backend not 'URL backend for youtube'
- I'd like to use 'URL backend for youtube' cause I worry about youtube-video binay-change, in which case all future download will fail backend verification.
-
-
-
-### What version of git-annex are you using? On what operating system?
-macOS 10.14.6, installed by 'brew install git-annex'
-git annex version
-git-annex version: 8.20201129
-build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.3 http-client-0.7.3 persistent-sqlite-2.11.0.0 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: darwin x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-
-
-### Please provide any additional information below.
-command line taken from https://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/
-
-[[!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)
-oh, yes, git-annex is great for managing binary files, thanks for the work!
-
-> [[done]], see my comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-02-24T17:20:12Z"
- content="""
-Well, it makes sense for addurl run on a file that is not an annexed file to
-fail. There is nothing else it could do in that case that makes sense.
-It can't record that the youtube url is a location for the annexed file,
-because there is no annexed file.
-
-What you can do is git-annex addurl --relaxed with the youtube url,
-which does not download it, and then make git-annex treat the mp4 file
-as the content, by running git-annex reinject with the first parameter
-being the git-annex filename, and the second being the f.mp4, which will
-get moved into the annex.
-
- git-annex addurl --file youtube.vid https://www.youtube.com/watch?v=U33dsEcKge --relaxed
- git-annex reinject f.mp4 youtube.vid
-
-Note that this command will work no matter what the content of the first file
-is, it will accept anything due to the use of --relaxed. So it's up to you
-to make sure you use it with a file that's the same content as the youtube
-video.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="m15"
- avatar="http://cdn.libravatar.org/avatar/a8c5fb405daff5f9c0c15209a3df4a4d"
- subject="new problem on reinject"
- date="2021-11-23T00:53:37Z"
- content="""
-Thanks for the suggestion!
-
-the cause: `addunlocked=true`, maybe show better error message to help
-- if with `pidlock=true`, message is more brief, even harder to debug
-
-## version
-git-annex version
-```
-git-annex version: 8.20200226
-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.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 git-lfs hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-```
-
-## setting
-root/.gitattributes
-```
-* annex.largefiles=(largerthan=700kb)and(not((mimetype=text/*)or(include=*.html)))
-* annex.backend=SHA512E
-* annex.numcopies=2
-```
-
-disk partition type: ext4 (12GB spare space)
-
-### .git/config
-```
-[annex]
- backend=SHA512E
- addsmallfiles=true
- addunlocked=true
- genmetadata=true
- alwayscommit=true
- synccontent=false
- youtube-dl-options = --no-overwrites ...
- autocommit = false
- resolvemerge = false
-[annex \"security\"]
- # allowed-ip-addresses = all
-[filter \"annex\"]
- smudge = git-annex smudge -- %f
- clean = git-annex smudge --clean -- %f
-
-```
-## shell command
-with file `1.mp4` (size 3.1M) existing, run as shell-command in Python
-```
-git-annex addurl --file Move_Dance_20200806_203.m4a https://www.youtube.com/watch?v=VsgpUHUYuJI --relaxed && git-annex reinject 1.mp4 Move_Dance_20200806_203.m4a
-```
-## output
-```
-addurl https://www.youtube.com/watch?v=VsgpUHUYuJI (to Move_Dance_20200806_203.m4a) ok
-(recording state in git...)
-reinject 1.mp4 ok
-(recording state in git...)
- English/Move_Dance_20200806_203.m4a failed to generate a key
-git-annex: could not add file to the annex
-CallStack (from HasCallStack):
- error, called at ./Command/Smudge.hs:141:24 in main:Command.Smudge
-error: external filter 'git-annex smudge --clean -- %f' failed 1
-error: external filter 'git-annex smudge --clean -- %f' failed
- English/Move_Dance_20200806_203.m4a failed to generate a key
-git-annex: could not add file to the annex
-CallStack (from HasCallStack):
- error, called at ./Command/Smudge.hs:141:24 in main:Command.Smudge
-error: external filter 'git-annex smudge --clean -- %f' failed 1
-error: external filter 'git-annex smudge --clean -- %f' failed
-```
-The result is a file staged for commit to git (not to git-annex).
-
-## Expected
-File added (reinjected) to git-annex as name `English/Move_Dance_20200806_203.m4a`
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-12-09T19:06:47Z"
- content="""
-@m15 I am finding it very hard to understand your comment. Also, you are
-commenting on a bug report that was closed a large number of months ago.
-
-It would perhaps be a good idea to file a new bug report, and explain more
-clearly how I can reproduce that problem.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Matching queries containing `-(`/`-)` without an explicit `--and`/`--or` next to them are interpreted strangely.
-
-(I'm not sure of the full space of queries that have an issue, but that describes what I've seen so far.)
-
-### What steps will reproduce the problem?
-
-[[!format sh """
-cd $(mktemp -d)
-git init
-git annex init
-touch a.1 a.2 b.1 b.2
-git annex add
-
-PS4='================ '
-set -x
-git annex find --include=a.* --include=*.1 # 'a.1' -- good (implicit --and)
-git annex find --include=a.* --and '-(' --include=*.1 --or --include=*.2 '-)' # 'a.1 a.2' -- good
-git annex find --include=a.* --or '-(' --include=*.1 --or --include=*.2 '-)' # 'a.1 a.2 b.1 b.2' -- good
-git annex find --include=a.* '-(' --include=*.1 --or --include=*.2 '-)' # 'a.1 a.2 b.2' -- ???
-"""]]
-
-Leaving out the `--and`/`--or` yields a result that is not the same as providing either one explicitly. The output is the same as `--include=a.* --or --include=*.2`, or perhaps `-( --include=a.* --include=*.1 -) --or --include=*.2`.
-
-`git annex find --want-get` with the equivalent preferred content expressions gives the same results.
-
-[[!format sh """
-git annex wanted . 'include=a.* include=*.1'; git annex find --want-get
-git annex wanted . 'include=a.* and (include=*.1 or include=*.2)'; git annex find --want-get
-git annex wanted . 'include=a.* or (include=*.1 or include=*.2)'; git annex find --want-get
-git annex wanted . 'include=a.* (include=*.1 or include=*.2)'; git annex find --want-get
-"""]]
-
-### What version of git-annex are you using? On what operating system?
-
-Freshly built from source on Arch Linux:
-[[!format text """
-git-annex version: 8.20201128-ge0062c4f9
-build flags: Assistant Webapp Pairing Inotify TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-"""]]
-
-### Please provide any additional information below.
-Output of the first script above:
-[[!format text """
-Initialized empty Git repository in /tmp/tmp.ZdtfLaDkA8/.git/
-init (scanning for unlocked files...)
-ok
-(recording state in git...)
-add a.1
-ok
-add a.2
-ok
-add b.1
-ok
-add b.2
-ok
-(recording state in git...)
-================ git annex find '--include=a.*' '--include=*.1'
-a.1
-================ git annex find '--include=a.*' --and '-(' '--include=*.1' --or '--include=*.2' '-)'
-a.1
-a.2
-================ git annex find '--include=a.*' --or '-(' '--include=*.1' --or '--include=*.2' '-)'
-a.1
-a.2
-b.1
-b.2
-================ git annex find '--include=a.*' '-(' '--include=*.1' --or '--include=*.2' '-)'
-a.1
-a.2
-b.2
-"""]]
-
-### 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! [My description from before](https://git-annex.branchable.com/bugs/async_external_special_remote__39__s_stdin_not_closed/) still applies. And I've continued growing my annex and expanded onto a new drive since then.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-01-28T16:54:29Z"
- content="""
-Let's see, here's the equivilant after parsing:
-
- # ghci Utility/Matcher.hs
- -- foo and (bar or baz)
- ghci> generate [Operation "foo", And, Open, Operation "bar", Or, Operation "baz", Close]
- MAnd (MOp "foo") (MOr (MOp "bar") (MOp "baz"))
- -- foo (bar or baz)
- ghci> generate [Operation "foo", Open, Operation "bar", Or, Operation "baz", Close]
- MOr (MAnd (MOp "foo") (MOp "bar")) (MOp "baz")
-
-So it's interpreting "foo (bar or baz) like "(foo and bar) or baz"
-which is surely a bug.
-
-Fixed.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-git-annex appears to not support relative paths for ssh remotes, e.g.:
-
-`remote.example.com:path/to/git`
-
-as opposed to:
-
-`remote.example.com:/absolute/path/to/git`
-
-
-### What steps will reproduce the problem?
-
-I was following the steps to setup a [centralized git repo](https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/).
-
-I have setup an SSH remote (referred to below as `remote.example.com:path/to/git`) and pushed to it as described in the docs. I then clone from this remote elsewhere:
-
-```
-0$ git clone remote.example.com:path/to/git remote
-0$ cd remote
-```
-
-But `git-annex init` runs into the following problem:
-
-```
-0$ git annex init 'local'
-init servo (scanning for unlocked files...)
-
- Unable to parse git config from origin
-
- Remote origin does not have git-annex installed; setting annex-ignore
-
- This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin
-ok
-(recording state in git...)
-0$
-```
-
-(Note problem but no non-zero return code.)
-
-However, if I clone the remote with an absolute path there is no issue:
-
-```shell
-0$ git clone remote.example.com:/absolute/path/to/git remote
-0$ cd remote
-0$ git annex init 'local'
-init servo (scanning for unlocked files...)
-ok
-(recording state in git...)
-0$
-```
-
-I suspected something was amiss when things were taking a long time, and looking at the process tree showed ssh commands that include the string `/~/path/to/git`
-
-### What version of git-annex are you using? On what operating system?
-
-```shell
-0$ git-annex version
-git-annex version: 8.20201127
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-local repository version: 8
-0$ cat /etc/issue
-Debian GNU/Linux bullseye/sid \n \l
-
-```
-
-
-### 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)
-
-
-> documentation fixed [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 10"
- date="2021-02-02T17:43:19Z"
- content="""
-Thanks so much @joey! Trust me, I would upgrade the server if I could...
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
- nickname="asakurareiko"
- avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
- subject="comment 11"
- date="2021-10-06T21:10:34Z"
- content="""
-I'm still experiencing this bug with 8.20200226. If the repo is cloned by ssh before doing `git annex init`, then the result is:
-
-```
- Unable to parse git config from origin
-
- Remote origin does not have git-annex installed; setting annex-ignore
-```
-
-
-Creating an empty repo and doing `git annex init` first then adding the remote and pulling in changes works fine, but this creates unrelated history on the `git-annex` branch.
-
-
-This affects ssh remotes but not local remotes.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
- nickname="asakurareiko"
- avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
- subject="comment 12"
- date="2021-10-07T06:21:25Z"
- content="""
-The problem I had was actually specific to WSL1. I added a section in [[todo/windows_support]] about cloning a repo with ssh in WSL1.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 1"
- date="2021-01-31T20:28:23Z"
- content="""
-I'm confused, because now I'm seeing the same problem even with absolute paths. What am I doing wrong? The server has git-annex installed system-wide, and seems to otherwise work ok.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-02-01T16:34:33Z"
- content="""
-I was going to say, I have repos with relative ssh paths that I use with
-git-annex every day.
-
-This seems likely to be a problem with how git-annex
-is installed on the server, that is preventing running git-annex-shell
-there. Ie, it should work to run `ssh remote.example.com git-annex-shell`.
-
-Sometimees there can be tricky problems with PATH not getting set as usual
-when sshing, see [[tips/get_git-annex-shell_into_PATH]].
-
-I don't know how the absolute path could have seemed to work, and then
-seemed to fail when you tried it again later. My guess would be, something
-must have changed on the server in the meantime.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 3"
- date="2021-02-01T17:45:14Z"
- content="""
-@joey, thank you for the response. I can confirm that I can run `ssh remote.example.com git-annex-shell` no problem from my local machine. Can you offer any other suggestions for things I could try to test the remote? Could it be some kind of version incompatibility? Is there some missing configuration I need to do on the server side? Right now it's just a bare git repo, nothing else.
-
-As for the absolute/local thing, I still there is some kind of issue there given the `/~/path/to/git` in the ssh command line in the process tree. That's obviously not a real directory, so it seems like something's wrong there. But it may well be what I'm experiencing is a separate issue.
-
-Any other help you could provide would be very much appreciated.
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 4"
- date="2021-02-01T18:25:08Z"
- content="""
-fwiw, if I continue and ignore the error I encounter when I try to `git annex init` on the local checkout, add a file, commit, push the `master` and `git-annex` branches to the remote, and then try to clone/get in another location, this is what happens:
-
-```
-0$ git clone ssh://remote.example.com/~/path/to/git
-Cloning into 'git'...
-remote: Enumerating objects: 19, done.
-remote: Counting objects: 100% (19/19), done.
-remote: Compressing objects: 100% (13/13), done.
-remote: Total 19 (delta 2), reused 0 (delta 0)
-Receiving objects: 100% (19/19), done.
-Resolving deltas: 100% (2/2), done.
-0$ cd git/
-0$ git annex get test.dat
-(merging origin/git-annex into git-annex...)
-(recording state in git...)
-(scanning for unlocked files...)
-get test.dat (not available)
- Maybe add some of these git remotes (git remote add ...):
- bac9e484-9534-464f-8aee-45670d5967ed -- servo
-failed
-git-annex: get: 1 failed
-1$
-```
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 5"
- date="2021-02-01T18:42:23Z"
- content="""
-here is the git-annex version info on the server side:
-
-```
-git-annex version: 5.20140221
-build flags: Assistant Inotify DBus Quvi TDFA
-key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
-remote types: git gcrypt bup directory rsync web tahoe glacier hook external
-```
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 6"
- date="2021-02-01T19:04:39Z"
- content="""
-Using the --debug option (thanks to suggestion fro @lukey) I was able to get a little deeper:
-
-```
-0$ git clone cal@ldas-pcdev1.ligo-wa.caltech.edu:archive/git
-Cloning into 'git'...
-warning: You appear to have cloned an empty repository.
-0$ cd git
-0$ git annex init --verbose --debug servo
-[...]
-
-[2021-02-01 10:50:13.141613956] process [1006769] read: ssh [\"remote.example.com\",\"-S\",\".git/annex/ssh/95ea79d833b87277ea620851140b81ec\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/~/archive/git' '--debug'\"]
-[2021-02-01 10:50:17.66427318] process [1006769] done ExitFailure 1'
-
- Unable to parse git config from origin
-[...]
-```
-
-Note the path `/~/archive/git`. That's obviously not going to work, so there really is an issue with relative paths and ssh.
-
-*However*, that's not the full problem. Something else is going on:
-
-```
-0$ git clone cal@ldas-pcdev1.ligo-wa.caltech.edu:/home/cal/archive/git
-Cloning into 'git'...
-warning: You appear to have cloned an empty repository.
-0$ cd git
-0$ git annex init --verbose --debug servo
-[...]
-[2021-02-01 10:53:36.256163655] process [1007229] read: ssh [\"remote.example.com\",\"-S\",\".git/annex/ssh/95ea79d833b87277ea620851140b81ec\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/home/cal/archive/git' '--debug'\"]
-[2021-02-01 10:53:40.632608448] process [1007229] done ExitFailure 1
-
- Unable to parse git config from origin
-[...]
-0$ ssh remote.example.com 'configlist' /home/cal/archive/git
-git-annex-shell: Not a git-annex or gcrypt repository.
-1$
-```
-
-This really makes it seem like there's some more configuration needed on the remote side. The instructions don't mention anything other than just initializing the bare git repo. Are you sure there's no other action that needs to be taken?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 7"
- date="2021-02-01T19:07:27Z"
- content="""
-crap I copied that last ssh command wrong. it should have been:
-
-```
-0$ ssh remote.example.com git-annex-shell 'configlist' /home/cal/archive/git
-git-annex-shell: Not a git-annex or gcrypt repository.
-1$
-```
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jrollins"
- avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
- subject="comment 8"
- date="2021-02-01T19:30:52Z"
- content="""
-Ok progress! I think we have resolved the issue. The [instructions](https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/) are missing a key command. From the \"set up the server\" section, you need to `git annex init` in the newly created bare git repo, e.g.:
-
-```
-server# cd
-server# git init annex.git --bare --shared
-server# cd annex.git
-server# git annex init server
-```
-
-Once the newly-created bare git repo is git-annex initialized, things seem to work properly. yay!
-
-It also seems to work for both absolute and relatively specified directories on the remote. I have tested with both. So I guess the odd path in the ssh command is a red herring, and git-annex-shell known how to resolve the path correctly. Very good.
-
-Thank you @joey and @lukey for the help. I guess we can close this issue once the instructions are properly updated. Thanks!
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 9"""
- date="2021-02-02T16:14:38Z"
- content="""
-The instructions work with the current version of git-annex
-installed on the server.
-
-It's true that the original version of the tip suggested running git-annex
-init in the repo on the server. I don't remember quite why; I thought
-git-annex always supported remote auto-init.
-
-I've changed this particular tutorial to work, but do note that 6 year old
-versions of git-annex will have numerous bugs that have been fixed since
-then, will be missing numerous features, are significantly slower, and that
-in general this website does not and will not go out of its way to keep
-documentation working for them.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-```
-(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2021/08[master]git
-$> grep 'prop_parse_build_presence_log' cron-*/build-ubuntu.yaml-*/1_test-annex\ \(normal\).txt
-...
-cron-20210810/build-ubuntu.yaml-373-69466103-success/1_test-annex (normal).txt:2021-08-10T02:46:59.4799294Z prop_parse_build_presence_log: OK (1.91s)
-cron-20210811/build-ubuntu.yaml-374-69466103-success/1_test-annex (normal).txt:2021-08-11T02:47:05.9924579Z prop_parse_build_presence_log: OK (2.09s)
-cron-20210812/build-ubuntu.yaml-375-69466103-failed/1_test-annex (normal).txt:2021-08-12T02:49:23.2932499Z prop_parse_build_presence_log: FAIL
-... and so on
-```
-
-so between those two revisions
-
-```
-$> grep 'name:.*8.202108' cron-2021081{1,2}/build-ubuntu.yaml-*/1_test-annex-more.txt
-cron-20210811/build-ubuntu.yaml-374-69466103-success/1_test-annex-more.txt:2021-08-11T02:46:49.4682708Z name: git-annex-debianstandalone-packages_8.20210803+git35-g2df44abad_amd64
-cron-20210812/build-ubuntu.yaml-375-69466103-failed/1_test-annex-more.txt:2021-08-12T02:48:07.7317675Z name: git-annex-debianstandalone-packages_8.20210803+git45-g6318c0f27_amd64
-```
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-08-18T20:38:06Z"
- content="""
-The test suite output includes the random seed that allows reproducing
-the failure.
-
- 2021-08-12T02:49:23.2932499Z prop_parse_build_presence_log: FAIL
- 2021-08-12T02:49:23.2934007Z *** Failed! Exception: 'recoverEncode: invalid argument (invalid character)' (after 3 tests):
- 2021-08-12T02:49:23.2935639Z Exception thrown while showing test case: 'recoverEncode: invalid argument (invalid character)'
- 2021-08-12T02:49:23.2937094Z Use --quickcheck-replay=271417 to reproduce.
-
-And git-annex test has to be run with LANG=C for it to fail.
-
-[[!commit fa62c98910746c2c5dda21b3f80effc147a04f65]] is responsible for this
-failure popping up, somehow. I tried reverting that commit, and it fixed
-the failure.
-
-But I don't understand why that commit would cause this problem.
-Also reverting it is not sufficient, because filepath-bytestring includes
-the same change, in its commit 7e88eb5726d8183987455e15d921dd4c5df94674.
-So if the new code is buggy, RawFilePath conversions could also trigger
-similar problems. Also, these changes were a 2x speedup over the old code.
-
-A similar problem was discussed and fixed long ago
-in [[!commit 4e4e11849a0d95389de81461ba2f2a4e0245d3b2]]:
-
- an Arbitrary String is not necessarily encoded using the filesystem
- encoding, and in a non-utf8 locale, encodeBS throws an exception on such a
- string. All I could think to do is limit test data to ascii.
-
- This shouldn't be a problem in practice, because the all Strings in
- git-annex that are not generated by Arbitrary should be loaded in a way
- that does apply the filesystem encoding.
-
-That makes sense. And it is also encodeBS failing here, in a similar
-situation. But why would the recent change to the implementation of
-encodeBS make it fail, in this case where the old implementation does not?
-
-So I've fixed this by similarly limiting the test to ascii, but I'm unsatisfied
-that the encodeBS implementation change might not break something else. I did
-try, with LANG=C, using git-annex in a repo with some filenames that were
-encoded in unicode, and it round-tripped them fine still, so the change seems
-ok to that extent.
-"""]]
+++ /dev/null
-The smudge --clean filter can fail on a file that uses an URL key:
-
- git-annex: Cannot generate a key for backend URL
- error: external filter 'git-annex smudge --clean -- %f' failed 1
-
-One way to make this happen is:
-
- git annex addurl --fast http://google.com/
- git annex sync
- git annex get
- git annex adjust --unlock
-
-When git-annex adjust runs git checkout of the new branch, git runs
-the clean filter on the unlocked files.
-
-Another way is to have an unlocked URL key file,
-modify it, and run `git add`.
-
-Since the smudge filter fails, git stages the file content into git.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-`git annex sync --content` in an annex on a FAT partition fails if it contains filenames with special characters like `"?:`
-
-
- error: unable to create file music/File "Test".mp3: Invalid argument
-
-
-### What version of git-annex are you using? On what operating system?
-
-debian sid
-
- git-annex version: 7.20190129
- 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
-
-> [[done]], this is a general git behavior, not a git-annex bug --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-02-07T19:16:11Z"
- content="""
-A FAT filesystem cannot contain those characters.
-
-This affects cloning or pulling from any git repository that happens
-to contain such files, it really doesn't have much to do with git-annex.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2019-02-07T19:21:31Z"
- content="""
-Also, "error: unable to create file" is an error message from git, not
-git-annex. And it seems like a perfectly fine error message for the
-situation.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-I'm using a special directory remote for one of my annex repository. This directory is slow (because it's a FUSE-mounted directory), so I decided to symlink /SPECIALREMOTEDIRECTORY/tmp/ to another drive (as tmp/ is just used during the copy operations). However it doesn't work as expected as git-annex seems unable to copy anything from /SPECIALREMOTEDIRECTORY/tmp/ to /SPECIALREMOTEDIRECTORY/.
-
- git annex copy --to special_dir myfile
- copy mlyfile (to special_dir...)
- 100% 288 MiB 26 MiB/s 0s
- /SPECIALREMOTEDIRECTORY/annex/k/tmp/GPGHMACSHA1--800acc67c0803274ed67cea51a1f0df75c225621/: renamePath:rename: unsupported operation (Cross-device link)
- git-annex: copy: 1 failed
-
- ls -l /SPECIALREMOTEDIRECTORY/annex/k/
- drwx------ 1 TroisSinges wheel 167 22 nov 17:49 fe5
- drwx------ 1 TroisSinges wheel 167 22 nov 17:53 ff5
- lrwx------ 1 TroisSinges wheel 18 23 nov 08:04 tmp -> /Users/TroisSinges/tmp
-
-
-### What version of git-annex are you using? On what operating system?
-git-annex version: 7.20181105 (via Homebrew)
-MacOS High Sierra 10.13.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)
-Of course! git-annex is totally amazing in order to manage big collections of files. I'm using it for my videos, and for my photos as well (thousands of files), on Linux and MacOS. Thank you very much for this awesome tool!
-
-> [[closing|done]] per my comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="TroisSinges"
- avatar="http://cdn.libravatar.org/avatar/43f6eb327d2da6cb5bc6d55740e1ed78"
- subject="comment 1"
- date="2018-11-23T07:33:55Z"
- content="""
-Found [this bug](https://github.com/commercialhaskell/hindent/issues/170) in another tool, I think it's the same root cause.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-01-29T18:28:30Z"
- content="""
-The directory special remote writes to a directory under the "tmp"
-directory, and then it renames that into place. Amoung other things that
-makes the update happen atomically. If "tmp" is on another filesystem than
-the final destination, a rename won't work.
-
-I just don't see any point in making this be supported, because if it were,
-git-annex would have to first write to the "tmp" directory, and then
-re-write the same files all over again to the final destination. So making
-the tmp directory be on a faster device can't actually speed anything up.
-It would just make it slower.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Syncing two repositories causes many files that are on both systems to be deleted.
-
-My computers A and B have a directory with 1600 files taking 500MB. I'm trying to sync A to B thus:
-
-git annex sync --no-commit --no-push
-
-This immediately deletes those 1600 files from B. (Before I added -no-push it also deleted those files from A).
-
-Recovering from this with git reset --hard takes 13 minutes, so it's difficult to run experiments. However I have spent about a full day on this over the last week.
-
-### What steps will reproduce the problem?
-
-This repository has evolved over time so I can't give a MWE. However, I created the git repository before initing annex, and did some more work before adding the largefiles option. It's probable that something inside annex is now badly confused.
-
-I don't expect you to solve my particular problem from this report. However, sync has a major hidden problem.
-
-### What version of git-annex are you using? On what operating system?
-
-20160511-1.
-the annex is v6.
-the OS is Ubuntu linux 4.4.0-38-generic
-
-### 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.
-"""]]
-
-.git/annex has no log files, even in subdirs.
-
-There have been occasional reports going back years from other people reporting that sync destroyed massive amounts of their repositories. That this bug persists suggests that the problem is subtle.
-
-I upgraded my annexes to v6 because the concept of locked and unlocked looks good. Then, when researching my problem before posting this bug report, I found a comment that upgrading to v6 is not (now?) recommended because of possible bugs. It would have been nice if this warning were more prominent.
-
-### 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)
-
-The idea is great. Preliminary tests were quite positive. That's why I tried it on my big repositories.
-
-
-> git-annex sync does not do anything to a working tree that git commit
-> and git pull doesn't do. I sync repos all the time and have never seen
-> anything like this. Without a way to reproduce such a bug, I have to
-> assume it was some kind of user error. [[done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-After upgrading Debian Buster to Bullseye (and thus git-annex to 8.20210223-2), two sync `git annex sync --content` jobs have started failing.
-
-One is to an encrypted remote:
-
- sending incremental file list
- 54c/e47/
- 54c/e47/GPGHMACSHA1--REDACTED/
- 54c/e47/GPGHMACSHA1--REDACTED/GPGHMACSHA1--REDACTED
-
- 32,768 8% 0.00kB/s 0:00:00
- 375,589 100% 326.94MB/s 0:00:00 (xfr#1, to-chk=0/5)
-
- failed
- content changed while it was being sent
- content changed while it was being sent
- git-annex: sync: 1 failed
-
-The content hasn't changed as far as I know.
-
-Another is to another local filesystem (from ext4 to ext4):
-
-```
- failed to send content to remote
- failed to send content to remote
- failed to send content to remote
-To /path/to/remote
- XXXXXXXXX..XXXXXXXXX git-annex -> synced/git-annex
- XXXXXXXXX..XXXXXXXXX master -> synced/master
-git-annex: sync: 884 failed
-```
-
-In the latter case, `--debug` prints two ExitFailures:
-
-```
-[2021-09-04 13:21:26.943294346] process [2934668] read: cp ["--reflink=always","--preserve=timestamps",".git/annex/objects/gM/mZ/SHA256E-REDACTED.pdf/SHA256E-REDACTED.pdf","/path/to/remote/.git/annex/tmp/SHA256E-REDACTED.pdf"]
-[2021-09-04 13:21:26.944187444] process [2934668] done ExitFailure 1
-<clip>
-2021-09-04 13:21:52.79239764] process [2936730] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","remote","master"]
-[2021-09-04 13:21:52.808201959] process [2936730] done ExitFailure 1
-```
-
-Manually running that cp command fails with "Permission denied", because the tmp file now exists and has 444 permissions.
-
-### What steps will reproduce the problem?
-
-I haven't tried to reproduce this from a clean repository, but it happens 100 % of the time.
-
-### What version of git-annex are you using? On what operating system?
-
-git-annex 8.20210223-2 on Debian 11/Bullseye.
-
-### 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)
-
-These sync worked fine before upgrade.
-
-> [[fixed|done]] in git-annex 8.20210803 --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-09-06T17:59:48Z"
- content="""
-Upgrade -- these problems are fixed already in version 8.20210803.
-
-I have filed a debian bug report suggesting they backport the fixes.
-"""]]
+++ /dev/null
-Given that repo1 and repo2 both have a branch adjusted/master(hidemissing), those branches should be local to the repo as they contain the files available locally. Yet, when doing a sync between the two repositories, the branches are forcefully merged which is wrong.
-
- $ git annex sync
- commit (recording state in git...)
- On branch master
- nothing to commit, working tree clean
- ok
- remote: Enumerating objects: 332, done.
- remote: Counting objects: 100% (332/332), done.
- remote: Compressing objects: 100% (185/185), done.
- remote: Total 232 (delta 35), reused 0 (delta 0)
- Receiving objects: 100% (232/232), 20.46 KiB | 1.57 MiB/s, done.
- Resolving deltas: 100% (35/35), completed with 2 local objects.
- From /media/leggewie/WD250G/@1TB.work
- + 20bcd18...170148a adjusted/master(hidemissing) -> WD250G/adjusted/master(hidemissing) (forced update)
- a071f8c..4a1f6d3 git-annex -> WD250G/git-annex
- pull WD250G ok
-
-> [[not a bug|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-05-03T10:26:35Z"
- content="""
-Hmm, from the output above, it is just updating the remote-tracking branch. So it shouldn't affect the local `adjusted/master(hidemissing)` branch at all.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-07-13T17:27:57Z"
- content="""
-Like Lukey said, your output does not show branches being "forcibly merged". What it shows
-is `git fetch WD250G` running and fetching a
-"WD250G/adjusted/master(hidemissing)" ref. That updates a previous version
-of that it fetched from the remote before.
-
-Nothing else will be done with that ref, as far as I can see. It's just
-being maintained by git as a remote tracking branch, the same as it would
-keep track of any other branch that happened to be on the remote.
-
-You can configure git to not fetch this or other branches, by
-changing the remote.WD250G.fetch git config.
-
-Now, what `git annex sync` does do, when in an adjusted branch, is
-propigate any changes that you have made to that branch back to the master
-branch, and then it pushes the master branch over to the remote. And if the
-remote is also in an adjusted branch, then running `git annex sync` on
-the remote will merge in those changes from the master branch. But
-when the branch is a --hide-missing branch, this process does not cause
-files that are missing on the one repo to get deleted from the branch on
-the other repo.
-"""]]
+++ /dev/null
-I have a client, non-bare, direct mode repository on a USB key. I use this to work on my files on Windows terminals at work. When I return to my own (Debian) workstation at home, I mount the drive, `cd /media/swhitton/SPWHITTON/annex && git annex sync --content`. This sync the contents of the key with both my workstation's `/home` and a remote VPS over SSH. When the sync is complete, Thunar can't unmount the key because git annex leaves ssh connections to my VPS open, with the working directory inside `/media/swhitton/SPWHITTON/annex`. So I have to run `pkill ssh`. It would be great if `git annex sync` could detect that a non-bare repository is on removable media, and not leave SSH connections open when it's finished the sync. Thanks! --spwhitton
-
-> Closing because spwhitton did not followup with a way to reproduce the
-> problem. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-04-20T16:47:50Z"
- content="""
-git-annex always registers a cleanup action when it starts using a ssh
-connection caching socket. As long as git-annex gets a change to shut down
-cleanly (ie is not interrupted), it should run the action to stop the ssh
-connection caching.
-
-For example, git-annex sync --debug here shows as its second to last line:
-
- [2016-04-20 12:47:40.069633] read: ssh ["-O","stop","-S","server","-o","ControlMaster=auto","-o","ControlPersist=yes","server"]
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="spwhitton"
- subject="comment 2"
- date="2016-04-20T19:01:21Z"
- content="""
-Thanks for letting me know about that functionality. I'll try to isolate why it sometimes fails on my machine.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Here's a new one :)
-
-Running the test QuickCheck.prop_relPathDirToFileAbs_basics fails in a particular case (but only occasionally).
-
-Running the following fails:
-
-[[!format sh """
-jkniiv@AINESIS MINGW64 /c/annx
-$ ./git-annex test -p QuickCheck.prop_relPathDirToFileAbs_basics --quickcheck-replay=564957 2>&1 | tee git-annex.test--p-QuickCheck_prop_relPathDirToFileAbs_basics.LOG~201
-Tests
- QuickCheck
- prop_relPathDirToFileAbs_basics: FAIL (0.05s)
- *** Failed! Falsified (after 795 tests):
- TestableFilePath {fromTestableFilePath = ":\\\DLEJ\STXm{u5;4*\EOTKo1"}
- Use --quickcheck-replay=564957 to reproduce.
-
-1 out of 1 tests failed (0.05s)
- (Failures above could be due to a bug in git-annex, or an incompatibility
- with utilities, such as git, installed on this system.)
-
-# End of transcript.
-"""]]
-
-If you remove the option `--quickcheck-replay=564957`, the test usually passes.
-
-### What version of git-annex are you using? On what operating system?
-
-[[!format sh """
-git-annex version: 8.20210804-gccf7e5b94
-build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: mingw32 x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 2 3 4 5 6 7
-"""]]
-
-Windows version 21H1 (build 19043.1165), 64 bit.
-
-### 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)
-
-Git Annex is great. It works with multi-gigabyte backup files (largest around 180GB) via the BLAKE2B160E backend just dandy :)
-
-[[!meta author=jkniiv]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-09-01T14:54:56Z"
- content="""
-Reproduced on Linux using System.FilePath.Windows.
-
-Minimal case is:
-
- ghci> let p = "\\\\\DLEJ\STXm{u5;4*\EOTKo1"
- ghci> relPathDirToFileAbs (p </> "bar") p
- "\\\\\DLEJ\STXm{u5;4*\EOTKo1"
-
-Which should be "bar", but the "normdrive" case in
-relPathDirToFileAbs causes it to not return that.
-
-Ah, that whole value is treated as a "drive letter" due to starting
-with "\\\\" and not containing any path separator.
-
- ghci> takeDrive p
- "\\\\\DLEJ\STXm{u5;4*\EOTKo1"
-
-And takeDrive includes the first path separator, which is present in one
-string and not in another. So, it thinks these paths are on
-two different drives, when they are not. And that's the root
-of the problem. normdrive was working around that by taking up until
-the ':', but there *is* no ':' in this drive letter!
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jkniiv"
- avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
- subject="comment 2"
- date="2021-09-02T05:24:14Z"
- content="""
-I can confirm that commit 9595a247a seems to fix the test case with quickcheck random seed value 564957
-(`--quickcheck-replay=564957`) on my Windows laptop.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-Running the test QuickCheck.prop_view_roundtrips fails in a particular case (but only occasionally).
-
-Running the following fails:
-
-[[!format sh """
-jkniiv@AINESIS MINGW64 /c/annx
-$ ./git-annex.exe test -p 'QuickCheck.prop_view_roundtrips' --quickcheck-replay=258328 --quickcheck-verbose 2>&1 | tee git-annex.test--p-QuickCheck_prop_view_roundtrips.LOG~201
-[...]
-$ tail -n 50 git-annex.test--p-QuickCheck_prop_view_roundtrips.LOG~201
-
- Passed:
- AssociatedFile Nothing
- MetaData (fromList [(MetaField "J",fromList []),(MetaField "kk",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\ACK",MetaValue (CurrentlySet False) "2ml",MetaValue (CurrentlySet False) "h",MetaValue (CurrentlySet False) "s\RS",MetaValue (CurrentlySet True) "u",MetaValue (CurrentlySet True) "yp"]),(MetaField "R",fromList [MetaValue (CurrentlySet True) "\NUL",MetaValue (CurrentlySet True) "\EOT",MetaValue (CurrentlySet False) "\r\DC1Fm",MetaValue (CurrentlySet False) "7\DC1~0#",MetaValue (CurrentlySet True) "b"]),(MetaField "Wq",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\USnZ\NAK\NAK"]),(MetaField "z",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "&C0GZ\DLE`",MetaValue (CurrentlySet False) "y",MetaValue (CurrentlySet False) "{\t\CAN\tHJ"])])
- False
-
- Passed:
- AssociatedFile (Just "\DC3Q\ENQ\SUB#6}9F5\NAK4\ACKQ\ETB;W\vN\ENQ\STXn\EM\ENQFy5\SO(?}qA\v\NAK")
- MetaData (fromList [(MetaField "cK",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\b;D-&\DC3\SOLvs",MetaValue (CurrentlySet True) "-L`vI\EOT",MetaValue (CurrentlySet True) "Lf\NUL%^\ACKY",MetaValue (CurrentlySet True) "Q\ETB\SYN\US"])])
- True
-
- Passed:
- AssociatedFile (Just "$GC7\nW]\DC16=z\STX]a1)L\NAK[\EOT71`Oi[DT`\SYNU\STXU>/%tEi:\SUBq\EM'Q\CANV\\\RS")
- MetaData (fromList [(MetaField "1",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\njX",MetaValue (CurrentlySet True) "\fpL",MetaValue (CurrentlySet False) "!\ESC@E#r9",MetaValue (CurrentlySet True) "6",MetaValue (CurrentlySet False) "C\tJK)",MetaValue (CurrentlySet True) "{"]),(MetaField "6NS",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) ";\SOs%",MetaValue (CurrentlySet False) "=",MetaValue (CurrentlySet True) "P",MetaValue (CurrentlySet False) "T !\STX\SOH",MetaValue (CurrentlySet False) "f&\NUL,\SUB",MetaValue (CurrentlySet False) "r\SUBi*&)"]),(MetaField "d",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "\RS",MetaValue (CurrentlySet True) "],x\CAN",MetaValue (CurrentlySet False) "c",MetaValue (CurrentlySet False) "n4I\SYN\n,"]),(MetaField "g",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\DC3F\r",MetaValue (CurrentlySet True) "= ",MetaValue (CurrentlySet False) "[",MetaValue (CurrentlySet True) "[Y.",MetaValue (CurrentlySet False) "]",MetaValue (CurrentlySet False) "nPHQ"]),(MetaField "Gb",fromList []),(MetaField "p9",fromList [MetaValue (CurrentlySet False) ""]),(MetaField "Q",fromList []),(MetaField "s9",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\US",MetaValue (CurrentlySet False) ","]),(MetaField "v",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "_q"]),(MetaField "x",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "4",MetaValue (CurrentlySet False) "4\r.\NAKrk",MetaValue (CurrentlySet False) "UNN",MetaValue (CurrentlySet True) "h"])])
- True
-
- Passed:
- AssociatedFile Nothing
- MetaData (fromList [(MetaField "56",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet False) ")/",MetaValue (CurrentlySet False) ". 8@\SYNQU\DLEl",MetaValue (CurrentlySet True) "2",MetaValue (CurrentlySet False) "nF"]),(MetaField "G",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\r6\NAK{@\NAKn\GS",MetaValue (CurrentlySet False) "\US!> [Y.",MetaValue (CurrentlySet True) "*c\DC37lq\"C",MetaValue (CurrentlySet True) "0",MetaValue (CurrentlySet True) "[@w`kZu",MetaValue (CurrentlySet True) "bw+\ESC"]),(MetaField "HhUjK",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "\NUL=",MetaValue (CurrentlySet True) "\NAKie",MetaValue (CurrentlySet False) ".\DC3+^;\a!s\NAK",MetaValue (CurrentlySet True) "8",MetaValue (CurrentlySet False) "B",MetaValue (CurrentlySet False) "J",MetaValue (CurrentlySet True) "~"]),(MetaField "p7i",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "TO",MetaValue (CurrentlySet False) "gx",MetaValue (CurrentlySet False) "lQqb\SUB:)\ACKX"]),(MetaField "qXr",fromList []),(MetaField "T",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "TF;",MetaValue (CurrentlySet True) "\\DZ",MetaValue (CurrentlySet False) "aOY_6",MetaValue (CurrentlySet True) "{xm;r"]),(MetaField "vOF",fromList [MetaValue (CurrentlySet True) "\DLE",MetaValue (CurrentlySet True) "\DC2L\DC1",MetaValue (CurrentlySet True) "\"|",MetaValue (CurrentlySet False) "H\EOT!3"]),(MetaField "vQ",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "\DLEp",MetaValue (CurrentlySet False) "\CANw#\DEL_G*W0pZ8",MetaValue (CurrentlySet True) "D",MetaValue (CurrentlySet True) "Lx6O\SO=C\\("]),(MetaField "Y",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "\ETB2",MetaValue (CurrentlySet False) "P\v",MetaValue (CurrentlySet False) "d$\SYN"])])
- True
-
- Passed:
- AssociatedFile (Just "\ESC")
- MetaData (fromList [(MetaField "9CY",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "7y\EOT",MetaValue (CurrentlySet True) "D$\f^\"\r{`",MetaValue (CurrentlySet False) "xpo\SOHq"]),(MetaField "aMO",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\ENQE\at",MetaValue (CurrentlySet True) "\DC4\"1",MetaValue (CurrentlySet True) "7J\n,Z&0j",MetaValue (CurrentlySet False) "T8|3",MetaValue (CurrentlySet False) "UZ",MetaValue (CurrentlySet False) "n\n",MetaValue (CurrentlySet False) "uZ:]K.z~\fa"]),(MetaField "H",fromList [MetaValue (CurrentlySet True) "hEu"]),(MetaField "LbT",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\ENQM7",MetaValue (CurrentlySet False) "\b0F`;",MetaValue (CurrentlySet False) "\CAN\USs",MetaValue (CurrentlySet True) "C",MetaValue (CurrentlySet False) "K",MetaValue (CurrentlySet True) "\\}(g_"]),(MetaField "v",fromList [MetaValue (CurrentlySet True) "ES"])])
- False
-
- Passed:
- AssociatedFile Nothing
- MetaData (fromList [(MetaField "J",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet False) "b(4G",MetaValue (CurrentlySet False) "bf\"\STXCF\DEL",MetaValue (CurrentlySet True) "i\DC3VB^"]),(MetaField "O",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet False) "\STXAX\US5",MetaValue (CurrentlySet True) "\ESC",MetaValue (CurrentlySet False) "&\GS\DEL\SOH)i\ACK,",MetaValue (CurrentlySet False) "3I4\DLE",MetaValue (CurrentlySet True) "J",MetaValue (CurrentlySet True) "t",MetaValue (CurrentlySet False) "yD6t"]),(MetaField "p",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\EOTM1ZcA",MetaValue (CurrentlySet True) "\nK",MetaValue (CurrentlySet False) ")\GS",MetaValue (CurrentlySet True) ".P'\RSJZ&\DC1\ETB\rz",MetaValue (CurrentlySet False) "1;",MetaValue (CurrentlySet True) "f4Z\SOHr",MetaValue (CurrentlySet False) "gkl"]),(MetaField "XaF",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "@",MetaValue (CurrentlySet False) "H4o?2\\K\EM",MetaValue (CurrentlySet False) "IQ\DC3p"])])
- False
-
- Failed:
- AssociatedFile (Just "A<#;\SUB\ETB]u v\FS?\bY\SUB9b%\DC4%Ws\\\aJ\FS4\rM\DC1\CAN6g;(TL\US5\\X:l!nFb\ENQ")
- MetaData (fromList [(MetaField "H",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "1=x",MetaValue (CurrentlySet True) ">\STX",MetaValue (CurrentlySet False) "H}9"]),(MetaField "HJ",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\f",MetaValue (CurrentlySet True) "\DC1\DC4Xw{aX",MetaValue (CurrentlySet False) "'\"{",MetaValue (CurrentlySet False) "'9\USKB*\r",MetaValue (CurrentlySet True) "I)\ar",MetaValue (CurrentlySet False) "l"]),(MetaField "m",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\GS#"]),(MetaField "ub",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\DC3{5q9",MetaValue (CurrentlySet False) ")",MetaValue (CurrentlySet False) "C\\!H",MetaValue (CurrentlySet False) "|"])])
- True
-
- Passed:
- AssociatedFile (Just "A<#;\SUB\ETB]u v\FS?\bY\SUB9b%\DC4%Ws\\\aJ\FS4\rM\DC1\CAN6g;(TL\US5\\X:l!nFb\ENQ")
- MetaData (fromList [(MetaField "H",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "1=x",MetaValue (CurrentlySet True) ">\STX",MetaValue (CurrentlySet False) "H}9"]),(MetaField "HJ",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\f",MetaValue (CurrentlySet True) "\DC1\DC4Xw{aX",MetaValue (CurrentlySet False) "'\"{",MetaValue (CurrentlySet False) "'9\USKB*\r",MetaValue (CurrentlySet True) "I)\ar",MetaValue (CurrentlySet False) "l"]),(MetaField "m",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\GS#"]),(MetaField "ub",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\DC3{5q9",MetaValue (CurrentlySet False) ")",MetaValue (CurrentlySet False) "C\\!H",MetaValue (CurrentlySet False) "|"])])
- False
-
- *** Failed! Falsified (after 385 tests):
- AssociatedFile (Just "A<#;\SUB\ETB]u v\FS?\bY\SUB9b%\DC4%Ws\\\aJ\FS4\rM\DC1\CAN6g;(TL\US5\\X:l!nFb\ENQ")
- MetaData (fromList [(MetaField "H",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "1=x",MetaValue (CurrentlySet True) ">\STX",MetaValue (CurrentlySet False) "H}9"]),(MetaField "HJ",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\f",MetaValue (CurrentlySet True) "\DC1\DC4Xw{aX",MetaValue (CurrentlySet False) "'\"{",MetaValue (CurrentlySet False) "'9\USKB*\r",MetaValue (CurrentlySet True) "I)\ar",MetaValue (CurrentlySet False) "l"]),(MetaField "m",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\GS#"]),(MetaField "ub",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet True) "\DC3{5q9",MetaValue (CurrentlySet False) ")",MetaValue (CurrentlySet False) "C\\!H",MetaValue (CurrentlySet False) "|"])])
- True
- Use --quickcheck-replay=258328 to reproduce.
-
-1 out of 1 tests failed (0.76s)
- (Failures above could be due to a bug in git-annex, or an incompatibility
- with utilities, such as git, installed on this system.)
-
-# End of transcript.
-"""]]
-
-If you remove the option `--quickcheck-replay=258328`, the test usually passes.
-
-By the way, if this bug report looks similar to the one I filed in commit 145c343b4 some 9 months back, indeed it is.
-I usually disregard these occasional test failures by simply running the tests again because that seems the
-path of least resistance. However, I just filed a simple compilation issue + patch today[^1], so I thought this would
-be a reasonable thing to do with the same effort involved.
-
-[^1]: [[bugs/commit_7550ef9a2_doesn__39__t_compile_on_Windows--patch]]
-
-### What version of git-annex are you using? On what operating system?
-
-[[!format sh """
-git-annex version: 8.20210804-g7550ef9a2
-build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: mingw32 x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 2 3 4 5 6 7
-"""]]
-
-This is built with the additional patch mentioned in [[bugs/commit_7550ef9a2_doesn__39__t_compile_on_Windows--patch]].
-
-Windows version 21H1 (build 19043.1165), 64 bit.
-
-### Please provide any additional information below.
-
-(The transcript is above. If you need more than the last 50 lines of the test log file, I'm happy to provide 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 is great. It works with multi-gigabyte backup files (largest around 180GB) via the BLAKE2B160E backend just dandy :)
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-08-24T17:01:01Z"
- content="""
-I fixed the other, similar bug shortly after you filed it. Please do file
-bug reports for intermittent test suite breakage like this.
-
-This does not reproduce on linux with --quickcheck-replay=258328, it's
-windows specific. I can reproduce it by subbing in the windows filepath
-modules on linux.
-
-Simplified:
-
- ghci> let f = AssociatedFile (Just "foo\\X:l")
- ghci> let m = MetaData (fromList [(MetaField "H",S.fromList [MetaValue (CurrentlySet True) ">"]),(MetaField "HJ",S.fromList [MetaValue (CurrentlySet True) "a"]),(MetaField "m",S.fromList [MetaValue (CurrentlySet True) "#"]),(MetaField "ub",S.fromList [MetaValue (CurrentlySet True) "9"])])
- ghci> prop_view_roundtrips f m True
- False
-
-Looks like viewedFileFromReference of that filename produces "X:l_%\\\\%",
-which won't work because that looks like a drive letter.
-
-This can't occur in real life, because "X:l" can't be the name of a file
-in a directory "foo".
-
-Fixed.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="jkniiv@b330fc3a602d36a37a67b2a2d99d4bed3bb653cb"
- nickname="jkniiv"
- avatar="http://cdn.libravatar.org/avatar/419f2eee8b0c37256488fabcc2737ff2"
- subject="will do"
- date="2021-08-24T21:45:27Z"
- content="""
-Thanks. I'll try to be more diligent in the future in reporting these type of bugs when I see them. :)
-
-I can confirm that commit 4ed36b263 seems to fix the test case with quickcheck random seed value 258328
-(`--quickcheck-replay=258328`) on my Windows laptop:
-
-[[!format sh \"\"\"
-jkniiv@AINESIS MINGW64 /c/annx
-$ grep -C 10 'TL\\US5\\\\X:l!nFb\\ENQ' git-annex.test--p-QuickCheck_prop_view_roundtrips.LOG~201
- AssociatedFile (Just \"\ESC\")
- MetaData (fromList [(MetaField \"9CY\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet True) \"7y\EOT\",MetaValue (CurrentlySet True) \"D$\f^\\"\r{`\",MetaValue (CurrentlySet False) \"xpo\SOHq\"]),(MetaField \"aMO\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet True) \"\ENQE\at\",MetaValue (CurrentlySet True) \"\DC4\\"1\",MetaValue (CurrentlySet True) \"7J\n,Z&0j\",MetaValue (CurrentlySet False) \"T8|3\",MetaValue (CurrentlySet False) \"UZ\",MetaValue (CurrentlySet False) \"n\n\",MetaValue (CurrentlySet False) \"uZ:]K.z~\fa\"]),(MetaField \"H\",fromList [MetaValue (CurrentlySet True) \"hEu\"]),(MetaField \"LbT\",fromList [MetaValue (CurrentlySet True) \"\",MetaValue (CurrentlySet True) \"\ENQM7\",MetaValue (CurrentlySet False) \"\b0F`;\",MetaValue (CurrentlySet False) \"\CAN\USs\",MetaValue (CurrentlySet True) \"C\",MetaValue (CurrentlySet False) \"K\",MetaValue (CurrentlySet True) \"\\}(g_\"]),(MetaField \"v\",fromList [MetaValue (CurrentlySet True) \"ES\"])])
- False
-
- Passed:
- AssociatedFile Nothing
- MetaData (fromList [(MetaField \"J\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet False) \"b(4G\",MetaValue (CurrentlySet False) \"bf\\"\STXCF\DEL\",MetaValue (CurrentlySet True) \"i\DC3VB^\"]),(MetaField \"O\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet False) \"\STXAX\US5\",MetaValue (CurrentlySet True) \"\ESC\",MetaValue (CurrentlySet False) \"&\GS\DEL\SOH)i\ACK,\",MetaValue (CurrentlySet False) \"3I4\DLE\",MetaValue (CurrentlySet True) \"J\",MetaValue (CurrentlySet True) \"t\",MetaValue (CurrentlySet False) \"yD6t\"]),(MetaField \"p\",fromList [MetaValue (CurrentlySet True) \"\",MetaValue (CurrentlySet True) \"\EOTM1ZcA\",MetaValue (CurrentlySet True) \"\nK\",MetaValue (CurrentlySet False) \")\GS\",MetaValue (CurrentlySet True) \".P'\RSJZ&\DC1\ETB\rz\",MetaValue (CurrentlySet False) \"1;\",MetaValue (CurrentlySet True) \"f4Z\SOHr\",MetaValue (CurrentlySet False) \"gkl\"]),(MetaField \"XaF\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet True) \"@\",MetaValue (CurrentlySet False) \"H4o?2\\K\EM\",MetaValue (CurrentlySet False) \"IQ\DC3p\"])])
- False
-
- Passed:
- AssociatedFile (Just \"A<#;\SUB\ETB]u v\FS?\bY\SUB9b%\DC4%Ws\\\aJ\FS4\rM\DC1\CAN6g;(TL\US5\\X:l!nFb\ENQ\")
- MetaData (fromList [(MetaField \"H\",fromList [MetaValue (CurrentlySet True) \"\",MetaValue (CurrentlySet False) \"1=x\",MetaValue (CurrentlySet True) \">\STX\",MetaValue (CurrentlySet False) \"H}9\"]),(MetaField \"HJ\",fromList [MetaValue (CurrentlySet True) \"\",MetaValue (CurrentlySet True) \"\f\",MetaValue (CurrentlySet True) \"\DC1\DC4Xw{aX\",MetaValue (CurrentlySet False) \"'\\"{\",MetaValue (CurrentlySet False) \"'9\USKB*\r\",MetaValue (CurrentlySet True) \"I)\ar\",MetaValue (CurrentlySet False) \"l\"]),(MetaField \"m\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet True) \"\GS#\"]),(MetaField \"ub\",fromList [MetaValue (CurrentlySet True) \"\",MetaValue (CurrentlySet True) \"\DC3{5q9\",MetaValue (CurrentlySet False) \")\",MetaValue (CurrentlySet False) \"C\\!H\",MetaValue (CurrentlySet False) \"|\"])])
- True
-
- Passed:
- AssociatedFile (Just \"\\+4xu#WC@\ENQ#%Txfh\n9Am};\tv!\ETB8\")
- MetaData (fromList [(MetaField \"I\",fromList [MetaValue (CurrentlySet True) \"\NAK\"])])
- True
-
- Passed:
- AssociatedFile (Just \"\SOH^=Fs\DC3Cmbt/\ESC5\US S\ETB\f}y%\GS\GSlwL\SOH\\N<T\SYN7\\"I\")
-
-\"\"\"]]
-
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-
-```
- retrieveKeyFile: FAIL
- Exception: .git\annex\objects\fc0\296\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key: DeleteFile "\\\\?\\C:\\Users\\runneradmin\\.t\\main2\\.git\\annex\\objects\\fc0\\296\\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key\\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key": permission denied (Access is denied.)
- fsck downloaded object: OK (0.01s)
- retrieveKeyFile resume from 33%: FAIL
- Exception: .git\annex\tmp\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key: openBinaryFile: permission denied (Permission denied)
- fsck downloaded object: OK (0.01s)
- retrieveKeyFile resume from 0: FAIL
- Exception: .git\annex\tmp\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key: openFile: permission denied (Permission denied)
- fsck downloaded object: OK (0.01s)
-cp: cannot create regular file '.git\annex\tmp\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key': Permission denied
- retrieveKeyFile resume from end: FAIL
- Exception: .git\annex\objects\fc0\296\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key: DeleteFile "\\\\?\\C:\\Users\\runneradmin\\.t\\main2\\.git\\annex\\objects\\fc0\\296\\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key\\SHA256E-s1048576--c347f274df214671e3bebb6674cc5d2e6c226d8358a416859d5fc3c79a08eb1f.this-is-a-test-key": permission denied (Access is denied.)
- fsck downloaded object: OK (0.01s)
- removeKey when present: OK (0.09s)
-```
-
-I think this fail is relatively recent since [5 days ago](https://github.com/datalad/git-annex/actions/runs/746941168) is green for git-annex (but red for datalad). Overall [today's log](https://github.com/datalad/git-annex/runs/2377452030?check_suite_focus=true) for 8.20210331-ge3de27dcc says `126 out of 833 tests failed (599.24s)`
-
-not sure if relates to [ubuntu build fails](https://git-annex.branchable.com/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy/) which seems to be less wild, so filing separately
-
-> Fixed by disabling the failing tests on windows, see comments for the
-> gory details. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-04-20T15:10:00Z"
- content="""
-It's possible it had the same cause as the other failure, which I've now
-fixed. That involved a file handle leak, and on windows a file handle being
-left open for write is treated the same as the file being locked and will
-prevent a later deletion attempt and also a later write attempt, which
-could explain the two unlike failures.
-
-However, the file that was left open was a temp file in the remote,
-not the object file in the annex. So I'm not sure if it's fixed.
-Also possible something else in the windows code path changed accidentially
-during those CoW changes. Will have to see what happens when the
-autobuilder runs again.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-04-21T16:11:15Z"
- content="""
-Still failing on windows after other fix.
-
-More context on the failure shows it cannot be related to exporting,
-this is pure key/value store operation.
-
- key size 1048576; directory remote chunksize=0 encryption=none
- removeKey when not present: OK (0.07s)
- present False: OK (0.07s)
- storeKey: OK (0.02s)
- present True: OK
- storeKey when already present: OK (0.02s)
- present True: OK
- retrieveKeyFile: OK (0.17s)
- fsck downloaded object: OK
- retrieveKeyFile resume from 33%: FAIL
- Exception: .git\annex\objects\d78\ee7\SHA256E-s1048576--b9be1c0379146c0bc17c03d1caa8fb1c9d25cc741f59c09ab27379d5fc41862d.this-is-a-test-key\SHA256E-s1048576--b9be1c0379146c0bc17c03d1caa8fb1c9d25cc741f59c09ab27379d5fc41862d.this-is-a-test-key: DeleteFile "\\\\?\\C:\\Users\\runneradmin\\.t\\main2\\.git\\annex\\objects\\d78\\ee7\\SHA256E-s1048576--b9be1c0379146c0bc17c03d1caa8fb1c9d25cc741f59c09ab27379d5fc41862d.this-is-a-test-key\\SHA256E-s1048576--b9be1c0379146c0bc17c03d1caa8fb1c9d25cc741f59c09ab27379d5fc41862d.this-is-a-test-key": permission denied (Access is denied.)
-
-Also, the directory special remote exporttree tests actually pass!
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-04-21T16:21:15Z"
- content="""
-Note that, before it fails, retrieveKeyFile has already succeeded once.
-
-It may be that the cause is that the earlier retrieveKeyFile leaves
-the annex object file somehow inaccessible.
-
-Or it may be that the cause is in Command.TestRemote's code
-that sets up this "resume from 33%" test case:
-
- loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
- tmp <- fromRawFilePath <$> prepTmp k
- partial <- liftIO $ bracket (openBinaryFile loc ReadMode) hClose $ \h -> do
- sz <- hFileSize h
- L.hGet h $ fromInteger $ sz `div` 3
- liftIO $ L.writeFile tmp partial
- lockContentForRemoval k noop removeAnnex -- appears that this is what fails to delete the file
-
-If the handle that is opened to read the annex object file somehow
-causes it to linger in a locked state past when the handle should be closed,
-it could cause the later failure to delete the annex object file, since windows
-may consider an open file handle to be a lock.
-
-(Some issues with ghc not promptly closing file handles, in a version
-in the last year or so, come to mind..)
-
-I've swapped the order of the resume from 33% and resume from 0%
-tests. The 0% test does not open a handle that way. So if the
-resume from 0% still fails, we'll know for sure the problem is not
-caused by the 33% test.
-
-If it is caused by the CoW changes, it seems likely to involve fileCopier's
-code that tries to preserve the source file's mode. Before the CoW
-changes, I don't think that was done by Remote.Directory's retrieveKeyFile.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2021-04-23T03:14:53Z"
- content="""
-I tried to reproduce this, but here the same part of the
-test suite fails at an earlier point:
-
- Remote Tests
- testremote type git
- init:
- Detected a filesystem without fifo support.
-
- Disabling ssh connection caching.
-
- Detected a crippled filesystem.
- (scanning for unlocked files...)
- FAIL
- Exception: MoveFileEx "C:\\Users\\IEUser\\AppData\\Local\\Temp\\ranD3A1" Just ".git\\annex\\objects\\37a\\645\\SHA256E-s1048576--bc48211bf79f8e756afe5cb3c44ac0b291da541d27647d3ebec17f73aa2a04c1.this-is-a-test-key\\SHA256E-s1048576--bc48211bf79f8e756afe5cb3c44ac0b291da541d27647d3ebec17f73aa2a04c1.this-is-a-test-key": does not exist (The system cannot find the path specified.)
-
-This failure is really weird. It's Command.TestRemote.randKey failing
-to move the temp file it just created into the annex object directory.
-I added some debugging just before it moves the file, to see which of
-source or destination didn't exist. Result is: Both do exist!
-
- doesFileExist "C:\\Users\\IEUser\\AppData\\Local\\Temp\\ranDD65"
- True
- doesDirectoryExist ".git\\annex\\objects\\bf8\\db3\\SHA256E-s1048576--e5c9f51441e7f2669ee7fd518c12c65f1e71fc07416abb4ddee5abcd0333f068.this-is-a-test-key"
- True
- MoveFileEx "C:\\Users\\IEUser\\AppData\\Local\\Temp\\ranDD65" Just ".git\\annex\\objects\\bf8\\db3\\SHA256E-s1048576--e5c9f51441e7f2669ee7fd518c12c65f1e71fc07416abb4ddee5abcd0333f068.this-is-a-test-key\\SHA256E-s1048576--e5c9f51441e7f2669ee7fd518c12c65f1e71fc07416abb4ddee5abcd0333f068.this-is-a-test-key": does not exist (The system cannot find the path specified.)
-
-WTF
-
-Anyway, I could chase these kind of things for a year and the windows port
-would be no better than it's ever been. The point is I currently have no way to
-reproduce or debug the original problem except for an autobuilder with a 1 day
-turnaround time that's building the master branch.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2021-04-23T04:21:05Z"
- content="""
-Results from Windows autobuilder with the 0% test being the first test ran:
-That test succeeded, and then the 33% test failed. So apparently the first
-retrieveKeyFile is setting up a situation where the second one fails.
-
-Meanwhile, on Linux, I have verified that there is no leaking file handle
-by retrieveKeyFile. Which doesn't mean there isn't on windows, but if there
-is, it's a ghc bug or a Windows bug and not a bug I can do anything about.
-
-Also, manually testing the directory special remote, not using the test
-suite, retrieveKeyFile seems to work ok, even when run multiple times.
-
-I have disabled the remote tests on Windows.
-"""]]
+++ /dev/null
-git-annex unannex (or uninit) with an annexed file that is modified loses
-the modified version, replacing it with the last annexed version.
-This is a data loss bug.
-
-Command.Unannex.cleanup just overwrites whatever's there without checking.
-Happens with both locked and unlocked files. --[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-```
-❯ git annex uninit
-fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
-Use '--' to separate paths from revisions, like this:
-'git <command> [<revision>...] -- [<file>...]'
-error: branch 'git-annex' not found.
-git-annex: git [Param "branch",Param "-D",Param "git-annex"] failed
-CallStack (from HasCallStack):
- error, called at ./Git/Command.hs:42:17 in main:Git.Command
-```
-
-### What steps will reproduce the problem?
-
-I guess:
-- git annex init
-- git annex uninit
-But I fear about my files so I won't try
-
-### What version of git-annex are you using? On what operating system?
-
-latest on arch linux
-```sh
-❯ git annex version
-git-annex version: 8.20210803-g9cae7c5bb
-build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-9.0.1 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.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 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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: linux x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 0 1 2 3 4 5 6 7
-```
-
-> Fixed both problems, although I don't know how a git-annex branch could
-> not exist. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-11-08T20:24:15Z"
- content="""
-It seems that not only does your repository not
-have any commits in master, it also lacks a git-annex branch.
-
-Since `git-annex init` creates the git-annex branch, and git will
-refuse to clone a repo with no master branch, I don't know how you
-could have gotten a repo in this state.
-(Aside from manually deleting the branch first.)
-
-With a git-annex branch, I see only the unknown HEAD warning,
-but it does succeed.
-"""]]
+++ /dev/null
-### Please describe the problem.
-
-I am wondering if there is an option to use the new 3-letter hash format in `.git/annex/objects` folder even if the file system is not crippled. The use case is that I have a git-annex repository in a Linux server that I sometimes mount with Samba, but then I can't open some locked annexed files because of the case-sensitiveness of the old 2-letter hash format.
-
-### What version of git-annex are you using? On what operating system?
-git-annex 8 on 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)
-
-Without Samba it's fine :-)
-
-> This does not seem to be an actionable bug. git-annex has to consistently
-> use the same hash format, unless all files are unlocked. So, [[done]] I
-> suppose. --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2020-06-11T18:05:55Z"
- content="""
-I think you should simply `git annex adjust --unlock` in that repository.
-Get rid of the symlinks from it, and the case sensitivity issues will, I
-hope, not matter. This is the same thing git-annex automatically does when
-initializating a repo on a crippled filesystem.
-
-The other way would be to set annex.tune.objecthashlower=true, see
-[[tuning]], but that can only be done when setting up a new repository,
-since it makes the lower-case hash be used everywhere. (Which is what I'd do
-if I had a time machine.)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="ntraut9@6c7c5e5bfddb591c28ab8222f1de9cb56840a69e"
- nickname="ntraut9"
- avatar="http://cdn.libravatar.org/avatar/c39ac3cf2806b08e1fdf8384c2817e6c"
- subject="comment 2"
- date="2021-04-26T16:01:02Z"
- content="""
-So I can do `git annex config --set annex.tune.objecthashlower true` to use the new hash format.
-I don't see why it couldn't become the default since it can be done even on existing repositories. It is just that already stored files will not be directly recoverable since the path expected will not be the same, but for newly created repositories I really don't see any problem.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="ntraut9@6c7c5e5bfddb591c28ab8222f1de9cb56840a69e"
- nickname="ntraut9"
- avatar="http://cdn.libravatar.org/avatar/c39ac3cf2806b08e1fdf8384c2817e6c"
- subject="comment 3"
- date="2021-04-26T16:40:15Z"
- content="""
-I tried to do `git annex config --set annex.tune.objecthashlower true` just after doing `git annex init` but after some other commands I got this error when trying to do `git annex sync` (I'm using git-annex v6):
-```
-git-annex: Remote repository is tuned in incompatible way; cannot be merged with local repository.
-```
-So I guess there is way to have this behavior in normal repos, but again I don't see why since it's even possible on crippled filesystems.
-"""]]
+++ /dev/null
-The suggestion to make remotes available isn't really applicable, since the error was local.
-
-This is with git annex 6.20161110-gd48f4ca.
-
-[[!format sh """
- ../git-annex.linux/git-annex get archiveteam-fire/metro.co.uk-urls-2007-04-12-20150627/metro.co.uk-urls-2007-04-12-20150627_meta.xml
-get archiveteam-fire/metro.co.uk-urls-2007-04-12-20150627/metro.co.uk-urls-2007-04-12-20150627_meta.xml
- not enough free space, need 98.82 GB more (use --force to override this check or adjust annex.diskreserve)
-
- Unable to access these remotes: web
-
- Try making some of these repositories available:
- 00000000-0000-0000-0000-000000000001 -- web
- 9f8218c0-763f-463d-9152-ecdc56d4452c -- iabak@redwyne.jwintjen.de:~/IA.BAK/shard12
-failed
-git-annex: get: 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)
-
-mixed success
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-It's possible for `git annex whereused --key=foo` to find a match in a
-file that uses key "foobar".
-
-One way this is likely to happen is SHA256 keys with and without extension,
-for the same content. Or WORM keys with similar filenames.
-
---[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-### Please describe the problem.
-
-I ran the unit tests of 8.20211029-g0983abf59 on Windows and unfortunately got loads of errors.
-The last time I built git-annex was the release version tagged 8.20211028 whose tests gave it
-a clean bill of health. I was going to assess what the changes with the long-running `filter-process`
-functionality would entail on Windows, but alas, no such luck yet.
-
-Update: The unit tests fail also under an Ubuntu 18.04 (x86_64) virtual machine (in VMware Player)
-with an almost identical pattern. For some reason `QuickCheck` and `Remote Tests` are still fine.
-
-### What steps will reproduce the problem?
-
-`stack setup && stack build`. Then copy git-annex(.exe) to `C:\annx` (`~/annx` under Ubuntu) and in (Git) Bash say:
-```
-./git-annex.exe test -p 'Unit Tests' 2>&1 | tee git-annex.test--p-Unit_Tests.LOG~102
-```
-Observe a lot of errors.
-
-`test -p QuickCheck` was fine.
-
-Also under Ubuntu 18.04: Both `test -p QuickCheck` and `test -p '/testremote type/'` were fine.
-
-### What version of git-annex are you using? On what operating system?
-
-[[!format sh """
-git-annex version: 8.20211029-g0983abf59
-build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
-dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.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 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 X*
-remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
-operating system: mingw32 x86_64
-supported repository versions: 8
-upgrade supported from repository versions: 2 3 4 5 6 7
-"""]]
-
-Windows version 21H1 (build 19043.1288), 64 bit.
-
-Also: Ubuntu 18.04, x86_64.
-
-### Please provide any additional information below.
-
-_Under Windows:_
-
-[[!format sh """
-jkniiv@AINESIS MINGW64 /c/annx
-$ ./git-annex.exe test -p 'Unit Tests' 2>&1 | tee git-annex.test--p-Unit_Tests.LOG~102
-[...]
-jkniiv@AINESIS MINGW64 /c/annx
-$ cat git-annex.test--p-Unit_Tests.LOG~102
-Tests
- Unit Tests v8 adjusted unlocked branch
- add dup: Init Tests
- init: OK (3.60s)
- add: OK (5.49s)
-
-All 2 tests passed (9.09s)
-FAIL (5.07s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/add dup/' to rerun this test only.
- add extras: OK (4.99s)
- readonly: OK
- ignore deleted files: FAIL (4.92s)
- .\\Test\\Framework.hs:90:
- unexpected value running find [] -- got: [] expected: ["foo"]
- Use -p '/Unit Tests/&&/ignore deleted files/' to rerun this test only.
- metadata: FAIL (7.86s)
- .\\Test\\Framework.hs:90:
- unexpected value running find ["--metadata","foo=bar"] -- got: ["foodup"] expected: ["foo","foodup"]
- Use -p '/Unit Tests/&&/metadata/' to rerun this test only.
- export_import: FAIL (6.09s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.export_import"' to rerun this test only.
- export_import_subdir: FAIL (6.10s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/export_import_subdir/' to rerun this test only.
- shared clone: OK (3.82s)
- log: OK (4.18s)
- view: OK (6.46s)
- magic: OK (3.63s)
- import: OK (11.33s)
- reinject: FAIL (5.07s)
- .\\Test\\Framework.hs:345:
- sha1foo failed to look up key
- Use -p '/Unit Tests/&&/reinject/' to rerun this test only.
- unannex (no copy): OK (4.77s)
- unannex (with copy): FAIL (4.76s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/unannex (with copy)/' to rerun this test only.
- drop (no remote): FAIL (4.99s)
- .\\Test\\Framework.hs:57:
- drop with no known copy of file not allowed failed (transcript follows)
-
- Use -p '/Unit Tests/&&/drop (no remote)/' to rerun this test only.
- drop (with remote): FAIL (5.41s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/drop (with remote)/' to rerun this test only.
- drop (untrusted remote): FAIL (5.49s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/drop (untrusted remote)/' to rerun this test only.
- get: FAIL (5.78s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.get"' to rerun this test only.
- get (ssh remote): OK
- move: FAIL (6.67s)
- .\\Test\\Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.move"' to rerun this test only.
- move (ssh remote): OK
- move (numcopies): FAIL (3.61s)
- .\\Test\\Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/move (numcopies)/' to rerun this test only.
- copy: FAIL (4.07s)
- .\\Test\\Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.copy/' to rerun this test only.
- lock: FAIL (6.19s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.lock"' to rerun this test only.
- lock --force: FAIL (4.39s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/lock --force/' to rerun this test only.
- edit (no pre-commit): FAIL (4.16s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/edit (no pre-commit)/' to rerun this test only.
- edit (pre-commit): FAIL (4.20s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/edit (pre-commit)/' to rerun this test only.
- partial commit: FAIL (4.17s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/partial commit/' to rerun this test only.
- fix: OK (3.63s)
- trust: OK (11.79s)
- fsck (basics): FAIL (5.28s)
- .\\Test\\Framework.hs:57:
- fsck failed (transcript follows)
- fsck foo
- failed
- fsck sha1foo ok
- (recording state in git...)
- ** No known copies exist of foo
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/fsck (basics)/' to rerun this test only.
- fsck (bare): FAIL (2.58s)
- .\\Test\\Framework.hs:57:
- fsck failed (transcript follows)
- fsck SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
-
- (Avoid this check by running: git annex dead --key )
- failed
- fsck SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa ok
- (recording state in git...)
- ** No known copies exist of SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/fsck (bare)/' to rerun this test only.
- fsck (local untrusted): FAIL (4.26s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/fsck (local untrusted)/' to rerun this test only.
- fsck (remote untrusted): FAIL (4.65s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/fsck (remote untrusted)/' to rerun this test only.
- fsck --from remote: FAIL (4.54s)
- .\\Test\\Framework.hs:57:
- fsck --from origin failed (transcript follows)
- fsck foo
- failed
- fsck sha1foo
-ok
- (recording state in git...)
- ** No known copies exist of foo
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/fsck --from remote/' to rerun this test only.
- conversion git to annexed: OK (6.49s)
- conversion annexed to git: FAIL (4.28s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/conversion annexed to git/' to rerun this test only.
- migrate: FAIL (5.36s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.migrate"' to rerun this test only.
- migrate (via gitattributes): FAIL (5.43s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/migrate (via gitattributes)/' to rerun this test only.
- unused: FAIL (4.28s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/unused/' to rerun this test only.
- describe: OK (4.68s)
- find: FAIL (4.94s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/find/' to rerun this test only.
- merge: OK (4.38s)
- info: OK (3.99s)
- version: OK (3.70s)
- sync: FAIL (9.80s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.sync/' to rerun this test only.
- concurrent get of dup key regression: FAIL (4.46s)
- .\\Test\\Framework.hs:57:
- concurrent get -J1 with dup failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get foo2 (not available)
- No other repository is known to contain the file.
- failed
- get: 2 failed
-
- Use -p '/Unit Tests/&&/concurrent get of dup key regression/' to rerun this test only.
- union merge regression: FAIL (12.25s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/union merge regression/' to rerun this test only.
- adjusted branch merge regression: OK (7.55s)
- adjusted branch subtree regression: OK (13.21s)
- conflict resolution: FAIL (31.85s)
- .\\Test\\Framework.hs:90:
- unexpected value running find ["conflictor.variant-a507","conflictor.variant-75dc"] -- got: [] expected: ["conflictor.variant-a507","conflictor.variant-75dc"]
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.conflict resolution"' to rerun this test only.
- conflict resolution (adjusted branch): FAIL (32.35s)
- .\\Test\\Framework.hs:90:
- unexpected value running find ["conflictor.variant-a507","conflictor.variant-75dc"] -- got: [] expected: ["conflictor.variant-a507","conflictor.variant-75dc"]
- Use -p '/Unit Tests/&&/conflict resolution (adjusted branch)/' to rerun this test only.
- conflict resolution movein regression: FAIL (8.76s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get sha1foo (from origin...)
-ok
- (recording state in git...)
- get: 1 failed
-
- Use -p '/Unit Tests/&&/conflict resolution movein regression/' to rerun this test only.
- conflict resolution (mixed directory and file): FAIL (26.82s)
- .\\Test\\Framework.hs:90:
- unexpected value running find ["conflictor"] -- got: [] expected: ["conflictor/subfile"]
- Use -p '/Unit Tests/&&/conflict resolution (mixed directory and file)/' to rerun this test only.
- conflict resolution symlink bit: OK
- conflict resolution (uncommitted local file): OK (38.69s)
- conflict resolution (removed file): OK (75.56s)
- conflict resolution (nonannexed file): OK (50.67s)
- conflict resolution (nonannexed symlink): OK (15.13s)
- conflict resolution (mixed locked and unlocked file): OK (34.19s)
- map: OK (11.06s)
- uninit: FAIL (5.18s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get sha1foo (from origin...)
-ok
- (recording state in git...)
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.uninit"' to rerun this test only.
- uninit (in git-annex branch): OK (8.46s)
- upgrade: OK (6.81s)
- whereis: FAIL (4.95s)
- .\\Test\\Framework.hs:57:
- whereis on non-present file failed (transcript follows)
- whereis foo (0 copies) failed
- whereis: 1 failed
-
- Use -p '/Unit Tests/&&/whereis/' to rerun this test only.
- hook remote: OK (5.00s)
- directory remote: FAIL (6.37s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/directory remote/' to rerun this test only.
- rsync remote: OK (4.30s)
- bup remote: OK (4.35s)
- borg remote: gpg testing not implemented on Windows
-FAIL (19.19s)
- .\\Test\\Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/borg remote/' to rerun this test only.
- crypto: OK
- preferred content: FAIL (5.39s)
- .\\Test\\Framework.hs:57:
- get --auto of file with default preferred content failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/preferred content/' to rerun this test only.
- required_content: FAIL (4.14s)
- .\\Test\\Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/required_content/' to rerun this test only.
- add subdirs: OK (6.82s)
- addurl: OK (6.39s)
-
-42 out of 76 tests failed (691.50s)
- (Failures above 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.
-"""]]
-
-_Under Ubuntu 18.04:_
-
-[[!format sh """
-jkniiv@jkniiv-Virtual:~/annx$ ./git-annex test -p '/Unit Tests/' 2>&1 | tee git-annex.test--p-_Unit_Tests_.LOG~102
-jkniiv@jkniiv-Virtual:~/annx$ cat git-annex.test--p-_Unit_Tests_.LOG~102
-Init Tests
- init: Tests
- Unit Tests v8 adjusted unlocked branch
- add dup: OK (0.67s)
- add: OK (1.08s)
-
-All 2 tests passed (1.79s)
-FAIL (1.24s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.add dup/' to rerun this test only.
- add extras: OK (1.43s)
- readonly: OK (3.23s)
- ignore deleted files: FAIL (1.09s)
- ./Test/Framework.hs:90:
- unexpected value running find [] -- got: [] expected: ["foo"]
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.ignore deleted files/' to rerun this test only.
- metadata: FAIL (1.62s)
- ./Test/Framework.hs:90:
- unexpected value running find ["--metadata","foo=bar"] -- got: ["foodup"] expected: ["foo","foodup"]
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.metadata/' to rerun this test only.
- export_import: FAIL (1.00s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.export_import"' to rerun this test only.
- export_import_subdir: FAIL (1.08s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.export_import_subdir/' to rerun this test only.
- shared clone: OK (0.80s)
- log: OK (0.77s)
- view: OK (1.40s)
- magic: OK (0.79s)
- import: OK (2.23s)
- reinject: FAIL (1.04s)
- ./Test/Framework.hs:345:
- sha1foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.reinject/' to rerun this test only.
- unannex (no copy): OK (1.00s)
- unannex (with copy): FAIL (1.20s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.unannex (with copy)/' to rerun this test only.
- drop (no remote): FAIL (0.94s)
- ./Test/Framework.hs:57:
- drop with no known copy of file not allowed failed (transcript follows)
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.drop (no remote)/' to rerun this test only.
- drop (with remote): FAIL (1.01s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.drop (with remote)/' to rerun this test only.
- drop (untrusted remote): FAIL (1.16s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.drop (untrusted remote)/' to rerun this test only.
- get: FAIL (1.16s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.get"' to rerun this test only.
- get (ssh remote): FAIL (1.73s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.get (ssh remote)/' to rerun this test only.
- move: FAIL (1.26s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.move"' to rerun this test only.
- move (ssh remote): FAIL (0.86s)
- ./Test/Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.move (ssh remote)/' to rerun this test only.
- move (numcopies): FAIL (0.86s)
- ./Test/Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.move (numcopies)/' to rerun this test only.
- copy: FAIL (0.79s)
- ./Test/Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.copy/' to rerun this test only.
- lock: FAIL (1.40s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.lock"' to rerun this test only.
- lock --force: FAIL (0.98s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.lock --force/' to rerun this test only.
- edit (no pre-commit): FAIL (0.88s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.edit (no pre-commit)/' to rerun this test only.
- edit (pre-commit): FAIL (0.88s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.edit (pre-commit)/' to rerun this test only.
- partial commit: FAIL (0.98s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.partial commit/' to rerun this test only.
- fix: OK (0.80s)
- trust: OK (2.17s)
- fsck (basics): FAIL (0.95s)
- ./Test/Framework.hs:57:
- fsck failed (transcript follows)
- fsck foo
- ** No known copies exist of foo
- failed
- fsck sha1foo ok
- (recording state in git...)
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.fsck (basics)/' to rerun this test only.
- fsck (bare): FAIL (0.48s)
- ./Test/Framework.hs:57:
- fsck failed (transcript follows)
- fsck SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
- ** No known copies exist of SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
-
- (Avoid this check by running: git annex dead --key )
- failed
- fsck SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa ok
- (recording state in git...)
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.fsck (bare)/' to rerun this test only.
- fsck (local untrusted): FAIL (0.96s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.fsck (local untrusted)/' to rerun this test only.
- fsck (remote untrusted): FAIL (1.08s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.fsck (remote untrusted)/' to rerun this test only.
- fsck --from remote: FAIL (0.94s)
- ./Test/Framework.hs:57:
- fsck --from origin failed (transcript follows)
- fsck foo
- ** No known copies exist of foo
- failed
- fsck sha1foo (checksum...) ok
- (recording state in git...)
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.fsck --from remote/' to rerun this test only.
- conversion git to annexed: OK (1.62s)
- conversion annexed to git: FAIL (0.91s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.conversion annexed to git/' to rerun this test only.
- migrate: FAIL (1.15s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.migrate"' to rerun this test only.
- migrate (via gitattributes): FAIL (1.26s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.migrate (via gitattributes)/' to rerun this test only.
- unused: FAIL (0.98s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.unused/' to rerun this test only.
- describe: OK (1.09s)
- find: FAIL (1.12s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.find/' to rerun this test only.
- merge: OK (0.99s)
- info: OK (1.00s)
- version: OK (0.93s)
- sync: FAIL (1.73s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.sync/' to rerun this test only.
- concurrent get of dup key regression: FAIL (1.18s)
- ./Test/Framework.hs:57:
- concurrent get -J1 with dup failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get foo2 (not available)
- No other repository is known to contain the file.
- failed
- get: 2 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.concurrent get of dup key regression/' to rerun this test only.
- union merge regression: FAIL (2.66s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.union merge regression/' to rerun this test only.
- adjusted branch merge regression: OK (6.19s)
- adjusted branch subtree regression: OK (2.39s)
- conflict resolution: FAIL (7.01s)
- ./Test/Framework.hs:90:
- unexpected value running find ["conflictor.variant-75dc","conflictor.variant-a507"] -- got: [] expected: ["conflictor.variant-75dc","conflictor.variant-a507"]
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.conflict resolution"' to rerun this test only.
- conflict resolution (adjusted branch): FAIL (6.66s)
- ./Test/Framework.hs:90:
- unexpected value running find ["conflictor.variant-75dc","conflictor.variant-a507"] -- got: [] expected: ["conflictor.variant-75dc","conflictor.variant-a507"]
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.conflict resolution (adjusted branch)/' to rerun this test only.
- conflict resolution movein regression: FAIL (1.97s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get sha1foo (from origin...)
-ok
- (recording state in git...)
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.conflict resolution movein regression/' to rerun this test only.
- conflict resolution (mixed directory and file): FAIL (5.76s)
- ./Test/Framework.hs:90:
- unexpected value running find ["conflictor"] -- got: [] expected: ["conflictor/subfile"]
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.conflict resolution (mixed directory and file)/' to rerun this test only.
- conflict resolution symlink bit: OK
- conflict resolution (uncommitted local file): OK (7.83s)
- conflict resolution (removed file): OK (13.70s)
- conflict resolution (nonannexed file): OK (10.76s)
- conflict resolution (nonannexed symlink): OK (9.80s)
- conflict resolution (mixed locked and unlocked file): OK (5.88s)
- map: OK (1.15s)
- uninit: FAIL (1.01s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get sha1foo (from origin...)
-ok
- (recording state in git...)
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 adjusted unlocked branch.uninit"' to rerun this test only.
- uninit (in git-annex branch): OK (1.18s)
- upgrade: OK (0.89s)
- whereis: FAIL (0.95s)
- ./Test/Framework.hs:57:
- whereis on non-present file failed (transcript follows)
- whereis foo (0 copies) failed
- whereis: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.whereis/' to rerun this test only.
- hook remote: FAIL (1.21s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.hook remote/' to rerun this test only.
- directory remote: FAIL (1.13s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.directory remote/' to rerun this test only.
- rsync remote: FAIL (1.09s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.rsync remote/' to rerun this test only.
- bup remote: OK (0.84s)
- borg remote: FAIL (5.88s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.borg remote/' to rerun this test only.
- crypto: FAIL (1.78s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.crypto/' to rerun this test only.
- preferred content: FAIL (0.99s)
- ./Test/Framework.hs:57:
- get --auto of file with default preferred content failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.preferred content/' to rerun this test only.
- required_content: FAIL (0.98s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 adjusted unlocked branch.required_content/' to rerun this test only.
- add subdirs: OK (1.88s)
- addurl: OK (1.70s)
- Unit Tests v8 unlocked
- add dup: Init Tests
- init: OK (0.35s)
- add: OK (1.36s)
-
-All 2 tests passed (1.71s)
-OK (0.78s)
- add extras: OK (1.76s)
- readonly: OK (2.21s)
- ignore deleted files: FAIL (0.79s)
- ./Test/Framework.hs:90:
- unexpected value running find [] -- got: [] expected: ["foo"]
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.ignore deleted files/' to rerun this test only.
- metadata: OK (1.56s)
- export_import: FAIL (0.80s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 unlocked.export_import"' to rerun this test only.
- export_import_subdir: FAIL (0.82s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.export_import_subdir/' to rerun this test only.
- shared clone: OK (0.52s)
- log: OK (0.56s)
- view: OK (1.13s)
- magic: OK (0.41s)
- import: OK (2.08s)
- reinject: FAIL (0.67s)
- ./Test/Framework.hs:345:
- sha1foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.reinject/' to rerun this test only.
- unannex (no copy): OK (0.55s)
- unannex (with copy): FAIL (0.68s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.unannex (with copy)/' to rerun this test only.
- drop (no remote): FAIL (0.73s)
- ./Test/Framework.hs:57:
- drop with no known copy of file not allowed failed (transcript follows)
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.drop (no remote)/' to rerun this test only.
- drop (with remote): FAIL (0.67s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.drop (with remote)/' to rerun this test only.
- drop (untrusted remote): FAIL (0.73s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.drop (untrusted remote)/' to rerun this test only.
- get: FAIL (0.83s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 unlocked.get"' to rerun this test only.
- get (ssh remote): FAIL (1.10s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.get (ssh remote)/' to rerun this test only.
- move: FAIL (0.84s)
- ./Test/Framework.hs:345:
- foo failed to look up key
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 unlocked.move"' to rerun this test only.
- move (ssh remote): FAIL (0.51s)
- ./Test/Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.move (ssh remote)/' to rerun this test only.
- move (numcopies): FAIL (0.43s)
- ./Test/Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.move (numcopies)/' to rerun this test only.
- copy: FAIL (0.51s)
- ./Test/Framework.hs:307:
- checkcontent foo
- expected: "annexed file content"
- but got: "/annex/objects/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\n"
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.copy/' to rerun this test only.
- lock: FAIL (1.20s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 unlocked.lock"' to rerun this test only.
- lock --force: FAIL (0.54s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.lock --force/' to rerun this test only.
- edit (no pre-commit): FAIL (0.54s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.edit (no pre-commit)/' to rerun this test only.
- edit (pre-commit): FAIL (0.61s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.edit (pre-commit)/' to rerun this test only.
- partial commit: FAIL (0.54s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.partial commit/' to rerun this test only.
- fix: OK (0.47s)
- trust: OK (1.70s)
- fsck (basics): FAIL (0.63s)
- ./Test/Framework.hs:57:
- fsck failed (transcript follows)
- fsck foo
- ** No known copies exist of foo
- failed
- fsck sha1foo ok
- (recording state in git...)
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.fsck (basics)/' to rerun this test only.
- fsck (bare): FAIL (0.50s)
- ./Test/Framework.hs:57:
- fsck failed (transcript follows)
- fsck SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
- ** No known copies exist of SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
-
- (Avoid this check by running: git annex dead --key )
- failed
- fsck SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa ok
- (recording state in git...)
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.fsck (bare)/' to rerun this test only.
- fsck (local untrusted): FAIL (0.52s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.fsck (local untrusted)/' to rerun this test only.
- fsck (remote untrusted): FAIL (0.79s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.fsck (remote untrusted)/' to rerun this test only.
- fsck --from remote: FAIL (0.63s)
- ./Test/Framework.hs:57:
- fsck --from origin failed (transcript follows)
- fsck foo
- ** No known copies exist of foo
- failed
- fsck sha1foo (checksum...) ok
- (recording state in git...)
- fsck: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.fsck --from remote/' to rerun this test only.
- conversion git to annexed: OK (1.09s)
- conversion annexed to git: FAIL (0.55s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.conversion annexed to git/' to rerun this test only.
- migrate: FAIL (0.74s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 unlocked.migrate"' to rerun this test only.
- migrate (via gitattributes): FAIL (0.75s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.migrate (via gitattributes)/' to rerun this test only.
- unused: FAIL (0.61s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.unused/' to rerun this test only.
- describe: OK (0.63s)
- find: FAIL (0.65s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.find/' to rerun this test only.
- merge: OK (0.52s)
- info: OK (0.57s)
- version: OK (0.44s)
- sync: FAIL (1.14s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.sync/' to rerun this test only.
- concurrent get of dup key regression: FAIL (0.70s)
- ./Test/Framework.hs:57:
- concurrent get -J1 with dup failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get foo2 (not available)
- No other repository is known to contain the file.
- failed
- get: 2 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.concurrent get of dup key regression/' to rerun this test only.
- union merge regression: FAIL (1.32s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.union merge regression/' to rerun this test only.
- adjusted branch merge regression: OK (4.80s)
- adjusted branch subtree regression: OK (2.17s)
- conflict resolution: FAIL (4.18s)
- ./Test/Framework.hs:90:
- unexpected value running find ["conflictor.variant-75dc","conflictor.variant-a507"] -- got: ["conflictor.variant-a507"] expected: ["conflictor.variant-75dc","conflictor.variant-a507"]
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 unlocked.conflict resolution"' to rerun this test only.
- conflict resolution (adjusted branch): FAIL (4.78s)
- ./Test/Framework.hs:90:
- unexpected value running find ["conflictor.variant-75dc","conflictor.variant-a507"] -- got: ["conflictor.variant-a507"] expected: ["conflictor.variant-75dc","conflictor.variant-a507"]
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.conflict resolution (adjusted branch)/' to rerun this test only.
- conflict resolution movein regression: FAIL (1.08s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get sha1foo (from origin...)
-ok
- (recording state in git...)
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.conflict resolution movein regression/' to rerun this test only.
- conflict resolution (mixed directory and file): FAIL (4.16s)
- ./Test/Framework.hs:90:
- unexpected value running find ["conflictor"] -- got: [] expected: ["conflictor/subfile"]
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.conflict resolution (mixed directory and file)/' to rerun this test only.
- conflict resolution symlink bit: OK
- conflict resolution (uncommitted local file): OK (4.68s)
- conflict resolution (removed file): OK (9.60s)
- conflict resolution (nonannexed file): OK (6.75s)
- conflict resolution (nonannexed symlink): OK (6.40s)
- conflict resolution (mixed locked and unlocked file): OK (4.53s)
- map: OK (0.70s)
- uninit: FAIL (0.70s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get sha1foo (from origin...)
-ok
- (recording state in git...)
- get: 1 failed
-
- Use -p '/Unit Tests/&&$0=="Tests.Unit Tests v8 unlocked.uninit"' to rerun this test only.
- uninit (in git-annex branch): OK (0.75s)
- upgrade: OK (0.55s)
- whereis: FAIL (0.64s)
- ./Test/Framework.hs:57:
- whereis on non-present file failed (transcript follows)
- whereis foo (0 copies) failed
- whereis: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.whereis/' to rerun this test only.
- hook remote: FAIL (0.77s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.hook remote/' to rerun this test only.
- directory remote: FAIL (0.78s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.directory remote/' to rerun this test only.
- rsync remote: FAIL (0.76s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.rsync remote/' to rerun this test only.
- bup remote: OK (0.46s)
- borg remote: FAIL (4.97s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.borg remote/' to rerun this test only.
- crypto: FAIL (1.38s)
- ./Test/Framework.hs:57:
- get of file failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.crypto/' to rerun this test only.
- preferred content: FAIL (0.67s)
- ./Test/Framework.hs:57:
- get --auto of file with default preferred content failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.preferred content/' to rerun this test only.
- required_content: FAIL (0.60s)
- ./Test/Framework.hs:57:
- get failed (transcript follows)
- get foo (not available)
- No other repository is known to contain the file.
- failed
- get: 1 failed
-
- Use -p '/Unit Tests/&&/Unit Tests v8 unlocked.required_content/' to rerun this test only.
- add subdirs: OK (1.27s)
- addurl: OK (1.11s)
- Unit Tests v8 locked
- add dup: Init Tests
- init: OK (0.38s)
- add: OK (1.10s)
-
-All 2 tests passed (1.48s)
-OK (0.90s)
- add extras: OK (0.74s)
- readonly: OK (1.86s)
- ignore deleted files: OK (0.74s)
- metadata: OK (1.63s)
- export_import: OK (4.50s)
- export_import_subdir: OK (4.97s)
- shared clone: OK (0.58s)
- log: OK (0.72s)
- view: OK (2.29s)
- magic: OK (0.81s)
- import: OK (3.11s)
- reinject: OK (1.42s)
- unannex (no copy): OK (0.96s)
- unannex (with copy): OK (1.66s)
- drop (no remote): OK (2.17s)
- drop (with remote): OK (2.03s)
- drop (untrusted remote): OK (1.53s)
- get: OK (1.32s)
- get (ssh remote): OK (1.27s)
- move: OK (2.26s)
- move (ssh remote): OK (2.91s)
- move (numcopies): OK (2.08s)
- copy: OK (1.92s)
- lock: OK (2.39s)
- lock --force: OK (1.54s)
- edit (no pre-commit): OK (2.42s)
- edit (pre-commit): OK (2.06s)
- partial commit: OK (1.45s)
- fix: OK (1.19s)
- trust: OK (2.03s)
- fsck (basics): OK (2.43s)
- fsck (bare): OK (0.51s)
- fsck (local untrusted): OK (1.54s)
- fsck (remote untrusted): OK (2.60s)
- fsck --from remote: OK (1.09s)
- conversion git to annexed: OK (1.37s)
- conversion annexed to git: OK (1.42s)
- migrate: OK (2.76s)
- migrate (via gitattributes): OK (4.50s)
- unused: OK (4.25s)
- describe: OK (0.73s)
- find: OK (2.72s)
- merge: OK (0.53s)
- info: OK (0.69s)
- version: OK (0.61s)
- sync: OK (3.13s)
- concurrent get of dup key regression: OK (1.82s)
- union merge regression: OK (6.21s)
- adjusted branch merge regression: OK (5.83s)
- adjusted branch subtree regression: OK (2.55s)
- conflict resolution: OK (4.06s)
- conflict resolution (adjusted branch): FAIL (5.47s)
- ./Test/Framework.hs:90:
- unexpected value running find ["conflictor.variant-a507","conflictor.variant-SHA256E-s11--aa299d36fd0b2f7ec1632ca3834c30c0c2f3b45749058e2611778d38a4a2b7cf.variant-75dc"] -- got: [] expected: ["conflictor.variant-a507","conflictor.variant-SHA256E-s11--aa299d36fd0b2f7ec1632ca3834c30c0c2f3b45749058e2611778d38a4a2b7cf.variant-75dc"]
- Use -p '/Unit Tests/&&/Unit Tests v8 locked.conflict resolution (adjusted branch)/' to rerun this test only.
- conflict resolution movein regression: OK (5.06s)
- conflict resolution (mixed directory and file): OK (7.11s)
- conflict resolution symlink bit: OK (4.26s)
- conflict resolution (uncommitted local file): OK (4.28s)
- conflict resolution (removed file): OK (8.60s)
- conflict resolution (nonannexed file): OK (6.14s)
- conflict resolution (nonannexed symlink): OK (5.57s)
- conflict resolution (mixed locked and unlocked file): OK (3.84s)
- map: OK (0.80s)
- uninit: OK (0.95s)
- uninit (in git-annex branch): OK (0.70s)
- upgrade: OK (0.50s)
- whereis: OK (1.34s)
- hook remote: OK (2.06s)
- directory remote: OK (1.86s)
- rsync remote: OK (2.13s)
- bup remote: OK (0.48s)
- borg remote: OK (12.04s)
- crypto: OK (10.56s)
- preferred content: OK (3.86s)
- required_content: OK (1.88s)
- add subdirs: OK (1.85s)
- addurl: OK (1.43s)
-
-93 out of 228 tests failed (475.37s)
- (Failures above 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)
-
-Yeah sure, I'm a believer. :) Using it with my multigigabyte backup files just fine most of the time.
-I'm also building select versions of git-annex for both Windows native and WSL1/2 use following the
-development on master. A fine piece of software it definitely is.
-
-[[!meta title="plenty of unit tests fail after 8.20211028"]]
-[[!meta author=jkniiv]]
-
-> I expect that [[!commit 837025b14f523f9180f82d0cced1e53a8a9b94de]] fixes
-> this. [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="jkniiv"
- avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
- subject="comment 1"
- date="2021-11-05T10:25:32Z"
- content="""
-Git bisected this in the Ubuntu VM and found out that \"afe327ac4947d6d32ff888e7485509be03d9baaf is the first bad commit\"
-which I don't quite understand as it's only conditionally disabling the `filter.annex.process` preference.
-
-"""]]
+++ /dev/null
-# As is
-At the FAT disks annex uses ajusted unlocked branch. Files use double space: in the file tree and in the .git folder.
-
-# As I wonder
-At such disks, with option annex.thin, annex uses only file tree for keeping content. Content of the files in the .git folder is wiped.
-
-> [[done]], dup of other todo, and I don't know how to avoid the problem
-> with git deleting the file. --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-02-08T18:17:00Z"
- content="""
-This has the following problem: You run git pull. A file got deleted. git
-deletes the file in the repository directory. That was the only copy of the
-content, so it's now impossible to revert the deletion and get the file
-back, which you're supposed to be able to do.
-
-This is why git-annex has to either make a copy or hard link the file
-away for safekeeping.
-
-As already discussed in [[annex.thin without hardlinks]].
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2016-09-21T17:11:06Z"
- content="""
-Standard encfs warning: It's buggy and insecure. Don't use it.
-
-You can find many other problems caused by encfs on this site, and
-<https://defuse.ca/audits/encfs.htm> has described security problems with
-encfs for years.
-
-It would not help for `git-annex add` to check some kind of filename limit,
-because it would not prevent you doing this:
-
- git annex add smallenough
- git mv smallenough oh-oops-my-name-is-too-long-for-encfs
- git commit -m haha
-
-A git pre-commit hook can of course be written that blocks such commits.
-
-I am not inclined to complicate git-annex just to handle encfs given how
-broken encfs is.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="interfect@b151490178830f44348aa57b77ad58c7d18e8fe7"
- nickname="interfect"
- subject="Pre Commit Hook"
- date="2016-09-21T19:20:04Z"
- content="""
-I'm basically stuck with whatever home directory encryption Canonical deigns to give me in their setup wizard, given my time and attention budget. I've looked a bit at the security problems with it and they mostly seem to be that it's a bit leaky due to not hiding structures and sizes. Hiding contents is better than not hiding contents, so that's what I've got.
-
-Anyway, a pre-commit hook, or maybe an update hook, would be a great solution. I'd like one to be on the wiki somewhere as a useful tip for actually using git annex effectively across a bunch of non-ideal environments. It would be great if a \"git annex init\" could set it up for me, too.
-
-Any ideas for writing a pre-commit script that works on Linux, Mac, Windows, Android, and whatever weird embedded NAS things people might want to use it on? If I went with an update script over a pre-commit, that would make platform support less of a problem, but then you'd get Git Annex into weird situations when syncing.
-
-How would Git Annex react if I made a commit on one system, but then my central syncing repo's update script rejected the commit for breaking the rules on file names? If I have a commit that isn't allowed to be pushed to a particular remote, how would I use git annex to get it out of the history of any repos it might have already gotten to?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="interfect@b151490178830f44348aa57b77ad58c7d18e8fe7"
- nickname="interfect"
- subject="comment 3"
- date="2016-09-21T19:32:06Z"
- content="""
-Also, I think Ubuntu is \"ecryptfs\" and not \"encfs\" anyway.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2016-09-21T20:16:44Z"
- content="""
-If an update hook rejects a push, then `git annex sync` will just note that
-it was unable to push. It will sync in only one direction until the problem
-that prevents pushing gets resolved.
-
-It might try pushing to a different branch name than usual to get around
-some other problems that cause pushes to fail so be sure to have the update
-hook check pushes to all branches (except for the git-annex branch)).
-
-I don't know why you'd want to filter such a commit out of the git history.
-You could just fix it by renaming the problem file and make a commit on top
-of the problem commit. Just make the update hook only look at the diff
-between the old version of the branch and the new version, so it won't be
-tripped up by intermediate commits that violate its rules.
-
-(I know that Ubuntu uses encfs or something like that by default, but
-surely they have not removed the Debian installer's support for full
-disk encryption?)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="interfect@b151490178830f44348aa57b77ad58c7d18e8fe7"
- nickname="interfect"
- subject="comment 5"
- date="2016-09-21T22:49:55Z"
- content="""
-OK, I'll try something like that.
-
-(Full disk encryption is still there; I think on one system I just have ecryptfs, because I want to be able to get in over ssh sometimes, and on one I have *both* FDE and ecryptfs on, because I enjoy performance penalties.)
-"""]]
+++ /dev/null
-Would it be hard to support MD5E keys that omit the -sSIZE part, the way this is allowed for URL keys? I have a use case where I have the MD5 hashes and filenames of files stored in the cloud, but not their sizes, and want to construct keys for these files to use with setpresentkey and registerurl. I could construct URL keys, but then I lose the error-checking and have to set annex.security.allow-unverified-downloads . Or maybe, extend URL keys to permit an -hMD5 hash to be part of the key?
-
-Another (and more generally useful) solution would be [[todo/alternate_keys_for_same_content/]]. Then can start with a URL-based key but then attach an MD5 to it as metadata, and have the key treated as a checksum-containing key, without needing to migrate the contents to a new key.
-
-> Closing, because [[external_backends]] is implemented, so you should be
-> able to roll your own backend for your use case here. Assuming you can't
-> just use regular MD5E and omit the file size field, which will work too.
-> [[done]]
-> --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-01-22T15:54:03Z"
- content="""
-Have you tried just constricting MD5E keys without the size value?
-git-annex still supports keys from before v2 repo version that did not
-include size, so I'd guess it would work ok.
-"""]]
+++ /dev/null
-What steps will reproduce the problem?
-Sync a lot of small files.
-
-What is the expected output? What do you see instead?
-The expected output is hopefully a fast transfer.
-
-But currently it seems like git-annex is only using one thread to transfer(per host or total?)
-
-An option to select number of transfer threads to use(possibly per host) would be very nice.
-
-> Opening a lot of connections to a single host is probably not desirable.
->
-> I do want to do something to allow slow hosts to not hold up transfers to
-> other hosts, which might involve running multiple queued transfers at
-> once. The webapp already allows the user to force a given transfer to
-> happen immediately. --[[Joey]]
-
-And maybe also an option to limit how long a queue the browser should show, it can become quite resource intensive with a long queue.
-
-> The queue is limited to 20 items for this reason. --[[Joey]]
-
-
----
-
-> There has been a lot of improvement in both parallization support
-> and per-file overhead on speed since this todo was filed. This todo does
-> not look relevent enough to leave open, so [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnKT33H9qVVGJOybP00Zq2NZmNAyB65mic"
- nickname="Lucas"
- subject="comment 1"
- date="2014-11-12T07:58:07Z"
- content="""
-Opening multiple connections to a host can be preferable sometimes and it's unlikely to be an issue at all for the larger remotes like Google, Microsoft or S3.
-
-For example, the OneDrive provider spends a lot of time sitting around waiting for initialisation between uploads. Using, say 5 threads instead of 1 would allow it to continue doing things while it waits.
-
-Multiple connections can also vastly improve upload speeds for users with congested home internet connections.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://launchpad.net/~krastanov-stefan"
- nickname="krastanov-stefan"
- subject="Status of this issue"
- date="2014-12-27T15:18:42Z"
- content="""
-I was unable to find a way to tell git-annex that certain remotes should receive multiple transfers in parallel. Is this implemented yet or on the roadmap? If neither would modifying the webapp to bear this logic without touching git-annex itself be a solution (asking mainly because it can be done with a greasemonkey script)?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="lhunath@3b4ff15f4600f3276d1776a490b734fca0f5c245"
- nickname="lhunath"
- subject="Simultaneous transfers"
- date="2018-02-02T17:37:27Z"
- content="""
-I highly recommend ensuring that:
-1. Each remote can configure a number of maximum simultaneous transfers, where each type of remote comes with a sensible default number.
-2. Transfers to multiple individual remotes happen in parallel regardless of their simultaneous transfers setting.
-
-Judging from the fact that simultaneous transfers happen just fine when you hit the > icon in the webapp, I would assume that most of the underbelly for this is already present.
-"""]]
+++ /dev/null
-```
-From 92dfde25409ae2268ab2251920ed11646c122870 Mon Sep 17 00:00:00 2001
-From: Reiko Asakura <asakurareiko@protonmail.ch>
-Date: Tue, 26 Oct 2021 15:46:38 -0400
-Subject: [PATCH] Call freezeContent after move into annex
-
-This change better supports Windows ACL management using
-annex.freezecontent-command and annex.thawcontent-command and matches
-the behaviour of adding an unlocked file.
-
-By calling freezeContent after the file has moved into the annex,
-the file's delete permission can be denied. If the file's delete
-permission is denied before moving into the annex, the file cannot
-be moved or deleted. If the file's delete permission is not denied after
-moving into the annex, it will likely inherit a grant for the delete
-permission which allows it to be deleted irrespective of the permissions
-of the parent directory.
----
- Annex/Content.hs | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/Annex/Content.hs b/Annex/Content.hs
-index da65143ab..89c36e612 100644
---- a/Annex/Content.hs
-+++ b/Annex/Content.hs
-@@ -346,6 +346,9 @@ moveAnnex key af src = ifM (checkSecureHashes' key)
- liftIO $ moveFile
- (fromRawFilePath src)
- (fromRawFilePath dest)
-+ -- On Windows the delete permission must be denied only
-+ -- after the content has been moved in the annex.
-+ freezeContent dest
- g <- Annex.gitRepo
- fs <- map (`fromTopFilePath` g)
- <$> Database.Keys.getAssociatedFiles key
---
-2.30.2
-
-```
-
-> [[applied|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-10-26T17:49:00Z"
- content="""
-Thank you for putting this patch together. It is especially helpful to get
-patches from a windows user, since it's far from my comfort zone.
-
----
-
-My first concern was what happens if git-annex is interrupted after moving
-the object into place but before freezeContent. Leaving an object file
-with possibly unsafe permissions. Looks like `git-annex fsck` will
-corrrect that, if it's run.
-
-As you mentioned, when an unlocked file is added, and linkToAnnex
-is called, it does move the object into the annex before freezeContent.
-Although that may have been an oversight really. It could just as well
-freeze before moving and so avoid leaving the file with the wrong
-permissions when interrupted.
-
-And there are other situations where being interrupted can have the same
-result. Eg, in lockContentForRemoval, it calls thawContent, then an action
-that may take long enough to be interrupted, and then freezeContent.
-And it's hard to see any other way that could work; it can't
-move the object out of the object directory before thawing it.
-
-So, this seems ok, I suppose.
-
----
-
-In Annex.Ingest, `lockDown'` calls freezeContent on the file
-when it's still in the work tree. So I think that would have the same
-problem you're trying to prevent with this patch?
-
-Command.Import also has a call to freezeContent that is not on the final
-object file location.
-
-A windows-specific feature like this risks getting broken, so maybe
-it would be good to change freezeContent to avoid such problems. Eg,
-it could be changed to take a Key, and freeze the object file
-for that Key. But at least the call in Annex.Ingest needs to happen
-before there is a Key.
-
-So perhaps there should be a freezeContent
-and a separate freezeObject, which takes a Key. There could
-then be a separate annex.freezeobject-command that gets run only
-for freezeObject, not freezeContent.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
- nickname="asakurareiko"
- avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
- subject="comment 2"
- date="2021-10-26T19:54:53Z"
- content="""
-Sorry I missed explaining a few things and made a mistake in the patch. I made my freeze script detect whether the input is inside or outside of .git/annex/objects, so there are no problems with calling freezeContent on something in the working tree. The problem is not calling freezeContent on the final object, because the delete permission can only be denied at that point. The easiest way without compromising the safety of the previous behaviour is to add another freezeContent call after moveFile.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-10-27T17:56:15Z"
- content="""
-Ah, making your script smart is reasonable enough.
-
-I hope you might consider sharing the script in a tip?
-
-Looking at your updated patch, you now leave the freezeContent call before it
-moves to the object file, and add another call afterwards. I think that would
-be objectionable if the user has a freeze hook that is expensive
-the run, because it would unncessarily run twice. I fairly well satisfied
-myself in comment #1 that it's ok to defer freezeContent to after it's
-moved the object file into place.
-
-So, I've applied it, but modified to remove that earlier freezeContent.
-"""]]
+++ /dev/null
-Sqlite docs [say](https://www.sqlite.org/pragma.html#pragma_synchronous) "commits can be orders of magnitude faster with synchronous OFF". The downside is a chance of db corruption if power fails at a bad moment, but since git-annex's dbs can be re-generated from git data, maybe that's a tradeoff some users would be ok with? One usually knows when power has failed.
-
-> [[closing|done]] per comments --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-06-23T17:05:38Z"
- content="""
-I think it could at least use synchronous=NORMAL, entirely safely, since it
-uses WAL mode.
-
-"WAL mode is always consistent with synchronous=NORMAL, but WAL mode does
-lose durability. A transaction committed in WAL mode with
-synchronous=NORMAL might roll back following a power loss or system crash."
-
-It's certianly already possible for a power loss or ctrl-c while git-annex
-is running to cause database changes to be lost, since git-annex buffers
-several changes together into a transaction and until it sends that
-transaction, can lose the data.
-
-Exactly how well git-annex recovers from that probably varies, eg
-Database.Keys.reconcileStaged flushes the transactions before updating its
-own state files, so on power loss it will just run again and recover. The
-fsck database gets recovered likewise. But there are probably other write points
-where getting the data recovered is harder.
-
-For example, moveAnnex updates the inode cache at the end when it populated
-a pointer file. If that database write is lost, git-annex won't know that
-the pointer file is populated with annexed content. So it will treat it as
-a possibly modified unlocked file, and when it eventually has a reason to,
-will re-hash it, and then should recover the lost information.
-
-Quite possible there are situations where it fails to recover the lost
-information and does something annoying. But like I said, such situations
-can already happen and setting synchronous=NORMAL does not make them more
-likely.
-
-It would still make sense to benchmark it before changing to it. It may
-well be that git-annex's buffering of changes into larger transactions
-already has a similar performance gain as the pragma and that the pragma
-does not speed it up.
-
-As far as OFF goes, I'd need to see some serious performance improvements
-in benchmarking, and also be sure that git-annex always recovered well,
-which would have to somehow include detecting corrupted sqlite databases
-and rebuilding them. I don't know if it's really possible to detect.
-Might some form of corrupted sqlite database cause sqlite, and thus
-git-annex, to crash? And rebuilding might entail re-hashing the entire
-repository, so very expensive.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="recovering from sqlite db corruption"
- date="2021-06-23T18:45:47Z"
- content="""
->detecting corrupted sqlite databases and rebuilding them. I don't know if it's really possible to detect.
-
-Could you detect whether a git-annex command finished normally,by creating a marker file when it starts, and deleting the marker file as the last thing before exiting?
-The next command then checks if the previous one crashed, and rebuilds the dbs if yes (or just warns the user and offers to rebuild.)
-
->Rebuilding might entail re-hashing the entire repository
-
-Aren't all file hashes recorded in git, which would not be affected by a sqlite crash?
-
-
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-06-23T19:15:55Z"
- content="""
-Benchmarked with NORMAL:
-
- joey@darkstar:~/tmp/t>/usr/bin/time ~/git-annex.synchrousNORMAL add 1??? --quiet
- 6.99user 5.09system 0:11.63elapsed 103%CPU (0avgtext+0avgdata 68356maxresident)k
- 143760inputs+40352outputs (819major+404774minor)pagefaults 0swaps
- joey@darkstar:~/tmp/t>/usr/bin/time ~/git-annex.synchrousNORMAL add 2??? --quiet
- 7.71user 5.15system 0:11.93elapsed 107%CPU (0avgtext+0avgdata 69876maxresident)k
- 11336inputs+42648outputs (9major+414417minor)pagefaults 0swaps
- joey@darkstar:~/tmp/t>/usr/bin/time ~/git-annex.synchrousNORMAL add 3??? --quiet
- 7.99user 5.16system 0:12.20elapsed 107%CPU (0avgtext+0avgdata 70452maxresident)k
- 11952inputs+44200outputs (8major+415267minor)pagefaults 0swaps
- joey@darkstar:~/tmp/t>/usr/bin/time ~/git-annex.synchrousNORMAL add 4??? --quiet
- 8.30user 5.25system 0:12.62elapsed 107%CPU (0avgtext+0avgdata 69496maxresident)k
- 17784inputs+45776outputs (9major+416640minor)pagefaults 0swaps
-
-Which is no improvement over git-annex with no pragmas. Actually slower.
-
- joey@darkstar:~/tmp/t>/usr/bin/time ~/git-annex.orig add 1??? --quiet
- 6.89user 5.36system 0:11.39elapsed 107%CPU (0avgtext+0avgdata 50576maxresident)k
- 47064inputs+40352outputs (5616major+404472minor)pagefaults 0swaps
- joey@darkstar:~/tmp/u>/usr/bin/time git-annex add 2??? --quiet
- 7.76user 5.09system 0:11.88elapsed 108%CPU (0avgtext+0avgdata 70848maxresident)k
- 12776inputs+42648outputs (9major+414346minor)pagefaults 0swaps
- joey@darkstar:~/tmp/u>/usr/bin/time git-annex add 3??? --quiet
- 7.90user 5.26system 0:12.14elapsed 108%CPU (0avgtext+0avgdata 71676maxresident)k
- 13824inputs+44200outputs (8major+415258minor)pagefaults 0swaps
- joey@darkstar:~/tmp/u>/usr/bin/time git-annex add 4??? --quiet
- 8.22user 5.38system 0:12.49elapsed 108%CPU (0avgtext+0avgdata 71652maxresident)k
- 14216inputs+45776outputs (8major+416784minor)pagefaults 0swaps
-
-OFF also benchmarks very close to the same.
-
- joey@darkstar:~/tmp/v>/usr/bin/time ~/git-annex.synchrousOFF add 1??? --quiet
- 6.85user 5.58system 0:12.01elapsed 103%CPU (0avgtext+0avgdata 71100maxresident)k
- 50080inputs+40352outputs (16major+405312minor)pagefaults 0swaps
- joey@darkstar:~/tmp/v>/usr/bin/time ~/git-annex.synchrousOFF add 2??? --quiet
- 7.64user 5.31system 0:11.96elapsed 108%CPU (0avgtext+0avgdata 71392maxresident)k
- 12672inputs+42640outputs (8major+414373minor)pagefaults 0swaps
- joey@darkstar:~/tmp/v>/usr/bin/time ~/git-annex.synchrousOFF add 3??? --quiet
- 8.02user 5.15system 0:12.19elapsed 108%CPU (0avgtext+0avgdata 71556maxresident)k
- 11648inputs+43928outputs (8major+415140minor)pagefaults 0swaps
- joey@darkstar:~/tmp/v>/usr/bin/time ~/git-annex.synchrousOFF add 4??? --quiet
- 8.24user 5.24system 0:12.41elapsed 108%CPU (0avgtext+0avgdata 71224maxresident)k
- 10952inputs+45304outputs (8major+416560minor)pagefaults 0swaps
-
-One pass did run 0.08s faster, could be due to not syncing but it does
-not seem a significant optimisation, at least not on this SSD.
-
-Should be noted that transactions build up 1000 changes, and that benchmark
-was operating on 1000 files per run, so it probably only wrote one or two
-transactions.
-
-Here's the patch that adds a pragma:
-
- diff --git a/Database/Handle.hs b/Database/Handle.hs
- index d7f1822dc..2d66af5e6 100644
- --- a/Database/Handle.hs
- +++ b/Database/Handle.hs
- @@ -1,11 +1,11 @@
- {- Persistent sqlite database handles.
- -
- - - Copyright 2015-2019 Joey Hess <id@joeyh.name>
- + - Copyright 2015-2021 Joey Hess <id@joeyh.name>
- -
- - Licensed under the GNU AGPL version 3 or higher.
- -}
-
- -{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
- +{-# LANGUAGE TypeFamilies, FlexibleContexts, OverloadedStrings #-}
-
- module Database.Handle (
- DbHandle,
- @@ -34,6 +34,7 @@ import qualified Data.Text as T
- import Control.Monad.Trans.Resource (runResourceT)
- import Control.Monad.Logger (runNoLoggingT)
- import System.IO
- +import Lens.Micro
-
- {- A DbHandle is a reference to a worker thread that communicates with
- - the database. It has a MVar which Jobs are submitted to. -}
- @@ -194,10 +195,13 @@ runSqliteRobustly tablename db a = do
- maxretries = 100 :: Int
-
- rethrow msg e = throwIO $ userError $ show e ++ "(" ++ msg ++ ")"
- -
- +
- + conninfo = over extraPragmas (const ["PRAGMA synchronous=OFF"]) $
- + mkSqliteConnectionInfo db
- +
- go conn retries = do
- r <- try $ runResourceT $ runNoLoggingT $
- - withSqlConnRobustly (wrapConnection conn) $
- + withSqlConnRobustly (wrapConnectionInfo conninfo conn) $
- runSqlConn a
- case r of
- Right v -> return v
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="thanks "
- date="2021-06-24T16:40:48Z"
- content="""
-Thanks for doing the benchmarking; seems like git-annex's batching of operations already captures whatever speedup de-synchronizing could give.
-
-
-"""]]
+++ /dev/null
-Like git annex runs git-annex, git-annex foo could run git-annex-foo when
-it's not built-in.
-
-One user of this would be annex-review-unused, which
-its author would rather name git-annex-reviewunused if that
-made "git annex reviewunused" work.
-
-In CmdLine, where autocorrect is handled, it would need to
-search the path for all "git-annex-" commands and then
-either dispatch the one matching the inputcmdname,
-or do autocorrect with the list of those commands
-included along with the builtins. --[[Joey]]
-
-> [[done]] --[[Joey]]
+++ /dev/null
-Currently annex.thin needs hard link support to be efficient;
-it hard links the content from .git/annex/objects into the work tree.
-When hard links are not supported, two copies of checked out files exist on
-disk.
-
-Would it be possible to make it work w/o hard links? Note that direct mode
-does avoid two copies of files.
-
-IIRC the main reason for the hard link is so, when git checkout deletes a
-work tree file, the only copy of the file is not lost. Seems this would
-need a git hook run before checkout to rescue such files.
-
-Also some parts of git-annex's code, including `withObjectLoc`, assume
-that the .annex/objects is present, and so it would need to be changed
-to look at the work tree file. --[[Joey]]
-
-> Git hook is not sufficient. Consider the case of "rm file; git checkout file"
-> Without hard links, if the only copy of the annex object was in that
-> deleted file, it can't be restored. Now, direct mode did have the same
-> problem, but it didn't support `git checkout`, so the user didn't have
-> reason to expect such a workflow to work.
->
-> So, I think this is not possible to implement in a way that won't
-> lead to users experiencing data loss when using it and doing
-> perfectly normal git things like this.
->
-> (Although to be fair, annex.thin has its own data loss scenarios,
-> involving modifying a file potentially losing the only copy of
-> the old version. The difference, I think, is that with it,
-> you modify the file yourself and so lose the old version; the data
-> loss does not happen when you run git checkout or git pull!)
->
-> In the meantime,
-> git-annex has gotten support for directory special remotes with
-> import/export tree. This can be used instead, for use cases such as a
-> device with a FAT filesystem. The git-annex repo can live on another
-> filesystem that does support hard links or symlinks, or where using
-> double disk space is not as much of a problem, or can even be a bare
-> git repo. That syncs up with the FAT device through tree import and
-> export. Once content has been imported to the git-annex repo,
-> the user can delete files from the FAT device without losing data.
->
-> So this seems about as good as it can get. [[done]] --[[Joey]]
+++ /dev/null
-Add a git config to limit the bandwidth of transfers to/from remotes.
-
-rsync has --bwlimit, so used to work, but is not used with modern
-git-annex for p2p transfers. (bup also has a --bwlimit)
-
-This should be possible to implement in a way that works for any remote
-that streams to/from a bytestring, by just pausing for a fraction of a
-second when it's running too fast. The way the progress reporting interface
-works, it will probably work to put the delay in there. --[[Joey]]
-
-[[confirmed]]
-
-> Implemented and works well. [[done]] --[[Joey]]
-
-> Note: A local git remote, when resuming an interrupted
-> transfer, has to hash the file (with default annex.verify settings),
-> and that hashing updates the progress bar, and so the bwlimit can kick
-> in and slow down that initial hashing, before any data copying begins.
-> This seems perhaps ok; if you've bwlimited a local git remote,
-> remote you're wanting to limit disk IO. Only reason it might not be ok
-> is if the intent is to limit IO to the disk containing the remote
-> but not the one containing the annex repo. (This also probably
-> holds for the directory special remote.)
-> Other remotes, including git over ssh, when resuming don't have that
-> problem. Looks like chunked special remotes narrowly avoid it, just
-> because their implementation choose to not do incremental verification
-> when resuming. It might be worthwhile to differentiate between progress
-> updates for incremental verification setup and for actual transfers, and
-> only rate limit the latter, just to avoid fragility in the code.
-> I have not done so yet though, and am closing this..
-> --[[Joey]]
-
-> (One other small caveat is that it pauses after each chunk, which means
-> it pauses unncessarily after the last chunk of the file. It doesn't know
-> it's the last chunk, and it would be hard to teach it. And the chunks
-> tend to be 32kb or so, and the pauses a small fraction of a second. So
-> mentioning this only for completeness.) --[[Joey]]
-
+++ /dev/null
-AFAICT, the `annex/` subdir in a bare annex repo is the exact same layout as a directory special remote.
-
-It'd be very useful if its parameters could be customised just like an actual directory special remote to allow for e.g. encrypted and/or chunked storage. I have a use-case where this could significantly simplify things.
-
-An interesting side-effect of this would be a tweakable location for a bare repo's storage which could be used to separate metadata and data (i.e. git repo on SSD for fast syncs and actual data on an HDD).
-
-> [[rejected|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-05-25T16:48:26Z"
- content="""
-You can already do this by setting the `remote.<name>.annex-ignore` config option for the bare repo and initializing an independent directory special-remote.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Atemu"
- avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
- subject="comment 2"
- date="2021-05-26T07:11:20Z"
- content="""
-The problem is that I need this repo to stay a remote from the eyes of all other repos; I need to be able to get files from and add new ones to it. I just want its storage back-end to work a little differently so that it fits my use-case.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-05-27T16:15:31Z"
- content="""
-It would not make sense for a non-bare git repository to have annexed
-contents in it encrypted or chunked, because that would prevent actually
-accessing the annexed files at all; git-annex symlinks have to point to a
-complete, non-encrypted file.
-
-Bare git repositories are a very minor special case of non-bare git
-repositories; they do not have a work tree or index. In other
-respected, they are the same, and it's entirely possible to manually
-convert a git repo to or from bare, or even temporarily use a bare repo
-with a work tree.
-
-It would be extremely inelegant if git-annex did something that broke
-that. Which this would.
-
-I think you should use a rsync special remote possibly. Which also has the
-same layout as a directory special remote.
-"""]]
+++ /dev/null
-When you want to dead a file in your checkout, you can only do so via the key of the file. You can find the corresponding key with a bit of bash like this: `git annex dead --key $(basename $(readlink file))` but that shouldn't be necessary IMO.
-
-It'd be a lot better if you could just dead files like this: `git annex dead --file file` or even like this: `git annex dead --file file1 file2 file3 otherfiles.*` (or maybe even like this: `git annex dead --file file1 file2 --key $key1 $key2`).
-
-> [[done]] in another way --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-05-31T19:08:32Z"
- content="""
-I suppose this could be useful, but note that `git annex fsck` without
---all will still warn if it finds a file in the working tree with no
-existing content, even if its key has been marked dead. Because having a
-file in the working tree that you can't get is certainly a bad situation.
-
-So, if this feature got implemented, you would want to follow `git annex
-dead` of a file with `git rm` of the file. Probably.
-
-The other reason dead only operates on keys is that the expected
-workflow was that the user will lose data, will delete the lost file out of
-their working tree, or overwrite it or whatever, and then at some later
-point get annoyed that fsck --all complains about it, and so then mark it
-dead. But if you want to be proactive, marking a file dead is certainly
-useful to be able to do.
-
-I'd also be concerned that `git annex dead` or `git annex dead .` run
-accidentally could be an annoying mistake to recover from. Certianly
-it should not default to marking all files dead when there are no
-parameters!
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-06-25T18:22:04Z"
- content="""
-In <https://git-annex.branchable.com/forum/Forget_about_accidentally_added_file__63__/>
-there is an idea of `git annex unannex --forget file`
-
-And using unannex for this makes some sense; it's intended to be used to undo an
-accidental `git-annex add`. When it's used that way, and later `git-annex
-unused` finds the object file is not used by anything and the object gets
-deleted, fsck --all will start complaining about it.
-
-But there are still many ways it could go wrong. Being run recursively by
-accident. Or another file, perhaps in another branch, using the same key,
-which gets marked as dead.
-
-Hmm, `git annex dropunused` (or `drop --unused`)
-could mark the key as dead. At that point it's known to be unused.
-
-This way, the existing workflow of git-annex unannex followed by git-annex
-unused followed by dropping can be followed, and fsck --all does
-not later complain about the key.
-
-Done!
-"""]]
+++ /dev/null
-Consider this, where branch foo has ten to a hundred thousand files
-not in the master branch:
-
- git checkout foo
- touch newfile
- git annex add newfile
-
-After recent changes to reconcileStaged, the result can be:
-
- add newfile 0b 100% # cursor sits here for several seconds
-
-This is because it has to look in the keys db to see if there's an
-associated file that's unlocked and needs populating with the content of
-this newly available key, so it does reconcileStaged, which can take some
-time.
-
-One fix would be, if reconcileStaged is taking a long time, make it display
-a note about what it's doing:
-
- add newfile 0b 100% (scanning annexed files...)
-
-It would also be possible to do the scan before starting to add files,
-which would look more consitent and would avoid it getting stuck
-with the progress display in view:
-
- (scanning annexed files...)
- add newfile ok
-
-> [[done]] --[[Joey]]
-
-It might also be possible to make reconcileStaged run a less expensive
-scan in this case, eg the scan it did before
-[[!commit 428c91606b434512d1986622e751c795edf4df44]]. In this case, it
-only really cares about associated files that are unlocked, and so
-diffing from HEAD to the index is sufficient, because the git checkout
-will have run the smudge filter on all the unlocked ones in HEAD and so it
-will already know about those associated files. However, I can't say I like
-this idea much because it complicates using the keys db significantly.
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-06-08T15:21:02Z"
- content="""
-Made `git-annex smudge --update` run the scan, and so the post-checkout or
-post-merge hook will call it.
-
-That avoids the scenario shown above. But adding a lot of files to the
-index can still cause a later pause for reconcileStaged without indication
-what it's doing.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-06-08T16:03:13Z"
- content="""
-I tried making reconcileStaged display the message itself, this is the
-result:
-
- add foo
- 100% 30 B 73 KiB/s 0s(scanning for annexed files...)
- ok
-
-So for that to be done, showSideAction would need to clear the progress
-bar display first. Note that the display is ok when concurrent output is
-enabled:
-
- add c (scanning for annexed files...)
- ok
-
-Ok.. Fixed that display glitch, and made reconcileStaged display
-the message itself when it's taking a while to run.
-"""]]
+++ /dev/null
-The protocol has `GETCONFIG`, which gives access to the configuration
-stored in remote.log, but it does not provide a good way to access git
-configs set on the remote.
-
-Datalad uses `GETCONFIG name` to get the remote name, and
-then using git config to get its configs. That is suboptimal
-because sameas remotes use sameas-name instead, and also because
-the two names are not necessarily the same, eg `git remote rename` can
-rename the git remote while the git-annex config still uses the other name.
-<https://github.com/datalad/datalad/issues/4259>
-
-One way to do that is `GETUUID` and then look for the git remote with
-annex-uuid set to that, in order to learn its name and then find its other git
-configs. But, it's also possible for there to be multiple git remotes with the
-same annex-uuid. (This does not happen with sameas remotes, but like a git repo
-can have multiple remotes pointing to it by different paths, the same can be
-set up for a special remote, at least in theory.)
-
-So, the protocol should be extended. Either with a way to get/set a single git
-config (like `GETCONFIG`/`SETCONFIG` do with the remote.log config), or with a
-way to get the git remote name.
-
-The latter has the problem that this business of there being multiple
-names for different related things that might be different but are probably
-the same is a perhaps not something people want to learn about.
-
-The former seems conceptually simpler, but there might be things that
-`git config` could do, that providing an interface on top of it would not
-allow. The --type option is one thing that comes to mind. --[[Joey]]
-
-> [[done]] as the GETGITREMOTENAME protocol extension and message.
-> --[[Joey]]
+++ /dev/null
-`git annex fsck` currently spams the terminal with all keys in a repo and prints `git-annex: fsck: n failed` at the end if errors occur. Finding these errors in a sea of `ok`s is not trivial however.
-
-A simple solution to this could be an fsck option which skips printing ok'd (and perhaps also dead) keys, i.e. `--no-ok` and `--no-dead`.
-
-[[!meta title="mention common options on per-command man pages"]]
-
-> common option man page and references [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 1"
- date="2021-05-10T12:21:37Z"
- content="""
-Just use the `--quiet` option, then it will only show the errors (failed files/keys).
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Atemu"
- avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
- subject="comment 2"
- date="2021-05-10T14:13:55Z"
- content="""
-Thanks, that's exactly what I'm looking for!
-
-It's not in the git-annex-fsck manpage though for some reason.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-05-10T15:07:06Z"
- content="""
-Normally the common options are not included in every command's man page
-because there are over 100 lines of them. However, I do think it's worth
-including --quiet on fsck's man page in this specific case and am doing
-that.
-
-Maybe individual command man pages should mention that there are
-also a bunch of common options. Perhaps those should be split out of the
-git-annex man page, like the git-annex-matching-options man page is
-handled.
-"""]]
+++ /dev/null
-ATM `annex get` (in particular '--json --json-error-messages --json-progress') would channel to the user the error from an attempt to get a key from a remote with a message which lacks information about remote and/or specifics of that particular attempt (e.g. which URL was attempted from web remote), e.g.
-
-```
-$> git clone https://github.com/dandisets/000029 && cd 000029
-Cloning into '000029'...
-remote: Enumerating objects: 326, done.
-remote: Counting objects: 100% (326/326), done.
-remote: Compressing objects: 100% (160/160), done.
-remote: Total 326 (delta 137), reused 295 (delta 106), pack-reused 0
-Receiving objects: 100% (326/326), 45.53 KiB | 1.30 MiB/s, done.
-Resolving deltas: 100% (137/137), done.
-dandiset.yaml sub-RAT123/ sub-anm369962/ sub-anm369963/ sub-anm369964/
-
-$> git update-ref refs/remotes/origin/git-annex b822a8d40ff348a60602f13d0add989bd24e727a # URLs fixed since then
-
-$> git annex get sub-RAT123
-get sub-RAT123/sub-RAT123.nwb (from web...)
-
- download failed: Not Found
-
-ok
-(recording state in git...)
-
-$> git annex version | head -n 1
-git-annex version: 8.20210803+git165-g249d424b8-1~ndall+1
-```
-
-NB. That "download failed: Not Found" is also channeled in that form (without any extra information) among "errors" of `--json-error-messages` (and each progress message within `--json-progress`)
-
-As such the message is not informative really, and might even be a bit confusing to the user since `get` does `ok` eventually here.
-I think it is useful to channel such information but it should be extended, e.g. in this case could be
-
-```
- failed to retrieve content from 'web' remote: https://api.dandiarchive.org/api/dandisets/000029/versions/draft/assets/b3675aad-db07-4fd4-9cce-c95f1184e7a3/download/ - Not Found
-```
-
-or alike. Even though considerably longer, it immediately provides feedback from which remote it failed to retrieve, and what was that particular URL.
-
-
-refs in DataLad issues:
-
-- from web remote: ["download failed: Not Found"](https://github.com/datalad/datalad/pull/5936)
-- from ["failed to retrieve content from remote"](https://github.com/datalad/datalad/issues/5750)
-
-> I think this is specific to downloading urls, although it can happen
-> for a few remotes (web, external). There's really no reason to display
-> a download failed message if it successfully downloads a later url.
-> (After all, if it had tried the working url first, it would never display
-> anything about the broken url.)
->
-> When all urls fail, it makes sense to display each url and why it failed
-> when using the web (or external) remote, so the user can decide what to
-> do about each of the problems.
->
-> [[done]] --[[Joey]]
+++ /dev/null
-Can git-annex-get be extended so that "git-annex-get --batch --key" fetches the keys (rather than filenames) given in the input?
-
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-09-18T17:07:56Z"
- content="""
---key can't be reused for another meaning like this, it would make "--key
-foo" be ambiguous.
-
-It would need to be some other option, --batch-key or whatever.
-
-Adding this would seem to open the door to adding it to every command that
-supports --batch now. I'm unsure if the added complexity justifies it.
-
-I'd be more sanguine if there were a way to reuse the existing batch
-machinery and apply it to keys. But many commands' --batch honor file
-matching options (eg --copies or --include), and that cannot be done when
-using keys.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://christian.amsuess.com/chrysn"
- nickname="chrysn"
- avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
- subject="Usefulness of batch key processing"
- date="2020-05-15T09:21:15Z"
- content="""
-This would be quite helpful to tools using git-annex (eg. [annex-to-web](https://gitlab.com/chrysn/annex-to-web), issue [2](https://gitlab.com/chrysn/annex-to-web/-/issues/2)), especially for short-running things like `whereis` where the launching time dominates over the processing time.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://christian.amsuess.com/chrysn"
- nickname="chrysn"
- avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
- subject="Re: Usefulness of batch key processing"
- date="2020-05-15T09:33:22Z"
- content="""
-Concerning the filtering, I'd find a note that \"--batch-keys is mutually exclusive with filtering\" perfectly acceptable if that makes implementation easier. (Or \"only with the filtering options that apply to keys\" -- as I found that `git annex whereis --in web --key=...` does work well with the key input).
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://christian.amsuess.com/chrysn"
- nickname="chrysn"
- avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
- subject="Another example"
- date="2021-08-15T17:42:54Z"
- content="""
-The program at [[forum/Migrate_mark_files_dead]] shows again how batch-key would be useful, here for `git annex drop --from remote` and `git annex dead`.
-
-I don't have numbers as I can't run it in batch, but comparing to other multi-file batch drop operations, I guesstimate this makes the difference of a script running for an hour invoking git-annex-drop a thousand times (with interruptions if the SSH agent decides to ask confirmation for a key again) or five minutes with --batch-key.
-
-Like with the original use case of annex-to-web, filtering is not an issue for this application.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2021-08-25T18:06:29Z"
- content="""
-I've implemented --batch-keys for the commands: get, drop, move, copy, whereis
-
-That covers everything mentioned here except for dead, but that does not
-support --batch yet, so if batch mode is needed for it, it can just use
---batch, not --batch-keys. However, after a recent change that makes
-dropping unused keys automatically mark them dead, I suspect there
-will not be a use case for that.
-
-Most of the other commands that use --batch don't make sense to support
---batch-keys. Eg, add and find can't operate on keys, while
-fromkey already operates on keys. About the only one that might is
-rmurl, but it uses a custom batch format so would not be able to use the
-current --batch-keys implementation. If someone needs that or some other
-one, they can open a new todo.
-"""]]
+++ /dev/null
-Files in the git-annex branch use timestamps to ensure that the most
-recently recorded state wins. This is unsatisfying, because it requires
-accurate clocks amoung all users. It would be better to use vector clocks,
-where possible, but it is not possible to use vector clocks for all
-information in the branch.
-
-To see why vector clocks can't be used for some information in the branch,
-consider location log files. They are meant to reflect the actual state of
-an external resource. Vector clocks can ensure that a consistent state is
-agreed on by distributed users, but there's no way to guarantee that state
-matches the actual state.
-
-For example, let's assume there's a vector clock consisting of an an
-integer, and an object is being added and removed from a remote by multiple
-parties. First Alice logs (present, 1), and then some time later, Alice
-logs (missing, 2). Meanwhile, Bob merges (present, 1) from Alice
-and then logs (missing, 2), followed by (present, 3). At some later point,
-they merge back up, and the winning state is (present, 3) as it has the
-highest vector clock. Is the content really present on the remote?
-Well, we don't know, Alice could have removed it before Bob stored it,
-or afterwards.
-
-But, other information in the branch could use vector clocks. Consider
-numcopies setting. It's fine if the winner of a conflict over that is not
-the one who set it most recently, as long as a value can be consistently
-determined. So, the numcopies setting, and similar other configuration, is not
-trying to track an external state, and so it could use vector clocks.
-
-How would these vector clocks work, and how to transition to using them
-without confusing old versions of git-annex that expect timestamps? A
-change to a log could simply increment the clock from the previous
-version of the log. This would make the new git-annex normally lose
-when a conflicting change was written by an old git-annex, but the result
-would be consistent, so that's acceptable.
-
-Files that are related to external state need to continue to use
-timestamps. But this could still be improved. Currently, if the clock is
-wronly set far in the future, logs using those timestamps will win over
-other logs for a long time. This could break git-annex badly as there
-becomes no way to correct wrong information.
-
-Experimenting with `GIT_ANNEX_VECTOR_CLOCK`, it looks like `git annex fsck`
-is able to recover from wrong location information being recorded with a
-far future timestamp. It replaces that timestamp with the current one.
-However, if that then gets union merged with a change to the same location
-log made in another repository, fsck's correction can be lost in the merge.
-Re-running the fsck will eventually get the information corrected, once a
-non-union merge happens. However, `git annex fsck` can't correct other
-logs, like remote state logs, if they end up with bad information with
-a far future timestamp.
-
-There's a mirror problem of information being recorded with a timestamp
-in the past and being ignored. But, at least in that case, re-recording
-good information with the right timestamp will fix the problem.
-
-Consider making git-annex ignore future timestamps
-(with some amount of allowance for minor lock skew). There are two
-problems, one is that currently valid information gets ignored, until it's
-able to be re-recorded. The second is that when the timestamp slips
-into the past, the old, invalid information suddenly starts being taken
-into account.
-
----
-
-A better idea: When writing new information, check if the old
-value for the log has a timestamp `>=` current timestamp. If so, don't use the
-current timestamp for the new information, instead increment the old
-timestamp. So when there's clock skew (forwards or backwards), this makes
-it fall back, effectively to vector clocks.
-
-This would work for both kinds of logs. For configuration changes,
-it's kind of better than using only vector clocks, because in the absence
-of clock skew, the most recent change to a configuration wins. For state
-changes, it keeps the benefits of timestamps except when there's clock
-skew, in which case there are not any benefits of timestamps anymore
-so vector clocks is the best that can be done. --[[Joey]]
-
-(How would `GIT_ANNEX_VECTOR_CLOCK` interact with this? Maybe, when that's
-set to a low number, it would be treated as the current time. So this would
-let it be used and not, without issues, and also would let it be set to a
-low number once, and not need to be changed, since git-annex would
-increment as necessary.)
-
-> The `vectorclock` branch has this mostly implemented. --[[Joey]]
-
-> > [[done]] --[[Joey]]
+++ /dev/null
-`git annex whereused` would report where in the git repository a
-key is used, as a complement to `git-annex unused`.
-
-Use cases include users not getting confused about why git-annex unused
-says a key is used.
-
-Also, it could scan through history to find where a key *was* used.
-git-annex unused outputs a suggestion to use a rather hairy `git log -S`
-command to do that currently.
-
-If it does both these things, it could explain why git-annex unused
-considers a key used despite a previous git rev referring to it. Eg:
-
- # git annex whereused SHA1--foo
- checking index... unused
- checking branches... unused
- checking tags... unused
- checking history... last used in master^40:somefile
- checking reflog... last used in HEAD@{30}:somefile
-
---[[Joey]]
-
-> First pass is a keys db lookup to filenames.
->
-> The historical pass can be done fairly efficiently by using
-> `git log -Skey --exclude=*/git-annex --glob=* --exclude=git-annex --remotes=* --tags=* --pretty='%H' --raw`
-> and fall back to `git log -Skey --walk-reflogs --pretty='%gd' --raw` if nothing was found.
->
-> That makes git log check all commits reachable from those refs,
-> probably as efficiently as possible, and stop after one match.
-> It won't allow quite as nice a display as above.
->
-> Parse the log output for commit sha and filename. Double-check
-> by catting the file's object and making sure it parses as an annex
-> link or pointer.
->
-> Then use `git describe --contains --all` to get a description of the commit
-> sha, which will be something like "master~2" or "origin/master~2",
-> and add ":filename" to get the ref to output.
->
-> Or, if it was found in the ref log, take the "HEAD@{n}" from log
-> output, and add ":filename"
-
-[[done]] --[[Joey]]
+++ /dev/null
-From [another thread](https://git-annex.branchable.com/todo/add_option_to_use_sqlite__39__s_synchronous__61__OFF/#comment-dbc9fdf5fd6d73f3e628bfe94b2a43a2):
-
->Quite possible there are situations where it fails to recover the lost information and does something annoying. But like I said, such situations can already happen
-
-Maybe, there are some simple ways to harden git-annex against possible weirdness following abrupt interruptions? E.g. using flag files to detect when a prior operation got interrupted,
-and rebuilding the sqlite dbs from git data. Or tagging sqlite records with the timestamp of their creation, and not using the data if the relevant worktree files got modified since then.
-
-> [[closing|done]] per comment --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-06-25T16:06:59Z"
- content="""
-I could make that statement about basically any program. I think git-annex
-deals with interruptions well. It is written with idempotency in mind. I
-interrupt it all the time. It always behaves well. That is not a proof that
-there is not some unforseen situation where I have made a mistake.
-"""]]
+++ /dev/null
-If a tree containing a non-annexed file (checked directly into git) is exported,
-and then an import is done from the remote, the new tree will have that
-file annexed, and so merging it converts to annexed (there is no merge
-conflict).
-
-If the user is using annex.largefiles to configure or list
-the non-annexed files, they'll be ok, but otherwise they'll be in for some
-pain.
-
-The importer could check for each file, if there's a corresponding file in
-the branch it's generating the import for, if that file is annexed.
-This corresponds to how git-annex add (and the smudge filter) handles these
-files. But this might be slow when importing a large tree of files.
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-03-05T16:38:25Z"
- content="""
-This leads to worse behavior than just converting to annexed from
-non-annexed. The converted file's contents don't verify due to some
-confusion between git and git-annex's use of SHA1. See
-<https://git-annex.branchable.com/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/>
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-03-05T16:42:03Z"
- content="""
-> The importer could check for each file, if there's a corresponding file in the branch it's generating the import for, if that file is annexed.
-
-Should it check the branch it's generating the import for though?
-If the non-annexed file is "foo" and master is exported, then in master
-that file is renamed to "bar", the import should not look at the new master
-to see if the "foo" from the remote should be annexed. The correct tree
-to consult would be the tree that was exported to the remote last.
-
-It seems reasonable to look at the file in that exported tree to see it was
-non-annexed before, and if the ContentIdentifier is the same as what
-was exported before, keep it non-annexed on import. If the ContentIdentifier
-has changed, apply annex.largefiles to decide whether or not to annex it.
-
-The export database stores information about that tree already,
-but it does not keep track of whether a file was exported annexed or not.
-So changing the database to include an indication of that, and using it
-when importing, seems like a way to solve this problem, and without slowing
-things down much.
-
-*Alternatively* the GitKey that git-annex uses for these files when
-exporting is represented as a SHA1 key with no size field. That's unusual;
-nothing else creates such a key usually. (Although some advanced users may
-for some reason.) Just treating such keys as non-annexed files when
-importing would be at least a bandaid if not a real fix.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-03-05T17:31:32Z"
- content="""
-Wait... The import code has a separate "GIT" key type that it uses
-internally once it's decided a file should be non-annexed. Currently
-that never hits disk. Using that rather than a SHA1 key for the export
-database could be a solution.
-
-(Using that rather than "SHA1" for the keys would also avoid
-the problem that the current GitKey hardcods an assumption
-that git uses sha1..)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-03-05T17:44:54Z"
- content="""
-In fact, a very simple patch that just makes a GitKey generate a
-"GIT" key seems to have solved this problem! Files that were non-annexed
-on export remain so on import, until they're changed, and then
-annex.largefiles controls what happens.
-
-Once non-annexed files have been exported using the new version, they'll
-stay non-annexed on import. Even when an old version of git-annex is doing
-the importing!
-
-When an old annex had exported, and a new one imports, what happens is
-the file gets imported as an annexed file. Exporting first with the new
-version avoids that unwanted conversion.
-
-Interestingly though, the annexed file when that conversion happens does
-not use the SHA1 key from git, so its content can be retrieved. I'm not
-quite sure how that problem was avoided in this case but something avoided
-the worst behavior.
-
-It would be possible to special case the handling of SHA1 keys without a
-size to make importing from an old export not do the conversion. But that
-risks breakage for some user who is generating their own SHA1 keys and not
-including a size in them. Or for some external special remote that supports
-IMPORTKEY and generates SHA1 keys without a size. It seems better to avoid
-that potential breakage of unrelated things, and keep the upgrade process
-somewhat complicated when non-annexed files were exported before, than it
-does to streamline the upgrade.
-"""]]
+++ /dev/null
-When a FAT filesystem is unmounted and remounted, the inode numbers all
-change. This makes import tree from a directory special remote on FAT
-think the files have changed, and so it re-imports them. Since the content
-is the unchanged, the unnecessary work that is done is limited to hashing
-the file on the FAT filesystem. But that can be a lot of work when the tree
-being imported has a lot of large files in it.
-
-This makes import tree potentially much slower than the legacy import
-interface (although that interface also re-hashes when used with
---duplicate/--skip-duplicates).
-
-Also, the content identifier log gets another entry, with a content
-identifier with the new inode number. So over time this can bloat the log.
-
-May be better to omit the inode number from the content
-identifier for such a filesystem, instead relying on size and mtime?
-Although that would risk missing swaps of files with the same size and
-mtime, that seems like an unlikely thing, and in any case git-annex would
-import the data, and only miss the renaming of the files. It would also
-miss modifications that don't change size and preserve the mtime; such
-modifications are theoretically possible, but unlikely.
-
-But how to detect when it's a FAT filesystem with this problem?
-The method git-annex uses when running on a FAT filesystem, of maintaining
-an inode sentinal file and checking it to tell when inodes have changed
-would need importing to write to the drive. That seems strange, and the
-drive could even be read-only. May be the directory special remote should
-just not use inode numbers at all?
-
-> [[done]] --[[Joey]]
+++ /dev/null
-[glacier-cli](https://github.com/basak/glacier-cli) calls its own command `glacier` rather than `glacier-cli` or something else. This conflicts with [boto](https://github.com/boto/boto/)'s own `glacier` executable, as noted here:
-
-* <https://github.com/basak/glacier-cli/issues/30>
-* <https://github.com/basak/glacier-cli/issues/47>
-
-Whilst the `glacier-cli` project should resolve this conflict, it would be good if git-annex could be made to use a configurable path for this executable, rather than just assuming that it has been installed as `glacier`. After all, its installation procedure is simply telling the user to run `ln -s`, so there's no reason why the user couldn't make the target of this command `~/bin/glacier-cli` rather than `~/bin/glacier` - it's really irrelevant what the source file inside the git repo is called.
-
-Of course, [`checkSaneGlacierCommand`](https://github.com/joeyh/git-annex/blob/master/Remote/Glacier.hs#L307) is still very much worth having, for safety.
-
-> Well, it never got renamed, and checkSaneGlacierCommand does check for
-> the conflict, so I don't see any point in making the name configurable.
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="basak"
- subject="comment 1"
- date="2015-04-24T15:48:48Z"
- content="""
-Well, it's supposed to be a command line command, and I don't type `cd-cli` and `ls-cli`. So while `glacier-cli` might be fine as a project name and is fine for a name for integration, I don't think it makes sense to call it that in `/usr/bin/`, which is why I didn't. I'd prefer to have seen that boto integrate an improved `glacier` command, or for packaging to provide this one as an alternative (like `mawk` vs. `gawk` as `/usr/bin/awk`). But upstream boto considers themselves deprecated, so that's not going to happen. One of these days I'll package glacier-cli up for Debian, at which point I'll see if the boto maintainer is interested in doing something, since I don't actually believe anybody uses boto's glacier command (since it's mostly useless).
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="https://adamspiers.wordpress.com/"
- nickname="adamspiers"
- subject="Good point"
- date="2015-04-24T15:55:29Z"
- content="""
-glacier-cli would be a rather silly name to put in `/usr/bin`. How about `glcr`, as suggested [here](https://github.com/basak/glacier-cli/issues/30#issuecomment-95972840)?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-04-24T17:23:10Z"
- content="""
-I don't want to complicate git-annex more with configurable names for
-programs, and glacier is not at all special in this regard, any program
-could be installed under any namee. We pick non-conflicting names to
-avoid integration nightmares. Pick a name and I'll use it.
-"""]]
+++ /dev/null
-Like was recently done for preferred content, when checking numcopies for a
-drop, it could check if other files are using the same key, and if so check
-that their numcopies (and mincopies) is satisfied as well.
-
-There would be an efficiency tradeoff of course, since it would have to
-query the keys db. The question I suppose is, if someone sets different
-numcopies for different files via .gitattributes, and they use the same
-key, will the user think it's a problem that numcopies can be violated in
-some circumstances. And I think that users would maybe consider that to be
-a problem, if they happened to encounter the behavior.
-
-It may also be worth considering making --all (etc) also check numcopies of
-associated files. Although then, in a bare repo, it would behave
-differently than in a non-bare repo. (Also if this is done, the preferred
-content checking should also behave the same way.) The docs for --all
-do say that it bypasses checking .gitattributes numcopies.
---[[Joey]]
-
-> Note that the assistant and git-annex sync already check numcopies
-> for all known associated files, so already handled this for unlocked
-> files. With the recent change to also track
-> associated files for locked files, they also handle it for those.
->
-> But, git-annex drop/move/mirror don't yet.
->
-> > [[fixed|done]] (did not change --all behavior) --[[Joey]]
+++ /dev/null
-Right now, non-annexed files get passed through the `annex` clean/smudge filter (see [[forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase]]). It would be better if `git-annex` configure the filter only for the annexed unlocked files, in the `.gitattributes` file at the root of the repository.
-
-> not a viable solution, [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2019-11-22T16:01:26Z"
- content="""
-It immediately occurs to me that the proposal would break this:
-
- git annex add foo
- git annex add bar
- git annex unlock bar
- git mv bar foo
- git commit -m add
-
-Since foo was a locked file, gitattributes would prevent from being
-smudged, so the large content that was in bar gets committed directly to git.
-
-The right solution is to improve the smudge/clean filter interface to it's
-not so slow, which there is copious discussion of elsewhere.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="moving unlocked file onto locked file isn't possible"
- date="2019-11-24T16:36:24Z"
- content="""
-`git mv` won't move an unlocked file onto a locked file (trace below).
-
-\"The right solution is to improve the smudge/clean filter interface\" -- of course, but realistically, do you think git devs can be persuaded to do [[this|todo/git_smudge_clean_interface_suboptiomal]] sometime soon? Even if yes, it still seems better to avoid adding a step to common git workflows, than to make the step fast.
-
-
-[[!format sh \"\"\"
-(master_env_v164_py36) 11:14 [t1] $ ls
-bar foo
-(master_env_v164_py36) 11:14 [t1] $ git init
-Initialized empty Git repository in /tmp/t1/.git/
-(master_env_v164_py36) 11:14 [t1] $ git annex init
-init (scanning for unlocked files...)
-ok
-(recording state in git...)
-(master_env_v164_py36) 11:14 [t1] $ git annex add foo
-add foo ok
-(recording state in git...)
-(master_env_v164_py36) 11:14 [t1] $ git annex add bar
-add bar ok
-(recording state in git...)
-(master_env_v164_py36) 11:14 [t1] $ ls -alt
-total 0
-drwxrwxr-x 8 ilya ilya 141 Nov 24 11:14 .git
-drwxrwxr-x 3 ilya ilya 40 Nov 24 11:14 .
-lrwxrwxrwx 1 ilya ilya 108 Nov 24 11:14 bar -> .git/annex/objects/jx/MV/MD5E-s4--c157a79031e1c40f85931829bc5fc552/MD5E-s4--c157a79031\
-e1c40f85931829bc5fc552
-lrwxrwxrwx 1 ilya ilya 108 Nov 24 11:14 foo -> .git/annex/objects/00/zZ/MD5E-s4--d3b07384d113edec49eaa6238ad5ff00/MD5E-s4--d3b07384d1\
-13edec49eaa6238ad5ff00
-drwxrwxrwt 12 root root 282 Nov 24 11:14 ..
-(master_env_v164_py36) 11:14 [t1] $ git annex unlock bar
-unlock bar ok
-(recording state in git...)
-(master_env_v164_py36) 11:16 [t1] $ git mv bar foo
-fatal: destination exists, source=bar, destination=foo
-(master_env_v164_py36) 11:17 [t1] $
-
-
-
-\"\"\"]]
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="even git mv -f seems to work correctly"
- date="2019-11-24T17:25:32Z"
- content="""
-Also, `git mv` seems to reuse the already-smudged object contents of the source file for the target file, so even with `git mv -f` only the checksum gets checked into git:
-
-[[!format sh \"\"\"
-+ cat ./test-git-mv
-#!/bin/bash
-
-set -eu -o pipefail -x
-
-cat $0
-
-TEST_DIR=/tmp/test_dir
-mkdir -p $TEST_DIR
-chmod -R u+w $TEST_DIR
-rm -rf $TEST_DIR
-mkdir -p $TEST_DIR
-pushd $TEST_DIR
-
-git init
-git annex init
-
-git --version
-git annex version
-
-rm .git/info/attributes
-echo foo > foo
-echo bar > bar
-git annex add foo bar
-git check-attr -a foo
-git check-attr -a bar
-echo 'bar filter=annex' > .gitattributes
-git add .gitattributes
-git check-attr -a foo
-git check-attr -a bar
-
-git annex unlock bar
-git mv bar foo || true
-git mv -f bar foo
-git commit -m add
-git log -p
-
-
-+ TEST_DIR=/tmp/test_dir
-+ mkdir -p /tmp/test_dir
-+ chmod -R u+w /tmp/test_dir
-+ rm -rf /tmp/test_dir
-+ mkdir -p /tmp/test_dir
-+ pushd /tmp/test_dir
-/tmp/test_dir /tmp
-+ git init
-Initialized empty Git repository in /tmp/test_dir/.git/
-+ git annex init
-init (scanning for unlocked files...)
-ok
-(recording state in git...)
-+ git --version
-git version 2.20.1
-+ git annex version
-git-annex version: 7.20191024-g6dc2272
-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.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 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
-+ rm .git/info/attributes
-+ echo foo
-+ echo bar
-+ git annex add foo bar
-add foo ok
-add bar ok
-(recording state in git...)
-+ git check-attr -a foo
-+ git check-attr -a bar
-+ echo 'bar filter=annex'
-+ git add .gitattributes
-+ git check-attr -a foo
-+ git check-attr -a bar
-bar: filter: annex
-+ git annex unlock bar
-unlock bar ok
-(recording state in git...)
-+ git mv bar foo
-fatal: destination exists, source=bar, destination=foo
-+ true
-+ git mv -f bar foo
-+ git commit -m add
-[master (root-commit) 8610c0d] add
- 2 files changed, 2 insertions(+)
- create mode 100644 .gitattributes
- create mode 100644 foo
-+ git log -p
-commit 8610c0d8f327140608e71dc229f167731552d284
-Author: Ilya Shlyakhter <ilya_shl@alum.mit.edu>
-Date: Sun Nov 24 12:24:28 2019 -0500
-
- add
-
-diff --git a/.gitattributes b/.gitattributes
-new file mode 100644
-index 0000000..649f07e
---- /dev/null
-+++ b/.gitattributes
-@@ -0,0 +1 @@
-+bar filter=annex
-diff --git a/foo b/foo
-new file mode 100644
-index 0000000..266ae50
---- /dev/null
-+++ b/foo
-@@ -0,0 +1 @@
-+/annex/objects/MD5E-s4--c157a79031e1c40f85931829bc5fc552
-
-\"\"\"]]
-
-
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="installing clean/smudge filter lazily"
- date="2021-03-19T02:30:13Z"
- content="""
-\"the proposal would break this\" -- suppose [[`git-annex-unlock`|git-annex-unlock]] was changed to install the clean/smudge filter for `*` if not installed yet?
-
-Related: [Avoid lengthy \"Scanning for unlocked files ...\"](https://git-annex.branchable.com/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/)
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2021-03-23T16:02:47Z"
- content="""
-> "the proposal would break this" -- suppose git-annex-unlock was changed to install the clean/smudge filter for * if not installed yet?
-
-git-annex unlock is not the only way unlocked files can appear in your
-tree. Consider git pull.
-"""]]
+++ /dev/null
-Some things to do with the [[design/P2P_protocol]]
-are works in progress, needing a future flag day to complete.
-
-## VERSION over tor
-
-Old versions of git-annex, before 6.20180312, which speak the P2P protocol
-over tor, don't support VERSION, and attempting to negotiate a version
-will cause the server to hang up the connection. To deal with this
-historical bug, the version is not currently negotiated when using the
-protocol over tor. At some point in the future, when all peers can be
-assumed to be upgraded, this should be changed.
-
-> [[done]] --[[Joey]]
-
-## git-annex-shell fallbacks
-
-When using git-annex-shell p2pio, git-annex assumes that if it exits 1,
-it does not support that, and falls back to the old sendkey/rerecvkey,
-etc.
-
-At some point in the future, once all git-annex and git-annex-shell
-can be assumed to be upgraded to 6.20180312, this fallback can be removed.
-It will allows removing a lot of code from git-annex-shell and a lot of
-fallback code from Remote.Git.
-
-> [[done]] --[[Joey]]
-
-[[!tag confirmed]]
+++ /dev/null
-git-annex has good support for running commands in parallel, but there
-are still some things that could be improved, tracked here:
-
-* Maybe support -Jn in more commands. Just needs changing a few lines of code
- and testing each.
-
-* Maybe extend --jobs/annex.jobs for more control. `--jobs=cpus` is already
- supported; it might be good to have `--jobs=cpus-1` to leave a spare
- cpu to avoid contention, or `--jobs=remotes*2` to run 2 jobs per remote.
-
-> Ok, those are maybe good ideas, but this needs to be closed at some
-> point, so [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="parallelization"
- date="2019-11-27T17:23:14Z"
- content="""
-When operating on many files, maybe run N parallel commands where i'th command ignores paths for which `(hash(filename) module N) != i`. Or, if git index has size I, i'th command ignores paths that are not legixographically between `index[(I/N)*i]` and `index[(I/N)*(i+1)]` (for index state at command start). Extending [[git-annex-matching-options]] with `--block=i` would let this be done using `xargs`.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2020-01-30T19:24:47Z"
- content="""
-How would running parallel commands with xargs be better than the current
--J?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="running parallel commands with xargs"
- date="2020-02-20T20:48:33Z"
- content="""
-\"How would running parallel commands with xargs be better than the current -J\" -- it would allow writing wrappers that kill/retry stuck git-annex process trees, as suggested [[here|https://git-annex.branchable.com/todo/more_extensive_retries_to_mask_transient_failures/#comment-209f8a8c38e63fb3a704e1282cb269c7]].
-"""]]
+++ /dev/null
-Hello,
-
-By means of bisection I have determined that commit 4bf7940d6b912fbf692b268f621ebd41ed871125, recently uploaded to Debian after the bullseye freeze, is responsible for breaking the annex-to-annex-reinject script which ships with Git::Annex. Here is a minimal reproducer of the problem:
-
- spwhitton@melete:~/tmp>echo foo >bar
- spwhitton@melete:~/tmp>mkdir annex
- spwhitton@melete:~/tmp>cp bar annex
- spwhitton@melete:~/tmp>cd annex
- spwhitton@melete:~/tmp/annex>git init
- spwhitton@melete:~/tmp/annex>git annex add bar
- spwhitton@melete:~/tmp/annex>git annex drop --force bar
- spwhitton@melete:~/tmp/annex>git annex reinject --known /home/spwhitton/tmp/bar
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- fatal: './../bar' is outside repository at '/home/spwhitton/tmp/annex'
- git-annex: fd:15: Data.ByteString.hGetLine: end of file
-
---spwhitton
-
-> [[fixed|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-10-01T16:42:36Z"
- content="""
-Also happens with a relative path to the file. And also
-`git annex reinject ../bar bar` fails the same way.
-
-Fixed. In case you want to cherry-pick the fix, it's the commit adding
-this comment, as well as the 2 prior commits fixing bugs in dirContains.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="spwhitton"
- avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
- subject="comment 2"
- date="2021-10-02T17:04:02Z"
- content="""
-Thanks so much for the fix! It looks like cherry-picking breaks the test suite, so I'll probably just wait for the next release.
-"""]]
+++ /dev/null
-Small files might also be used for performance reasons, so there should be an option to also automatically fix merge conflicts for small files in git-annex-sync.
-
-> [[wontfix|done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-06-23T16:43:34Z"
- content="""
-There's a reason people don't want git to automatically resolve merge
-conflicts of code, and for all git-annex knows small files are code.
-
-Or looking at it from the other perspective, non-technical git-annex
-assistant users need an automatic merge conflict resolution of annexed
-files, since the assistant commits changes to those files and otherwise
-they could end up with a conflict they don't understand how to resolve.
-
-And, git-annex sync inherited that from the assistant. Which may or may not
-have been the best decision. One thing in favor of it being a reasonable
-decision is that a conflict in an annexed file will mostly be resolved by
-picking one version of the file or the other, unlike conflicts in source
-code which are often resolved by using brain sweat. Large and often binary
-files not being very possible for human brains to deal with directly. Or
-perhaps by a tool that combines the two versions in some way, in which case
-the conflict resolution leaves both versions easily accessible for such a
-tool.
-
-So git-annex does know, or can make some reasonable assumptions, about
-annexed files, but generalizing those assumptions to small files would not
-make sense.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Lukey"
- avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
- subject="comment 2"
- date="2021-06-24T17:43:36Z"
- content="""
-The idea is to solve the conflicts in a similar way to conflicts in annexed files. I.e. by creating two files file.version-a and file.version-b.
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="resolving merge conflicts"
- date="2021-06-24T18:03:40Z"
- content="""
-\"Small files\" here means \"non-annexed files\", right?
-
-Whether a file is annexed, and whether its merge conflicts should be auto-resolved by creating two files `file.version-a` and `file.version-b`, seem like orthogonal things.
-One might check small binary files directly into git, and one might annex source code files e.g. just for the simplicity of annexing everything (as [[DataLad|projects/datalad]] does or at least used to).
-
-So, maybe, `.gitattributes` should control which files' merge conflicts get auto-resolved?
-
-
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-06-25T16:12:02Z"
- content="""
-I have no interest in continung a feature added for the assistant down a
-road to making source code files that are checked into git be handled in
-some other way when merging.
-"""]]
+++ /dev/null
-It'd be very useful if you could specify a size limit for drop/move/copy/get-type operations. `git annex move --to other --limit 1G` would move at most 1G of data to the other repo for example.
-
-This way you could quickly "garbage collect" a few dozen GiB from your annex repo when you're running out of space without dropping everything for example.
-
-Another issue this could be used to mitigates is that, for some reason, git-annex doesn't auto-stop the transfer when the repos on my external drives are full properly.
-
-I imagine there are many more use-cases where quickly being able to set a limit for the amount of data a command should act on could come in handy.
-
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-06-04T18:07:44Z"
- content="""
-I agree this could be useful.
-
-Implementation is complicated by it needing to only count the size when a
-file is acted on. Eg `git annex get` shouldn't stop when it's seen enough
-files that already have content present.
-
-So it seems it would need to be implemented next to where showStartMessage
-is used in commandAction, looking at the size of the key in the
-StartMessage (or possibly file when there's no key?) and when it would go
-over the limit, rather than proceeding to perform the action it could skip
-doing anything and go on to the next file.
-
-I don't think there is a good way to make it immediately exit
-when it reaches the limit, so if there were subsequent smaller files
-after a skipped file that could be processed still, it still would.
-
-It would probably also make sense to make it later exit with 101 like
---time-limit does, or another special exit code, to indicate it didn't
-process everything.
-
-Hmm, if an action fails, should the size of the file be counted or not?
-If failures are not counted, incomplete transfers could result in a
-lot more work/disk space than desired. But if failures are counted
-after failing to drop a bunch of files, or failing early on to get a bunch
-of files, it could stop seemingly prematurely. Also there's a problem with
-concurrency, if it needs to know the result of running jobs before deciding
-whether to start a new job. Seems no entirely good answer here, but the
-concurrency problem seems only solvable by updating the count at start time.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2021-06-04T20:35:26Z"
- content="""
---size-limit is implemented, for most git-annex commands.
-
-Ones like `git-annex add` that don't operate on annexed files don't support
-it, at least yet.
-
-Ones like git-annex export/import/sync I'm not sure it makes sense to
-support it, since they kind of operate at a higher level than individual
-files.
-"""]]
+++ /dev/null
-When adding a lot of small files to git with `git annex add`,
-it is slow because git runs the smudge filter on all files
-and [[that_is_slow|todo/git_smudge_clean_interface_suboptiomal]].
-
-But `git-annex add --force-small` is much much faster, because that
-bypasses git add entirely, hashing the content and staging it in the index
-from git-annex. So could that same method be used to speed up the slow case?
-
-My concern with doing this is that there may be things that `git add`
-does that are not done when bypassing it. The only one I can think of is,
-if the user has other smudge/clean filters than the git-annex one
-installed, they would not be run either. It could be argued that's a bug
-with the existing `--force-small` too, but at least that's not the default.
-
-Possible alternate approach: Unsetting filter.annex.smudge and
-filter.annex.clean when running `git add`?
-
-> This approach is a winner! [[done]] --[[Joey]]
+++ /dev/null
-reconcileStaged should be able to be sped up by improving streaming through
-git, similar to [[!commit 0f54e5e0ae73b89bb6743bf298915619da00c3f4]].
-
-Normally it's plenty fast enough, but users who often switch between
-branches that have tens to hundreds of thousands of diverged files will
-find it slow, and this should speed it up by somewhere around 3x (excluding
-sqlite writes). --[[Joey]]
-
-> Implemented this. Benchmarked it in a situation where 100,000 annexed
-> files were added to the index (by checking out a branch with more annexed
-> files). old: 50 seconds; new: 41 seconds
-
-> Also benchmarked when 100,000 annexed files were removed from the index.
-> old: 26 seconds; new: 17 seconds.
->
-> Adding associated files to the sqlite db is clearly more expensive than
-> removing from it.
->
-> [[done]] --[[Joey]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="keys db optimization"
- date="2021-06-02T16:53:02Z"
- content="""
-\"users who often switch between branches that have tens to hundreds of thousands of diverged files will find it slow\" -- that's my use case ;) Could one keys-to-files db be kept per branch?
-
-Maybe, the keys db could be split, based e.g. on prefix of md5 of the key, into separate sqlite files, and the writing to them parallelized?
-It's common to be working on a many-core machine.
-
-Is the keys-to-locked-files db used for anything besides detecting keys used by more than one files? For that one purpose there might be faster solutions.
-But, if it's implemented, maybe it also be used to remove the [[limitation|git-annex-preferred-content]] that \"when a command is run with the --all option, or in a bare repository, there is no filename associated with an annexed object, and so \"include=\" and \"exclude=\" will not match\"?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject="matching include/exclude based on file extension in the key"
- date="2021-06-02T17:02:58Z"
- content="""
-Actually, the include/exclude limitation above could be removed by just looking at the keys themselves, if the include/exclude expression is of the form `*.ext` and the keys include file extensions.
-
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2021-06-04T17:45:21Z"
- content="""
-It is not very useful to detect if a key is used by more than one file if
-you don't know the files. In any case, yes, the keys db is used for a large
-number of things, when it comes to unlocked files.
-
-[[todo/numcopies_check_other_files_using_same_key]] has some thoughts on
---all, but I doubt it will make sense to change --all.
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2021-06-04T17:49:43Z"
- content="""
-Keys with extensions do not necessarily have the same extension as used in
-the worktree files that include/exclude match on.
-
-I'm not sure why all these wild ideas are being thrown out there when this
-todo is about a specific, simple improvement that will speed up the git
-part of the scanning by about 3x? It's like you somehow consider this an
-emergency where increasingly wild measures have to be taken to prevent me
-from making a terrible mistake?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="Ilya_Shlyakhter"
- avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
- subject=""why all these wild ideas are being thrown out there""
- date="2021-06-04T22:15:32Z"
- content="""
-It just seemed like all the speedup possibilities from `annex.supportunlocked=false` are getting undone to optimize a not-too-common scenario?
-"""]]
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2021-06-07T15:48:07Z"
- content="""
-annex.supportunlocked=false still prevents the smudge/clean filter from
-being used, which can significantly speed up git if the repository has a
-lot of files stored in git.
-"""]]
+++ /dev/null
-For commands like [[`git-annex-whereis`|git-annex-whereis]] that take a `path` argument, it would help if this could be generalized to taking a [tree-ish](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddeftree-ishatree-ishalsotreeish). E.g. for `git-annex-whereis` this could be used to look up where previous file versions are stored.
-
-> [[done]] before this was filed
+++ /dev/null
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2021-05-12T16:23:02Z"
- content="""
-This is already supported by whereis (and quite a lot of other commands)
-with the --branch option, which is documented to support a treeish.
-"""]]
+++ /dev/null
-Based on an irc conversation earlier today:
-
-19:50 < warp> joeyh: what is the best way to figure out the (remote) filename for a file stored in an rsync remote?
-
-20:43 < joeyh> warp: re your other question, probably the best thing would be to make the whereis command print out locations for each remote, as it always does for the web special remotes
-
-> Several remotes do now populate whereis with urls, but an rsync remote
-> does not in general have http urls to content in it. So I don't think
-> it makes sense to do anything for rsync remotes. [[closeing|done]] --[[Joey]]
projects / git-annex.git / commitdiff