mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' into s3-aws

Browse source 
Conflicts:
	Remote/S3.hs
This commit is contained in:
Joey Hess 2014-10-22 17:14:38 -04:00
commit 35551d0ed0
502 changed files with 7127 additions and 2453 deletions
Download patch file Download diff file Expand all files Collapse all files

287
doc/bugs/Build_error_with_Yesod_1.4.mdwn Normal file
View file

@ -0,0 +1,287 @@
### Please describe the problem.
I have problems building with yesod 1.4
### What steps will reproduce the problem?
Building git annex in a clean sandbox.
### What version of git-annex are you using? On what operating system?
5.20140927 on OS X i.e. Trying to upgrade the homebrew recipe to the most recent version of git-annex
### Please provide any additional information below.
Error messages below are discussed in the following SO-thread:
https://stackoverflow.com/questions/26225991/illegal-view-pattern-frompathpiece-just-dyn-abdd-when-using-parameters-on
[[!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
[310 of 470] Compiling Assistant.WebApp.Types ( Assistant/WebApp/Types.hs, dist/dist-sandbox-52ca649e/build/git-annex/git-annex-tmp/Assistant/WebApp/Types.o )
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aceZO
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aceZW
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf02
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0c
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0e
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0f
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0h
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0j
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0l
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0n
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0p
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0r
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0u
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0w
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0y
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0z
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0C
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0D
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0F
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0H
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0J
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0L
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0M
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0O
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0R
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0T
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf0U
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf11
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf13
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf18
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1a
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1c
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1e
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1g
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1i
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1k
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1m
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1o
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1q
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1s
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1v
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1x
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1z
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1B
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1D
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1G
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1I
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1J
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1L
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1M
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1O
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1R
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1U
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1X
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf1Y
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf20
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf22
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf25
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf27
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf28
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf2b
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf2d
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf2f
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf2h
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_acf2j
Use ViewPatterns to enable view patterns
cabal: Error: some packages failed to install:
git-annex-5.20140927
# End of transcript or log.
"""]]
> You're not building the most recent version of git-annex; this was
> already fixed in version 5.20141013. [[done]] --[[Joey]]

8
doc/bugs/Build_error_with_Yesod_1.4/comment_1_42fe9d62c9dcc55deea35d16b67177e6._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
nickname="Carl"
subject="Not on hackage"
date="2014-10-15T15:34:02Z"
content="""
I stand corrected, but it seems this release is not on hackage?
"""]]

8
doc/bugs/Build_error_with_Yesod_1.4/comment_2_05f6fb19f2527f6dd72ab0e2f87c021a._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.111"
subject="comment 2"
date="2014-10-15T17:30:45Z"
content="""
Hmm, yeah, it seems the upload to hackage failed, because hackage still rejects cabal files mentioning the legal os(gnu). Sigh. Fixed now.
"""]]

17
doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="JerSou"
ip="82.228.88.32"
subject="comment 10"
date="2014-09-25T19:27:43Z"
content="""
I thought a workaround (but I don't think ultimately use) :
> \# for each git repo :
> mv .git .gitToAnnex
> ln -s .gitToAnnex .git
> echo .gitToAnnex >> .gitignore
"""]]

33
doc/bugs/Drop_files_with_the_same_checksum..mdwn Normal file
View file

@ -0,0 +1,33 @@
### Please describe the problem.
When two identical files are annexed and one of them is dropped, both files are gone (one dangling symlink is left). This may be intentional (the checksums are the same after all), but then is there a way to drop one of the files?
### What steps will reproduce the problem?
mkdir annex
cd annex
git init
git annex init
mkdir a b
dd if=/dev/urandom of=a/data.bin count=2048
cp a/data.bin b
git annex add a/data.bin b/data.bin
git commit -m "Added raw data."
git annex drop --force a/data.bin
file b/data.bin
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140831+b1
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
Distributor ID: Debian
Description: Debian GNU/Linux testing (jessie)
Release: testing
Codename: jessie
> If you don't want git-annex to de-duplicate files you can use a backend
> such as WORM. Here it's behaving as expected, so [[done]]. --[[Joey]]

9
doc/bugs/Issue_fewer_S3_GET_requests.mdwn Normal file
View file

@ -0,0 +1,9 @@
It appears that git-annex issues one GET request to S3 / Google cloud for every file it tries to copy, if you don't pass --fast. (I could be wrong; I'm basing this on the fact that each "checking <remote name>" takes about the same amount of time, and that it's slow enough to be hitting the network.)
Amazon lets you GET 1000 objects in one GET request, and afaict a request that returns 1000 objects costs just as much as a request that returns 1 object. The cost of GET'ing every file in my annex is nontrivial -- Google charges 0.01 per 1000 GETs, and my repo has 130k objects, so that's $1.3, compared to a monthly cost for storage of under $10. This means that if I want to back up my files more than, say, once a week, I need to write a script that parses the JSON output of git annex whereis and uploads with --fast only the files that aren't present in the cloud. It also means that I have to trust the output of whereis.
All those GETs also slow down the non-fast copy, and this also applies to other kinds of remotes.
There are a number of ways one could implement this. One way would be to have a command that updates the whereis data from the remote and then to add a parameter (maybe you already have it) to copy that's like --fast but skips files that are already present (maybe this is what --fast already does, but I did a quick check and it doesn't seem to). Because of the way git annex names files, I think it would be hard to coalesce GETs during a copy command, but it could be done.
Anyway, please don't consider this a high-priority request; I can get by as-is, and I <3 git annex.

24
doc/bugs/Req:_Upgrade_to_Yesod_1.4__63___https:__47____47__github.com__47__NixOS__47__nixpkgs__47__pull__47__4391.mdwn Normal file
View file

@ -0,0 +1,24 @@
### Please describe the problem.
Not a super big "problem" but I'm blocked upgrading Nix packages to Yesod 1.4 because of git-annex breakage.
### What steps will reproduce the problem?
Try to build with Yesod 1.4
### What version of git-annex are you using? On what operating system?
Latest
### 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.
"""]]
> [[fixed|done]], although I have not made a release yet.
> It's a 1 line change anyhow, just adding ViewPatterns. --[[Joey]]

21
doc/bugs/S3_upload_not_using_multipart/comment_7_f620888512cd78628f82ec9e5eed4ad1._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
nickname="Richard"
subject="comment 7"
date="2014-09-29T08:07:55Z"
content="""
As I found the latest comment confusing, here's the full quote:
Depending on the size of the data you are uploading, Amazon S3 offers the following options:
Upload objects in a single operation—With a single PUT operation you can upload objects up to 5 GB in size.
Upload objects in parts—Using the Multipart upload API you can upload large objects, up to 5 TB.
The Multipart Upload API is designed to improve the upload experience for larger objects. You can upload objects in parts.
These object parts can be uploaded independently, in any order, and in parallel.
You can use a Multipart Upload for objects from 5 MB to 5 TB in size.
We encourage Amazon S3 customers to use Multipart Upload for objects greater than 100 MB.
"""]]

8
doc/bugs/S3_upload_not_using_multipart/comment_8_4d9242cde0d2348452438659a8aa8d6d._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
nickname="Richard"
subject="comment 8"
date="2014-09-29T08:09:33Z"
content="""
PS: Chunking spams the S3 remote with individual objects whereas multipart uploads do not. Just something to keep in mind in case you turn on chunking for S3.
"""]]

2
doc/bugs/Upload_to_S3_fails_.mdwn
View file

@ -55,3 +55,5 @@ If I fire up the web app and open the log, the end looks like this:
3% 858.1KB/s 6h45mmux_client_request_session: read from master failed: Broken pipe
"""]]
[[!tag moreinfo]]

8
doc/bugs/Upload_to_S3_fails_/comment_10_b7e912bac673bdffa5775b71d5d39937._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
nickname="Thedward"
subject="comment 10"
date="2014-10-21T21:25:57Z"
content="""
The only files that succeeded were small text files. The other files — 3-200MiB — all failed.
"""]]

10
doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 1"
date="2014-09-18T18:49:43Z"
content="""
This is using the old hS3 library. So, each chunk is sent using a new http connection. It seems that the connection must be being closed by S3 part way through the upload of a chunk.
It may be that the new aws library somehow avoids this problem. So, a git-annex built with the `s3-aws` branch merged in may help with this bug. OTOH, that new branch makes a single http connection be reused for all the chunks in a file, so it might also make things worse.
"""]]

10
doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 2"
date="2014-09-18T18:52:17Z"
content="""
If you're using the new chunking system, git-annex should support resuming the upload to S3. Next time you try to send the file, it should find the chunks that were successfully sent, and resume at the chunk where it failed.
Supporting this even for encrypted uploads was a major benefit of the new chunking system, so I hope it works...?
"""]]

8
doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="annexuser"
ip="71.198.212.13"
subject="comment 3"
date="2014-09-19T04:43:42Z"
content="""
Was the version I listed above not using the new chunking from the `s3-aws` branch? How do I determine if my version of git-annex was built with the new or old chunking?
"""]]

8
doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="67.223.1.203"
subject="comment 4"
date="2014-09-19T18:33:17Z"
content="""
Your version supports both new and old style chunking. Which is used depends on how the S3 remote was configured when it was set up. It can't really be changed w/o re-setting up the remote. You can check which is used by `git show git-annex:remote.log`, find the line for the UUID of the remote, and see if it has chunk= (new chunking) or chunksize= (old chunking).
"""]]

43
doc/bugs/Upload_to_S3_fails_/comment_5_020c055f6c06860dda27c1debb123742._comment Normal file
View file

@ -0,0 +1,43 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
nickname="Thedward"
subject="comment 5"
date="2014-10-21T04:10:16Z"
content="""
I am experiencing similar behavior on Ubuntu Trusty (x86_64) using a prebuilt Linux release:
Linux hostname 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
git-annex version: 5.20141016-g26b38fd
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
Copying files to S3 consistently fails both from the command line and via the assistant:
[2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
[2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
[2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..78e9b6b85f3b453d8ed4f66f63ff09e03ce13d06\",\"-n1\",\"--pretty=%H\"]
[2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..658720ba59a2fefee89c908b972971ca901f84dc\",\"-n1\",\"--pretty=%H\"]
[2014-10-20 22:34:32 CDT] chat: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
[2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"storage/data.bin\"]
[2014-10-20 22:34:32 CDT] chat: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
copy storage/data.bin (gpg) (checking S3git-annex...) (to S3git-annex...)
0% 0.0 B/s 0s[2014-10-20 22:34:33 CDT] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"14\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"]
8% 512.0KB/s 21s[2014-10-20 22:34:35 CDT] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"14\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"]
8% 528.0KB/s 21s
ErrorClosed
failed
git-annex: copy: 1 failed
Two files (out of several hundred) have succeeded.
Any ideas?
"""]]

10
doc/bugs/Upload_to_S3_fails_/comment_6_8bc023fca8cedfc517856cdcd20b7f10._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.96"
subject="comment 6"
date="2014-10-21T16:31:02Z"
content="""
I need to know if the S3 remote is configured to use the new style chunking feature, and what size chunks it is configured to use. I have already explained how to check that in this thread.
I also need to know if retrying the upload after it fails lets it resume where it left off.
"""]]

10
doc/bugs/Upload_to_S3_fails_/comment_7_32685258748a7cdd177e7af2105f128e._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
nickname="Thedward"
subject="comment 7"
date="2014-10-21T17:35:16Z"
content="""
It is running the new style chunking (chunk=1MiB).
It does not appear to resume when it tries again. If I try copying a file to the remote from the command line, it always starts at 0% and dies at some point before 100% even if it has tried to copy that file before.
"""]]

8
doc/bugs/Upload_to_S3_fails_/comment_8_841fd94d0f599c71a76fd22b07944366._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
nickname="Thedward"
subject="comment 8"
date="2014-10-21T17:47:35Z"
content="""
Additional info: I created both of the related git-annex repositories yesterday via the webapp. Then imported a number of files to each one. Then connected them via xmpp. Then created the S3 remote via the webapp so they could actually share files. I am using an IAM identity for S3 instead of my root access key; it has full S3 access (and data IS showing up in the bucket, so it's not a *simple* permissions problem).
"""]]

8
doc/bugs/Upload_to_S3_fails_/comment_9_dd837a1cb2146224b9c000cbeea4f3b3._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.96"
subject="comment 9"
date="2014-10-21T20:22:52Z"
content="""
How big is the file that it fails to copy?
"""]]

36
doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn Normal file
View file

@ -0,0 +1,36 @@
### Please describe the problem.
"git-annex enableremote box.com" fails with "git-annex: WebDAV test failed". The server returns error message "The resource you tried to create already exists" (see below).
### What steps will reproduce the problem?
1. I initialize box.com special remote in desktop. The path at box.com is at "gas/annex".
2. I enable the box.com special remote in laptop. I got the error I described above.
### What version of git-annex are you using? On what operating system?
$ git annex version
git-annex version: 5.20140831-g62e6ad8
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
$ uname -a
Linux tkf-acer 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 GNU/Linux
### Please provide any additional information below.
I ran the following while with appropriate environment variable WEBDAV_USERNAM and WEBDAV_PASSWORD.
me@desktop$ git-annex initremote box type=webdav url=https://dav.box.com/dav/gas/annex chunk=50mb encryption=shared
me@laptop$ git-annex enableremote box.com
enableremote box.com (testing WebDAV server...)
git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 405, statusMessage = "Method Not Allowed"}) [("Server","nginx"),("Date","Sat, 27 Sep 2014 09:36:42 GMT"),("Content-Type","application/xml; charset=utf-8"),("Content-Length","247"),("Connection","keep-alive"),("Vary","Host"),("Allow","OPTIONS, GET, HEAD, DELETE, PROPFIND, PUT, PROPPATCH, COPY, MOVE, REPORT, LOCK, UNLOCK"),("X-Response-Body-Start","<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n <s:exception>Sabre_DAV_Exception_MethodNotAllowed</s:exception>\n <s:message>The resource you tried to create already exists</s:message>\n</d:error>\n")] (CJ {expose = []}): user error
failed
git-annex: enableremote: 1 failed
> You are using an old version of git-annex; this bug was fixed in
> version 5.20140919. [[done]] --[[Joey]]

8
doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists/comment_1_ac40ddc26bff27dafdbc457837695a92._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk0GR7KgDF6PAzHTkLZCCkjAvJVB7ceXTY"
nickname="Takafumi"
subject="comment 1"
date="2014-09-27T19:46:08Z"
content="""
I updated git-annex and it works. Thank you very much.
"""]]

2
doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
View file

@ -42,3 +42,5 @@ WebApp crashed: getAddrInfo: does not exist (Name or service not known)
# End of transcript or log.
"""]]
> [[done]] --[[Joey]]

10
doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_11_7776659e257a97c9a3855c8ad008207a._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 11"
date="2014-10-02T16:09:37Z"
content="""
It seems to me that the problem must be with .git/annex/index.
I would be interested in looking at this git repository, if there's a way to get a copy (no .git/annex/objects needed).
"""]]

27
doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn Normal file
View file

@ -0,0 +1,27 @@
### Please describe the problem.
annex get does not work from read-only file systems...
### What steps will reproduce the problem?
$ git annex get --from=...
error: could not lock config file /.../Annex/.git/config: Read-only file system
get ... (from ...) error: could not lock config file .../Annex/.git/config: Read-only file system
git [Param "config",Param "annex.version",Param "5"] failed
failed
### What version of git-annex are you using? On what operating system?
annex.version = 3 in the remote
$ git annex version
git-annex version: 5.20140927
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 0 1 2 4
[[!tag confirmed]]
[[!meta title="read-only filesystem on remote prevents auto-upgrade from v3 to v5, and prevents using a remote"]]

10
doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 1"
date="2014-10-06T15:11:18Z"
content="""
There might be a general problem with using git-annex against a read-only filesystem, but the specific case here is a read-only filesystem containing a repository in an old format which git-annex needs to upgrade to the current format to use. So it's pretty reasonable that the (automatic) upgrade fails, since it's not being allowed to write to the repository to upgrade it.
Now, if that repository is a indirect mode repo, there is really no change between version 3 and version 5, so it might do to let git-annex ignore the failure to write out the config, and treat that repo as if it's a v5 repo. It seems easier in most cases to mount the media read-write for git-annex to do the upgrade though.
"""]]

8
doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://id.koumbit.net/anarcat"
ip="72.0.72.144"
subject="comment 2"
date="2014-10-06T15:18:20Z"
content="""
i've seen problems like this not related to upgrades at all, in [[todo/read-only removable drives]]. furthermore, it seems to me that failure to upgrade a repository shouldn't be fatal and we should be able to recover and get files anyways, in the spirit of [[backwards compatibility|future_proofing]]. --[[anarcat]]
"""]]

10
doc/bugs/annex_get_fails_from_read-only_filesystem/comment_3_c505a9df0ef63bb7cac28af9502a953d._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 3"
date="2014-10-06T15:59:10Z"
content="""
From a code complication POV, it's useful for git-annex to only support one version of repository at a time.
As far as backwards compatablity goes, I don't anticipate ever removing the upgrade code from git-annex. It still supports upgrading v0 repos which probably only I ever used!
"""]]

10
doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 1"
date="2014-09-18T19:28:56Z"
content="""
Ok, I managed to reproduce this. In my case, there was no \"Bad creds\" message because the broken creds data it used happened to contain a newline, but same problem; the creds stored by the webapp are not used properly when re-enabling the box.com remote elsewhere. Same problem would affect other special remotes using embedded creds and shared encryption.
Seems to be a bug introduced in [[!commit fbdeeeed5fa276d94be587c8916d725eddcaf546]]. Despite what the commit says, the embedded creds did get encrypted with the shared gpg key. I have reverted that commit to fix this problem.
"""]]

216
doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn Normal file
View file

@ -0,0 +1,216 @@
### Please describe the problem.
Can't install git-annex from current git master. cabal install also fails. Both fail with the same error.
### What steps will reproduce the problem?
cabal install git-annex --bindir=$HOME/bin
### What version of git-annex are you using? On what operating system?
[[!format sh """
$ uname -a
Linux arch 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux
$ cabal --version
cabal-install version 1.20.0.3
using version 1.20.0.0 of the Cabal library
"""]]
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
$ cabal install git-annex --bindir=$HOME/bin
Resolving dependencies...
Configuring DAV-1.0.2...
Configuring gnuidn-0.2.1...
Configuring gsasl-0.3.5...
Configuring hS3-0.5.8...
Failed to install gsasl-0.3.5
Build log ( /home/dirk/.cabal/logs/gsasl-0.3.5.log ):
Configuring gsasl-0.3.5...
setup-Simple-Cabal-1.18.1.3-x86_64-linux-ghc-7.8.3: The pkg-config package
libgsasl version >=1.1 is required but it could not be found.
Failed to install gnuidn-0.2.1
Build log ( /home/dirk/.cabal/logs/gnuidn-0.2.1.log ):
Configuring gnuidn-0.2.1...
setup-Simple-Cabal-1.18.1.3-x86_64-linux-ghc-7.8.3: The program c2hs is
required but it could not be found.
Building hS3-0.5.8...
Building DAV-1.0.2...
Failed to install hS3-0.5.8
Build log ( /home/dirk/.cabal/logs/hS3-0.5.8.log ):
Configuring hS3-0.5.8...
Building hS3-0.5.8...
Preprocessing library hS3-0.5.8...
Network/AWS/S3Object.hs:26:8:
Could not find module ‘Network.URI’
It is a member of the hidden package ‘network-uri-2.6.0.1’.
Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
Failed to install DAV-1.0.2
Build log ( /home/dirk/.cabal/logs/DAV-1.0.2.log ):
Configuring DAV-1.0.2...
Building DAV-1.0.2...
Preprocessing library DAV-1.0.2...
[1 of 2] Compiling Network.Protocol.HTTP.DAV.TH ( Network/Protocol/HTTP/DAV/TH.hs, dist/build/Network/Protocol/HTTP/DAV/TH.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.3.1 ... linking ... done.
Loading package text-1.2.0.0 ... linking ... done.
Loading package parsec-3.1.6 ... linking ... done.
Loading package hashable-1.2.2.0 ... linking ... done.
Loading package scientific-0.3.3.1 ... linking ... done.
Loading package attoparsec-0.12.1.2 ... linking ... done.
Loading package dlist-0.7.1 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package syb-0.4.2 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package unordered-containers-0.2.5.0 ... linking ... done.
Loading package primitive-0.5.3.0 ... linking ... done.
Loading package vector-0.10.11.0 ... linking ... done.
Loading package aeson-0.8.0.0 ... linking ... done.
Loading package blaze-builder-0.3.3.4 ... linking ... done.
Loading package blaze-markup-0.6.1.1 ... linking ... done.
Loading package blaze-html-0.7.0.3 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package unix-2.7.0.1 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package exceptions-0.6.1 ... linking ... done.
Loading package process-1.2.0.0 ... linking ... done.
Loading package system-filepath-0.4.12 ... linking ... done.
Loading package system-fileio-0.3.14 ... linking ... done.
Loading package shakespeare-2.0.1.1 ... linking ... done.
Loading package stm-2.4.3 ... linking ... done.
Loading package transformers-base-0.4.3 ... linking ... done.
Loading package monad-control-0.3.3.0 ... linking ... done.
Loading package lifted-base-0.2.3.0 ... linking ... done.
Loading package mmorph-1.0.4 ... linking ... done.
Loading package resourcet-1.1.2.3 ... linking ... done.
Loading package nats-0.2 ... linking ... done.
Loading package semigroups-0.15.3 ... linking ... done.
Loading package void-0.6.1 ... linking ... done.
Loading package conduit-1.2.0.2 ... linking ... done.
Loading package attoparsec-conduit-1.1.0 ... linking ... done.
Loading package blaze-builder-conduit-1.1.0 ... linking ... done.
Loading package network-2.6.0.2 ... linking ... done.
Loading package random-1.1 ... linking ... done.
Loading package zlib-0.5.4.1 ... linking ... done.
Loading package streaming-commons-0.1.5 ... linking ... done.
Loading package conduit-extra-1.1.3.4 ... linking ... done.
Loading package data-default-class-0.0.1 ... linking ... done.
Loading package data-default-instances-base-0.0.1 ... linking ... done.
Loading package data-default-instances-containers-0.0.1 ... linking ... done.
Loading package data-default-instances-dlist-0.0.1 ... linking ... done.
Loading package data-default-instances-old-locale-0.0.1 ... linking ... done.
Loading package data-default-0.5.3 ... linking ... done.
Loading package xml-types-0.3.4 ... linking ... done.
Loading package xml-conduit-1.2.2 ... linking ... done.
Loading package xml-hamlet-0.4.0.9 ... linking ... done.
Loading package transformers-compat-0.3.3.4 ... linking ... done.
Loading package contravariant-1.2 ... linking ... done.
Loading package tagged-0.7.2 ... linking ... done.
Loading package distributive-0.4.4 ... linking ... done.
Loading package comonad-4.2.2 ... linking ... done.
Loading package semigroupoids-4.2 ... linking ... done.
Loading package bifunctors-4.1.1.1 ... linking ... done.
Loading package prelude-extras-0.4 ... linking ... done.
Loading package profunctors-4.2.0.1 ... linking ... done.
Loading package free-4.9 ... linking ... done.
Loading package parallel-3.2.0.4 ... linking ... done.
Loading package reflection-1.5.1 ... linking ... done.
Loading package split-0.2.2 ... linking ... done.
Loading package lens-4.4.0.2 ... linking ... done.
Loading package byteable-0.1.1 ... linking ... done.
Loading package securemem-0.1.3 ... linking ... done.
Loading package crypto-cipher-types-0.0.9 ... linking ... done.
Loading package cipher-aes-0.2.8 ... linking ... done.
Loading package crypto-random-0.0.8 ... linking ... done.
Loading package cprng-aes-0.5.2 ... linking ... done.
Loading package cereal-0.4.0.1 ... linking ... done.
Loading package socks-0.5.4 ... linking ... done.
Loading package asn1-types-0.2.3 ... linking ... done.
Loading package asn1-encoding-0.8.1.3 ... linking ... done.
Loading package cipher-des-0.0.6 ... linking ... done.
Loading package cipher-rc4-0.1.4 ... linking ... done.
Loading package crypto-numbers-0.2.3 ... linking ... done.
Loading package crypto-pubkey-types-0.4.2.2 ... linking ... done.
Loading package cryptohash-0.11.6 ... linking ... done.
Loading package crypto-pubkey-0.2.4 ... linking ... done.
Loading package asn1-parse-0.8.1 ... linking ... done.
Loading package base64-bytestring-1.0.0.1 ... linking ... done.
Loading package pem-0.2.2 ... linking ... done.
Loading package x509-1.4.12 ... linking ... done.
Loading package x509-store-1.4.4 ... linking ... done.
Loading package x509-validation-1.5.0 ... linking ... done.
Loading package tls-1.2.9 ... linking ... done.
Loading package x509-system-1.4.5 ... linking ... done.
Loading package connection-0.2.3 ... linking ... done.
Loading package case-insensitive-1.2.0.1 ... linking ... done.
Loading package cookie-0.4.1.3 ... linking ... done.
Loading package http-types-0.8.5 ... linking ... done.
Loading package mime-types-0.1.0.4 ... linking ... done.
Loading package network-uri-2.6.0.1 ... linking ... done.
Loading package utf8-string-0.3.8 ... linking ... done.
Loading package publicsuffixlist-0.1 ... linking ... done.
Loading package http-client-0.4.0 ... linking ... done.
Loading package http-client-tls-0.2.2 ... linking ... done.
Loading package MonadRandom-0.3 ... linking ... done.
Loading package either-4.3.1 ... linking ... done.
Loading package safe-0.3.8 ... linking ... done.
Loading package errors-1.4.7 ... linking ... done.
[2 of 2] Compiling Network.Protocol.HTTP.DAV ( Network/Protocol/HTTP/DAV.hs, dist/build/Network/Protocol/HTTP/DAV.o )
Network/Protocol/HTTP/DAV.hs:80:1: Warning:
The import of ‘unauthorized401’
from module ‘Network.HTTP.Types’ is redundant
Network/Protocol/HTTP/DAV.hs:92:95: Warning:
‘DAVT’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.
Network/Protocol/HTTP/DAV.hs:213:1: Warning:
Defined but not used: ‘supportsCalDAV’
Network/Protocol/HTTP/DAV.hs:88:10: Warning:
Orphan instance: instance Default DAVContext
Network/Protocol/HTTP/DAV.hs:95:10: Warning:
Orphan instance: instance MonadMask m => MonadMask (EitherT e m)
In-place registering DAV-1.0.2...
Preprocessing executable 'hdav' for DAV-1.0.2...
hdav.hs:33:8:
Could not find module ‘Network.URI’
It is a member of the hidden package ‘network-uri-2.6.0.1’.
Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
DAV-1.0.2 failed during the building phase. The exception was:
ExitFailure 1
git-annex-5.20140919 depends on DAV-1.0.2 which failed to install.
gnuidn-0.2.1 failed during the configure step. The exception was:
ExitFailure 1
gsasl-0.3.5 failed during the configure step. The exception was:
ExitFailure 1
hS3-0.5.8 failed during the building phase. The exception was:
ExitFailure 1
network-protocol-xmpp-0.4.6 depends on gnuidn-0.2.1 which failed to install.
# End of transcript or log.
"""]]
> This is a bug in hS3, not in git-annex. hS3 needs to be updated
> per the example at <http://hackage.haskell.org/package/network>.
> Email sent to hS3 author; [[done]]. --[[Joey]]

98
doc/bugs/cannot_add_local_readonly_repo_through_the_webapp.mdwn Normal file
View file

@ -0,0 +1,98 @@
### Please describe the problem.
A readonly repository that I can add fine on the commandline (and sync content from) cannot be added through the webapp.
### What steps will reproduce the problem?
Say I have a readonly (owned by root) repository in `~/test/a` and I create a `~/test/b` (owned by my user). In the webapp, when to add `/home/anarcat/test/a` as a "local repository" (`Add another local repository`) to the `~/test/b` repo, it fails when i enter that path, with "Cannot write a repository there." I obviously can't sync content from there then.
This works on the commandline, although with warnings.
### What version of git-annex are you using? On what operating system?
Version: 5.20140927
Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
Debian Jessie.
### Please provide any additional information below.
Here's the transcript of the commandline equivalent:
~~~
anarcat@marcos:test$ git init a
Dépôt Git vide initialisé dans /home/anarcat/test/a/.git/
anarcat@marcos:test$ git init b
Dépôt Git vide initialisé dans /home/anarcat/test/b/.git/
anarcat@marcos:test$ cd a
anarcat@marcos:a$ git annex init
init ok
(Recording state in git...)
anarcat@marcos:a$ echo hellow world > README
anarcat@marcos:a$ git annex add README
add README ok
(Recording state in git...)
anarcat@marcos:a$ git commit -m"test repo a"
[master (commit racine) 3ece2a1] test repo a
1 file changed, 1 insertion(+)
create mode 120000 README
anarcat@marcos:a$ cd ../ ^C
anarcat@marcos:a$ sudo chown -R root .
[sudo] password for anarcat:
Sorry, try again.
[sudo] password for anarcat:
anarcat@marcos:a$ cd ../b
anarcat@marcos:b$ git annex init
init ok
(Recording state in git...)
anarcat@marcos:b$ git remote add a ../a
anarcat@marcos:b$ git annex sync a
commit ok
pull a
warning: no common commits
remote: Décompte des objets: 13, fait.
remote: Compression des objets: 100% (9/9), fait.
remote: Total 13 (delta 1), reused 0 (delta 0)
Dépaquetage des objets: 100% (13/13), fait.
Depuis ../a
* [nouvelle branche] git-annex -> a/git-annex
* [nouvelle branche] master -> a/master
merge: refs/remotes/a/synced/master - not something we can merge
failed
(merging a/git-annex into git-annex...)
(Recording state in git...)
push a
Décompte des objets: 8, fait.
Delta compression using up to 2 threads.
Compression des objets: 100% (6/6), fait.
Écriture des objets: 100% (8/8), 819 bytes | 0 bytes/s, fait.
Total 8 (delta 1), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database objects
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ../a
! [remote rejected] git-annex -> synced/git-annex (unpacker error)
! [remote rejected] master -> synced/master (unpacker error)
error: impossible de pousser des références vers '../a'
Pushing to a failed.
(non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
failed
git-annex: sync: 2 failed
anarcat@marcos:b$ ls
README
anarcat@marcos:b$ git annex copy --from a
copy README (from a...) ok
(Recording state in git...)
anarcat@marcos:b$ ls -al
total 16K
drwxr-xr-x 3 anarcat anarcat 4096 oct. 20 15:36 .
drwxr-xr-x 4 anarcat anarcat 4096 oct. 20 15:35 ..
drwxr-xr-x 9 anarcat anarcat 4096 oct. 20 15:36 .git
lrwxrwxrwx 1 anarcat anarcat 180 oct. 20 15:36 README -> .git/annex/objects/wz/Zq/SHA256E-s13--8c083c6897455257dfbace7a9012d92ca8ebfb6e6ebe8acddc6dfa8fc81226ed/SHA256E-s13--8c083c6897455257dfbace7a9012d92ca8ebfb6e6ebe8acddc6dfa8fc81226ed
~~~
This is part of the [[todo/read-only_removable_drives/]] series. --[[anarcat]]

96
doc/bugs/fatal:_Cannot_handle_files_this_big.mdwn Normal file
View file

@ -0,0 +1,96 @@
### Please describe the problem.
Syncing a 20GB video file causes this error. I have no problems with 8GB files.
### What steps will reproduce the problem?
See additional info
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140920-gb0c4300
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 2 3 4
git version 1.9.4.msysgit.2
Windows 7 64bit
### Please provide any additional information below.
[[!format sh """
Z:\>git clone L:\repositories\bigFilesTest.git-annex
Cloning into 'bigFilesTest.git-annex'...
done.
Z:\>cd bigFilesTest.git-annex
Z:\bigFilesTest.git-annex>git annex init "cloned"
init cloned
Detected a filesystem without fifo support.
Disabling ssh connection caching.
Detected a crippled filesystem.
Enabling direct mode.
ok
(Recording state in git...)
Z:\bigFilesTest.git-annex>git annex add test20GBVideo.mkv
add test20GBVideo.mkv ok
(Recording state in git...)
Z:\bigFilesTest.git-annex>git annex sync --debug
[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","git-annex"]
[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--hash","refs/heads/git-annex"]
[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..54de336a3423f7f8f72f897effd29f952534c24e","-n1","--pretty=%H"]
[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..53cfcf38b40247b3992b6007336b2c915a945ad4","-n1","--pretty=%H"]
[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] chat: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","cat-file","--batch"]
[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["config","--null","--list"]
commit [2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","ls-files","--stage","-z","--others","--exclude-standard","--","Z:\\bigFilesTest.git-annex"]
[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] chat: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","cat-file","--batch"]
(Recording state in git...)
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","add","-f","test20GBVideo.mkv"]
fatal: Cannot handle files this big
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--head"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","diff-index","-z","--raw","--no-renames","-l0","--cached","HEAD"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","symbolic-ref","HEAD"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--hash","refs/heads/annex/direct/master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","write-tree"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","rev-parse","b12e8477242df97be13c1395db143f860ce8e895:"]
ok
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","symbolic-ref","HEAD"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","refs/heads/annex/direct/master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/heads/synced/master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/annex/direct/master..refs/heads/synced/master","-n1","--pretty=%H"]
pull origin
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","fetch","origin"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/annex/direct/master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/synced/master..refs/remotes/origin/synced/master","-n1","--pretty=%H"]
ok
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","git-annex"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--hash","refs/heads/git-annex"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..54de336a3423f7f8f72f897effd29f952534c24e","-n1","--pretty=%H"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..53cfcf38b40247b3992b6007336b2c915a945ad4","-n1","--pretty=%H"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","branch","-f","synced/master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","branch","-f","master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/remotes/origin/synced/master..refs/heads/synced/master","-n1","--pretty=%H"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/git-annex"]
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/remotes/origin/git-annex..git-annex","-n1","--pretty=%H"]
push origin
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","push","origin","+git-annex:synced/git-annex","annex/direct/master:synced/master"]
Everything up-to-date
[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","push","origin","master"]
ok
"""]]

72
doc/bugs/get_from_glacier_fails_too_early.mdwn Normal file
View file

@ -0,0 +1,72 @@
### Please describe the problem.
In order to test the integrity of my file backup on glacier,
I initiated get of a single file from glacier via:
$ git annex get --from=glacier localdir/myfile.jpg
A check with
$ glacier job list
confirmed, that a job was in progress.
Then after a couple hours wait the job is complete
[[!format sh """
[ben@voyagerS9 annex]$ glacier job list
i/d 2014-10-16T20:25:23.068Z glacier-bbbbbbbb-bbbb-bbbb-bbbb-MYVAULTbbbbb
a/d 2014-10-16T20:30:13.086Z glacier-bbbbbbbb-bbbb-bbbb-bbbb-MYVAULTbbbbb GPGHMACSHA1--cccccccccccc
"""]]
So, again I enter the get command:
[[!format sh """
[ben@voyagerS9 annex]$ git annex get --from=glacier localdir/myfile.jpg
get localdir/myfile.jpg (from glacier...) (gpg)
failed
git-annex: get: 1 failed
[ben@voyagerS9 annex]$
"""]]
The command immediately fails after entering the gpg passphrase, releasing the shell.
But in the background the glacier-cli is still running, downloads the file from Amazon
and then dumps the gpg encrypted file content into the terminal.
(4 MB of binary character garbage on the screen)
git annex should not fail so early and wait until the data is coming in order to pipe it into gpg.
### What version of git-annex are you using? On what operating system?
Arch Linux git-annex-bin package.
[[!format sh """
[ben@voyagerS9 annex]$ git annex version
git-annex version: 5.20140920-gb0c4300
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 0 1 2 4
[ben@voyagerS9 annex]$ gpg --version
gpg (GnuPG) 2.0.26
libgcrypt 1.6.2
"""]]
### Possibly related information about the annexed repo and its history
The file was uploaded sometime earlier this year with a different version of git annex: Older source package for Arch Linux with Haskell packages from the Arch haskell repos.
The special glacier remote was initially set up with an old gpg key (hybrid encryption), which is still in my keychain but has expired. I exchanged the key with a new one by
$ git annex enableremote glacier keyid+=NEWKEY keyid-=OLDKEY
I don't know why, but my AWS credentials seem no longer be embedded into the git repo. glacier upload (copy --to=) only succeeds with explicitly set AWS credential environment variables
I tried
$ git annex enableremote embedcreds=yes
with no noticeable change.
I had changed the AWS credentials a while ago.
Tomorrow I will try to download a just recently uploaded file with the current credentials and keys.
> [[done]]; I am not confident that I understand this failure on retrival,
> and that I've fixed it. --[[Joey]]

14
doc/bugs/get_from_glacier_fails_too_early/comment_1_5a4e37fef629e07dce6b83ae311d1b03._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2014-10-20T18:54:43Z"
content="""
Wow, the code seems to neglect to actually set up a pipe from glacier-cli's
stdout. It seems this broke quite a while ago, in
[[!commit fb19d56476bb6eb5aa4d794a10199adb267d5870]] and nobody noticed.
I have committed what should be a fix, but it's pretty hard for me to test
this. Can you please either test the current daily autobuild for linux
amd64 (should be ready about 15 minutes after I post this comment), or
build git-annex from master and test?
"""]]

9
doc/bugs/get_from_glacier_fails_too_early/comment_2_da065d367d0a3c91e4957f588f36dc67._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="joey"
subject="""creds"""
date="2014-10-20T19:09:28Z"
content="""
Since you are using gpg encryption, your repository may have
[[upgrades/insecure_embedded_creds]]. Strongly suggest you check if it
does.
"""]]

11
doc/bugs/get_from_glacier_fails_too_early/comment_3_1b49cd66a612bb46da5b73c83ab14688._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkck-Tokgfh_1Fwh6pkl69xPA_dYUgA4Tg"
nickname="Benjamin"
subject="autobuild"
date="2014-10-20T22:39:25Z"
content="""
Okay, where do I get the newest build? I cannot find a link to a packaged file at http://downloads.kitenet.net/git-annex/autobuild/amd64/
I'd rather not build it from master myself, as all the Haskell dependencies are not well supported on Arch linux. Thats why I switched from the git-annex package to the git-annex-bin package in AUR in the first place.
"""]]

7
doc/bugs/get_from_glacier_fails_too_early/comment_4_a20b46a5e9c1c72a484962f3539d3b3e._comment Normal file
View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2014-10-21T16:31:33Z"
content="""
http://git-annex.branchable.com/install/Linux_standalone/
"""]]

8
doc/bugs/get_from_glacier_fails_too_early/comment_5_488bb44796e6a4e16f7bfc1f229233e7._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.96"
subject="comment 5"
date="2014-10-21T19:59:06Z"
content="""
Recent autobuilds will also print out some useful info when you run `git annex info glacier`, including where it's getting the AWS credentials from.
"""]]

48
doc/bugs/get_from_glacier_fails_too_early/comment_6_9c8f262b3d8b37f2e68108337acbd303._comment Normal file
View file

@ -0,0 +1,48 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkck-Tokgfh_1Fwh6pkl69xPA_dYUgA4Tg"
nickname="Benjamin"
subject="autobuild test"
date="2014-10-21T22:09:47Z"
content="""
Okay I managed to package the autobuild for my Arch system and installed. Here is what I get, retrieving finished glacier retrieval jobs which was started yesterday:
Without AWS credentials as environment variables, the call fails:
[[!format sh \"\"\"
[ben@voyagerS9 annextest]$ git annex get --from=glacier mydir/myfile1
get mydir/myfile (from glacier...) (gpg)
['/usr/local/bin/glacier', '--region=us-east-1', 'archive', 'retrieve', '-o-', 'glacier-myvault', 'GPGHMACSHA1--4286b1a121892c9e64de436725478b0bc5038e67']
glacier: archive 'GPGHMACSHA1--4286b1a121892c9e64de436725478b0bc5038e67' not found
failed
git-annex: get: 1 failed
\"\"\"]]
I patched the glacier-cli Python source so that it prints out the command arguments argv.
The archive _does_ exist. Executing the glacier-cli command manually is successful. So is calling
git-annex with AWS credentials exported into env:
[[!format sh \"\"\"
[ben@voyagerS9 annextest]$ git annex get --from=glacier mydir/myfile2
get mydir/myfile2 (from glacier...) (gpg)
['/usr/local/bin/glacier', '--region=us-east-1', 'archive', 'retrieve', '-o-', 'glacier-myvault', 'GPGHMACSHA1--c3827c03d48b4829c7cc584778652c66e2784b0f']
ok
(Recording state in git...)
\"\"\"]]
So I guess one bug is fixed, although I think there is a wrong error message.
Regarding AWS credentials, I have no success in updating credentials or finding out which if any are embedded:
[[!format sh \"\"\"
[ben@voyagerS9 annextest]$ git annex info glacier
remote: glacier
description: [glacier]
uuid: b4dcf525-40c7-4f04-86cc-3850d1260680
cost: 1050.0
type: glacier
glacier vault: glacier-myvault
encryption: encrypted (to gpg keys: MYKEY)
chunking: none
\"\"\"]]
When I checkout the git-annex branch and look into the remote.log I see fields for cipher, cipherkeys, datacenter, embedcreds=yes, name, s3creds, type, vault, timestamp.
The s3creds field does not look like my current AWS credentials, at least not in plaintext.
"""]]

12
doc/bugs/get_from_glacier_fails_too_early/comment_7_c96b71759fe0d2af450e321ca57edb46._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.96"
subject="comment 7"
date="2014-10-22T18:30:29Z"
content="""
I forgot to include the creds in `git annex info` for glacier; fixed that now.
It seems that changing the creds with `enableremote` did embed them into your git repository, but it neglected to update the .git/annex/creds/$remoteuuid file that caches the creds locally. So I think that your old creds are still cached there, and still being used, and this explains why the file is not found in glacier; the wrong creds are being used to access it! You can work around this by deleting the .git/annex/creds/$remoteuuid file correspnding to the uuid of the glacier remote. (You can also look at that file and compare it with what the creds are supposed to be.) I have fixed git-annex enableremote to update that creds file.
Also, it looks like you did not fall afoul of the [[upgrades/insecure_embedded_creds]] problem! If you had, this new version of git-annex would be complaining that it had detected that problem. If you want to double-check that, the s3creds= value is base64 encoded, and when run through `base64 -d`, it should yield a gpg encrypted file. If your repo did have that problem, it would instead decode to the creds in clear text.
"""]]

21
doc/bugs/git_annex_add_adds_unlocked_files.mdwn Normal file
View file

@ -0,0 +1,21 @@
### Please describe the problem.
git annex add . should ignore unlocked files
### What steps will reproduce the problem?
SEE NEXT COMMENT
### What version of git-annex are you using? On what operating system?
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]
> [[done]] --[[Joey]]

12
doc/bugs/git_annex_add_adds_unlocked_files/comment_2_4b46116eabe61946ae65b293d7bbacb7._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="behaving as intended"
date="2014-10-09T20:30:26Z"
content="""
git-annex add is supposed to add unlocked files. See the documentation for the unlock command on the man page. Typical workflow is to unlock a file, edit it, add the changes, and commit it.
Your example has 2 files with content \"foo\" and 1 file with content \"foobar\", which require 2 objects to be stored by git-annex, so that's what it stores.
I suggest you get a bit more familiar with git-annex before filing bugs on it.
"""]]

55
doc/bugs/git_annex_add_adds_unlocked_files/comment_2_d53d0710d6ad9f0fdc8a29a98647e94b._comment Normal file
View file

@ -0,0 +1,55 @@
[[!comment format=sh
username="https://www.google.com/accounts/o8/id?id=AItOawn0hu_TPhLcUM1Ivvn7iIoZ_iD3g_5WDcs"
nickname="Greg"
subject="comment 2"
date="2014-10-06T19:20:26Z"
content="""
ubuntu@hostname:~$ cd annex
ubuntu@hostname:~/annex$ git init
Initialized empty Git repository in /home/ubuntu/annex/.git/
ubuntu@hostname:~/annex$ git annex init
init ok
ubuntu@hostname:~/annex$ echo foo > test.txt
ubuntu@hostname:~/annex$ git annex add .
add test.txt (checksum...) ok
(Recording state in git...)
ubuntu@hostname:~/annex$ git commit -a -m first
[master (root-commit) fe54856] first
1 file changed, 1 insertion(+)
create mode 120000 test.txt
ubuntu@hostname:~/annex$ git annex unlock test.txt
unlock test.txt (copying...) ok
ubuntu@hostname:~/annex$ echo foobar > test.txt
ubuntu@hostname:~/annex$ echo foo > test2.txt
ubuntu@hostname:~/annex$ git annex add .
add test2.txt (checksum...) ok
add test.txt (checksum...) ok
(Recording state in git...)
ubuntu@hostname:~/annex$ git commit -a -m second
[master 1776b25] second
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 120000 test2.txt
ubuntu@hostname:~/annex$ tree -d ./git/annex
./git/annex [error opening dir]
0 directories
ubuntu@hostname:~/annex$ tree -d .git/annex
.git/annex
├── journal
├── objects
│   ├── 8Z
│   │   └── 1J
│   │   └── SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
│   └── q2
│   └── Xj
│   └── SHA256-s7--aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f
└── tmp
9 directories
ubuntu@hostname:~/annex$ ls
test2.txt test.txt
ubuntu@hostname:~/annex$
I'm expecting 3 SHA's in .git/annex, but I only see two.
"""]]

2
doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__.mdwn
View file

@ -36,3 +36,5 @@ git-annex: repair: 1 failed
# End of transcript or log.
"""]]
> Provisionally [[done]]; see comment. --[[Joey]]

22
doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_3_7502f88ae1c46e070e7fdbd9b9c1b54d._comment Normal file
View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="relevant excerpt "
date="2014-10-12T18:08:55Z"
content="""
<pre>
[2014-08-20 09:05:45 MSK] call: git [\"--git-dir=/tmp/tmprepo.0/.git\",\"--work-tree=/tmp/tmprepo.0\",\"fetch\",\"ssh://crabman@git-annex-192.168.1.246-crabman_annex/~/annex/\",\"--force\",\"--update-head-ok\",\"--quiet\",\"+*:*\"]
Auto packing the repository in background for optimum performance.
See \"git help gc\" for manual housekeeping.
[2014-08-20 09:05:50 MSK] call: rsync [\"-qr\",\"/tmp/tmprepo.0/.git/objects/\",\"/home/crabman/annex/.git/objects/\"]
[2014-08-20 09:14:58 MSK] read: git [\"--git-dir=/home/crabman/annex/.git\",\"--work-tree=/home/crabman/annex\",\"-c\",\"core.bare=false\",\"show\",\"584a7836d05e6733224a53e5882547eeb87d43db\"]
[2014-08-20 09:14:59 MSK] read: git [\"--git-dir=/home/crabman/annex/.git\",\"--work-tree=/home/crabman/annex\",\"-c\",\"core.bare=false\",\"show\",\"62fee7cc3ec6ea4c56ba42015ab9bf8f0f808dee\"]
[2014-08-20 09:14:59 MSK] read: git [\"--git-dir=/home/crabman/annex/.git\",\"--work-tree=/home/crabman/annex\",\"-c\",\"core.bare=false\",\"show\",\"c7a698397328c71a33bbc2852fda8d09d52c4f38\"]
Running git fsck ...
Trying to recover missing objects from remote 192.168.1.246_annex.
Unpacking all pack files.
Trying to recover missing objects from remote 192.168.1.246_annex.
git-annex: /tmp/tmprepo.0/.git/gc.pid: removeLink: does not exist (No such file or directory)
</pre>
"""]]

10
doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_4_9f67b14c9ac81f159439c5dff7354b8f._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 4"
date="2014-10-12T18:27:39Z"
content="""
So the auto gc was triggered by git fetch. I have made the repair code prevent that from happening. I expect that will solve the problem, so I am marking this bug as closed.
However, I don't understand really what could have caused it to try to remove the gc.pid file. I tried creating such a pid file manually after the fetch, and it didn't try to remove it.
"""]]

8
doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_6_4540c31acd63626fbad9bde487ec3005._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="stp"
ip="91.34.113.105"
subject="Any update"
date="2014-10-01T12:46:34Z"
content="""
Any update?
"""]]

25
doc/bugs/git_clone_ignores_annex.mdwn Normal file
View file

@ -0,0 +1,25 @@
### Please describe the problem.
More of a feature request than a bug. It would be nice if when creating a local clone with git clone this would run automatically:
ln -s ../../annex/.git/annex .git/annex
to hook up the annex. Just a minor thing, but I'd be nice.
### What steps will reproduce the problem?
### What version of git-annex are you using? On what operating system?
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]
> [[done]] --[[Joey]]

10
doc/bugs/git_clone_ignores_annex/comment_1_18ba05c51f82ddadd2558f6cd789e394._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 1"
date="2014-10-06T15:42:26Z"
content="""
Making that symlink is extremely unsafe! git-annex will see two repositories. So if a file is present in the annex, with only one actual copy existing, and you try to drop it, git-annex will go check the other repository, find the file there, assume this means there's an extra copy and so proceed with the drop. Which deletes the only existing copy of your file. So if you do this, you will likely eventually lose data.
However, recent versions of git-annex will detect if you clone a git repository with `--shared` and automatically hard link files into the annex when getting them into that repository. They also mark the shared clone as untrusted, to avoid the above problem. This is a much better solution.
"""]]

3
doc/bugs/hS3_prevents_build.mdwn Normal file
View file

@ -0,0 +1,3 @@
The `hS3` dependency doesn't work with the `network` / `network-uri` split, which causes a build failure for `git-annex` in a fresh sandbox with its current version bounds. Either more gymnastics are needed to constrain `network` to accommodate `hS3`, or the `s3-aws` branch could be merged in if it's ready. Building `git-annex` with a `< 2.6` constraint on `network` does succeed.
> not a bug in git-annex, but in a dependency it uses, so [[done]]. (I already told the hS3 author about this, which is a very easy fix there, and he promised to fix it soon.) --[[Joey]]

8
doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_7_f53d0542c9da38e0f6339df8c49c87db._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="stp"
ip="24.134.205.34"
subject="Any update"
date="2014-10-01T12:48:06Z"
content="""
Any update?
"""]]

40
doc/bugs/modified_permissions_persist_after_unlock__44___commit.mdwn Normal file
View file

@ -0,0 +1,40 @@
### Please describe the problem.
Modifying an annexed file with unlock then commit leaves the link with permissions 777 and git status reports a typechange, which makes checkout impossible. Resolves by running git unlock on the file.
### What steps will reproduce the problem?
echo foo > test.txt
git annex add test.txt
git commit -a -m "first"
git annex unlock test.txt
echo foobar > test.txt
git commit -a -m "second"
git status (notice typechange message)
git unlock test.txt (corrects and retains both versions)
### What version of git-annex are you using? On what operating system?
git-annex version: 3.20120406
local repository version: 3
default repository version: 3
supported repository versions: 3
upgrade supported from repository versions: 0 1 2
git version 1.7.9.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.
"""]]
[[!tag confirmed]]
[[!meta title="git commit of unlocked file leaves typechange staged in index"]]

16
doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_1_875ca12936d4b4505f2e280a454fe558._comment Normal file
View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 1"
date="2014-10-06T15:47:39Z"
content="""
I am unable to reproduce any problem with the steps you gave. I don't see any typechange message, and would not expect one. Perhaps your repository is lacking a .git/hooks/pre-commit script to run git-annex when you use `git commit -a`?
It's not clear to me what problem you experienced, beyond the typechange message that I don't see.
> git unlock test.txt (corrects and retains both versions)
I don't understand that line at all. `git unlock` is not a valid git command, and what does \"corrects and retains both versions\" mean?
Please provide an actual trascript of the problem, rather than the unclear description.
"""]]

94
doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_2_59f68098fa6edb2fe8902b120fda0280._comment Normal file
View file

@ -0,0 +1,94 @@
[[!comment format=sh
username="https://www.google.com/accounts/o8/id?id=AItOawn0hu_TPhLcUM1Ivvn7iIoZ_iD3g_5WDcs"
nickname="Greg"
subject="comment 2"
date="2014-10-06T17:06:27Z"
content="""
ubuntu@ip-10-170-13-124:~$ mkdir annex
ubuntu@ip-10-170-13-124:~$ cd annex
ubuntu@ip-10-170-13-124:~/annex$ ls
ubuntu@ip-10-170-13-124:~/annex$ git init .
Initialized empty Git repository in /home/ubuntu/annex/.git/
ubuntu@ip-10-170-13-124:~/annex$ git annex init \"test annex\"
init test annex ok
ubuntu@ip-10-170-13-124:~/annex$ echo \"foo\" > test.txt
ubuntu@ip-10-170-13-124:~/annex$ ls
test.txt
ubuntu@ip-10-170-13-124:~/annex$ ls -al
total 16
drwxrwxr-x 3 ubuntu ubuntu 4096 Oct 6 16:43 .
drwxr-xr-x 7 ubuntu ubuntu 4096 Oct 6 16:42 ..
drwxrwxr-x 9 ubuntu ubuntu 4096 Oct 6 16:42 .git
-rw-rw-r-- 1 ubuntu ubuntu 4 Oct 6 16:43 test.txt
ubuntu@ip-10-170-13-124:~/annex$ git annex add test.txt
add test.txt (checksum...) ok
(Recording state in git...)
ubuntu@ip-10-170-13-124:~/annex$ ls -al
total 16
drwxrwxr-x 3 ubuntu ubuntu 4096 Oct 6 16:48 .
drwxr-xr-x 7 ubuntu ubuntu 4096 Oct 6 16:42 ..
drwxrwxr-x 9 ubuntu ubuntu 4096 Oct 6 16:48 .git
lrwxrwxrwx 1 ubuntu ubuntu 176 Oct 6 16:43 test.txt -> .git/annex/objects/8Z/1J/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
ubuntu@ip-10-170-13-124:~/annex$ git commit test.txt
Aborting commit due to empty commit message.
ubuntu@ip-10-170-13-124:~/annex$ git commit test.txt -m first
[master (root-commit) 38a8e18] first
Committer: Ubuntu <ubuntu@ip-10-170-13-124.us-west-1.compute.internal>
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:
git config --global user.name \"Your Name\"
git config --global user.email you@example.com
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 test.txt
ubuntu@ip-10-170-13-124:~/annex$ ls -al
total 16
drwxrwxr-x 3 ubuntu ubuntu 4096 Oct 6 16:48 .
drwxr-xr-x 7 ubuntu ubuntu 4096 Oct 6 16:42 ..
drwxrwxr-x 9 ubuntu ubuntu 4096 Oct 6 16:49 .git
lrwxrwxrwx 1 ubuntu ubuntu 176 Oct 6 16:43 test.txt -> .git/annex/objects/8Z/1J/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
ubuntu@ip-10-170-13-124:~/annex$ git annex unlock test.txt
unlock test.txt (copying...) ok
ubuntu@ip-10-170-13-124:~/annex$ cat test.txt
foo
ubuntu@ip-10-170-13-124:~/annex$ echo foobar > test.txt
ubuntu@ip-10-170-13-124:~/annex$ git commit test.txt -m second
add test.txt (checksum...) ok
ok
(Recording state in git...)
[master f265461] second
Committer: Ubuntu <ubuntu@ip-10-170-13-124.us-west-1.compute.internal>
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:
git config --global user.name \"Your Name\"
git config --global user.email you@example.com
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
1 file changed, 1 insertion(+), 1 deletion(-)
ubuntu@ip-10-170-13-124:~/annex$ git status
# On branch master
# Changes to be committed:
# (use \"git reset HEAD <file>...\" to unstage)
#
# typechange: test.txt
#
# Changes not staged for commit:
# (use \"git add <file>...\" to update what will be committed)
# (use \"git checkout -- <file>...\" to discard changes in working directory)
#
# typechange: test.txt
#
ubuntu@ip-10-170-13-124:~/annex$
"""]]

8
doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_3_22df91abd8c025000e67bdcef891de3b._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawn0hu_TPhLcUM1Ivvn7iIoZ_iD3g_5WDcs"
nickname="Greg"
subject="comment 3"
date="2014-10-06T17:07:46Z"
content="""
Looks like its doing it when you specifically commit a filename.
"""]]

13
doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_4_ecf84eeb4feddafcfa7ba7d4a2f164b1._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 4"
date="2014-10-09T20:43:34Z"
content="""
Ah, ok. git's index has the file listed as not being a symlink, because `git commit $file` stages it in the index that way. Running `git reset --hard` will fix git's index.
This problem is avoided if you `git annex add $file` before committing. Which is generally a good idea
for other reasons, including avoiding staging a potentially huge file's contents in the git index in the first place.
git-annex's pre-commit hook should probably update the git index for the committed files, replacing the staged full file contents with the git-annex symlink. That would avoid this problem.
"""]]

39
doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_5_2ea1d78ec8a652a53391969e43bcb6f0._comment Normal file
View file

@ -0,0 +1,39 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 5"
date="2014-10-10T00:01:54Z"
content="""
Actually, the pre-commit hook does stage the annexed symlink into the index. But it seems that `git commit $file` causes the pre-commit hook's changes to the index to be partially ignored, in a way that `git commit -a` does not.
While the pre-commit hook is running, `git commit -a` sets `GIT_INDEX_FILE=index.lock`, while `git commit $file` instead sets `GIT_INDEX_FILE=next-index-$pid.lock`. git's builtin/commit.c refers to this latter file as the \"false index\". Full comment from git:
<pre>
/*
* A partial commit.
*
* (0) find the set of affected paths;
* (1) get lock on the real index file;
* (2) update the_index with the given paths;
* (3) write the_index out to the real index (still locked);
* (4) get lock on the false index file;
* (5) reset the_index from HEAD;
* (6) update the_index the same way as (2);
* (7) write the_index out to the false index file;
* (8) return the name of the false index file (still locked);
*
* The caller should run hooks on the locked false index, and
* create commit from it. Then
* (A) if all goes well, commit the real index;
* (B) on failure, rollback the real index;
* In either case, rollback the false index.
*/
</pre>
So, the pre-commit hook is run on the false index, which has been reset to HEAD. The changes it stages are committed, but do not affect the real index. If I read that comment right, the commit from the false index is then supposed to be committed on the real index, but it seems in this case the real index does not get updated to reflect the changes.
This seems to be a bug in git. Reproduced w/o git-annex, and bug report sent to the git ML.
Depending on what happens, this might just get fixed in git. Or, I might need to make git-annex detect this case (by looking at what `GIT_INDEX_FILE` is set to) and have the pre-commit hook cancel the commit.
"""]]

8
doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_6_2a3ad3f95ee03c79404e3784c9ce1a4b._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 6"
date="2014-10-10T17:26:04Z"
content="""
upstream bug: <http://www.mail-archive.com/git@vger.kernel.org/msg59587.html>
"""]]

5
doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
View file

@ -1,6 +1,6 @@
### Please describe the problem.
This is a followup from the discussion on https://git-annex.branchable.com/forum/Standard_groups__47__preferred_contents/ where I unfortunately did not get a complete answer.
This is a followup from the discussion on <https://git-annex.branchable.com/forum/Standard_groups__47__preferred_contents/> where I unfortunately did not get a complete answer.
I don't know if it is really a bug but at least it does not work as I would expect and the documentation provides no clear discussion on that.
Now to the problem:
@ -36,3 +36,6 @@ Similarly for directories:
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
[[!meta title="manual mode preferred content expression does not want newer versions of present files"]]
[[!tag confirmed]]

10
doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_1_9d7591faf99ce48b1e5753c80306ae8b._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
nickname="Tor Arne"
subject="comment 1"
date="2014-10-01T22:25:24Z"
content="""
Have you found a solution for this? This seems useful if you're only interested in a subset of files/directories on your laptop, eg, but those that are fetched (present) that you are interested you'd want to keep up to date (in sync) with other computers?
Btw, the link to the previous discussion didnt work for me.
"""]]

14
doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_2_7316cba69b9dc0415fea1389238edf25._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.96"
subject="comment 2"
date="2014-10-21T20:20:25Z"
content="""
The problem is that there's no way for preferred content expressions to specify that a file is wanted just because some old version of the file is (or was) present.
It's not clear to me how that could be added to the preferred content expressions in an efficient way.
It might be possible to hack `git annex sync --content` and the assistant to look at incoming merges, and queue downloads of newer versions of files before merging.
Also being discussed at <https://github.com/datalad/datalad/issues/6>.
"""]]

105
doc/bugs/problems_with_enableremote_on_gcrypt_remote___40__hosted_with_gitolite__41__.mdwn Normal file
View file

@ -0,0 +1,105 @@
### Please describe the problem.
cannot enable an exiting gcrypt special remote after successfully having cloned the git repository; I get this error: "git-annex: uuid mismatch ..." at the end of the enableremote command (see transcript for details)
maybe my fault but cannot understand what I'm doing wrong
### What steps will reproduce the problem?
1. cloned the encrypted repository with: "git clone gcrypt::git.myserver.net:myrepo TEST-myrepo.annex"
2. enabled the special remote with: "git annex enableremote backup type=gcrypt encryption=hybrid gitrepo=git.myserver.net:myrepo"
### What version of git-annex are you using? On what operating system?
[[!format sh """
git-annex version: 5.20140927~bpo70+2
build flags: Assistant Pairing S3 Inotify XMPP Feeds Quvi TDFA
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
remote types: git gcrypt S3 bup directory rsync web tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 0 1 2 4
"""]]
### Please provide any additional information below.
[[!format sh """
# transcript of commands and results
(cloning)
g@renaissance:~$ git clone gcrypt::git.myserver.net:DMS-myrepo TEST-myrepo.annex
Cloning into 'TEST-myrepo.annex'...
gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Decrypting manifest
gpg: Signature made Thu 16 Oct 2014 12:58:33 CEST
[...]
gcrypt: Remote ID is :id:8sucFsBZIGQKXFv5ecSW
Receiving objects: 100% (3531/3531), 245.40 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1382/1382), done.
[...]
Receiving objects: 100% (636/636), 66.78 KiB | 0 bytes/s, done.
Resolving deltas: 100% (209/209), done.
Checking connectivity... done.
(annex info)
g@renaissance:~/TEST-myrepo.annex$ git annex info
repository mode: indirect
trusted repositories: (merging origin/git-annex origin/synced/git-annex into git-annex...)
(Recording state in git...)
0
semitrusted repositories: 5
-- here
00000000-0000-0000-0000-000000000001 -- web
622362eb-3882-4429-829b-1ec0f299f5a7 -- [omissis]
69b848ef-dd29-43e4-ae1b-73ec6a01f2f6 -- [omissis]
ffc5c5d1-6166-4753-a2e4-88727d0f8c7b -- backup
untrusted repositories: 1
b185b2ed-c024-43ac-9049-3bc12a87dacc -- [omissis]
transfers in progress: none
available local disk space: 51.53 gigabytes (+1 megabyte reserved)
local annex keys: 0
local annex size: 0 bytes
annexed files in working tree: 212
size of annexed files in working tree: 210.56 megabytes
bloom filter size: 16 mebibytes (0% full)
backend usage:
SHA256E: 212
(list of remotes)
g@renaissance:~/TEST-myrepo.annex$ git annex enableremote
git-annex: Specify the name of the special remote to enable.
Known special remotes: backup
(enabling remote)
g@renaissance:~/TEST-myrepo.annex$ git annex enableremote backup type=gcrypt encryption=hybrid gitrepo=git.myserver.net:myrepo
enableremote backup (encryption update) (hybrid cipher with gpg key [omissis]) gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Decrypting manifest
gpg: Signature made Thu 16 Oct 2014 12:58:33 CEST
[omissis]
gcrypt: Remote ID is :id:8sucFsBZIGQKXFv5ecSW
From gcrypt::git.myserver.net:myrepo
* [new branch] synced/master -> backup/synced/master
* [new branch] master -> backup/master
* [new branch] synced/git-annex -> backup/synced/git-annex
* [new branch] git-annex -> backup/git-annex
gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Decrypting manifest
gpg: Signature made Thu 16 Oct 2014 12:58:33 CEST
[omissis]
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Total 3 (delta 0), reused 1 (delta 0)
gcrypt: Encrypting to: -r [omissis]
gcrypt: Requesting manifest signature
gpg: [omissis]: skipped: public key already present
To gcrypt::git.myserver.net:myserver
1195dda..3254af7 git-annex -> git-annex
git-annex: uuid mismatch (UUID "78104a6f-16a9-504b-8e8a-d8a3c59351e8",Just (UUID "984e0333-3327-5f21-87a1-35d30f37f337"),":id:8sucFsBZIGQKXFv5ecSW")
# End of transcript or log.
"""]]

21
doc/bugs/problems_with_enableremote_on_gcrypt_remote___40__hosted_with_gitolite__41__/comment_1_72a97bc3ccb00c623baee874609bb4ca._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawlZ-6dtxJY4cP7shhvV8E6YyuV0Rak8it4"
nickname="Giovanni"
subject="I messed up that repo"
date="2014-10-16T13:31:15Z"
content="""
I'm sure I messed up the repository at some point
the remote repository have a duplicated (I hope just duplicated and not triplicated) UUID: both ffc5c5d1-6166-4753-a2e4-88727d0f8c7b and 984e0333-3327-5f21-87a1-35d30f37f337
on one of my working remotes I already used \"git annex dead 984e0333-3327-5f21-87a1-35d30f37f337\" and synced the special (bare) remote **but** trying to make a new clone and adding the remote special with enableremote i always get the same \"UUID mismatch\" error, listing the (marked) dead UUID
please is there a way to get rid of the mess I did?!? :-)
I'm tempted to manually add \"annex-uuid = ffc5c5d1-6166-4753-a2e4-88727d0f8c7b\" to the repo \".git/config\" but I fear I'm going to further mess things
sorry for reportng this as a bug... actually it was my fault
best regards
Giovanni
"""]]

26
doc/bugs/rsync_remote_is_not_working.mdwn Normal file
View file

@ -0,0 +1,26 @@
Host: Mac OS with git-annex 5.20140919-g0f7caf5
Remote: Linux
* with git-annex 5.20140920-gb0c4300
* using user&password login
On Host:
1. create a repo with git init && git annex init && git annex direct
1. add a rsync repo in git-annex webapp, type "small archive", with shared encryption (same result using command line)
1. copy some new files to the repo, expect the files to appear in the remote repo (check with du)
1. Web app says "synced with remote-name", but remote repo is completely empty
1. run git annex copy --to $remotename, now remote repo is filled with files
1. but the sizes are really small, seems that the actual files are not being transferred
1. convert the repo to indirect repo: git annex indirect
1. re-run git annex copy, now the repo size on the remote seems about right
1. now start git annex assistant, copy some new files, expect new files to be synced
1. actual: the remote becomes completely empty, the existing files are removed!
The other small issue
* The add remote interface stops at "check remote" prompt for a long time without completing
* Kill the webapp process, re-run webapp, add remote again, it worked very quickly
* But future interaction with the remote still requires password, both commandline & webapp

20
doc/bugs/rsync_remote_is_not_working/comment_1_8998edf856a411de1f90b27568628feb._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.96"
subject="comment 1"
date="2014-10-21T20:07:40Z"
content="""
A \"small archive\" only wants to contain files that are located inside archive/ directories.
That seems to explain everything you reported except for:
> 6. but the sizes are really small, seems that the actual files are not being transferred
Maybe the remote is configured to use chunking? What happens if you run `git annex fsck --from $remotename` after copying a file to it? Any problem detected?
> The add remote interface stops at \"check remote\" prompt for a long time without completing
Please explain exactly what you did in the webapp. What did you click on, and what did you enter? I need enough detail to be able to reproduce the problem.
(Also, in the future, one problem per bug report turns out to be a lot less confusing, and have better results all around. True here and really anywhere..)
"""]]

8
doc/bugs/runs_of_of_memory_adding_2_million_files/comment_10_a201485bf41514fde7c61a4dcbb5064f._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 10"
date="2014-10-02T15:35:15Z"
content="""
This got fixed in version 5.20140707
"""]]

8
doc/bugs/runs_of_of_memory_adding_2_million_files/comment_9_27a31463bcf28b5c684bb483b46a3baf._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmyYyXrtGKiR3Pu2OjdVsETXf4ePmECW54"
nickname="Andrey"
subject="comment 9"
date="2014-09-29T10:48:36Z"
content="""
Joeyh, in what version it was fixed? I really need it for Ubuntu 14.04
"""]]

2
doc/bugs/vicfg_and_description_often_not_propagated.mdwn
View file

@ -150,3 +150,5 @@ wanted a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = standard
#schedule a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 =
# End of transcript or log.
"""]]
[[!tag moreinfo]]

12
doc/bugs/vicfg_and_description_often_not_propagated/comment_2_d56aed617e0791aa17d9f37c8d3fd317._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.96"
subject="comment 2"
date="2014-10-21T20:02:40Z"
content="""
Can you please provide more information, like showing the commits made to the git-annex branch when the configuration was reverted?
Also, might some of the clocks of computers where you're using git-annex be set wrong?
I have tagged this report moreinfo because I don't have enough information to do anything else.
"""]]