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

remove old closed bugs and todo items to speed up wiki updates and reduce size

Browse source 
Remove closed bugs and todos that were last edited or commented before Q3 2015.

Command line used:

for f in $(grep -l '\[\[done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=09-09-2015 --pretty=oneline -- "$f")" -a -z "$(git log --since=09-09-2015 --pretty=oneline -- "$d")" ]; then git rm -- "$f"; git rm -rf "$d"; fi; done
for f in $(grep -l '|done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=09-09-2015 --pretty=oneline -- "$f")" -a -z "$(git log --since=09-09-2015 --pretty=oneline -- "$d")" ]; then git rm -- "$f"; git rm -rf "$d"; fi; done
This commit is contained in:
Joey Hess 2016-04-19 13:46:11 -04:00
parent a9c7260adb
commit b949e85045
Failed to extract signature
1404 changed files with 0 additions and 43109 deletions
Download patch file Download diff file Expand all files Collapse all files

25
doc/bugs/--help_should_not_demand_being_in_the_git_repo.mdwn
View file

@ -1,25 +0,0 @@
### Please describe the problem.
subj -- happens for sync and merge commands at least
[[!format sh """
$> git annex sync --help
git-annex: Not in a git repository.
$> git annex merge --help
git-annex: Not in a git repository.
$> git annex version
git-annex version: 5.20150819+gitgc587698-1~ndall+1
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
YES -- lots of luck ;)
> [[fixed|done]] --[[Joey]]

49
doc/bugs/--json_issues.mdwn
View file

@ -1,49 +0,0 @@
### Please describe the problem.
Duplicate "note" properties in JSON output of whereis command. The JSON output is "[strictly speaking](http://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object)" valid, however, the duplicate property makes it difficult to use python-json, and possibly other implementations (I just checked node and chromium and they also keep the value of the last property after deserialization).
I noticed the problem being mentioned [here](https://git-annex.branchable.com/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/), where the user desires to parse an entry in the machine parsable json output that is apparently not meant to be parsed by a machine, which makes a person wonder why it's there anyway. Even so, obtaining the actual url in the web remote for an annexed object relies on one of the "note" properties in the json output. Using [whereis](
http://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/#comment-7878bde74289b42500e4fac3a122a535) to get the url(s) for a file is the recommended method. A json implementation that sets the first property, then ignores remaining duplicates will only parse the "2 copies" note, and ignore the url.
If the "note" properties are meant to be comments, it might be a good idea to find another property for the url(s). Please note that I haven't looked at multiple urls for an object, so I'm not sure that only the last listed url will appear in parsed json object.
> The note properties are any notes git-annex normally displays while
> running a command.
### What steps will reproduce the problem?
git-annex whereis --json
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20151208-1 (sid chroot)
### 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
umeboshi@bard:~/tmp$ git init testweb
Initialized empty Git repository in /freespace/home/umeboshi/tmp/testweb/.git/
umeboshi@bard:~/tmp$ cd testweb/
umeboshi@bard:~/tmp/testweb$ git-annex init
init ok
(recording state in git...)
umeboshi@bard:~/tmp/testweb$ git-annex addurl http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
addurl www.ecma_international.org_publications_files_ECMA_ST_ECMA_404.pdf (downloading http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf ...)
/freespace/home/ume 100%[===================>] 1.08M 917KB/s in 1.2s
ok
(recording state in git...)
umeboshi@bard:~/tmp/testweb$ git-annex whereis www.ecma_international.org_publications_files_ECMA_ST_ECMA_404.pdf --json
{"command":"whereis","file":"www.ecma_international.org_publications_files_ECMA_ST_ECMA_404.pdf","note":"2 copies","whereis":[{"uuid":"00000000-0000-0000-0000-000000000001","description":"web","here":false},{"uuid":"996522e8-a433-42ff-85f2-48e456fdb120","description":"umeboshi@bard:~/tmp/testweb","here":true}],"note":"\t00000000-0000-0000-0000-000000000001 -- web\n \t996522e8-a433-42ff-85f2-48e456fdb120 -- umeboshi@bard:~/tmp/testweb [here]\n","untrusted":[],"note":"web: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf\n","success":true}
umeboshi@bard:~/tmp/testweb$
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Lol! Positive note! I spend a couple of days making specially crafted rss files for importfeed, so I can have appropriate filenames, then look back and see that you are working on '--batch --with-files' options to addurl. Have a Happy New Year! :)
> [[fixed|done]] --[[Joey]]

37
doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes.mdwn
View file

@ -1,37 +0,0 @@
### Please describe the problem.
Some time in may 2014, git-annex stopped working with previous versions of git-annex.
### What steps will reproduce the problem?
Trying to sync with the server fails with:
git-annex-shell: Not a git-annex or gcrypt repository.
With older versions (e.g. 5.20140412), it's even worse:
Remote marcos does not have git-annex installed; setting annex-ignore
This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git config remote.marcos.annex-ignore false
Basically, if git-annex-shell is missing, newer versions of git-annex just crash and burn instead of going the more gentle, backward-compatible way...
### What version of git-annex are you using? On what operating system?
git-annex from debian sid (5.20140517) on the "client" side and from jessie (5.20140421) on the "server".
### 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
ssh server
git init books
exit
git remote add server server:books
git annex sync server
# End of transcript or log.
"""]]
If this is intended behavior, it seems to me the major version of git annex should be bumped, at the very least... -- [[anarcat]]
> [[done]], seems operator error --[[Joey]]

10
doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_1_323262a080daed9cebd4caee4c887210._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="24.159.78.125"
subject="comment 1"
date="2014-05-23T14:25:04Z"
content="""
git-annex has always required the remote have git-annex-shell installed in order to store files on it. Nothing has changed in this area.
So, you seem to be very confused about something, but I cannot tell what from this bug report, and I certianly see no evidence of any bug in the information provided so far. You need to install git-annex on your server and then it should work, assuming the server actually has a git-annex repository set up on it.
"""]]

8
doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_2_6172dcd7db2322084483a18d4f3cc2d6._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://id.koumbit.net/anarcat"
ip="72.0.72.144"
subject="comment 2"
date="2014-05-27T03:00:48Z"
content="""
marcos has had git-annex installed ever since i started using git-annex, which is around version 4.x. furthermore, i have assumed that the procedure i detailed in the last part were enough to reproduce the bug, but i may be mistaken.
"""]]

10
doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_3_5ae2178863709230ddb995905c629c4e._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.176"
subject="comment 3"
date="2014-05-27T17:54:06Z"
content="""
Well, your transcript shows you init a git repository. But you have not run `git annex init` in it, so git-annex-shell won't use it.
"""]]

8
doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://id.koumbit.net/anarcat"
ip="72.0.72.144"
subject="comment 4"
date="2014-06-04T04:53:36Z"
content="""
ah. i see. certainly an operator error then. feels like a usability issue now, or i just feel stupid, not sure which. :)
"""]]

74
doc/bugs/Addurl_downloads_but_does_not_checkout_files.mdwn
View file

@ -1,74 +0,0 @@
What steps will reproduce the problem?
Example below illustrates downloading a podcast with git annex addurl:
list directory before...
~/Podcasts/TuxRadar Linux Podcast (Ogg)$ ls
folder.jpg tuxradar_s04e24.ogg
tuxradar_s04e09.ogg tuxradar_s05e01.ogg
tuxradar_s04e11.ogg tuxradar_s05e02.ogg
tuxradar_s04e13.ogg tuxradar_s05e03.ogg
tuxradar_s04e15.ogg tuxradar_s05e04.ogg
tuxradar_s04e16.ogg www.tuxradar.com_files_podcast_tuxradar_s04e10.ogg
tuxradar_s04e19.ogg www.tuxradar.com_files_podcast_tuxradar_s04e12.ogg
tuxradar_s04e20.ogg www.tuxradar.com_files_podcast_tuxradar_s04e14.ogg
tuxradar_s04e21.ogg www.tuxradar.com_files_podcast_tuxradar_s04e17.ogg
tuxradar_s04e22.ogg www.tuxradar.com_files_podcast_tuxradar_s04e18.ogg
tuxradar_s04e23.ogg
download file...
~/Podcasts/TuxRadar Linux Podcast (Ogg)$ git annex addurl http://www.tuxradar.com/files/podcast/tuxradar_s05e05.ogg
addurl www.tuxradar.com_files_podcast_tuxradar_s05e05.ogg (downloading http://www.tuxradar.com/files/podcast/tuxradar_s05e05.ogg ...) --2013-04-10 21:18:12-- http://www.tuxradar.com/files/podcast/tuxradar_s05e05.ogg
Resolving www.tuxradar.com (www.tuxradar.com)... 80.244.178.150
Connecting to www.tuxradar.com (www.tuxradar.com)|80.244.178.150|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33249291 (32M) [application/ogg]
Saving to: `/home/rob/Podcasts/.git/annex/tmp/URL--http&c%%www.tuxradar.com%files%podcast%tuxradar_s05e05.ogg'
100%[===============================>] 33,249,291 404K/s in 81s
2013-04-10 21:19:35 (399 KB/s) - `/home/rob/Podcasts/.git/annex/tmp/URL--http&c%%www.tuxradar.com%files%podcast%tuxradar_s05e05.ogg' saved [33249291/33249291]
(checksum...) ok
(Recording state in git...)
file appears to have been downloaded, but isn't there...
~/Podcasts/TuxRadar Linux Podcast (Ogg)$ ls
folder.jpg tuxradar_s04e24.ogg
tuxradar_s04e09.ogg tuxradar_s05e01.ogg
tuxradar_s04e11.ogg tuxradar_s05e02.ogg
tuxradar_s04e13.ogg tuxradar_s05e03.ogg
tuxradar_s04e15.ogg tuxradar_s05e04.ogg
tuxradar_s04e16.ogg www.tuxradar.com_files_podcast_tuxradar_s04e10.ogg
tuxradar_s04e19.ogg www.tuxradar.com_files_podcast_tuxradar_s04e12.ogg
tuxradar_s04e20.ogg www.tuxradar.com_files_podcast_tuxradar_s04e14.ogg
tuxradar_s04e21.ogg www.tuxradar.com_files_podcast_tuxradar_s04e17.ogg
tuxradar_s04e22.ogg www.tuxradar.com_files_podcast_tuxradar_s04e18.ogg
tuxradar_s04e23.ogg
What is the expected output? What do you see instead?
File should exist in current directory. As you can see from above output, this has worked in the past (with older versions).
What version of git-annex are you using? On what operating system?
git-annex version: 4.20130405
local repository version: 3
default repository version: 3
supported repository versions: 3 4
upgrade supported from repository versions: 0 1 2
build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
OS: Debian Testing/Unstable
Please provide any additional information below.
The repository in question was created by the assistant and I tried the above with the assistant both running and not running, with no difference. I have also tried downloading other files.
EDIT: formatting
> Bug only affected direct mode. I think it used to work but I broke
> it when fixing another bug in direct mode. [[fixed|done]] --[[Joey]]

19
doc/bugs/Amazon_S3_storage_hosted_in_Frankfurt_not_usable.mdwn
View file

@ -1,19 +0,0 @@
### Please describe the problem.
Can't add Amazon S3 repository hosted in Frankfurt
### What steps will reproduce the problem?
Create Amazon S3 account, create a bucket hosted in Frankfurt and create an access key.
### What version of git-annex are you using? On what operating system?
Ubuntu, git-annex via repositories. Aptitude says 5.20140717.
### Please provide any additional information below.
The git-annex assistant does not offer the selection of hosting in Frankfurt. If I enter "EU (Ireland)" instead, of course while also providing the other necessary details (access key id, secret access key, data center), the result is the following error:
[[!format sh """
The request signature we calculated does not match the signature you provided. Check your key and signing method.
"""]]
I have not tried other hosting locations but I assume it has to do with the location which is not listed in the dropdown-list.
> [[done]]; etooold --[[Joey]]

13
doc/bugs/Amazon_S3_storage_hosted_in_Frankfurt_not_usable/comment_1_013f8f609ac2f8b6666bbae2db2a147a._comment
View file

@ -1,13 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""step 1: upgrade"""
date="2015-05-27T21:12:38Z"
content="""
Your version is almost a year out of date.
Frankfurt was added to the webapp in 20141023.
The entire S3 backend library has been changed, so it is vanishingly
unlikely that the current version would have whatever problem the old one
had.
"""]]

33
doc/bugs/Android___91__Terminal_session_finished__93__.mdwn
View file

@ -1,33 +0,0 @@
### Please describe the problem.
Launching the Git Annex app on Android, the shell just reads:
[[!format sh """
[Terminal session finished]
"""]]
Attempting to launch /data/data/ga.androidterm/runshell via the adb shell does also not work:
[[!format sh """
/system/bin/sh: /data/data/ga.androidterm/runshell: not found
"""]]
Listing the contents of that directory from the git annex terminal appears to confirm this:
[[!format sh """
u0_a172@android:/data/data/ga.androidterm $ ls
cache
lib
shared_prefs
"""]]
Following the instructions for the similar issue here [[http://git-annex.branchable.com/Android/oldcomments/#comment-4c5a944c1288ddd46108969a4c664584]]:
[[!format sh """
u0_a172@android:/ $ ls -ld /data/data/ga.androidterm
drwxr-x--x u0_a172 u0_a172 2014-04-20 11:12 ga.androidterm
"""]]
### What version of git-annex are you using? On what operating system?
version 5.20140413 of the Git Annex app (tested using the daily build and regular build).
Samsung Galaxy Tab 3 (GT-P5210) running Android 4.2.2 (without root access).
> [[dup|done]] --[[Joey]]

12
doc/bugs/Android___91__Terminal_session_finished__93__/comment_1_31af3e5226430a4e94de58c0e33bd22b._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 1"
date="2014-04-20T17:16:50Z"
content="""
From the git-annex terminal, try to run:
/data/data/ga.androidterm/lib/lib.start.so
Paste me any output..
"""]]

22
doc/bugs/Android___91__Terminal_session_finished__93__/comment_2_a5bcbd2f85283e29e237e9850cd8109a._comment
View file

@ -1,22 +0,0 @@
[[!comment format=mdwn
username="cbaines"
ip="86.166.14.171"
subject="comment 2"
date="2014-04-20T19:40:11Z"
content="""
When I run that, I get:
[[!format sh \"\"\"
/system/bin/sh: /data/data/ga.androidterm/lib/lib.start.so: not found
\"\"\"]]
Which makes some sense, as the file is not there. The following files can be found under /data/data/ga.androidterm:
[[!format sh \"\"\"
/data/data/ga.androidterm/cache/com.android.renderscript.cache/ <- empty directory
/data/data/ga.androidterm/lib/libga-androidterm4.so
/data/data/ga.androidterm/shared_prefs/ga.androidterm_preferences.xml
\"\"\"]]
I tried running libga-androidterm4.so, but I just got Segmentation fault back.
I also tried using logcat to see if I could see anything obvious going wrong when running the app for the first time after installation, but I could not see anything obvious in the logs (there was a lot of noise, so I might of missed something), will anything useful appear with the use of a filter?
"""]]

8
doc/bugs/Android___91__Terminal_session_finished__93__/comment_3_965efa6736dcff4d7010ea5533f31a59._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="cbaines"
ip="86.166.14.171"
subject="comment 3"
date="2014-04-20T19:50:12Z"
content="""
Looking at the contents of the apk for the x86 architecture (which this tablet is), would you expect that file to be there? That file only appears in the /lib/armeabi and not /lib/x86 ?
"""]]

31
doc/bugs/Android___91__Terminal_session_finished__93__/comment_4_90a0be2296b4a1d8c1708423666c9619._comment
View file

@ -1,31 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 4"
date="2014-04-20T19:55:59Z"
content="""
Ok, so the git-annex.apk ships several libraries (and pseudo-libraries), and it seems your version of Android only installed the one that is really an Android java application. I don't know why.
Here's the full list of files that are supposed to be installed in the lib dir. If you can find something about them in the logs, that might help.
I suppose it's possible they were installed to some other location in the android file system (which might be hard to find w/o root.. You could check if git-annex in the app list has a larger installed size than the size of libga-androidterm4.so, that might give a hint.
<pre>
lib.busybox.so
lib.git-annex.so
lib.git-shell.so
lib.git-upload-pack.so
lib.git.so
lib.git.tar.gz.so
lib.gpg.so
lib.rsync.so
lib.runshell.so
lib.ssh-keygen.so
lib.ssh.so
lib.start.so
lib.version.so
libga-androidterm4.so
</pre>
(I just installed the 5.20140414-gb70cd37 autobuild on an android device and it worked ok.)
"""]]

8
doc/bugs/Android___91__Terminal_session_finished__93__/comment_5_be4b720293992f75b9cc3e8f6687fb87._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="cbaines"
ip="86.166.14.171"
subject="comment 5"
date="2014-04-20T20:20:55Z"
content="""
I'm guessing you missed my last comment regarding the architecture. Sorry I did not pick this up earlier, but it only came to mind when I had a poke around in the apk?
"""]]

8
doc/bugs/Android___91__Terminal_session_finished__93__/comment_6_8e439138c97b8853ab2b6f96f6111568._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 6"
date="2014-04-20T20:58:22Z"
content="""
Yes, that fully explains it. git-annex is a native program and for android it's only built for arm.
"""]]

8
doc/bugs/Android___91__Terminal_session_finished__93__/comment_7_6142516d816f78c724e22737aa3bca53._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 7"
date="2014-04-20T20:59:35Z"
content="""
So, this is a dup of [[todo/Not_working_on_Android-x86]]
"""]]

9
doc/bugs/Android___91__Terminal_session_finished__93__/comment_8_e28f25897caa301e69ad7aabab821086._comment
View file

@ -1,9 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkAm9yT27yU-qBTGKIsTMdWW3AgL_WAfkc"
nickname="Cameron"
subject="Similar issue here"
date="2015-03-28T22:17:08Z"
content="""
Im on the LG F60 (ms395) not rooted. I downloaded a cracked.apk of KBOX and it kept failing to start due to not having Busybox in its file path. So I got the Busybox .apk and copied it into KBOX's path. Now k box is stoped at 'In mgmain JNI_OnLoad'. As soon as I try to ENTER anything, it force closes. Also, I'm not sure if it's related, but my phone is not and does not get recognized by my car stereo via usb. I managed to get around not having permission to look at the 'usbautorun.iso' file. No luck though, it's coded. Any ideas?
"""]]

39
doc/bugs/Android_build_missing_webapp.mdwn
View file

@ -1,39 +0,0 @@
### Please describe the problem.
Setting git-annex on an Android device (either the released version, or the autobuilder apk), I'm told:
[[!format sh """
git-annex: unknown command webapp
"""]]
Looking in the logs on the Android autobuilder I see many instances of:
[[!format sh """
#warning Building without the webapp. You probably need to install Yesod..
"""]]
### What steps will reproduce the problem?
Run git-annex.
### What version of git-annex are you using? On what operating system?
v5.20150617~g031b85a
### 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.
"""]]
> I've reverted to the previous release, which included the webapp, afaik.
>
> Unfortunately, the android autobuilder remains broken after I spent 12
> hours fighting with it. Unsure when that will be resolved and a newer
> release will be able to be made.
>
> Anyhow, the immediate bug is [[done]] --[[Joey]]

166
doc/bugs/Android_fails_on_Google_Nexus_10_Jellybean.mdwn
View file

@ -1,166 +0,0 @@
### Please describe the problem.
Install seems to die because /data/app-lib not found. Sorry, I did not copy. Git-annex log is below.
I tried To run git-annex second time, here's what terminal says.
Falling back to hardcoded app location; cannot find expected files in /data/app-lib
git annex webapp
u0_a36@manta:/sdcard/git-annex.home $ git annex webapp
WARNING: linker: git-annex has text relocations. This is wasting memory and is a security risk. Please fix.
error: fchmod on /sdcard/mediashare/.git/config.lock failed: Operation not permitted
error: fchmod on /sdcard/mediashare/.git/config.lock failed: Operation not permitted
From git terminal, can start web viewer, it offers to make repo. I chose /sdcard/mediashare, result is browser fail:
git [Param "config",Param "annex.uuid",Param "380f6ec2-a7b0-43db-9447-f0de1b5a1b5b"] failed
The install did create /sdcard/mediashare. I did have the sdcard directory all along.
I can't say for sure what else is in file system. ES File manager shows /data exists, but it is empty. But tablet not easy to diagnose
### What steps will reproduce the problem?
Install git-annex.apk from website. I downloaded 20140620.
### What version of git-annex are you using? On what operating system?
Android 4.4.2 on Nexus tablet.
### Please provide any additional information below.
Git-anex-install.log. it is only file in /sdcard/git-annex.home. note it says it is installing to /data/data/. I may manually create that structure and see if a reinstall ends differently.
[[!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
Installation starting to /data/data/ga.androidterm
1bebb0d66f3f7c5ac4889b86669cab04ebee9bba
installing busybox
installing git-annex
installing git-shell
installing git-upload-pack
installing git
installing gpg
installing rsync
installing ssh
installing ssh-keygen
linking ./bin/git-upload-archive to git
linking ./bin/git-receive-pack to git
linking ./libexec/git-core/git-help to git
linking ./libexec/git-core/git-fsck to git
linking ./libexec/git-core/git-cat-file to git
linking ./libexec/git-core/git-init to git
linking ./libexec/git-core/git-checkout-index to git
linking ./libexec/git-core/git-notes to git
linking ./libexec/git-core/git-grep to git
linking ./libexec/git-core/git-blame to git
linking ./libexec/git-core/git-verify-tag to git
linking ./libexec/git-core/git-write-tree to git
linking ./libexec/git-core/git-log to git
linking ./libexec/git-core/git-stage to git
linking ./libexec/git-core/git-update-ref to git
linking ./libexec/git-core/git-status to git
linking ./libexec/git-core/git-show-branch to git
linking ./libexec/git-core/git-merge-file to git
linking ./libexec/git-core/git-for-each-ref to git
linking ./libexec/git-core/git to git
linking ./libexec/git-core/git-replace to git
linking ./libexec/git-core/git-update-index to git
linking ./libexec/git-core/git-annotate to git
linking ./libexec/git-core/git-patch-id to git
linking ./libexec/git-core/git-merge-recursive to git
linking ./libexec/git-core/git-rm to git
linking ./libexec/git-core/git-ls-tree to git
linking ./libexec/git-core/git-update-server-info to git
linking ./libexec/git-core/git-diff-tree to git
linking ./libexec/git-core/git-merge-tree to git
linking ./libexec/git-core/git-mktag to git
linking ./libexec/git-core/git-rev-list to git
linking ./libexec/git-core/git-column to git
linking ./libexec/git-core/git-apply to git
linking ./libexec/git-core/git-var to git
linking ./libexec/git-core/git-rev-parse to git
linking ./libexec/git-core/git-archive to git
linking ./libexec/git-core/git-verify-pack to git
linking ./libexec/git-core/git-push to git
linking ./libexec/git-core/git-commit to git
linking ./libexec/git-core/git-tag to git
linking ./libexec/git-core/git-pack-refs to git
linking ./libexec/git-core/git-fmt-merge-msg to git
linking ./libexec/git-core/git-fast-export to git
linking ./libexec/git-core/git-remote-ext to git
linking ./libexec/git-core/git-mailsplit to git
linking ./libexec/git-core/git-send-pack to git
linking ./libexec/git-core/git-diff-index to git
linking ./libexec/git-core/git-mailinfo to git
linking ./libexec/git-core/git-revert to git
linking ./libexec/git-core/git-diff-files to git
linking ./libexec/git-core/git-merge-ours to git
linking ./libexec/git-core/git-show-ref to git
linking ./libexec/git-core/git-diff to git
linking ./libexec/git-core/git-clean to git
linking ./libexec/git-core/git-bundle to git
linking ./libexec/git-core/git-check-mailmap to git
linking ./libexec/git-core/git-describe to git
linking ./libexec/git-core/git-branch to git
linking ./libexec/git-core/git-checkout to git
linking ./libexec/git-core/git-name-rev to git
linking ./libexec/git-core/git-gc to git
linking ./libexec/git-core/git-fetch to git
linking ./libexec/git-core/git-whatchanged to git
linking ./libexec/git-core/git-cherry to git
linking ./libexec/git-core/git-reflog to git
linking ./libexec/git-core/git-hash-object to git
linking ./libexec/git-core/git-init-db to git
linking ./libexec/git-core/git-rerere to git
linking ./libexec/git-core/git-reset to git
linking ./libexec/git-core/git-stripspace to git
linking ./libexec/git-core/git-prune to git
linking ./libexec/git-core/git-mktree to git
linking ./libexec/git-core/git-unpack-file to git
linking ./libexec/git-core/git-remote to git
linking ./libexec/git-core/git-commit-tree to git
linking ./libexec/git-core/git-symbolic-ref to git
linking ./libexec/git-core/git-credential to git
linking ./libexec/git-core/git-check-ignore to git
linking ./libexec/git-core/git-shortlog to git
linking ./libexec/git-core/git-fetch-pack to git
linking ./libexec/git-core/git-clone to git
linking ./libexec/git-core/git-mv to git
linking ./libexec/git-core/git-read-tree to git
linking ./libexec/git-core/git-merge-subtree to git
linking ./libexec/git-core/git-ls-remote to git
linking ./libexec/git-core/git-config to git
linking ./libexec/git-core/git-cherry-pick to git
linking ./libexec/git-core/git-merge to git
linking ./libexec/git-core/git-prune-packed to git
linking ./libexec/git-core/git-count-objects to git
linking ./libexec/git-core/git-merge-base to git
linking ./libexec/git-core/git-index-pack to git
linking ./libexec/git-core/git-repack to git
linking ./libexec/git-core/git-show to git
linking ./libexec/git-core/git-fsck-objects to git
linking ./libexec/git-core/git-format-patch to git
linking ./libexec/git-core/git-bisect--helper to git
linking ./libexec/git-core/git-upload-archive to git
linking ./libexec/git-core/git-ls-files to git
linking ./libexec/git-core/git-check-attr to git
linking ./libexec/git-core/git-get-tar-commit-id to git
linking ./libexec/git-core/git-remote-fd to git
linking ./libexec/git-core/git-unpack-objects to git
linking ./libexec/git-core/git-add to git
linking ./libexec/git-core/git-check-ref-format to git
linking ./libexec/git-core/git-merge-index to git
linking ./libexec/git-core/git-pack-objects to git
linking ./libexec/git-core/git-receive-pack to git
linking ./libexec/git-core/git-pack-redundant to git
linking ./libexec/git-core/git-shell to git-shell
linking ./libexec/git-core/git-upload-pack to git-upload-pack
Installation complete
# End of transcript or log.
"""]]
> [[fixed|done]] --[[Joey]]

25
doc/bugs/Android_fails_on_Google_Nexus_10_Jellybean/comment_1_b41666c032aeb2d0de35023328391edb._comment
View file

@ -1,25 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.55"
subject="comment 1"
date="2014-07-03T20:10:41Z"
content="""
This is not an installation problem; the /data/app-lib message is a red herring.
Is /sdcard/mediashare a directory that already existed? If so, perhaps it's some \"mediashare\" thing that has a even more crippled filesystem than usual. Seems possible, but I don't know. Want to rule it out..
The actual failure seems to be when git tries to write to its config.lock file, and changes its permissions. This is a recent change in git, commit daa22c6f8da466bd7a438f1bc27375fd737ffcf3, \"config: preserve config file permissions on edits\".
[[!language C \"\"\"
+ if (fchmod(fd, st.st_mode & 07777) < 0) {
+ error(\"fchmod on %s failed: %s\",
+ lock->filename, strerror(errno));
+ ret = CONFIG_NO_WRITE;
+ goto out_free;
+ }
\"\"\"]]
This seems utterly innocuous; the config file has some mode, and this just sets that same mode back (excluding some high bit flags). But Android goes out of its way to make /sdcard the most craptacular filesystem in use on any Linux system, so I'm not really surprised that it might just refuse all fchmod even when it's a no-op. (This is the only fchmod call currently in git.)
I've patched the bundled git to work around this. Will be a while until there is an updated autobuild..
"""]]

8
doc/bugs/Android_fails_on_Google_Nexus_10_Jellybean/comment_2_95ebed938df3db2b6d4ebe4c666c08f8._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.55"
subject="comment 2"
date="2014-07-04T17:52:35Z"
content="""
This problem should be fixed in the most recent daily build of git-annex for android. Testing appreciated.
"""]]

28
doc/bugs/Armel_version_broken_on_Synology_DSM_4.3-3810.mdwn
View file

@ -1,28 +0,0 @@
### Please describe the problem.
The armel daily build linked from https://git-annex.branchable.com/install/Linux_standalone/ doesn't seem to work.
When runshell is run as root, it hangs with no output and trying to run git directly from the bin directory gives
"/git: exec: line 2: : Permission denied:."
When run as an ordinary user, it gives
"./runshell: line 40: can't create /root/.ssh/git-annex-shell: Permission denied
chmod: /root/.ssh/git-annex-shell: Permission denied"
### What steps will reproduce the problem?
- Login in to NAS as root via SSH
- Download latest daily build via curl
- Untar, chown -R root:root, and CD in to git-annex.linux
- ./runshell or 'cd bin; ./git"
### What version of git-annex are you using? On what operating system?
Synology DSM 4.3-3810 and latest nightly build of git-annex.
> The shimming was broken, causing the hang. [[fixed|done]]
>
> (It looks like you somehow forgot to set HOME when becoming the non-root
> user.) --[[Joey]]

14
doc/bugs/Armel_version_broken_on_Synology_DSM_4.3-3810/comment_1_c398f92de91729e60b59127733759a38._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmZgZuUhZlHpd_AbbcixY0QQiutb2I7GWY"
nickname="Jimmy"
subject="Same hang when added to $PATH"
date="2013-12-21T03:28:07Z"
content="""
DiskStation> echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin:/root/git-annex.linux
DiskStation> git-annex-shell
[...hangs...]
"""]]

8
doc/bugs/Armel_version_broken_on_Synology_DSM_4.3-3810/comment_2_646087d44ee32f78784ae9e8d65d87e6._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://grossmeier.net/"
nickname="greg"
subject="comment 2"
date="2013-12-21T06:27:49Z"
content="""
Try not as root, see how far that gets you.
"""]]

10
doc/bugs/Armel_version_broken_on_Synology_DSM_4.3-3810/comment_3_205e41cb0abaed3e16d45206bb2e77a4._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmZgZuUhZlHpd_AbbcixY0QQiutb2I7GWY"
nickname="Jimmy"
subject="comment 3"
date="2013-12-21T08:22:28Z"
content="""
Hi Greg, I tried that and got a permissions error.
\"./runshell: line 40: can't create /root/.ssh/git-annex-shell: Permission denied chmod: /root/.ssh/git-annex-shell: Permission denied\"
"""]]

9
doc/bugs/Assistant_breaks_when_broken_symlinks_are_in_.git__47__annex__47__tmp.mdwn
View file

@ -1,9 +0,0 @@
The assistant web UI says: `SanityCheckerStartup crashed: /home/zerodogg/Delt/.git/annex/tmp/Sak_7.pdf: getFileStatus: does not exist (No such file or directory)` with a «Restart thread»-button. Clicking said button merely makes the error re-appear. The file in question is a broken symlink. Deleting the symlink and then restarting the thread fixes the problem.
I'm not sure what causes said symlink to appear (which has the name of a file that does exist in the annex), but it has done so on several systems accross different distributions here (Fedora 20, Ubuntu 14.04, Archlinux). Perhaps an rsync copies over a symlink instead of a file?
git-annex version: 5.20140517-gee56d21
[[!tag confirmed]]
> [[fixed|done]] --[[Joey]]

10
doc/bugs/Assistant_breaks_when_broken_symlinks_are_in_.git__47__annex__47__tmp/comment_1_659e0c5127c92b1c7643823d0c240543._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.176"
subject="comment 1"
date="2014-05-30T18:58:56Z"
content="""
Well, Sak7.pdf is not a git-annex object filename. And .git/annex/tmp used to be used as a general-purpose temp directory, but in recent versions we're moving away from that; it's only supposed to contain git-annex objects.
So, this must be a leftover file from an old version of git-annex. I don't know offhand what would create a symlink in the temp directory. However, the crash is from the code that was added to the assistant to clean up such left behind files. So, I'll fix that code.
"""]]

64
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files.mdwn
View file

@ -1,64 +0,0 @@
### Please describe the problem.
The assistant/webapp doesn't drop files from the local (source) repository after transferring it to the 2 backup repositories (numcopies 2), but they are listed with:
git annex find --want-drop
### What steps will reproduce the problem?
#### mintcream ####
git init annex
cd ~/annex
git commit -m "create" --allow-empty
git annex init mintcream
git annex numcopies 2
git annex group here source
git config annex.autocommit false
git annex webapp
#### liquorice ####
git init annex
cd ~/annex
git annex init liquorice
git annex group here backup
#### candyfloss ####
git init annex
cd ~/annex
git annex init candyfloss
git annex group here backup
#### mintcream ####
(add both backup repositories in webapp as "remote repositories")
(copy files into ~/annex directory)
git annex add
git commit -m "add some files"
(use "sync now" to prod assistant into noticing the commit)
### What was I expecting to happen? ###
The assistant to transfer the files to liquorice and candyfloss, then for the assistant to drop the files from mintcream.
### What actually happened? ###
The assistant transfers the files to liquorice and candyfloss. No files are dropped from mintcream.
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140707-g923b436
Arch Linux (git-annex-bin from AUR)
### Please provide any additional information below.
I wish to retain control of the commits on "master" (annex.autocommit false) but want the assistant to handle moving/dropping the files as required in the background.
git annex drop --auto
works as expected.
> [[done]]; user misconfiguration. --[[Joey]]

10
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_1_f32fbae29e4db039804c0853256c238c._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 1"
date="2014-07-10T18:48:17Z"
content="""
Reproduced. `git annex sync --content` has the same problem.
Of course, both it and the assistant *do* check if files can be dropped. For some reason, it is deciding it is not safe to drop the file.
"""]]

10
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_2_405bfa00dfd433352c263afe75e94b2c._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="user misconfiguration"
date="2014-07-10T19:02:00Z"
content="""
Reason is simple: You manually put the repository into the source group, but its preferred content is not set to \"standard\". No matter what group a repository is in, you have to set its preferred content to something, or git-annex will default to assuming you want the repo to retain all files.
So, `git annex wanted mintcream standard` and away you go. You'll also want to set that for the other 2 repos probably..
"""]]

40
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_3_c8cac8d800199ca4d8a65ba72abf678e._comment
View file

@ -1,40 +0,0 @@
[[!comment format=mdwn
username="CandyAngel"
ip="81.111.193.130"
subject="comment 3"
date="2014-07-11T10:41:23Z"
content="""
Ohhh I see!
I was expecting \"standard\" to be the default because of what vicfg shows..
# Repository preferred contents
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard
# (for test)
#wanted 025d4d21-7648-426c-a406-bb7f27688afe = standard
# Group preferred contents
# (Used by repositories with \"groupwanted\" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
In my experience with configuration files, a commented out line like this:
#wanted 025d4d21-7648-426c-a406-bb7f27688afe = standard
without any \"this is an example\" text above it means \"this is the default setting\". Everything in vicfg looks like it is the current settings, rather than just placeholders..
I understand why you need to set the wanted explicitly (at least from the command line), but the way information is shown in vicfg led me to interact with it incorrectly. Would it be worth adding a disclaimer that commented lines are examples, not defaults? As far as I am aware, the logic I explained above (commented line == default) is the \"norm\" in *nix configuration files, which would make vicfg non-intuitive.
All I need to do now is not be so bothered by how messy the git-annex branch looks when the assistant is running things! :D
Thankies
"""]]

14
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_4_ee5fa8a22d1571b0040aa97c4979ef92._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="CandyAngel"
ip="81.111.193.130"
subject="comment 4"
date="2014-07-11T10:57:58Z"
content="""
Actually, I'm still a little confused.
If git-annex was presuming I wanted to keep all the files as you say, why were they listed in `git annex find --want-drop` and dropped by `git annex drop --auto`?
Shouldn't they have been empty and a no-op respectively?
There seems to be a difference in the behaviour between the command line (wanting to and actually dropping the files) and the assistant (wanting to keep them) for the same settings.
"""]]

10
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_5_eef448b9e3dd1a717430a60d1001a7ee._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 5"
date="2014-07-11T18:27:44Z"
content="""
The assistant defaults to assuming all files are wanted if there's no preferred content settings, while command-line dropping stuff defaults to assuming no files are wanted (or more accurately, that you'll drop anything you don't want and get anything you do) when there's no preferred content settings. So the default differs, but this only matters when not setting preferred contents.
I agree that the vicfg could be misread, so have changed it.
"""]]

435
doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate.mdwn
View file

@ -1,435 +0,0 @@
### Please describe the problem.
On two hosts, I've configured two separate local repositories (~/foo and ~/bar) with the assistant and added a transfer repository to ~/foo.
While files are kept separate, the configuration seems to get mixed up. This results in all files beeing uploaded to the configured transfer repository.
The reason might be, that informations about ~/bar are included in the configuration of ~/foo (see below).
### What steps will reproduce the problem?
* Create local repository ~/foo on both hosts
* Add transfer repository to ~/foo on both hosts
* Add some files to ~/foo and let it sync
* Create local repository ~/bar and select keep the repositories separate on both hosts
* All files of ~/foo will now be uploaded again to the transfer repository
### What version of git-annex are you using? On what operating system?
5.20140421~bpo70+1 on Debian 7.5 amd64
### Please provide any additional information below.
*trh@czc4142wfz:~/foo$ git-annex info*
<pre><code>repository mode: direct
trusted repositories: 0
semitrusted repositories: 4
00000000-0000-0000-0000-000000000001 -- web
bd23a5ed-af6e-466d-ac8c-9ea38a220c62 -- trh@r9-y3pll:~/foo
cc888105-b6c3-4926-8396-e3870f6bfc05 -- transfer_foo
f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 -- here (trh@czc4142wfz:~/foo)
untrusted repositories: 0
transfers in progress: none
available local disk space: 356.11 gigabytes (+1 megabyte reserved)
local annex keys: 2
local annex size: 2.99 gigabytes
annexed files in working tree: 2
size of annexed files in working tree: 2.99 gigabytes
bloom filter size: 16 mebibytes (0% full)
backend usage:
SHA256E: 4
</code></pre>
*trh@czc4142wfz:~/bar$ git-annex info*
<pre><code>repository mode: direct
trusted repositories: 0
semitrusted repositories: 2
00000000-0000-0000-0000-000000000001 -- web
f1478436-cf7b-4a05-91a6-91157ae5e9c4 -- here (trh@czc4142wfz:~/bar)
untrusted repositories: 0
transfers in progress: none
available local disk space: 356.11 gigabytes (+1 megabyte reserved)
local annex keys: 0
local annex size: 0 bytes
annexed files in working tree: 0
size of annexed files in working tree: 0 bytes
bloom filter size: 16 mebibytes (0% full)
backend usage:
</code></pre>
*trh@czc4142wfz:~/foo$ git-annex vicfg*
<pre><code># git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
# setting field = value
# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@r9-y3pll:~/foo)
#trust bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = semitrusted
# (for transfer_foo)
#trust cc888105-b6c3-4926-8396-e3870f6bfc05 = semitrusted
# (for trh@czc4142wfz:~/foo)
#trust f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = semitrusted
# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for )
group 357eaef4-af1b-491a-a003-01c2d583056e = client
# (for trh@r9-y3pll:~/foo)
group bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = client
# (for )
group f1478436-cf7b-4a05-91a6-91157ae5e9c4 = client
# (for trh@czc4142wfz:~/foo)
group f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = client
# (for transfer_foo)
group cc888105-b6c3-4926-8396-e3870f6bfc05 = transfer
# (for web)
#group 00000000-0000-0000-0000-000000000001 =
# Repository preferred contents
# (for )
wanted 357eaef4-af1b-491a-a003-01c2d583056e = standard
# (for trh@r9-y3pll:~/foo)
wanted bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = standard
# (for transfer_foo)
wanted cc888105-b6c3-4926-8396-e3870f6bfc05 = standard
# (for )
wanted f1478436-cf7b-4a05-91a6-91157ae5e9c4 = standard
# (for trh@czc4142wfz:~/foo)
wanted f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = standard
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard
# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard
# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*
# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#required bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#required cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#required f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =
# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#schedule bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#schedule cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#schedule f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =
</code></pre>
**Note: f1478436-cf7b-4a05-91a6-91157ae5e9c4 is id of ~/bar on local host (see below) / 357eaef4-af1b-491a-a003-01c2d583056e is id of ~/bar on r9-y3pll**
*trh@czc4142wfz:~/bar$ git-annex vicfg*
<pre><code># git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
# setting field = value
# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@czc4142wfz:~/bar)
#trust f1478436-cf7b-4a05-91a6-91157ae5e9c4 = semitrusted
# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for web)
#group 00000000-0000-0000-0000-000000000001 =
# (for trh@czc4142wfz:~/bar)
#group f1478436-cf7b-4a05-91a6-91157ae5e9c4 =
# Repository preferred contents
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard
# (for trh@czc4142wfz:~/bar)
#wanted f1478436-cf7b-4a05-91a6-91157ae5e9c4 = standard
# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard
# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*
# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@czc4142wfz:~/bar)
#required f1478436-cf7b-4a05-91a6-91157ae5e9c4 =
# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@czc4142wfz:~/bar)
#schedule f1478436-cf7b-4a05-91a6-91157ae5e9c4 =
</code></pre>
*trh@r9-y3pll:~/foo$ git-annex info*
<pre><code>repository mode: direct
trusted repositories: 0
semitrusted repositories: 4
00000000-0000-0000-0000-000000000001 -- web
bd23a5ed-af6e-466d-ac8c-9ea38a220c62 -- here (trh@r9-y3pll:~/foo)
cc888105-b6c3-4926-8396-e3870f6bfc05 -- transfer_foo
f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 -- trh@czc4142wfz:~/foo
untrusted repositories: 0
transfers in progress: none
available local disk space: 280.24 gigabytes (+1 megabyte reserved)
local annex keys: 2
local annex size: 2.99 gigabytes
annexed files in working tree: 2
size of annexed files in working tree: 2.99 gigabytes
bloom filter size: 16 mebibytes (0% full)
backend usage:
SHA256E: 4
</code></pre>
*trh@r9-y3pll:~/bar$ git-annex info*
<pre><code>repository mode: direct
trusted repositories: 0
semitrusted repositories: 2
00000000-0000-0000-0000-000000000001 -- web
357eaef4-af1b-491a-a003-01c2d583056e -- here (trh@r9-y3pll:~/bar)
untrusted repositories: 0
transfers in progress: none
available local disk space: 280.24 gigabytes (+1 megabyte reserved)
local annex keys: 0
local annex size: 0 bytes
annexed files in working tree: 0
size of annexed files in working tree: 0 bytes
bloom filter size: 16 mebibytes (0% full)
backend usage:
</code></pre>
*trh@r9-y3pll:~/foo$ git-annex vicfg*
<pre><code># git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
# setting field = value
# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@r9-y3pll:~/foo)
#trust bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = semitrusted
# (for transfer_foo)
#trust cc888105-b6c3-4926-8396-e3870f6bfc05 = semitrusted
# (for trh@czc4142wfz:~/foo)
#trust f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = semitrusted
# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for )
group 357eaef4-af1b-491a-a003-01c2d583056e = client
# (for trh@r9-y3pll:~/foo)
group bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = client
# (for )
group f1478436-cf7b-4a05-91a6-91157ae5e9c4 = client
# (for trh@czc4142wfz:~/foo)
group f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = client
# (for transfer_foo)
group cc888105-b6c3-4926-8396-e3870f6bfc05 = transfer
# (for web)
#group 00000000-0000-0000-0000-000000000001 =
# Repository preferred contents
# (for )
wanted 357eaef4-af1b-491a-a003-01c2d583056e = standard
# (for trh@r9-y3pll:~/foo)
wanted bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = standard
# (for transfer_foo)
wanted cc888105-b6c3-4926-8396-e3870f6bfc05 = standard
# (for )
wanted f1478436-cf7b-4a05-91a6-91157ae5e9c4 = standard
# (for trh@czc4142wfz:~/foo)
wanted f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = standard
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard
# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard
# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*
# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#required bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#required cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#required f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =
# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#schedule bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#schedule cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#schedule f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =
</code></pre>
*trh@r9-y3pll:~/bar$ git-annex vicfg*
<pre><code># git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
# setting field = value
# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@r9-y3pll:~/bar)
#trust 357eaef4-af1b-491a-a003-01c2d583056e = semitrusted
# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for web)
#group 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/bar)
#group 357eaef4-af1b-491a-a003-01c2d583056e =
# Repository preferred contents
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard
# (for trh@r9-y3pll:~/bar)
#wanted 357eaef4-af1b-491a-a003-01c2d583056e = standard
# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard
# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*
# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/bar)
#required 357eaef4-af1b-491a-a003-01c2d583056e =
# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/bar)
#schedule 357eaef4-af1b-491a-a003-01c2d583056e =
</code></pre>
> [[fixed|done]] --[[Joey]]

8
doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_1_418103046e296a43cfe0f0cf69e729d5._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.176"
subject="comment 1"
date="2014-05-29T18:21:30Z"
content="""
As far as I can understand the description (which has an lot of different \"foo\"'s in it that seem to refer to different things?) -- This is the assistant behaving as designed: Any time two repositories are pointed at the same transfer repository, or removable drive repository, etc, they will unify and share all their files.
"""]]

23
doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_2_9405804842bb23e8040ec85b271b18af._comment
View file

@ -1,23 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmi0jblSiI4c5-EswqKw4PXkx5M4fuVvdk"
nickname="Henry"
subject="comment 2"
date="2014-05-29T19:10:08Z"
content="""
I'm using the same folder name on different hosts. So yes, ~/foo exists 3 times. Let me try to clarify it:
<pre>
Client Transfer Client
r9-y3pll edhp-transfer czc4142wfz
~/foo <-> ~/foo <-> ~/foo
~/bar ~/bar
</pre>
So, I have two clients and one transfer server. Both clients have two local repositories ~/foo and ~/bar.
The transfer repository has only be configured to the ~/foo client repositories, but not to the ~/bar repositories.
But for some reason, the ~/foo repositories know about the ~/bar repositories (see the id's of the git-annex vicfg output for ~/foo repositories above) and keep uploading files to the transfer repository, even I did select keep the repositories separate on both hosts.
"""]]

10
doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_3_01fc26e443ea3a8a351174b45f25dc2a._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.176"
subject="comment 3"
date="2014-05-29T19:14:51Z"
content="""
Are you using XMPP?
There's no way for the foo repositories to learn about the bar repositories unless one of the foo repositories has a remote that is either one of the bar repositories, or that one of the bar repositories points to.
"""]]

14
doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_4_6e8f0889359bb2f3e3438658c9776f76._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmi0jblSiI4c5-EswqKw4PXkx5M4fuVvdk"
nickname="Henry"
subject="comment 4"
date="2014-05-29T20:10:15Z"
content="""
No, I haven't configured XMPP yet.
I just tried something else:
Within assistant I've switched to repository ~bar and then added another repository ~/foobar and again selected keep the repositories separate.
The result is, ~/bar knows (vicfg) about ~/foobar, but ~/foo doesn't. It seems to me, that when adding another local repository, the new repository gets known to the currently selected repository.
"""]]

10
doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_5_902fe9ff295453461b66d84463205fc3._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.176"
subject="comment 5"
date="2014-05-29T20:46:47Z"
content="""
Ok, reproduced that.
Webapp seems to be setting up the newly created repository's group and preferred content settings inside the current repository. The 2 repositories are not otherwise linked or sharing data in any way, so this the impact is limited to 2 lines that won't affect anything being committed to the git-annex branch, and to the newly created repository not defaulting to being in the client group or having the standard preferred content setting (which can easily be fixed with the webapp).
"""]]

12
doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_6_ce01656b191d2bb13a3ddc29794e1e7a._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmi0jblSiI4c5-EswqKw4PXkx5M4fuVvdk"
nickname="Henry"
subject="comment 6"
date="2014-06-11T16:31:09Z"
content="""
I've just installed 5.20140606 from sid and the problem is gone :-)
Now hoping that this or one of the next release will make it into wheezy backports ;-)
Thank you for your great work and support and sorry for my late feedback.
"""]]

28
doc/bugs/Assistant_dropping_from_backup_repo.mdwn
View file

@ -1,28 +0,0 @@
Setup:
* fresh install of Debian Wheezy with git-annex 4.20130227 pulled in from unstable
Steps:
* clone existing repository and activate assistant
* Have USB drive, U, with repository group `backup` and preferred content string `standard`
Expected:
* Assistant never ever tries to drop anything from U
Actual:
* Assistant immediately tries to drop files from U; fortunately I didn't have the USB drive plugged in
* Changing the preferred content string of U to `present or include=*` stops the dropping, but this was never required before
Additional information:
* The files that the Assistant started trying to drop were, I believe, the first (alphabetically) files in my repository to contain non-ascii characters in their file names (some French accented letters)
Thanks.
> The non-ascii characters are the giveaway: For 1 version, git-annex used
> a regex library that failed to ever match non-ascii characters. So it
> thought backup repos, which match "*" with a regex, wanted no such files.
> This is [[fixed|done]]. --[[Joey]]

8
doc/bugs/Assistant_dropping_from_backup_repo/comment_1_c13d86fb2541676ee4ca1446b99e0e68._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://edheil.wordpress.com/"
ip="173.162.44.162"
subject="comment 1"
date="2013-03-12T14:25:16Z"
content="""
This sounds very similar to [[http://git-annex.branchable.com/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/]]; my client was pulling in content prior to dropping it from a \"backup\" repo on a USB drive.
"""]]

31
doc/bugs/Assistant_from_standalone_5.20131230_64bit_crashes_on_startup.mdwn
View file

@ -1,31 +0,0 @@
The assistant from the standalone 64bit build crashes upon startup.
### Version information
[0 zerodogg@firefly annexed]$ git annex version
git-annex version: 5.20131230-g4aa88d8
build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus 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 webdav glacier hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 0 1 2 4
[0 zerodogg@firefly annexed]$ uname -a
Linux firefly 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[0 zerodogg@firefly annexed]$ cat /etc/fedora-release
Fedora release 20 (Heisenbug)
[0 zerodogg@firefly annexed]$
### Error
[0 zerodogg@firefly annexed]$ git annex webapp
Launching web browser on file:///home/zerodogg/Documents/annexed/.git/annex/webapp.html
(process:6045): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
libgcc_s.so.1 must be installed for pthread_cancel to work
error: git-annex died of signal 6
[134 zerodogg@firefly annexed]$ ls -l /usr/lib64/libgcc_s.so.1
lrwxrwxrwx. 1 root root 28 2013-12-18 10:54 /usr/lib64/libgcc_s.so.1 -> libgcc_s-4.8.2-20131212.so.1
[0 zerodogg@firefly annexed]$
> [[fixed|done]] --[[Joey]]

14
doc/bugs/Assistant_from_standalone_5.20131230_64bit_crashes_on_startup/comment_1_56befc288c40e062e086d93d26064342._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.227"
subject="comment 1"
date="2013-12-31T18:55:36Z"
content="""
You seem to show `git-annex version` being run without crashing, so it does not seem to crash on startup generally.
Also, this build of git-annex is not linked to libgcc at all.
Also, git-annex seems to start your web browser.
So, it seems more likely that your web browser is crashing than that git-annex is crashing. The web browser crash may be taking out git-annex in some way.
"""]]

24
doc/bugs/Assistant_from_standalone_5.20131230_64bit_crashes_on_startup/comment_2_107ab23eac98a168d2920bb88b4ec86f._comment
View file

@ -1,24 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.227"
subject="comment 2"
date="2013-12-31T19:11:16Z"
content="""
I've verified that git-annex runs the web browser in a cleaned up environment, that does not, for example, have the `LD_LIBRARY_PATH` used by the bundle set.
I checked this by making a ~/dumpenv script:
[[!format sh \"\"\"
#!/bin/sh
set
echo \"$@\"
\"\"\"]]
Then `chmod +x ~/dumpenv; git config web.browser ~/dumpenv` and `git annex webapp` to run it.
I did notice that it set `GCONV_PATH=''`, rather than unsetting that variable, and have made a commit fixing that. But I doubt that caused this problem.
The \"g_slice_set_config: assertion 'sys_page_size == 0\" seems to be a Mozilla bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=672671>, and does not seem to be related, probably firefox is printing that well before crashing.
It looks like libc can somehow demand-load libgcc_s.so, so I have force included that into the bundle. Don't know if that will help. Will be available in autobuilds in an hour.
"""]]

10
doc/bugs/Assistant_from_standalone_5.20131230_64bit_crashes_on_startup/comment_3_7707c47aacde425ca6149dd828dd27fb._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="EskildHustvedt"
ip="80.202.213.197"
subject="comment 3"
date="2014-01-01T02:36:47Z"
content="""
The browser doesn't crash, it stays up, though the git annex page disappears (replaced by the usual \"connection refused\" page from firefox) after a few seconds (ie. \"git annex webapp\" starts the browser, the git-annex page appears for a few seconds, and then it disappears as git-annex crashes, leaving the browser still running).
The latest daily build appears to work now though: git-annex version: 5.20140101-gf9e5218, so that seems to have done the trick.
"""]]

19
doc/bugs/Assistant_merge_loop.mdwn
View file

@ -1,19 +0,0 @@
The assistant appears to be in a merge loop with at least two of my repos. It's creating thousands of merge commits without any changes. One repository that contains around 600 files that change very very rarely now has 63528 commits.
Here's a screenshot from tig: [[https://ssl.zerodogg.org/~zerodogg/private/tmp/Skjermdump_fra_2014-07-05_07:09:22-2014-07-05.png]]
I can privately provide a copy of the git repo itself if needed.
Using the standalone build, 64bit, on ArchLinux, Fedora 20 and Ubuntu 14.04.
$ git annex version
git-annex version: 5.20140610-g5ec8bcf
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
> [[fixed|done]]. Note that 5.20140708 contained an incomplete fix for this
> bug. --[[Joey]]

8
doc/bugs/Assistant_merge_loop/comment_10_8fe176691f0f61c15085d3c38f0ea50f._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 10"
date="2014-07-16T20:32:57Z"
content="""
I have two computers with Debian testing (5.20140529) that aren't having the issue, and one with Debian Sid (5.20140709) that is still creating the empty merge commits
"""]]

10
doc/bugs/Assistant_merge_loop/comment_11_6e3a78327c0b813415ebf85e298813d4._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 11"
date="2014-07-16T20:36:32Z"
content="""
Has the assistant been restarted since git-annex was upgraded to the fixed version?
Can you post a debug.log?
"""]]

8
doc/bugs/Assistant_merge_loop/comment_12_fc5ceb09cc358521b32877fe4b0fb821._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="EskildHustvedt"
ip="80.202.103.55"
subject="comment 12"
date="2014-07-19T06:22:57Z"
content="""
This issue has been resolved for me. No new empty merges since 2014-07-12.
"""]]

8
doc/bugs/Assistant_merge_loop/comment_14_46bddc2451da3bf5029248198cf02dcd._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 14"
date="2014-09-08T07:27:46Z"
content="""
Still experiencing this bug in Debian testing (5.20140717) and Debian sid (5.20140831)
"""]]

10
doc/bugs/Assistant_merge_loop/comment_14_89947f4af19ceae36fbe0a69aa10df25._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 14"
date="2014-11-09T22:56:31Z"
content="""
I have 3 computers syncing through a private github repo (with annex-ignore = true) and a box account for transferring files. The computers are up to date debian:testing:amd64, debian:testing:i386 and debian:sid:amd64.
I'm getting lots of empty commits with the text \"merge refs/remotes/github/synced/master\". I would really like to help in debugging this issue if possible.
"""]]

54
doc/bugs/Assistant_merge_loop/comment_15_494f55419f131495a7994afe2a0e9bc3._comment
View file

@ -1,54 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 15"
date="2015-02-18T12:39:04Z"
content="""
This is happening in in a repo shared by two computers using the webapp with version 5.20141125. All are empty commits.
* 23da33e - (7 minutes ago) merge refs/remotes/bitbucket/synced/master (HEAD, bitbucket/synced/master, annex/direct/master)
* 7bd23db - (67 minutes ago) merge refs/remotes/bitbucket/synced/master
* d2f5c6b - (2 hours ago) merge refs/remotes/bitbucket/synced/master
* 05c0448 - (12 hours ago) merge refs/remotes/bitbucket/synced/master
* 5c370aa - (19 hours ago) merge refs/remotes/bitbucket/synced/master
* c6d7be4 - (20 hours ago) merge refs/remotes/bitbucket/synced/master
* 507a6c7 - (21 hours ago) merge refs/remotes/bitbucket/synced/master
* 6932fec - (22 hours ago) merge refs/remotes/bitbucket/synced/master
* cc0efa1 - (23 hours ago) merge refs/remotes/bitbucket/synced/master
* 12a7b8f - (24 hours ago) merge refs/remotes/bitbucket/synced/master
* 49a3f2c - (25 hours ago) merge refs/remotes/bitbucket/synced/master
* 6611612 - (26 hours ago) merge refs/remotes/bitbucket/synced/master
* 303895c - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 3f8c96b - (2 days ago) merge refs/remotes/bitbucket/synced/master
* f283e20 - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 96b920e - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 2c88b50 - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 5f6643b - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 7a2f5ff - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 3bdb942 - (2 days ago) merge refs/remotes/bitbucket/synced/master
* d24de2b - (2 days ago) merge refs/remotes/bitbucket/synced/master
* b29d45e - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 871adb7 - (2 days ago) merge refs/remotes/bitbucket/synced/master
|\
* | 4138b01 - (2 days ago) merge refs/remotes/bitbucket/synced/master
|/
* c754adc - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 587a56a - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 2d257fd - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 23018bf - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 9f202b7 - (2 days ago) merge refs/remotes/bitbucket/synced/master
* bdd40f4 - (2 days ago) merge refs/remotes/bitbucket/synced/master
* 146b1a5 - (4 days ago) merge refs/remotes/bitbucket/synced/master (bitbucket/master)
|\
* | 3886b4a - (4 days ago) merge refs/remotes/github/synced/master
* | 5714860 - (4 days ago) merge refs/remotes/github/synced/master
* | 64325a0 - (4 days ago) merge refs/remotes/github/synced/master
* | f1b49e6 - (5 days ago) merge refs/remotes/github/synced/master
* | 17330c8 - (5 days ago) merge refs/remotes/github/synced/master
|/
* 54f9a8b - (6 days ago) (synced/master, master)
* ceb8133 - (6 days ago)
* f36ae3b - (6 days ago)
* 6acdf4c - (6 days ago)
"""]]

8
doc/bugs/Assistant_merge_loop/comment_16_cb57e3a438c115b59e4504d80e6f8273._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="happening every hour"
date="2015-03-18T17:35:09Z"
content="""
I've noticed that when this happens it occurs every hour, so it has to be related to something the assistant is doing every hour.
"""]]

14
doc/bugs/Assistant_merge_loop/comment_1_ccf46511b924f86b488dba25060baa06._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.55"
subject="comment 1"
date="2014-07-05T20:34:39Z"
content="""
I am seeing some evidence of this in my own family's repo, where one node updated to 5.20140613 and started making series of empty commits with message \"merge refs/heads/synced/master\" and only 1 parent (so not really a merge).
Quite likely [[!commit d6711800ad261fb4c37fc361bc84918d1e296bc4]] is at fault. Probably the fastForwardable check isn't quite right.
This should only affect direct mode repositories. When only one node has the problem, it won't be bad, but if multiple nodes are doing this, their repos never converge and keep growing.
Hmm, I think I have partially reproduced it with 2 direct mode repos, each having the other as a remote. `git annex sync` repeatedly in each does not add unncessary commits, but running the assistant in each does. In this particular case, it manages to converge eventually after several commits.
"""]]

12
doc/bugs/Assistant_merge_loop/comment_2_afcbf3f8575e1a967c79693b94ef055c._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.55"
subject="comment 2"
date="2014-07-05T21:17:17Z"
content="""
Well, it looks like this is as simple as the assistant trying to merge refs/remotes/$foo/synced/master into the current branch, when that ref is behind or the same as the current branch. Nothing to merge, so it does some pointless work and then the fastForwardable check runs -- and that check looks for refs between the \"old\" and \"new\" refs. Since the \"new\" is behind the \"old\", there are no such commits, and the unnecessary empty commit results.
The reason only the assistant is affected is because `git-annex sync` already checked Git.Branch.changed before trying to do any merging, which avoids the problem.
Fix committed.
"""]]

62
doc/bugs/Assistant_merge_loop/comment_3_07341221b2839fdc1c43634e011451d2._comment
View file

@ -1,62 +0,0 @@
[[!comment format=mdwn
username="EskildHustvedt"
ip="80.202.103.55"
subject="comment 3"
date="2014-07-08T08:13:40Z"
content="""
I'm still seeing this problem in 5.20140707-g923b436
[0 zerodogg@firefly annexed]$ git annex version
git-annex version: 5.20140707-g923b436
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
[0 zerodogg@firefly annexed]$ git graph | head -n20
* d4bf68f - (HEAD, annex/direct/master) merge refs/remotes/serenity/synced/master (3 minutes ago) <Eskild Hustvedt>
|\
* | d03f280 - merge refs/remotes/browncoats/synced/master (3 minutes ago) <Eskild Hustvedt>
|/
* e6863b8 - (serenity/synced/master, browncoats/synced/master) merge refs/remotes/serenity/synced/master (3 minutes ago) <Eskild Hustvedt>
|\
* \ 616d985 - merge refs/remotes/browncoats/synced/master (3 minutes ago) <Eskild Hustvedt>
|\ \
| |/
* | 3b39706 - merge refs/remotes/serenity/synced/master (3 minutes ago) <Eskild Hustvedt>
|\ \
| |/
* | 6d354cc - merge refs/remotes/browncoats/synced/master (4 minutes ago) <Eskild Hustvedt>
|\ \
| |/
* | 710c3c1 - merge refs/remotes/serenity/synced/master (4 minutes ago) <Eskild Hustvedt>
|\ \
| |/
* | 763930f - merge refs/remotes/browncoats/synced/master (4 minutes ago) <Eskild Hustvedt>
|/
[0 zerodogg@firefly annexed]$ git annex assistant --stop
[0 zerodogg@firefly annexed]$ git annex assistant
[0 zerodogg@firefly annexed]$ git graph | head -n20
* 947f1a2 - (HEAD, annex/direct/master) merge refs/remotes/serenity/synced/master (15 seconds ago) <Eskild Hustvedt>
|\
* | 19c6043 - merge refs/remotes/browncoats/synced/master (18 seconds ago) <Eskild Hustvedt>
|/
* b453741 - (serenity/synced/master, browncoats/synced/master) merge refs/remotes/serenity/synced/master (18 seconds ago) <Eskild Hustvedt>
|\
* \ 6baaebd - merge refs/remotes/browncoats/synced/master (18 seconds ago) <Eskild Hustvedt>
|\ \
| |/
* | 03e4fa2 - merge refs/remotes/serenity/synced/master (24 seconds ago) <Eskild Hustvedt>
|\ \
| |/
* | 33302d8 - merge refs/remotes/browncoats/synced/master (24 seconds ago) <Eskild Hustvedt>
|\ \
| |/
* | d4bf68f - merge refs/remotes/serenity/synced/master (4 minutes ago) <Eskild Hustvedt>
|\ \
| |/
* | d03f280 - merge refs/remotes/browncoats/synced/master (4 minutes ago) <Eskild Hustvedt>
|/
[0 zerodogg@firefly annexed]$
"""]]

8
doc/bugs/Assistant_merge_loop/comment_4_7ae215b478843d2a8c705cac385fcf22._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="EskildHustvedt"
ip="80.202.103.55"
subject="comment 4"
date="2014-07-09T00:24:36Z"
content="""
As far as I can see in my repo, the empty merges started on 2014-05-27, but then appear to resolve themselves after 40-50 commits on that day. They reappear again on 2014-06-03, and appears to have kept going daily ever since.
"""]]

8
doc/bugs/Assistant_merge_loop/comment_5_11873461f093a266f0bb7e129bc21cde._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.55"
subject="comment 5"
date="2014-07-09T19:00:35Z"
content="""
I have confirmed this is still happening, though I had certianly thought I had reproduced and fixed it.
"""]]

80
doc/bugs/Assistant_merge_loop/comment_6_e7b6ecdd7e2b0222ea0baa0ed770e66d._comment
View file

@ -1,80 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmN5jDf53oRJZsTo8Ahj2uXzCzq6HcvEro"
nickname="Gregory"
subject="confirmed?"
date="2014-07-15T01:29:00Z"
content="""
I seem to be getting this behavior, in tandem with the [bad merge commit deleting all files](http://git-annex.branchable.com/bugs/bad_merge_commit_deleting_all_files/) on
git-annex version: 5.20140709-gf15d2aa
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: unknown
supported repository version: 5
upgrade supported from repository versions: 0 1 2 4
Here is my log over the past couple weeks when I basically made no changes to the filesystem.
git log --oneline --decorate --color --graph
<pre>
* b304ad7 (HEAD, origin/synced/master, origin/master, origin/HEAD, master)
* 568cf6c merge refs/remotes/diskb/synced/master
* 5e426d0 merge refs/remotes/diskb/synced/master
* b2fa076 merge refs/remotes/diskb/synced/master
* b66a37d merge refs/remotes/diskb/synced/master
|\
* | 910cba5 merge refs/remotes/diskb/synced/master
|/
* 60736c3 merge refs/remotes/diskb/synced/master
* a957439 merge refs/remotes/diskb/synced/master
|\
* \ 5c135c0 merge refs/remotes/diskb/synced/master
|\ \
| |/
* | 52d8b66 merge refs/heads/synced/master
|\ \
* | | d77f3a2 merge refs/remotes/diskb/synced/master
| |/
|/|
* | 03bb56a merge refs/remotes/diskb/synced/master
|\ \
* \ \ bb000db merge refs/heads/synced/master
|\ \ \
| |/ /
|/| /
| |/
* | 3bc8520 merge refs/heads/synced/master
|/
* 1c3ee7e
* d3b096a merge refs/remotes/diskb/synced/master
|\
* \ 0fa0f6d merge refs/heads/synced/master
|\ \
| |/
* | 173592c merge refs/remotes/diskb/synced/master
|\ \
| |/
* | 3dd8086 merge refs/remotes/diskb/synced/master
|\ \
| |/
* | 68be2a1 merge refs/heads/synced/master
|\ \
| |/
* | bb304f4 merge refs/remotes/diskb/synced/master
|\ \
| |/
|/|
* | 1c9a2cd
* | 298b362 merge refs/heads/synced/master
|/
* 4c23257 merge refs/remotes/diskb/synced/master
|\
* | b709997 merge refs/remotes/diskb/synced/master
|/
* 215f061 merge refs/remotes/diskb/synced/master
|\
* \ e0f75b4 merge refs/heads/synced/master
</pre>
"""]]

8
doc/bugs/Assistant_merge_loop/comment_7_7717d074611943b831f00ad10918b515._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 7"
date="2014-07-15T19:15:13Z"
content="""
This bug and the other one are fixed in 5.20140709. I assume that your `git log` dates from an earlier version.
"""]]

8
doc/bugs/Assistant_merge_loop/comment_8_5ce91ac76498539ada344d1639984302._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 8"
date="2014-07-16T13:42:16Z"
content="""
I'm still having this issue in 5.20140709
"""]]

10
doc/bugs/Assistant_merge_loop/comment_9_b09a5eaa2588559e19b3549bd3c8b496._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 9"
date="2014-07-16T18:08:26Z"
content="""
Are you sure that you have upgraded git-annex on every machine that uses that repository? You could have one old un-upgraded one still causing commits that would of course be visible on the rest.
Also, what version exactly does `git-annex version` show?
"""]]

1305
doc/bugs/Assistant_removed_all_references_to_files.mdwn
View file

File diff suppressed because it is too large Load diff

14
doc/bugs/Assistant_removed_all_references_to_files/comment_1_1f7da19ea99c263d56db6331d4b1e346._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.132"
subject="comment 1"
date="2014-09-11T17:45:31Z"
content="""
Unfortunately, the old version of git-annex you have been using is exactly the wrong version, so you ran into this horrible bug, which is fixed in newer versions.
<http://git-annex.branchable.com/bugs/bad_merge_commit_deleting_all_files/>
That page has details, including instructions on how to recover your data.
I hope that you were not using that old version because it's included in some distribution somewhere still?
"""]]

10
doc/bugs/Assistant_removed_all_references_to_files/comment_2_0dbb8df1ad267d1c502646a7131a99f1._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="https://andrew.aylett.co.uk/"
nickname="andrew"
subject="comment 2"
date="2014-09-11T19:03:07Z"
content="""
Unfortunately, that bug involves merges while I'm seeing regular commits so I don't think it's identical.
As to why I'm on that version, it appears that the updater and something in my environment conspired against me, leaving an old version in my path. I'll fix that now and let you know if I see the issue again.
"""]]

44
doc/bugs/Bloom_filter_capacity_too_large_to_represent.mdwn
View file

@ -1,44 +0,0 @@
### Please describe the problem.
When running git-annex info I get an error when it tries to show the bloom filter size
### What steps will reproduce the problem?
git-annex info in my Photos repo
### What version of git-annex are you using? On what operating system?
[[!format sh """
$ git-annex version
git-annex version: 5.20140814-g9b89b5c
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
"""]]
### Please provide any additional information below.
[[!format sh """
$ git-annex info
repository mode: direct
trusted repositories: 2
c0e4106e-2631-11e2-9749-1bfa37a61069 -- [rose]
ca735977-973c-44bc-9257-915b2c875e39 -- synology [here]
semitrusted repositories: 3
00000000-0000-0000-0000-000000000001 -- web
7e5c0010-2634-4a5e-bc7b-6fea84b8b947 -- [glacier]
d7e01abc-d74b-40e2-8607-3d41ce8bc4bd -- seagate3
untrusted repositories: 1
c1fe5922-43f1-11e2-b146-33530f7fa6cc -- x200s
transfers in progress: none
available local disk space: 928.4 gigabytes (+1 megabyte reserved)
local annex keys: 34758
local annex size: 186.78 gigabytes
annexed files in working tree: 35300
size of annexed files in working tree: 193.76 gigabytes
bloom filter size: git-annex: Data.BloomFilter.Util.suggestSizing: capacity too large to represent
"""]]
> I've worked around this problem in the arm autobuilder (only build
> affected), so [[done]] --[[Joey]]

14
doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_1_43c824a3b843faa2377bfd78158c72fe._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.132"
subject="comment 1"
date="2014-09-12T16:03:09Z"
content="""
It seems you must have tweaked the annex.bloomcapacity and/or annex.bloomaccuracy settings, probably to some quite large values.
For example capacity of 50000000 and accuracy of 10000000000 will fail this way.
This happens when it runs out of Double floating point precision to calculate the requested bloom filter size. I think that a bloom filter can be built that has this capacity/accuracy, it's just that Data.BloomFilter.Easy.safeSuggestSizing falls over trying to find the bloom filter size. Also, such a bloom filter may use rather a lot of memory..
"""]]

12
doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.132"
subject="comment 2"
date="2014-09-12T16:34:56Z"
content="""
However, in Greg's case he had no such configuration. Instead, I think something is broken with the use of floating point or bit math that bloomfilter uses, on the NAS where he's using git-annex.
I have made git-annex not crash when this happens, just show a warning and fall back to a reasonable default bloom filter size. If the problem is with the bit math, then the bloom filter may not work either, which would probably show up as false negatives, so `git annex unused` not finding things that are unused.
I need to update the armel build with this so Greg can test it..
"""]]

12
doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.132"
subject="comment 3"
date="2014-09-12T16:38:47Z"
content="""
I have reproduced the bug, using the standalone build on an arm box (turtle).
On the same box, the debian git-annex build works ok.
Suggests to me the problem is related to the cross-compiling method used for the standalone arm build.
"""]]

12
doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.132"
subject="turns out to be an upstream bug already filed"
date="2014-09-12T17:46:23Z"
content="""
It seems that this is a bug on bloomfilter 2.0.0.0 on armel generally. It's also preventing this newer version from building on armel currently:
<http://bugs.debian.org/756801>
The git-annex standalone arm autobuilder installed it with cabal, so ended up with the newer, broken version.
"""]]

12
doc/bugs/Box.com_ReposnseTimeout.mdwn
View file

@ -1,12 +0,0 @@
Box.com is still not working properly in version 5.20140227 (I'm using it in Debian testing and sid).
I created a new clean repository and configured Box.com (everything from the webapp). At first it seamed to work, files where being uploaded and the logs where fine. Then I created another clean repository in another computer and started syncing. Downloading files worked properly, but when trying to upload a file from the second computer I got this:
copy my_file (gpg) (checking box.com...) (to box.com...)
100% 0.0 B/s 0sResponseTimeout
failed
git-annex: copy: 1 failed
When I got back to the first computer I saw the same behavior, uploading files wasn't working any more.
> [[duplicate|done]] --[[Joey]]

20
doc/bugs/Box.com_ReposnseTimeout/comment_1_4ac0bf61fb4b2ac335a8a1f29e9d882d._comment
View file

@ -1,20 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 1"
date="2014-03-01T11:23:05Z"
content="""
I have another error log:
29% 653.2KB/s 1m49sgpg: [stdout]: write error: Broken pipe
gpg: DBG: deflate: iobuf_write failed
gpg: build_packet failed: file write error
gpg: [stdout]: write error: Broken pipe
gpg: iobuf_flush failed on close: file write error
gpg: symmetric encryption of `[stdin]' failed: file write error
ResponseTimeout
git-annex: fd:96: hPutBuf: resource vanished (Broken pipe)
ResponseTimeout
Some files (very few) are being uploaded properly, so the error is not always reproducible.
"""]]

10
doc/bugs/Box.com_ReposnseTimeout/comment_2_29d8a9fa8d385a08fa70337baaba462c._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.146"
subject="comment 2"
date="2014-03-05T03:15:43Z"
content="""
I suspect this is just box.com's webdav support being flakey.
It's possible there's a timeout that's too aggressive in the http library. I have had some trouble with that when trying to use DAV over a slow connection.
"""]]

8
doc/bugs/Box.com_ReposnseTimeout/comment_3_b73450b3a9728ac6f34f0e63255f6fa9._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 3"
date="2014-03-05T08:10:25Z"
content="""
My connection is pretty fast, I've just copied a 77MB folder through Box's webdav with my file manager in ~90sec and I have never seen a timeout when using my file manager, all uploads finish properly.
"""]]

9
doc/bugs/Box.com_ReposnseTimeout/comment_4_0bd9eb5947a21d0657e79cf276923bb5._comment
View file

@ -1,9 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.146"
subject="comment 4"
date="2014-03-05T17:11:40Z"
content="""
Previous bug report about this with much more information, please do any followup there:
[[bugs/box.com_never_stops_syncing.]]
"""]]

20
doc/bugs/Bug_Report_doesn__39__t_work.mdwn
View file

@ -1,20 +0,0 @@
### Please describe the problem.
Bug Report doesn't work
### 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.
"""]]
[[fixed|done]] --[[Joey]]

39
doc/bugs/Build_error_when_S3_is_disabled.mdwn
View file

@ -1,39 +0,0 @@
With release 5.20141203, I'm getting the following build error.
Remote/Helper/AWS.hs:15:18:
Could not find module ‘Aws’
Use -v to see a list of the files searched for.
Remote/Helper/AWS.hs:16:18:
Could not find module ‘Aws.S3’
Use -v to see a list of the files searched for.
I'm installing dependencies with cabal but have disabled S3 support
('-f-S3'). This setup has worked for previous releases (I'm on a machine running Arch Linux).
_features=(-f-Android
-f-Assistant
-fDbus
-fDNS
-fInotify
-fPairing
-fProduction
-f-S3
-fTestSuite
-fTDFA
-f-Webapp
-f-WebDAV
-fXMPP
-fFeed
-fQuvi
-fCryptoHash)
cabal update
cabal install c2hs
cabal install --user --force-reinstalls --only-dependencies "${_features[@]}"
cabal configure "${_features[@]}"
make
> [[fixed|done]] --[[Joey]]

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

@ -1,287 +0,0 @@
### 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
View file

@ -1,8 +0,0 @@
[[!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
View file

@ -1,8 +0,0 @@
[[!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.
"""]]

46
doc/bugs/Build_fails_when_no_wget_avalible.mdwn
View file

@ -1,46 +0,0 @@
### Please describe the problem.
When trying to build git-annex 5.21050113 in a clean cabal sandbox on OSX and not having wget avalible, breaks the configure step of the build. See excerpt of build log below.
I am not sure if it is a bug or not, from the debian dependencies it seems that wget is required, but from reading various pieces of the documentation it seems to only be recommended. Installing wget makes it build.
### What steps will reproduce the problem?
### What version of git-annex are you using? On what operating system?
5.20150113 on OSX Yosemite.
### Please provide any additional information below.
[[!format sh """
checking version...fatal: Not a git repository (or any of the parent directories): .git
5.20150113
checking UPGRADE_LOCATION... not available
checking git... yes
checking git version... 2.2.1
checking cp -a... yes
checking cp -p... yes
checking cp --preserve=timestamps... no
checking cp --reflink=auto... no
checking xargs -0... yes
checking rsync... yes
checking curl... yes
checking wget... no
checking wget supports -q --show-progress...setup: wget: does not exist
cabal: Error: some packages failed to install:
git-annex-5.20150113 failed during the configure step. The exception was:
ExitFailure 1
# End of transcript or log.
"""]]
-- Carl
> wget is not intended to be a hard build dependency. The Debian package
> should always be built with wget, so it's a build-dependency there.
>
> I've fixed the configure script to not crash in this situation.
> [[done]]. --[[Joey]]

10
doc/bugs/Build_fails_when_no_wget_avalible/comment_1_c40db66d48d69d03847d73154faf3f59._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
nickname="Carl"
subject="Thanks and question"
date="2015-01-16T20:14:32Z"
content="""
Thanks for the quick fix.
Is there any advantage in using wget over curl, for git-annex (when it comes to progress bars etc or are they just as good?
"""]]

7
doc/bugs/Build_fails_when_no_wget_avalible/comment_2_f98ce0d40c60ea37f6174117bb7cef9f._comment
View file

@ -1,7 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
subject="comment 2"
date="2015-01-16T20:38:57Z"
content="""
git-annex defaults to wget when both are available, but curl works equally well.
"""]]

45
doc/bugs/Build_failure_at_commit_1efe4f3.mdwn
View file

@ -1,45 +0,0 @@
Applying this
<pre>
laplace:git-annex jtang$ git diff
diff --git a/Assistant/WebApp/Configurators.hs b/Assistant/WebApp/Configurators.hs
index b9630b1..bf36e59 100644
--- a/Assistant/WebApp/Configurators.hs
+++ b/Assistant/WebApp/Configurators.hs
@@ -101,7 +101,7 @@ checkRepositoryPath p = do
-
- If run in another directory, the user probably wants to put it there. -}
defaultRepositoryPath :: Bool -> IO FilePath
-defaultRepositoryPath firstrun = do
+defaultRepositoryPath firstRun = do
cwd <- liftIO $ getCurrentDirectory
home <- myHomeDir
if home == cwd && firstRun
</pre>
Causes this to occur,
<pre>
Assistant/WebApp/Configurators.hs:114:17:
Couldn't match expected type `Control.Monad.Trans.RWS.Lazy.RWST
(Maybe (Env, FileEnv), WebApp, [Yesod.Form.Types.Lang])
Enctype
Ints
(GHandler WebApp WebApp)
t0'
with actual type `Text'
Expected type: String
-> Control.Monad.Trans.RWS.Lazy.RWST
(Maybe (Env, FileEnv), WebApp, [Yesod.Form.Types.Lang])
Enctype
Ints
(GHandler WebApp WebApp)
t0
Actual type: String -> Text
In the first argument of `(.)', namely `T.pack'
In the first argument of `(<$>)', namely
`T.pack . addTrailingPathSeparator'
make: *** [git-annex] Error 1
</pre>
> [[fixed|done]] --[[Joey]]

27
doc/bugs/Build_failures_with_7.10.mdwn
View file

@ -1,27 +0,0 @@
### Please describe the problem.
git-annex fails to build in the NixOS builder
### What steps will reproduce the problem?
cabal build
### What version of git-annex are you using? On what operating system?
5.20150812
### Please provide any additional information below.
[The build log](http://hydra.cryp.to/build/1099681/nixlog/1/raw) has a full transcript of the build from one of the build machines, though I have reproduced this locally.
The pertinent bit of the log (which is *not* at the end, though I think that's just a capture-both-stderr-and-stdin thing, since it was at the end when I repro'd it:
[[!format sh """
Assistant/WebApp/Types.hs:39:1: ‘WebApp’ is not in scope at a reify
"""]]
If I'm reading things correctly (you can do some diffing of the inputs from [the page for the build](http://hydra.cryp.to/build/1099681)), I'm going to guess that it was the upgrade to yesod-1.4.14.
I'll continue to look into it, but it would seem to touch on TH and Yesod stuff with which I am largely unfamiliar.
> Fixed with mdorman's patch, [[done]] (will push a release in a day or 2) --[[Joey]]

8
doc/bugs/Build_failures_with_7.10/comment_1_3ef2d6bcc66d57140777e6262467a40a._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="mdorman@ddbe259e8f6e03351350a04515c67f7957abf736"
nickname="mdorman"
subject="In fact, the problem *is* the yesod update"
date="2015-08-22T10:37:20Z"
content="""
Per https://github.com/yesodweb/yesod/issues/1059, it would appear that all you would need to do is reorder some declarations---though that was my first thought and I thought I tried it and it failed, perhaps I got something else wrong in doing so. I'll report back when I have more info.
"""]]

8
doc/bugs/Build_failures_with_7.10/comment_2_d3b68bbf83d9e83f93fc10a588e127f5._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="mdorman@ddbe259e8f6e03351350a04515c67f7957abf736"
nickname="mdorman"
subject="Fix for this issue"
date="2015-08-23T17:26:34Z"
content="""
[My yesod-core-fix branch](https://github.com/mdorman/git-annex/tree/yesod-core-fix) has as its HEAD the (super-simplistic) fix for this issue.
"""]]

20
doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them.mdwn
View file

@ -1,20 +0,0 @@
### Please describe the problem.
Some filenames in doc have a colon `(:)` in them and it seems it's not allowed on Windows.
There's no hurry with this since I was able to clone the repo by doing a fork on Github and removing `doc/`.
### What steps will reproduce the problem?
[[!format sh """
D:\tmp> git clone git://git-annex.branchable.com/
Cloning into 'git-annex.branchable.com'...
remote: Counting objects: 72064, done.
remote: Compressing objects: 100% (18759/18759), done.
remote: Total 72064 (delta 52959), reused 72032 (delta 52944)
Receiving objects: 100% (72064/72064), 18.05 MiB | 2.39 MiB/s, done.
Resolving deltas: 100% (52959/52959), done.
fatal: cannot create directory at 'doc/bugs/3.20121112:_build_error_in_assistant': Invalid argument
D:\tmp>
"""]]
> [[wontfix|done]] --[[Joey]]

12
doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/comment_1_5fc1347f4bcc13c9f8dbc5ecd4847fc7._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 1"
date="2013-06-10T16:22:00Z"
content="""
IMHO this is a bug in msysgit. It should support git repositories containing any legal filenames.
Luckily, there is another git for Windows that does. It comes with Cygwin. You need Cygwin to build git-annex on Windows, anyway.
So, I do not plan to do anything in git-annex to address this.
"""]]

8
doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/comment_2_38696178e658d1d32deec37dbea66a3d._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnXm4VZC7ekVOXHGKjBObojiHB2E1kmMgA"
nickname="Leonardo"
subject="comment 2"
date="2013-08-11T21:21:56Z"
content="""
Files with colon are not allowed in windows, they are interpreted as absolute path. The fact that you can checkout them \"fine\" (actually, their name get truncated to whatever was before the colon) using cygwin's GIT implementation is to be interpreted as a bug in cygwin's GIT in my opinion. I suggest renaming them before cygwin get fixed.
"""]]

12
doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/comment_3_f34d996827f5e7662bec409cbcce961b._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.0.63"
subject="comment 3"
date="2013-08-24T19:27:57Z"
content="""
Leonardo, you made me boot up my windows machine just to check if cygwin git truncated files at the colon. It does not.
AFAIK, Cygwin transliterates colons to another unicode character or something like that. I would be highly surprised if the Cygwin people consider this feature to be a bug.
Since you need Cygwin to build git-annex on Windows anyway (though not to run it!), this remains WONTFIX.
"""]]

62
doc/bugs/Can__39__t_get_content_from_S3_with_s3-aws_library.mdwn
View file

@ -1,62 +0,0 @@
### Please describe the problem.
I have lots of content stored in Amazon S3. Using git-annex from before commit 911ba8d972e4e7b151385d30c198598e1a0dfaca, I am able to ``git annex get`` from S3 and files are downloaded.
Using a more recent version (eg that commit, or the current master, or release 20150409), I am unable to download the content.
I'm not sure if my repo or remote is somehow misconfigured, or if there's something else going on here.
--Walter
### What steps will reproduce the problem?
Use a version of git-annex with s3-aws
### What version of git-annex are you using? On what operating system?
Debian, versions as above
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
git annex get . --from cloud --debug
[2015-04-19 22:23:37 BST] read: git ["--git-dir=../../../.git","--work-tree=../../..","--literal-pathspecs","show-ref","git-annex"]
[2015-04-19 22:23:37 BST] read: git ["--git-dir=../../../.git","--work-tree=../../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
[2015-04-19 22:23:37 BST] read: git ["--git-dir=../../../.git","--work-tree=../../..","--literal-pathspecs","log","refs/heads/git-annex..a51a912223d3d86f19762e387e3eae23c3024d2c","-n1","--pretty=%H"]
[2015-04-19 22:23:37 BST] chat: git ["--git-dir=../../../.git","--work-tree=../../..","--literal-pathspecs","cat-file","--batch"]
[2015-04-19 22:23:37 BST] read: git ["--git-dir=../../../.git","--work-tree=../../..","--literal-pathspecs","ls-files","--cached","-z","--","."]
get IMG_7079.JPG (from cloud...) [2015-04-19 22:23:37 BST] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
failed
get IMG_7080.JPG (from cloud...)
failed
git annex info cloud
remote: cloud
description: [cloud]
uuid: be992080-b1db-11e1-8f79-1b10bb4092ef
trust: semitrusted
cost: 250.0
type: S3
creds: embedded in git repository (gpg encrypted)
bucket: ffffffffffffffffffffffffff
partsize: unlimited
encryption: encrypted (to gpg keys: FFFFFFFFFFFF) (hybrid mode)
chunking: none
remote annex keys: 0
remote annex size: 0 bytes
git annex fsck -f cloud
fsck IMG_6876.JPG (checking cloud...) (StatusCodeException (Status {statusCode = 301, statusMessage = "Moved Permanently"}) [("x-amz-request-id","275ADF5B1B77D514"),("x-amz-id-2","flWGBHOZYEZAohygAzBIZAYd7nBGkm3HpSMfJuhgRp3txXx20yJz7S4yRlNLwCs1cHUMyWc9JbA="),("Content-Type","application/xml"),("Transfer-Encoding","chunked"),("Date","Sun, 19 Apr 2015 22:23:15 GMT"),("Server","AmazonS3")] (CJ {expose = []})) failed
# End of transcript or log.
"""]]
> I think I've made all the git-annex improvements that are going to come
> from this bug report. There's still the open bug on the aws library to better
> follow these redirects. Anyway, I think it makes sense to call this
> bug [[done]]. --[[Joey]]

21
doc/bugs/Can__39__t_get_content_from_S3_with_s3-aws_library/comment_11_f30f86482d48ff8d658a4ee74d4c8586._comment
View file

@ -1,21 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
nickname="Walter"
subject="comment 11"
date="2015-04-23T20:29:17Z"
content="""
I think I may have not been entirely clear previously; the file \"GPGHMACSHA1--417830f4c50a2887674917abd2c18c522853255a\" was not in the bucket, but git annex said it was. That is, the upload failed, but git annex thought it succeeded.
Similarly, all the files I recently added we not actually uploaded, but git annex thought they were. I ``git annex fsck``ed them, which was fast because it failed to download any of them. fscking other files is slow, as it has to download them of course.
Maybe to reproduce this, you could try:
[[!format sh \"\"\"
git annex initremote cloud datacenter=ap-southeast-1
git annex add file
git annex copy --to cloud file
git annex drop file
git annex enableremote could dataceter=ap-southeast-2
git annex get file
\"\"\"]]
"""]]

32
doc/bugs/Can__39__t_get_content_from_S3_with_s3-aws_library/comment_12_1ba3271a62b8ce8088c67e4741ecf385._comment
View file

@ -1,32 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""fully reproduced"""
date="2015-04-24T16:33:02Z"
content="""
I was able to fully reproduce this bug! I installed the old version of
git-annex that used the S3 library, and made a remote:
joey@darkstar:~/tmp/rrold>git annex initremote S3 type=S3 encryption=none datacenter=ap-southeast-1
initremote S3 (checking bucket...) (creating bucket in ap-southeast-1...) ok
joey@darkstar:~/tmp/rrold>git annex move me --to S3
move me (checking S3...) (to S3...)
ok
Retrieval then failed using current git-annex.
Also, a remote made with the old git-annex with datacenter=ap-southeast-2
fails with the new git-annex.
Hypothesis: Either the new or the old S3 library must be confusing between
ap-southeast-1/2. My guess is the old library was just creating and using
buckets in the wrong place, at least when told to use ap-southeast-*.
---
I cannot reproduce anything about "the upload failed, but git annex thought it succeeded",
nor do I see any indications in comments 11 or 12 that git-annex's location
log is failing in any way. The sequence of commands in comment 11 ends with the
get failing, as it should, since the remote has been switched to a different
datacenter. I don't understand what you're seeing in comment #12 at all;
it seems to just show it getting a file successfully.
"""]]

61
doc/bugs/Can__39__t_get_content_from_S3_with_s3-aws_library/comment_12_a208344e552bfe6b8d9f409560c9a515._comment
View file

@ -1,61 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
nickname="Walter"
subject="comment 12"
date="2015-04-23T21:03:36Z"
content="""
For completeness, here is the output when I get a file that *is* properly in the bucket (and you could use for any further testing you need to do).
While this may have been caused by some misconfiguration on my part (though I'm not entirely sure how that could happen, strangely it would be easier to muck up now enableremote doesn't create a new bucket), I feel the potential harm here (the location information being wrong) is quite serious. (I'm sure this point does not escape you).
[[!format sh \"\"\"
>git annex get --force --debug file.jpg --from cloud
[2015-04-23 21:52:41 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
[2015-04-23 21:52:41 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
[2015-04-23 21:52:41 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..cb0f954d09e3ea28171434e0e7499c84d1722fce\",\"-n1\",\"--pretty=%H\"]
[2015-04-23 21:52:41 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..573f75e01681e9bf2b513bc85e18fc250298a4d3\",\"-n1\",\"--pretty=%H\"]
[2015-04-23 21:52:41 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
[2015-04-23 21:52:41 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"file.jpg\"]
[2015-04-23 21:52:41 BST] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
(checking cloud...) [2015-04-23 21:52:42 BST] String to sign: \"HEAD\n\n\nThu, 23 Apr 2015 20:52:42 GMT\n/BUCKET/GPGHMACSHA1--08b3dee71059819e3558ac9ef8b82ad87e2d8951\"
[2015-04-23 21:52:42 BST] Host: \"BUCKET.s3-ap-southeast-2.amazonaws.com\"
[2015-04-23 21:52:42 BST] Path: \"/GPGHMACSHA1--08b3dee71059819e3558ac9ef8b82ad87e2d8951\"
[2015-04-23 21:52:42 BST] Query string: \"\"
[2015-04-23 21:52:42 BST] Response status: Status {statusCode = 200, statusMessage = \"OK\"}
[2015-04-23 21:52:42 BST] Response header 'x-amz-id-2': 'f8bEclNud1KNHevvGPVHutG3V0TH/ixnMSuu3NBhEKRrWaUYtENbKyA5PyxCdSrz0REgq/Bgu1w='
[2015-04-23 21:52:42 BST] Response header 'x-amz-request-id': '7A344C3C3A27308E'
[2015-04-23 21:52:42 BST] Response header 'Date': 'Thu, 23 Apr 2015 20:52:43 GMT'
[2015-04-23 21:52:42 BST] Response header 'Last-Modified': 'Fri, 31 Oct 2014 07:03:03 GMT'
[2015-04-23 21:52:42 BST] Response header 'ETag': '\"66a85b0007a52d82e5bd29192ebdb510\"'
[2015-04-23 21:52:42 BST] Response header 'Accept-Ranges': 'bytes'
[2015-04-23 21:52:42 BST] Response header 'Content-Type': ''
[2015-04-23 21:52:42 BST] Response header 'Content-Length': '46058'
[2015-04-23 21:52:42 BST] Response header 'Server': 'AmazonS3'
[2015-04-23 21:52:42 BST] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
get file.jpg (from cloud...)
[2015-04-23 21:52:42 BST] String to sign: \"GET\n\n\nThu, 23 Apr 2015 20:52:42 GMT\n/BUCKET/GPGHMACSHA1--08b3dee71059819e3558ac9ef8b82ad87e2d8951\"
[2015-04-23 21:52:42 BST] Host: \"BUCKET.s3-ap-southeast-2.amazonaws.com\"
[2015-04-23 21:52:42 BST] Path: \"/GPGHMACSHA1--08b3dee71059819e3558ac9ef8b82ad87e2d8951\"
[2015-04-23 21:52:42 BST] Query string: \"\"
[2015-04-23 21:52:43 BST] Response status: Status {statusCode = 200, statusMessage = \"OK\"}
[2015-04-23 21:52:43 BST] Response header 'x-amz-id-2': 'LRDMgQAj+F81m3UqDebJ5CoZdyM/c2tMaFUvhjn8kjqq3x2Evy7O+wgLUiwE7lqascd0yrHR+xA='
[2015-04-23 21:52:43 BST] Response header 'x-amz-request-id': '068D946E995E7473'
[2015-04-23 21:52:43 BST] Response header 'Date': 'Thu, 23 Apr 2015 20:52:44 GMT'
[2015-04-23 21:52:43 BST] Response header 'Last-Modified': 'Fri, 31 Oct 2014 07:03:03 GMT'
[2015-04-23 21:52:43 BST] Response header 'ETag': '\"66a85b0007a52d82e5bd29192ebdb510\"'
[2015-04-23 21:52:43 BST] Response header 'Accept-Ranges': 'bytes'
[2015-04-23 21:52:43 BST] Response header 'Content-Type': ''
[2015-04-23 21:52:43 BST] Response header 'Content-Length': '46058'
[2015-04-23 21:52:43 BST] Response header 'Server': 'AmazonS3'
[2015-04-23 21:52:43 BST] Response metadata: S3: request ID=068D946E995E7473, x-amz-id-2=LRDMgQAj+F81m3UqDebJ5CoZdyM/c2tMaFUvhjn8kjqq3x2Evy7O+wgLUiwE7lqascd0yrHR+xA=
99% 22.5KB/s 0s[2015-04-23 21:52:44 BST] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"14\",\"--decrypt\"]
ok
[2015-04-23 21:52:44 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
[2015-04-23 21:52:44 BST] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
[2015-04-23 21:52:44 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
(recording state in git...)
[2015-04-23 21:52:44 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
[2015-04-23 21:52:44 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"444e504a0ab73d01df08ef731e691205cfd485f5\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
[2015-04-23 21:52:44 BST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"6e57ed008525cd58641c54a5ac6f07a960a7dc5c\"]
\"\"\"]]
"""]]

10
doc/bugs/Can__39__t_get_content_from_S3_with_s3-aws_library/comment_14_035a933289f95c365ce2c851f6946181._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
nickname="Walter"
subject="comment 14"
date="2015-04-24T20:13:31Z"
content="""
Playing around with it, I also can't reproduce it (using new or old versions of git-annex; it may be, as you allude, a problem in an old version of the s3 library).
Anyway, I'm happy that it's working now.
"""]]

22
doc/bugs/Can__39__t_get_content_from_S3_with_s3-aws_library/comment_16_2f16c63e539e51d9d1c0f85605e6d1e8._comment
View file

@ -1,22 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 16"""
date="2015-04-25T01:18:51Z"
content="""
Investigating further, when I create a bucket with the AWS library
in ap-southeast-2, `s3cmd info` shows it is located there.
When I create a bucket with hS3 in ap-southeast-2, I get this
interesting output:
joey@darkstar:~>s3cmd info s3://s3-43302240-076c-4420-8099-f2ef0b517e5f
s3://s3-43302240-076c-4420-8099-f2ef0b517e5f/ (bucket):
Location: ap-southeast-2
WARNING: Redirected to: s3-43302240-076c-4420-8099-f2ef0b517e5f.s3-ap-southeast-2.amazonaws.com
Expiration Rule: none
policy: none
ACL: joeyhess: FULL_CONTROL
So, it's apparently in the datacenter I asked for when making it,
but here's a redirect again.
"""]]

Some files were not shown because too many files have changed in this diff Show more