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 2017.

Command line used:

for f in $(grep -l '|done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --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=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; done
This commit is contained in:
Joey Hess 2017-09-29 12:55:42 -04:00
parent 80764993ee
commit 65a76bf381
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
840 changed files with 0 additions and 21980 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
doc/bugs/403_for_windows_installer_download.mdwn
View file

@ -1,24 +0,0 @@
### Please describe the problem.
As of Nov 2, 2016 1:30AM EST, no Windows installer is to be found in https://downloads.kitenet.net/git-annex/windows/current/. Accessing .exe URI directly yields a 403 error. Not sure if this is a temporary hiccup or a script error somewhere -- pardon if this is not the right channel to report this issue.
### What steps will reproduce the problem?
See https://downloads.kitenet.net/git-annex/windows/current/.
### What version of git-annex are you using? On what operating system?
N/A
### Please provide any additional information below.
N/A
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes! Worked like a charm on my Mac.
> [[done]]

8
doc/bugs/403_for_windows_installer_download/comment_1_5a9d0e95ae3db43d44fe465888327c64._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2016-11-02T15:05:04Z"
content="""
Hmm, seems my backup server moved the files off for some reason.
I've copied them back now.
"""]]

26
doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching.mdwn
View file

@ -1,26 +0,0 @@
### Please describe the problem.
When switching between my 2 repositories I now see a "." repository, see screenshot: http://screencast.com/t/0wxugJ9P
If I chose to switch to it, I get this error: http://screencast.com/t/5mndGNlhh8oN
### What steps will reproduce the problem?
Not sure if this is a real bug, maybe I screwed up?
### What version of git-annex are you using? On what operating system?
Version: 5.20150929-g7010007
Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA TorrentParser Database
MAC OSX 10.10.5
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
there is nothing relevant to this error in there unfortunately.
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
> [[fixed|done]] --[[Joey]]

14
doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_1_70a34d43629075249897bdc5301c55f5._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
nickname="ovidiu"
subject="comment 1"
date="2015-10-03T19:03:17Z"
content="""
trying to delete the test-repository I had created I get:
http://screencast.com/t/AhSiNXESvm
trying again I get:
http://screencast.com/t/hpFZL0mL
but in the end it got deleted. kinda. not sure. :-( one deleted successfully one simply hangs.
still nothing in the logs.
"""]]

24
doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_2_ffe8e30474e87e8cfa5aee2a3acb0952._comment
View file

@ -1,24 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2015-12-02T19:36:14Z"
content="""
Found this in the changelog:
* webapp: When adding another local repository, and combining it
with the current repository, the new repository's remote path
was set to "." rather than the path to the current repository.
This was a reversion caused by the relative path changes in 5.20150113.
I guess this is a similar problem, although it seems that the "." in your case
made it into `~/.config/git-annex/autostart`
I found two ways to do that. One is to tell the webapp to make a repository, and
enter "." as the repository location. The other, which is probably what you
did, is to go to Configuration -> Preferences and uncheck "Auto start", save
and then go back and check it. This wrongly puts in a "." instead of the full
repo path.
I've fixed all code paths to force absolute paths in the autostart file,
and made any relative paths that got in there be ignored.
"""]]

26
doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist.mdwn
View file

@ -1,26 +0,0 @@
### Please describe the problem.
When entering Jabber account data, the assistant responds with:
Internal Server Error: /etc/resolv.conf does not exist (No such file or directory).
### What steps will reproduce the problem?
Get a jabber account at http://jit.si. Enter your jabber name and password on Android assistant, and click "Use This Account". The dark overlay and progress message appears. After about 30 seconds the browser forwards to the "Internal Server Error: /etc/resolv.conf does not exist (No such file or directory)" page.
### What version of git-annex are you using? On what operating system?
Android 4.2 on Lenovo 780p. This model is only for sale in China and India and has been rooted, but the original ROM is still on. Often this makes no difference but you might want to confirm with another device.
git-annex version 5.20131127-g736ce5e
### 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]]

13
doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_1_d4f22335d5b6cb178c77579a1b450f9c._comment
View file

@ -1,13 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"
nickname="Christian"
subject="Same on CyaogenMod 10.2"
date="2013-11-29T11:00:58Z"
content="""
CM10.2 Nightly Build for Sony Experia Mini Pro does show the same behaviour. Creating the resolv.conf does not solve the problem:
1|root@mango:/etc # touch resolv.conf; ls resolv.conf
touch resolv.conf; ls resolv.conf
resolv.conf: No such file or directory
"""]]

20
doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_2_19dd9ebfebbece9d3654825492ebd5b9._comment
View file

@ -1,20 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawknsDuoV1R2hz6QoCJmMFWLmWgdZfULjMI"
nickname="Jakob"
subject="Moto G"
date="2013-12-02T13:53:55Z"
content="""
Same proplem on a Moto G - Android 4.3 - not rooted / Stock
running git-annex version 5.20131202-g5b9eb74
Error Message:
/etc/resolv.conf: openFile: does not exist (No such file or directory)
command-line output:
Falling back to hardcoded app location; cannot find expected files in /data/app-lib
git annex webapp
ex webapp
"""]]

10
doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_3_4a85c4c45768f96bdc6619c193de55ab._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.64"
subject="comment 3"
date="2013-12-03T17:35:11Z"
content="""
The dns library used only for srv lookups was trying to use /etc/resolv.conf. I've patched it to use the android getprop command instead to discover the DNS server.
The daily build has already been updated with this fix. I have not tested it completely myself.
"""]]

20
doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__.mdwn
View file

@ -1,20 +0,0 @@
### Please describe the problem.
On Andorid adding a respository on a remote server (ssh) to an exisiting repository does not work. After selecting "Make unencrypted repository" in the webapp the following error message is displayed:
Internal Server Error
/sdcard/git-annex.home/.ssh/config: setFileMode: permission denied (Operation not permitted)
The file "/sdcard/git-annex.home/.ssh/config" is created and its content seems to be fine. I could not find anything related to file mode in logcat / daemon.log.
### What steps will reproduce the problem?
Add a repository on a remote server to an existing repository. After selecting "Make unencrypted repository" the error messages is displayed.
### What version of git-annex are you using? On what operating system?
git-annex version 5.20140116-g2d9ec29
Android version 4.4 (running on a Nexus 5)
> I have made this failure to set the file mode not be a fatal error.
> [[fixed|done]] --[[Joey]]

10
doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_1_414adc1bee73711e3133c7fe8811aae2._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkViAynw-AW5kjf3w_QDwCVwhPc3k7gY5E"
nickname="Thomas"
subject="I see the same fail"
date="2014-01-29T21:52:18Z"
content="""
I se the same failure at both my android devices:
Nexus 7, Android 4.4.2, git-annex 5.20140128 and
Xperia phone, Android 4.1.2, git-annex 5.20140108
"""]]

8
doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_2_977a529f488ce0c167035675f76ebabf._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnx07B9weuZowXqh--1BDvGw8VM25aXsRw"
nickname="Matthew"
subject="comment 2"
date="2014-02-01T02:44:47Z"
content="""
Same here, any workarounds?
"""]]

84
doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__.mdwn
View file

@ -1,84 +0,0 @@
### Please describe the problem.
Seems to not upload files from Android client (set to "Manual mode: only stores files you...") to servers configured to get the files despite "syncing enabled"
Even when I chose "File source:" mode -- it just dropped all locally stored ones and didn't transfer those I have added.
### What steps will reproduce the problem?
Add file to the sdcard (vfat), and see it added to git (annex) but not uploaded
### What version of git-annex are you using? On what operating system?
Android build as now of Dec 13 I believe
### Please provide any additional information below.
First it just said that nothing to be transfered, I have switched that remote to "Full backup", web dashboard had "Scanning for files to transfer" for a while, then refreshed with "Synced with" and no file transfers running. Below is an excerpt from the log
[[!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
(Recording state in git...)
(Recording state in git...)
(Recording state in git...)
add pics/20131217_125740.jpg ok
add pics/20131217_125740.jpg [2013-12-17 16:19:25 EST] Committer: Committing changes to git
[2013-12-17 16:19:25 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Invalid pid specified
Invalid pid specified
warning: no threads support, ignoring --threads
Already up-to-date.
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
bcb7ed7..3672b38 git-annex -> synced/git-annex
e8cc37f..052b758 annex/direct/master -> synced/master
Already up-to-date.
[2013-12-17 16:19:29 EST] Committer: Adding 20131217_125726.jpg
ok
(Recording state in git...)
(Recording state in git...)
add pics/20131217_125726.jpg ok
add pics/20131217_125726.jpg [2013-12-17 16:19:30 EST] Committer: Committing changes to git
Invalid pid specified
[2013-12-17 16:19:32 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Already up-to-date.
warning: no threads support, ignoring --threads
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
3672b38..f914fed git-annex -> synced/git-annex
052b758..859d3c6 annex/direct/master -> synced/master
Already up-to-date.
Invalid pid specified
Invalid pid specified
Invalid pid specified
# End of transcript or log.
"""]]
previous runs experienced different problems, so may be those could lead to unreported problem here?
e.g. from previous run:
[[!format sh """
[2013-12-17 16:04:44 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Already up-to-date.
warning: no threads support, ignoring --threads
warning: no threads support, ignoring --threads
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
a889d7b..c9a7466 git-annex -> synced/git-annex
error: Ref refs/heads/synced/git-annex is at c9a74663dc863eb95d316deac4657173c92653df but expected a889d7b335738ef1c4f85da18d1bea337cd36522
remote: error: failed to lock refs/heads/synced/git-annex^[[K
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
! [remote rejected] git-annex -> synced/git-annex (failed to lock)
error: failed to push some refs to 'ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/'
Everything up-to-date
Invalid pid specified
[2013-12-17 16:08:34 EST] main: Syncing with vagus.cns.dartmouth.edu_annex
Everything up-to-date
Invalid pid specified
~
]]
> [[fixed|done]] --[[Joey]]

10
doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_1_3f0e3fed240252207020d31ab96d0666._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 1"
date="2013-12-17T23:51:32Z"
content="""
The \"Invalid pid specified\" seems to point at the problem. (Or it's a nice red herring.) I cannot find this error message in either git-annex or in git.
Enabling debug logging and restarting the assistant should produce a nice log that will both tell us what command it was running when that message showed up, and show some details about its preferred content decisions.
"""]]

66
doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_2_87746f4fd0b404db7070c0b2346e8e2b._comment
View file

@ -1,66 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
nickname="Yaroslav"
subject="comment 2"
date="2013-12-18T02:07:46Z"
content="""
enabled debug logging in the preferences of webapp, clicked on 'restart daemon', fetched log:
$> grep -B 1 pid daemon.log
[2013-12-17 20:51:49 EST] chat: nice [\"ionice\",\"-c3\",\"git-annex\",\"transferkeys\"]
Invalid pid specified
entire log http://www.onerussian.com/tmp/daemon.log.gz
in the webbrowser page got stuck white without updating, refreshed it and got
\"Internal Server Error\"
git-annex: createProcess: runInteractive
Process: pipe: resource exhausted (Too many open files)
went to terminal, ctrl-c, started again -- seems have managed to start:
$> grep -B 3 pid daemon.log
(scanning...) [2013-12-17 20:57:36 EST] Watcher: Performing startup scan
Already up-to-date.
Everything up-to-date
Invalid pid specified
disabled, and then reenabled syncing with vagus, refetched daemon.log to see similar to above message.
New experiment -- added locally yet another file pics/test.jpg which according to whereis was quickly pushed out from my laptop.
Then realized that daemon.log is no longer verbose! (i.e. changes in preferences within webapp didn't persist) By now on phone it synced git, but didn't download the load (rightfully since I have instructed not to).
ok -- went to enable debug logging again in webapp -- it was already selected.
in the log now found following
```
(started...) [2013-12-17 20:59:10 EST] main: Syncing with vagus.cns.dartmouth.edu_annex
Everything up-to-date
Invalid pid specified
[2013-12-17 21:02:37 EST] main: Syncing with vagus.cns.dartmouth.edu_annex
From ssh://git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex
c3a5fd6..29b6694 master -> vagus.cns.dartmouth.edu_annex/master
d9a09e2..0c3e966 synced/git-annex -> vagus.cns.dartmouth.edu_annex/synced/git-annex
c3a5fd6..29b6694 synced/master -> vagus.cns.dartmouth.edu_annex/synced/master
error: Ref refs/heads/annex/direct/master is at 29b6694ee483c4563955bc5ae1ee1664daed7f19 but expected c3a5fd6b7cee1cbd43fbeb5aa4a445a5407067bd
fatal: Cannot lock the ref 'HEAD'.
Updating c3a5fd6..29b6694
Fast-forward
(merging vagus.cns.dartmouth.edu_annex/synced/git-annex into git-annex...)
git-annex: /storage/extSdCard/annex/.git/annex/merge/: getDirectoryContents: does not exist (No such file or directory)
Already up-to-date.
Already up-to-date.
[2013-12-17 21:02:41 EST] Committer: Committing changes to git
[2013-12-17 21:02:42 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Everything up-to-date
[2013-12-17 21:02:43 EST] Committer: Committing changes to git
[2013-12-17 21:02:45 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Everything up-to-date
```
I guess I will just try now to enable debug logging in .git/config while in the terminal on the phone
"""]]

27
doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_3_72c9e9f6bb5ca23ddfd513fcc8bff48c._comment
View file

@ -1,27 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
nickname="Yaroslav"
subject="comment 3"
date="2013-12-18T02:21:17Z"
content="""
ah -- may be that was debug log, but nothing exciting was happening? .git/config does have annex.debug true
ok -- went to \"switch repositories\", showed the list of my only repository, clicking on it didn't go anywhere... ok - restarted the beast in the terminal, added a new file to the pics/ directory, again -- registered, added to git, synced, did not 'push' the load, and no informative debug messages:
add pics/earth-daynight.jpg [2013-12-17 21:17:26 EST] Committer: Committing changes to git
[2013-12-17 21:17:26 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Invalid pid specified
Already up-to-date.
warning: no threads support, ignoring --threads
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
0c3e966..6d94fd4 git-annex -> synced/git-annex
29b6694..bbd3fa3 annex/direct/master -> synced/master
[2013-12-17 21:17:28 EST] Committer: Adding earth-daynight.jpg
Already up-to-date.
ok
(Recording state in git...)
(Recording state in git...)
so again that pid msg but no debug logging seems to be done. Is there some other way to enable debug logging? ;)
"""]]

14
doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_4_b54c169a96e263e12495690fe14d8b4a._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="etset"
ip="188.83.111.161"
subject="comment 4"
date="2013-12-29T15:12:43Z"
content="""
I also can't transfer from and to an Android tablet with the git-annex assistant. The `daemon.log` shows the same error, `Invalid pid specified`, repeated several times.
Enabling the debug log mode always shows lines similar to this one before each \"Invalid pid\" line: `[2013-12-29 14:50:49 WET] chat: nice [\"ionice\", \"-c3\", \"git-annex\", \"transferkeys\"]`.
However, using the `git annex get` and `git annex copy` commands to fetch and send the files from the same tablet work as expected.
I can post the full log later, if needed.
"""]]

8
doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_5_56ef816d3d4f3d85d31ccaf806133073._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.227"
subject="reproduced bug"
date="2013-12-29T21:06:30Z"
content="""
Debug logs shows that the problem is it tries to run ionice. So fix should be trivial.
"""]]

22
doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn
View file

@ -1,22 +0,0 @@
### Please describe the problem.
I'm trying to get an Android development environment set up, but I am running into conflicting library versions inside of the chroot. The package installation script now finishes, but I run into a link-time error during `cabal configure` because it is pulling in two different versions of the unix package for some reason. Please let me know if there is any information I can get from my build environment that would help diagnosing the issue.
### What steps will reproduce the problem?
Run `buildchroot`, `install-haskell-packages`, `make android`
### What version of git-annex are you using? On what operating system?
Attempting to build from source, cross-compiling for Android on Debian Jessie.
### Please provide any additional information below.
[[!format sh """
Linking ./dist/setup/setup ...
/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers':
(.text+0x300): multiple definition of `pPrPr_disableITimers'
/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile:225: recipe for target 'android' failed
make: *** [android] Error 1
"""]]
> [[fixed|done]] --[[Joey]]

20
doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_1_2ecd076870d75816671dc0950f89c54a._comment
View file

@ -1,20 +0,0 @@
[[!comment format=mdwn
username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899"
nickname="divergentdave"
subject="comment 1"
date="2016-04-15T12:24:07Z"
content="""
I just created a new chroot, using revision d4b3a8a for both the initial scripts and inside the chroot.
```
...
[32 of 32] Compiling Main ( dist/setup/setup.hs, dist/setup/Main.o )
Linking ./dist/setup/setup ...
/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers':
(.text+0x300): multiple definition of `pPrPr_disableITimers'
/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile:225: recipe for target 'android' failed
make: *** [android] Error 1
```
"""]]

14
doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_2_98ad86d951bda7f2f849b084fd40d1c6._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2016-04-19T17:22:48Z"
content="""
unix-2.6.0.1 is a very old version of that package, and unix-2.7.1.0 is
included with the version of ghc used by the android build.
So, it seems that some dependency mess is causing cabal to try to install a
second, old version of unix. Which can't possibly work.
This is apparently happening in the host ghc setup, not the cross compiling
ghc setup.
"""]]

30
doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_3_6e13c53def5da8d903b220522bbd23ba._comment
View file

@ -1,30 +0,0 @@
[[!comment format=mdwn
username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899"
nickname="divergentdave"
subject="Further information"
date="2016-04-23T18:31:23Z"
content="""
I did some further testing, but I'm still stumped. If I run `cabal configure -O0 -fAndroidSplice --ghc-options=-v`, I get the following items in the resulting log file. (trimmed for space)
```
Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.6.3
Using binary package database: /usr/lib/ghc/package.conf.d/package.cache
Using binary package database: /home/builder/.ghc/i386-linux-7.6.3/package.conf.d/package.cache
...
hiding package unix-2.6.0.1 to avoid conflict with later version unix-2.7.1.0
...
Chasing modules from: *dist/setup/setup.hs
Created temporary directory: /tmp/ghc1639_0
*** C pre-processor:
'/usr/bin/gcc' '-E' '-undef' '-traditional' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' ... '-I' '/usr/lib/ghc/unix-2.6.0.1/include' ... '-x' 'c' './Common.hs' '-o' '/tmp/ghc1639_0/ghc1639_0.hscpp'
...
*** Linker:
'/usr/bin/gcc' ... '-L/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0' ... '-L/usr/lib/ghc/unix-2.6.0.1' ... '-lHSunix-2.7.1.0' ... '-lHSunix-2.6.0.1' ...
/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers':
(.text+0x300): multiple definition of `pPrPr_disableITimers'
/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
```
I'm not sure what \"hiding\" means in the context of GHC, but clearly it isn't working.
"""]]

7
doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_4_3dd3b8005fef7a5dad69b7d1c1154235._comment
View file

@ -1,7 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2016-04-28T17:21:00Z"
content="""
Reproduced, fixed.
"""]]

30
doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_.mdwn
View file

@ -1,30 +0,0 @@
### Please describe the problem.
Two regular repositories created with the assistant, one on the computer and one on an USB stick cannot synchronise. Log reports problem with the index file:
/media/usb/annex/.git/index: copyFile: does not exist (No such file or directory)
### What steps will reproduce the problem?
Create a repository and then another on an usb stick (with `Add another repository`) and add a file to the first one, it doesn't synchronise.
### What version of git-annex are you using? On what operating system?
git-annex 5.20141125 from Debian Jessie
### Please provide any additional information below.
I was able to solve the problem by copying the .git/index file from the first repository to the second one.
Also note that the second repository is on a FAT32 usb stick
[[!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]]

9
doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_1_36d1207818c8db747dbf94d9a48e3e98._comment
View file

@ -1,9 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-03-16T17:34:22Z"
content="""
Well, non-bare git repositories are supposed to have a .git/index file.
Perhaps some damage to your USB stick caused it to lose this file?
"""]]

27
doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_2_82f1c3c6aaeb488582ee08518b193f99._comment
View file

@ -1,27 +0,0 @@
[[!comment format=mdwn
username="clement"
subject="Details"
date="2015-03-27T10:34:26Z"
content="""
I tried it again with dfifferent usbs and filesystems, and it looks like it only
happens with VFAT (e.g not ext). Retracing my step, here is what I do:
1. Create a repository on my local machine using git-annex assistant.
2. Create another non-bare repository on a VFAT usb stick and combine the two.
3. Add a file to the local repository
4. I doesn't synchronise and log shows the missing index error.
It also happens the other way around. If I
1. Create a repository on the usb device, and
2. create a paired repository on my machine, I get a straight up
Internal Server Error
/mnt/USB/annexdir/.git/index: copyFile: does not exist (No such file or directory)
"""]]

19
doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_3_db50cbdc302480c4b1fe0f364aa769d9._comment
View file

@ -1,19 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2015-09-22T16:25:15Z"
content="""
Ok, that seems clear enough, and there's only 1 place where git-annex
copies .git/index; in `mergeDirect`. Indeed, if .git/index doesn't exist
yet when that is called, it'll crash. And, a freshly created git repo
starts off without a .git/index until changes start to be staged.
However, I can't reproduce the crash with a current version of git-annex,
and this bug report is about a version nearly a year old now. AFAICS,
the sync (or the assistant) will make a commit before merging, and that
commit results in the index file being created, as a side effect.
Also, I can't see anything that VFAT could have to do with this.
Hmm, I did manage to reproduce the crash using the new --no-commit flag to
git-annex sync. Will fix on that basis.
"""]]

32
doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo.mdwn
View file

@ -1,32 +0,0 @@
### Please describe the problem.
The assistant keeps making merges that deletes all the files in the repository. I "git revert" the merge commit, but the next day it does it again. It also seems to have gone into a merge loop before this happens (will post a screenshot of tig). I can make the repo available privately if that will help.
### What steps will reproduce the problem?
Unknown. It does it on its own without me even interacting with files in the annex.
### What version of git-annex are you using? On what operating system?
The host that keeps deleting is running 6.20160428-g1f253e8 on ArchLinux (x86_64). A remote that it keeps syncing with is running 6.20160511-g4633f0b, also on ArchLinux x86_64.
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
Updating 8cb69d3..c589c5e
Fast-forward
.gitignore | 3 ---
Bilete/8mars-2013-1.jpg | 1 -
etc.
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I use git-annex for everything. I've got 10 repositories and around 2.5TB of data in those repos which in turn is synced all over the place. It's excellent.
> This seems to be a git bug probably; see
> <http://thread.gmane.org/gmane.comp.version-control.git/297237>.
>
> Luckily, easy to work around the problem.
>
> [[fixed|done]] in [[!commit bfd00a0f8ca69cb0669df50f8d98354f11c5253c]].
> --[[Joey]]

11
doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_1_951d03de942c19f760e9ff01a3b61f33._comment
View file

@ -1,11 +0,0 @@
[[!comment format=mdwn
username="EskildHustvedt"
subject="comment 1"
date="2016-05-20T07:45:52Z"
content="""
Right, so I forgot to mention, perhaps crucially. I'm using v6 for these repos.
Here's the tig grap for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge1-2016-05-20.png]]
Here's the merge commit itself for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge2-2016-05-20.png]]
"""]]

56
doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_2_c3408c31cf1c58b6b1e34102127ba613._comment
View file

@ -1,56 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2016-05-23T17:30:07Z"
content="""
I've now got a copy of the repo, in
~/lib/big/git-annex-test-repos/ssl.zerodogg.org__zerodogg_private_tmp_privateDocs.zerodogg.tar.xz.gpg
Looking at commit 77c7d149646655fb5851c3db584fe70d64707d04, it merges in
0b4896bc205696630c81cf557959a4aaa24906f0 which has an empty tree.
0b4896bc205696630c81cf557959a4aaa24906f0 is itself a merge commit.
Both of the commits it merges themselves have empty trees.
And so it goes down quite a way, with empty merge commits including
418367b, 7bab5cf, b651554, cf5de84, c5905f7, 928040e, a590245, 5b53fc9,
6d9f5da, 5f2623d. The freqency of these might indeed indicate some kind
of feedback loop, but I don't think whatever is causing that is the core problem.
fc6670a37fd9d3984a112a80d9bbaec5c041c005 is the crucial merge it seems. Its
parents are 71b6c8a and f8dfc21. Both of those parents have the same tree,
5f18bed323c29fb77add3a84abcf8b1fb6b646d7, and that tree is populated with all
the files. But somehow this merge deleted everything.
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent 71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c
parent f8dfc219a40b2871baed3192ea5806bb4ac551e7
author xxx 1463570165 +0200
committer xxx 1463570165 +0200
Merge branch 'refs/heads/synced/master' into HEAD
(There are empty trees earlier where the same thing happened that you
reverted, but it seems best to focus on the most recent occurance.)
So, can you find fc6670a in .git/annex/daemon.log* in any of the
clones of this repository? It would be good to narrow down on which
machine(s) the bad merge is happening. (Maybe you've already narrowed it down?)
One of the two parent commits (71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c)
is a manual revert you did, the other commit looks to have been done by
the assistant.
I'm guessing that refs/heads/synced/master was f8dfc219a40b2871baed3192ea5806bb4ac551e7
when the bad merge was generated. So this bad merge probably happened in
the repository where you did that manual reversion.
As far as I can tell this was a regular git merge that somehow decided to empty
the tree. It was not a case of git-annex auto-resolving a merge conflict.
Are you using adjusted branches in any of the clones of this repository?
What version(s) of git are being used?
(I noticed that despite using v6 mode, every file in the repository
seems to be locked, so the smudge filters etc should not be involved in the
problem unless using an adjusted branch.)
"""]]

47
doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_3_518bc431b16143b9ec0caa78e54c2d6b._comment
View file

@ -1,47 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2016-06-13T16:22:27Z"
content="""
@EskildHustvedt, are you using adjusted branches in any of your v6
repositories?
While investigating a test suite failure that occurs only on FAT,
I think I have reproduced this bug. I used two v6 repos, both of
them using adjusted branches, and added a file with the same name and
content to both independently, then merged the two.
In a merge of two commits that both had the same tree, a merge
commit was constructed with an empty tree.
Also, much as in the original bug report, there was a pattern of
repeated merges.
commit 4bcff45c9670007b8faee5c5514bdd7b9096984a
Merge: 4935ace 63fe78f
# empty tree
commit 63fe78f28218ad71e865f52e2a833dbd4b452c96
Merge: 4e42f30 4935ace
# populated tree
4935ace has populated tree
4e42f30 has populated tree
Notice that 4935ace is merged in twice, a bit oddly. Indeed, that
is not possible to construct with manual git commands:
joey@darkstar:~/tmp/meep/2>git checkout 63fe78f
HEAD is now at 63fe78f... Merge branch 'refs/heads/synced/master' into HEAD
joey@darkstar:~/tmp/meep/2>git merge 4935ace
Already up-to-date.
joey@darkstar:~/tmp/meep/2>git checkout 4935ace
Previous HEAD position was 63fe78f... Merge branch 'refs/heads/synced/master' into HEAD
HEAD is now at 4935ace... git-annex in joey@darkstar:~/tmp/meep/2
joey@darkstar:~/tmp/meep/2>git merge 63fe78f
Updating 4935ace..63fe78f
Fast-forward
In either case, git updates to 63fe78f. So, adusted branches must be
breaking handling of one or the other of these two cases.
"""]]

10
doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_4_49bdbdc261c8e5b72f84c52014f892df._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2016-06-14T01:55:03Z"
content="""
Forgot to mention that the repeated merge commits happened because git
merge -no-ff was being used, which makes a merge commit even when it can
just fast-forward. That was removed as part of the fix, so the repeated
merges should also be resolved.
"""]]

25
doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__.mdwn
View file

@ -1,25 +0,0 @@
### Please describe the problem.
If I create a git annex repository in my home directory, then start the assistant, the assistant will try to annex my entire home dir.
### What steps will reproduce the problem?
$ cd
$ git init
$ git annex init
Applications Menu -> Internet -> Git Annex
### What version of git-annex are you using? On what operating system?
Debian Jessie git-annex (5.20141125)
### Expected behavior
The assistant shouldn't do anything unless I tell it to. Currently, I cannot play with the assistant at all, because I do not want everything in my homedir to be locked and symlinked.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I use git annex for managing the image and video resources on my website and it works fine for that.
> HOME git repo guard added, [[done]] --[[Joey]]

12
doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_1_af3cc2384e230601851e5379dacd3d29._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2016-04-04T20:14:29Z"
content="""
By creating a git repository in your home directory,
and telling git-annex it's a git-annex repository, and starting
the assistant, what would you say you've told git-annex to do?
(Note that the webapp has a guard to prevent this mistake.
You have to shoot your foot manually, and repeatedly, to do this.)
"""]]

12
doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_2_36e71b11f30a6fd4e95cd32a6deb57d9._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
nickname="timothyhobbs"
subject="comment 2"
date="2016-04-04T21:21:56Z"
content="""
When I launch the annex assistant web app, it should do nothing to the repository, because I have not told it to do anything. I have only tried to open up what, to me, the naive user, is some gui app. I know of no other gui app that initializes an operation simple by way of being opened. Does synaptic update your system when you click \"Applications Menu -> Settings -> Synaptic package manager\"?
You say that I have to shoot myself in the foot repeatedly and manually to do it, but that simply isn't true. There is nothing wrong with initializing a git repo in ~/ in order to, say, track changes to dot files. There shouldn't be anything wrong with running \"git annex init\" in that git repo, to, for example, track some binaries in ~/bin. Afterall, I didn't \"git annex add .\" I was trying to use git annex to track specific and manually specified files.
I actually ended up opening the assistant, from the Applications Menu, for a reason entirely unrelated to the git annex repo that happened to be located in ~/. So I hope you can imagine my shock, when by simply opening what I thought was going to be a gui that I could use to manage some entirely unrelated repositories, I actually ended up running a command on the repository in ~/.
"""]]

8
doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_3_a29edaf9110cc6e0ed68f92d33ed7735._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
nickname="timothyhobbs"
subject="comment 3"
date="2016-04-05T21:28:20Z"
content="""
If I understand correctly, than if you run the command `git annex webapp` and the $PWD is a git annex repository, then this will start the assistant and annex all of the files in that directory. And that, I think is a bug, no one expects the `webapp` command to do anything besides display a GUI.
"""]]

27
doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_4_6353daafdf250ea0c4dad1e2fd1233a3._comment
View file

@ -1,27 +0,0 @@
[[!comment format=mdwn
username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
nickname="timothyhobbs"
subject="comment 4"
date="2016-04-05T22:29:06Z"
content="""
Yes, that is the problem. Try:
````
$ mkdir foo
$ cd foo
$ echo foo > bar
$ git init
$ git annex init
$ git annex webapp
````
You'll get:
````
x Committed changes to git
× Added bar
× Performed startup scan
````
But I wouldn't expect that. Why should the command `git annex webapp` run an `add` command?
"""]]

17
doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_5_200e00eb84c9278c9f90fe545cb6531d._comment
View file

@ -1,17 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2016-04-13T17:40:15Z"
content="""
If ~/ is a git repository, the assistant will still refuse to run in it,
unless you've manually run `git annex init` in that git repository
at some point in the past.
Here it is in my home directory, which is indeed a git repo:
joey@darkstar:~>git annex assistant
git-annex: First run: git-annex init
When I run the webapp, it doesn't run the assistant, but prompts in the web browser for
where I want to make a new git-annex repository.
"""]]

24
doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_6_ed1b53ceef3e7a499b92e6f3f0f6d672._comment
View file

@ -1,24 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 6"""
date="2016-04-13T17:43:34Z"
content="""
So, I see that you *did* tell git-annex to treat your home git repo as a
git-annex repo.
And, starting the the assistant/webapp from inside a git annex repository is
intended to start them running in that repository. This behavior makes a
lot of sense in general. It's consistent with running any other git command
inside a git repository causing that command to run on that repository.
I guess that the issue here is, opening the git-annex webapp from a menu
causes the program to run with its working directory set to HOME. But in
this case, the HOME is only incidental, the intent is not to start the
webapp/assistant in that repository.
Seems kind of hard for the assistant to determine intent though.
So, the best that can be done, I suppose, is to make starting the webapp
in the HOME git repository behave as if that git repository was not
initialized for use by git-annex.
"""]]

49
doc/bugs/Build_with_aws_head_fails.mdwn
View file

@ -1,49 +0,0 @@
### Please describe the problem.
https://github.com/aristidb/aws/issues/206 was recently resolved in https://github.com/aristidb/aws/pull/213.
A newer version will be tagged imminently according to https://github.com/aristidb/aws/issues/206#issuecomment-260214736.
With the http-conduit (<2.2.0) constraint removed from git-annex.cabal, and the aws dependency set to use aws head (currently c8806dc), the git-annex build fails.
### What steps will reproduce the problem?
Remove the http-conduit (<2.2.0) constraint and attempt to build git-annex with aws head.
### What version of git-annex are you using? On what operating system?
macOS 10.11, git-annex 6.20161118.
### Please provide any additional information below.
Full build log: https://gist.github.com/ilovezfs/15bcd8f1086b3d825beff58140e04eec
[[!format sh """
[ 90 of 542] Compiling Types.Crypto ( Types/Crypto.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Types/Crypto.o )
[ 91 of 542] Compiling Utility.Metered ( Utility/Metered.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Metered.o )
[ 92 of 542] Compiling Messages.JSON ( Messages/JSON.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Messages/JSON.o )
[ 93 of 542] Compiling Utility.Url ( Utility/Url.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Url.o )
Utility/Url.hs:354:34: error:
• The constructor ‘StatusCodeException’ should have 2 arguments, but has been given 3
• In the pattern: StatusCodeException s _ _
In an equation for ‘matchStatusCodeException’:
matchStatusCodeException want e@(StatusCodeException s _ _)
| want s = Just e
| otherwise = Nothing
Utility/Url.hs:354:34: error:
• Couldn't match expected type ‘HttpException’
with actual type ‘HttpExceptionContent’
• In the pattern: StatusCodeException s _ _
In an equation for ‘matchStatusCodeException’:
matchStatusCodeException want e@(StatusCodeException s _ _)
| want s = Just e
| otherwise = Nothing
cabal: Leaving directory '.'
cabal: Error: some packages failed to install:
git-annex-6.20161118 failed during the building phase. The exception was:
ExitFailure 1
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes :)
> [[done]] via the nice patch! --[[Joey]]

149
doc/bugs/Build_with_aws_head_fails/comment_1_d48bc2b3eb48c2a3a4d8608803913000._comment
View file

@ -1,149 +0,0 @@
[[!comment format=mdwn
username="alpernebbi"
avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106"
subject="Patch to fix aws head build issue"
date="2016-12-10T13:08:58Z"
content="""
I think I fixed this. I'm attaching the output of `git format-patch origin/master`.
In an Arch Linux chroot with their [PKGBUILD](https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/git-annex) (with a small modification to apply the patch), `haskell-http-client 0.5.3.3-1` and `http-conduit 2.2.3-5` both the build and the tests are successful.
It's also successful in a Debian Sid chroot, where `sudo apt build-dep git-annex` gives me `libghc-http-client-dev 0.4.31.1-3+b2`, `libghc-http-conduit-dev 2.1.11-3+b2`.
### Patch
[[!format patch \"\"\"
From 2ce09420aa8f3d916c6562abea4ed8911a186902 Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Date: Sat, 10 Dec 2016 15:24:27 +0300
Subject: [PATCH] Remove http-conduit (<2.2.0) constraint
Since https://github.com/aristidb/aws/issues/206 is resolved, this
constraint is no longer necessary. However, http-conduit (>=2.2.0)
requires http-client (>=0.5.0) which introduces some breaking changes.
This commit also implements those changes depending on the version.
Fixes: https://git-annex.branchable.com/bugs/Build_with_aws_head_fails/
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
---
Remote/S3.hs | 8 +++++++-
Remote/WebDAV.hs | 17 +++++++++++++++++
Utility/Url.hs | 8 ++++++++
git-annex.cabal | 3 +--
4 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/Remote/S3.hs b/Remote/S3.hs
index 4c1bd57..9563b5a 100644
--- a/Remote/S3.hs
+++ b/Remote/S3.hs
@@ -49,6 +49,12 @@ import Annex.Content
import Annex.Url (withUrlOptions)
import Utility.Url (checkBoth, managerSettings, closeManager)
+#if MIN_VERSION_http_client(0,5,0)
+import Network.HTTP.Client (responseTimeoutNone)
+#else
+responseTimeoutNone = Nothing
+#endif
+
type BucketName = String
remote :: RemoteType
@@ -430,7 +436,7 @@ withS3HandleMaybe c gc u a = do
where
s3cfg = s3Configuration c
httpcfg = managerSettings
- { managerResponseTimeout = Nothing }
+ { managerResponseTimeout = responseTimeoutNone }
s3Configuration :: RemoteConfig -> S3.S3Configuration AWS.NormalQuery
s3Configuration c = cfg
diff --git a/Remote/WebDAV.hs b/Remote/WebDAV.hs
index 19dbaa8..14947f1 100644
--- a/Remote/WebDAV.hs
+++ b/Remote/WebDAV.hs
@@ -5,6 +5,7 @@
- Licensed under the GNU GPL version 3 or higher.
-}
+{-# LANGUAGE CPP #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Remote.WebDAV (remote, davCreds, configUrl) where
@@ -34,6 +35,10 @@ import Utility.Url (URLString, matchStatusCodeException)
import Annex.UUID
import Remote.WebDAV.DavLocation
+#if MIN_VERSION_http_client(0,5,0)
+import Network.HTTP.Client (HttpExceptionContent(..), responseStatus)
+#endif
+
remote :: RemoteType
remote = RemoteType {
typename = \"webdav\",
@@ -302,6 +307,17 @@ goDAV (DavHandle ctx user pass _) a = choke $ run $ prettifyExceptions $ do
{- Catch StatusCodeException and trim it to only the statusMessage part,
- eliminating a lot of noise, which can include the whole request that
- failed. The rethrown exception is no longer a StatusCodeException. -}
+#if MIN_VERSION_http_client(0,5,0)
+prettifyExceptions :: DAVT IO a -> DAVT IO a
+prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go
+ where
+ go (HttpExceptionRequest _ (StatusCodeException response message)) = error $ unwords
+ [ \"DAV failure:\"
+ , show (responseStatus response)
+ , show (message)
+ ]
+ go e = throwM e
+#else
prettifyExceptions :: DAVT IO a -> DAVT IO a
prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go
where
@@ -311,6 +327,7 @@ prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go
, show (statusMessage status)
]
go e = throwM e
+#endif
prepDAV :: DavUser -> DavPass -> DAVT IO ()
prepDAV user pass = do
diff --git a/Utility/Url.hs b/Utility/Url.hs
index 9b68871..d0e1b37 100644
--- a/Utility/Url.hs
+++ b/Utility/Url.hs
@@ -350,8 +350,16 @@ hUserAgent = \"User-Agent\"
-
- > catchJust (matchStatusCodeException (== notFound404))
-}
+#if MIN_VERSION_http_client(0,5,0)
+matchStatusCodeException :: (Status -> Bool) -> HttpException -> Maybe HttpException
+matchStatusCodeException want e@(HttpExceptionRequest _ (StatusCodeException r _))
+ | want (responseStatus r) = Just e
+ | otherwise = Nothing
+matchStatusCodeException _ _ = Nothing
+#else
matchStatusCodeException :: (Status -> Bool) -> HttpException -> Maybe HttpException
matchStatusCodeException want e@(StatusCodeException s _ _)
| want s = Just e
| otherwise = Nothing
matchStatusCodeException _ _ = Nothing
+#endif
diff --git a/git-annex.cabal b/git-annex.cabal
index ec54a14..83d45a1 100644
--- a/git-annex.cabal
+++ b/git-annex.cabal
@@ -357,8 +357,7 @@ Executable git-annex
resourcet,
http-client,
http-types,
- -- Old version needed due to https://github.com/aristidb/aws/issues/206
- http-conduit (<2.2.0),
+ http-conduit,
time,
old-locale,
esqueleto,
--
2.7.4
\"\"\"]]
"""]]

56
doc/bugs/Building_fails__58___Not_in_scope__58_____96__myHomeDir__39___.mdwn
View file

@ -1,56 +0,0 @@
What steps will reproduce the problem?
Building of the current github HEAD fails with a strange error message regarding OSX. I'm not using OSX but Ubuntu 12.10, why is cabal trying to build these files?
<pre>
dominik@Atlantis:/var/tmp$ git clone git://github.com/joeyh/git-annex.git
Cloning into 'git-annex'...
remote: Counting objects: 40243, done.
remote: Compressing objects: 100% (10568/10568), done.
remote: Total 40243 (delta 29647), reused 40044 (delta 29449)
Receiving objects: 100% (40243/40243), 9.12 MiB | 184 KiB/s, done.
Resolving deltas: 100% (29647/29647), done.
dominik@Atlantis:/var/tmp$ cd git-annex/
dominik@Atlantis:/var/tmp/git-annex$ cabal update
Downloading the latest package list from hackage.haskell.org
dominik@Atlantis:/var/tmp/git-annex$ cabal install --only-dependencies
Resolving dependencies...
All the requested packages are already installed:
Use --reinstall if you want to reinstall anyway.
dominik@Atlantis:/var/tmp/git-annex$ cabal configure
Resolving dependencies...
[ 1 of 21] Compiling Utility.FileSystemEncoding ( Utility/FileSystemEncoding.hs, dist/setup/Utility/FileSystemEncoding.o )
[ 2 of 21] Compiling Utility.Applicative ( Utility/Applicative.hs, dist/setup/Utility/Applicative.o )
[ 3 of 21] Compiling Utility.PartialPrelude ( Utility/PartialPrelude.hs, dist/setup/Utility/PartialPrelude.o )
[ 4 of 21] Compiling Utility.UserInfo ( Utility/UserInfo.hs, dist/setup/Utility/UserInfo.o )
[ 5 of 21] Compiling Utility.Monad ( Utility/Monad.hs, dist/setup/Utility/Monad.o )
[ 6 of 21] Compiling Utility.Path ( Utility/Path.hs, dist/setup/Utility/Path.o )
[ 7 of 21] Compiling Utility.OSX ( Utility/OSX.hs, dist/setup/Utility/OSX.o )
Utility/OSX.hs:22:17: Not in scope: `myHomeDir'
</pre>
What is the expected output? What do you see instead?
I expect cabal to build git-annex.
What version of git-annex are you using? On what operating system?
github HEAD on Ubuntu 12.10
Please provide any additional information below.
<pre>
$ cabal --version
cabal-install version 0.14.0
using version 1.14.0 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.2
$ uname -a
Linux Atlantis 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
</pre>
> [[fixed|done]] --[[Joey]]

44
doc/bugs/Can__39__t_create_remote_for_Google_cloud_storage_DRA___47___nearline_buckets.mdwn
View file

@ -1,44 +0,0 @@
### Please describe the problem.
Creating a remote for a GCS durable reduced availability (DRA) or nearline bucket fails with "Invalid argument".
### What steps will reproduce the problem?
$ git annex initremote test encryption=none bucket=BUCKET type=S3 host=storage.googleapis.com
This works if BUCKET is a standard bucket, but fails with "invalid argument" if BUCKET is a DRA or nearline bucket.
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20150205
on macos 10.10
### Please provide any additional information below.
I spent some time in strace, and my best guess is that this is because git-annex is sending x-amz-storage-class: STANDARD. I couldn't figure out a way to disable this; if I did e.g.
$ git annex initremote test encryption=none bucket=BUCKET type=S3 host=storage.googleapis.com storageclass="NEARLINE"
it still fails and still sends storage-class: STANDARD. I also tried storageclass="" -- same thing.
Here's the HTTP request that's failing:
PUT /annex-uuid HTTP/1.1\r\nAuthorization: AWS GOOG<...>:<...>=\r\nDate: Mon, 16 Mar 2015 01:41:38 GMT\r\nHost: jlebar-backup-annex-nearline-test.storage.googleapis.com\r\nContent-Type: \r\nx-amz-storage-class: STANDARD\r\nContent-Length: 36\r\n\r\n<...>
And the (rather unhelpful) HTTP response:
HTTP/1.1 400 Bad Request\r\nContent-Type: application/xml; charset=UTF-8\r\nContent-Length: 117\r\nVary: Origin\r\nDate: Mon, 16 Mar 2015 01:41:38 GMT\r\nServer: UploadServer (\"Built on Feb 27 2015 12:13:16 (1425067996)\")\r\nAlternate-Protocol: 80:quic,p=0.5\r\n\r\n<?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidArgument</Code><Message>Invalid argument.</ Message></Error>
[[!format sh """
$ AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY="..." git annex --debug initremote test encryption=none bucket=<DRA bucket> type=S3 host=storage.googleapis.com
[2015-03-15 19:12:19 PDT] read: git ["--git-dir=.git","--work-tree=.","show-ref","git-annex"]
[2015-03-15 19:12:19 PDT] read: git ["--git-dir=.git","--work-tree=.","show-ref","--hash","refs/heads/git-annex"]
[2015-03-15 19:12:19 PDT] read: git ["--git-dir=.git","--work-tree=.","log","refs/heads/git-annex..d7640d68e3bd55735fb275816df0b94ec05031a7","-n1","--pretty=%H"]
[2015-03-15 19:12:20 PDT] chat: git ["--git-dir=.git","--work-tree=.","cat-file","--batch"]
initremote test (checking bucket...) git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "InvalidArgument", s3ErrorMessage = "Invalid argument.", s3ErrorResource = Nothing, s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing}
# End of transcript or log.
"""]]
> [[dup|done]] of [[todo/Nearline_support]] --[[Joey]]

46
doc/bugs/Can__39__t_keep_gpg_quiet.mdwn
View file

@ -1,46 +0,0 @@
### Please describe the problem.
Can't seem to stop gpg writing it's progress/info messages out
### What steps will reproduce the problem?
Use a gcrypt-remote, do a git sync
### What version of git-annex are you using? On what operating system?
Arch Linux, stable, updated daily.
git-annex 6.20160613-8
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
I have the following in my config, but I still get the standard gnupg noise produced. I have read that work was done to propogate the gnupg-options and gnupg-decrypt-options through to the required places (in May, and I'm on a June version), but it doesn't appear to work for me.
[annex]
uuid = 583acd1e-f969-4b7b-89d5-7a4aff9a7077
version = 6
gnupg-options = --quiet --batch --no-tty
gnupg-decrypt-options = --quiet --batch --no-tty
I still get the output, which I shouldn't@
gcrypt: Decrypting manifest
gpg: Signature made Sun 02 Oct 2016 21:04:31 BST
gpg: using RSA key XXXYYYZZZ
gpg: Good signature from "x <xx@x.x>" [ultimate]
gpg: aka "[jpeg image of size 2004]" [ultimate]
# 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)
Mixed bag, works when it works, but I've had quite a few "unexplained" happenings. Perservering for now, hoping me reporting bugs will see things improve...
> [[done]]; gcrypt.gpg-args is the answer. --[[Joey]]

18
doc/bugs/Can__39__t_keep_gpg_quiet/comment_1_ab0ffdf17fb5caf8db70b77220878a1b._comment
View file

@ -1,18 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2016-10-17T20:32:02Z"
content="""
The gnupg-options and gnupg-decrypt-options only apply when git-annex
is running gpg, not when git-annex is running git push which is running
git-remote-gcrypt which is running gpg.
I don't think there's any way to pass gpg options through that chain of
programs. Even if there is, I don't know that it would make sense to use
the git-annex configuration, which normally is used when git-annex is using
gpg in symmetric encryption mode, for git-remote-gcrypt, which is using gpg
in pubic key encryption mode.
I think you should just set gcrypt.gpg-args to whatever options are
appropriate for its use of gpg.
"""]]

106
doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn
View file

@ -1,106 +0,0 @@
### Please describe the problem.
Git-annex with v6 repo causes weird file creation behavior.
### What steps will reproduce the problem?
On central repo:
git init --bare central6
cd central6
git annex init origin
git annex upgrade
On Client A
git clone {central6 repo path/URI}
cd central6
git annex init clientA6
git annex upgrade
On Client B
git clone {central6 repo path/URI}
cd central6
git annex init clientB6
git annex upgrade
Start assistant on both clients.
Start webapp on both clients.
Add files to both clients.
Wait for assistant to sync new files.
Force sync with webapp on both clients
At this point examine files coming from the central repo on the non-originating client. I see:
Client A originated file:
-rw-rw-r--. 1 user group 92528731 May 10 20:16 image.png
Client B created file:
-rw-rw-r--. 1 user group 103 May 10 20:21 image.png
Here's the content of Client B's file:
/annex/objects/SHA256E-s92528731--098928032fddbd0327c1d608249a133e276a00b8aa8bffca371bd32bded49777.png
### What version of git-annex are you using? On what operating system?
Linux (Fedora 23/CentOS 7)
[[!format sh """
git-annex version: 6.20160428-g1f253e8
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: 6
supported repository versions: 5 6
upgrade supported from repository versions: 0 1 2 4 5
"""]]
### Please provide any additional information below.
[[!format sh """
# Client B
[2016-05-10 20:09:51.879642] main: starting assistant version 6.20160428-g1f253e8
[2016-05-10 20:09:52.127709] Cronner: You should enable consistency checking to protect your data.
[2016-05-10 20:09:57.340186] TransferScanner: Syncing with origin
(scanning...) [2016-05-10 20:09:58.182781] Watcher: Performing startup scan
(started...)
merge: refs/remotes/origin/master - not something we can merge
merge: refs/remotes/origin/synced/master - not something we can merge
gpg: Signature made Thu 28 Apr 2016 10:44:48 AM EDT using DSA key ID 89C809CB
gpg: /tmp/git-annex-gpg.tmpOTZtDq/trustdb.gpg: trustdb created
gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4005 5C6A FD2D 526B 2961 E78F 5EE1 DBA7 89C8 09CB
git-annex: Daemon is already running.
[2016-05-10 20:21:19.633914] main: Syncing with origin
From /smb/r7000/USB_Storage/tmp/git-annex/central6
7f1d48c..3e6f240 git-annex -> origin/git-annex
* [new branch] master -> origin/master
* [new branch] synced/git-annex -> origin/synced/git-annex
* [new branch] synced/master -> origin/synced/master
(merging origin/git-annex into git-annex...)
(recording state in git...)
Already up-to-date.
[2016-05-10 20:21:23.337732] Pusher: Syncing with origin
To /smb/r7000/USB_Storage/tmp/git-annex/central6
3e6f240..358afc3 git-annex -> synced/git-annex
[2016-05-10 20:21:25.056294] Committer: Adding image.png
add image.png ok
[2016-05-10 20:21:25.543293] Committer: Committing changes to git
(recording state in git...)
SHA256E-s103--d7d52e9de4a9c7c030743825c3a1ca072062e4ccadefcf1eb34be3004360b9b2.png
103 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
(checksum...) [2016-05-10 20:21:27.240904] Transferrer: Uploaded image.png
[2016-05-10 20:21:27.787233] Pusher: Syncing with origin
[2016-05-10 20:21:28.12119] Committer: Adding image.png
(recording state in git...)
add image.png ok
[2016-05-10 20:21:28.696135] Committer: Committing changes to git
(recording state in git...)
To /smb/r7000/USB_Storage/tmp/git-annex/central6
358afc3..e3ef364 git-annex -> synced/git-annex
15d9319..976e99f master -> synced/master
[2016-05-10 20:21:32.584488] Pusher: Syncing with origin
Everything up-to-date
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
It seems to work really well on v5, but the v6 file "corruption" is difficult to recover from.
> [[fixed|done]] --[[Joey]]

43
doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__/comment_1_b11a50f945002f536ca43b181195c580._comment
View file

@ -1,43 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2016-05-12T19:15:28Z"
content="""
I'd recommend not using the assistant with v6 repos yet. v6 is
still considered experimental.
In v6 mode, the "/annex/objects/" file content means that an unlocked file's
content is not locally available yet.
I reproduced this, and here's the log for a single file "bar" which was
created on clientA:
<pre>
commit 2806e7c46e1df2bfd35ae22cf399a222957caa83
Author: Joey Hess <joeyh@joeyh.name>
Date: Thu May 12 15:18:28 2016 -0400
git-annex in clientB
bar | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit 99160180e14d3920e2b7ce4ded12b86057a8923f
Author: Joey Hess <joeyh@joeyh.name>
Date: Thu May 12 15:18:24 2016 -0400
git-annex in clientA
bar | 1 +
1 file changed, 1 insertion(+)
</pre>
So, it looks like clientB changed it for some reason.
-/annex/objects/SHA256E-s30--325229d85342c107421616848843592c2c1335d4d4e429b2805765af07de59be
+/annex/objects/SHA256E-s93--7493e6fd3acc936ff943283df9aa82ba3ad5f94e3c3168c2599f4fdf9a8c504d
And, 7493e6fd3acc936ff943283df9aa82ba3ad5f94e3c3168c2599f4fdf9a8c504d is the sha256sum of
"/annex/objects/SHA256E-s30--325229d85342c107421616848843592c2c1335d4d4e429b2805765af07de59be\n", so
it's getting confused and re-adding pointer files, it seems.
"""]]

33
doc/bugs/Doesn__39__t_build_with_QuickCheck_2.8.2.mdwn
View file

@ -1,33 +0,0 @@
### Please describe the problem.
I am getting build errors when trying to compile git-annex with QuickCheck 2.8.2.
### What steps will reproduce the problem?
Build git-annex with QuickCheck 2.8.2, and get the following errors:
[ 30 of 535] Compiling Utility.QuickCheck ( Utility/QuickCheck.hs, dist/build/git-annex/git-annex-tmp/Utility/QuickCheck.o )
Utility/QuickCheck.hs:24:10:
Duplicate instance declarations:
instance (Arbitrary k, Arbitrary v, Eq k, Ord k) =>
Arbitrary (M.Map k v)
-- Defined at Utility/QuickCheck.hs:24:10
instance [safe] (Ord k, Arbitrary k, Arbitrary v) =>
Arbitrary (M.Map k v)
-- Defined in `Test.QuickCheck.Arbitrary'
Utility/QuickCheck.hs:27:10:
Duplicate instance declarations:
instance (Arbitrary v, Eq v, Ord v) => Arbitrary (S.Set v)
-- Defined at Utility/QuickCheck.hs:27:10
instance [safe] (Ord a, Arbitrary a) => Arbitrary (S.Set a)
-- Defined in `Test.QuickCheck.Arbitrary'
### What version of git-annex are you using? On what operating system?
git-annex 6.20160114, on Arch Linux x86_64.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes, it built fine with QuickCheck 2.8. I didn't test with 2.8.1, though.
> ifdefed those instances out with this version of quickcheck. [[done]]
> --[[Joey]]

64
doc/bugs/External_special_remote_broken__63__.mdwn
View file

@ -1,64 +0,0 @@
[[!meta title="encrypted key not checked when resuming upload to chunked encrypted special remote"]]
### Please describe the problem.
Resuming an upload seems not to work when used with chunking. Here is some sample conservation:
[2016-04-26 21:26:14.465287] chat: git-annex-remote-rclone []
[2016-04-26 21:26:14.468527] git-annex-remote-rclone --> VERSION 1
[2016-04-26 21:26:14.468726] git-annex-remote-rclone <-- PREPARE
[2016-04-26 21:26:14.469533] git-annex-remote-rclone --> GETCONFIG prefix
[2016-04-26 21:26:14.469741] git-annex-remote-rclone <-- VALUE annex.datengrotte
[2016-04-26 21:26:14.475725] git-annex-remote-rclone --> GETCONFIG target
[2016-04-26 21:26:14.47597] git-annex-remote-rclone <-- VALUE hubic
[2016-04-26 21:26:14.481164] git-annex-remote-rclone --> PREPARE-SUCCESS
[2016-04-26 21:26:14.485361] git-annex-remote-rclone <-- CHECKPRESENT GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
[2016-04-26 21:26:14.485831] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
[2016-04-26 21:26:14.485937] git-annex-remote-rclone <-- VALUE GM/2k/
[2016-04-26 21:26:25.571228] git-annex-remote-rclone --> CHECKPRESENT-FAILURE GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
[2016-04-26 21:26:25.5726] git-annex-remote-rclone <-- CHECKPRESENT SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
[2016-04-26 21:26:25.57296] git-annex-remote-rclone --> DIRHASH SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
[2016-04-26 21:26:25.573207] git-annex-remote-rclone <-- VALUE 1v/zK/
[2016-04-26 21:26:27.392524] git-annex-remote-rclone --> CHECKPRESENT-FAILURE SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
[2016-04-26 21:26:27.393076] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","23","--symmetric","--force-mdc","--no-textmode"]
[2016-04-26 21:26:31.103132] git-annex-remote-rclone <-- TRANSFER STORE GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100 ../.git/annex/tmp/GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
[2016-04-26 21:26:31.103773] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
[2016-04-26 21:26:31.103888] git-annex-remote-rclone <-- VALUE 8Q/Z9/
There are some steps that do not get in my mind:
1. What is the first "CHECKPRESENT GPGHMACSHA1" good for? The full file including all chunks?
2. Second: Why is git-annex looking for "CHECKPRESENT SHA256E", the plain file (not encrypted)?
3. And now the 'real' problem: git-annex does a "TRANSFER STORE" of some key, but does not first check with CHECKPRESENT if it's there. And indeed, this file is already in the repo, so a "CHECKPRESENT GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100" would return true in my case. Therefore it reuploads all my data, which is not so great ;P.
### What version of git-annex are you using? On what operating system?
it-annex version: 6.20160418-geff8673
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: 6
supported repository versions: 5 6
upgrade supported from repository versions: 0 1 2 4 5
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
> [[fixed|done]] --[[Joey]]

15
doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment
View file

@ -1,15 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2016-04-27T16:23:43Z"
content="""
Reproduced this using a directory special remote.
The first checkpresent is because a file can be present on a remote in
non-chunked form, since a remote can be reconfigured to add chunking.
So it's nothing to worry about.
The lack of encryption of the key when checking to resume is definitely a
bug. A bit of a security bug too.
(I double checked the other operations and they all encrypt keys)
"""]]

138
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications.mdwn
View file

@ -1,138 +0,0 @@
The Date resolution of the FAT filesystem is only 2 seconds for the "last modified time."
This leads to the strange behaviour, that after umount and remount of an usb drive (direct mode) git-annex thinks that suddenly approx. 50% of
the files are modified. (after remount the "seconds" appears to be rounded to even values - the inode cache before unmount had 1 second resolution) So git-annex is not real "guilty" but it would be fine to create a "workaround" for this problem...
Possible the best solution for this is to set even values for the seconds in the filesystem and in annex internal tables direct after the `git annex get`.
Other solution would be to treat differences up to 1s in modification time as unmodified or create an new parameter like rsync's "modify-window" for this. To do an `git annex sync` or `git annex add` is in my opinion not a good option, because one could add so Bad file content by accident...
Here's an konsole session to show this behaviour:
$ mount /mnt/transfer/
$ git clone source/ /mnt/transfer/transfer-repo
Klone nach '/mnt/transfer/transfer-repo'...
Fertig.
$ cd /mnt/transfer/transfer-repo/
$ git annex init "test"
init test
Detected a filesystem without fifo support.
Disabling ssh connection caching.
Detected a crippled filesystem.
Enabling direct mode.
ok
(Recording state in git...)
$ git annex group here transfer
group here (merging origin/git-annex into git-annex...)
(Recording state in git...)
ok
(Recording state in git...)
$ git annex wanted here standard
wanted here ok
(Recording state in git...)
$ git annex get --auto
get n01.mp3 (from origin...)
SHA256E-s1159018--5674452792970dc03e9ba47d3a8af5ad7c8da6b3ca19e8e64b9a4cf462d4a92d.mp3
1159018 100% 82.62MB/s 0:00:00 (xfer#1, to-check=0/1)
sent 1159308 bytes received 31 bytes 2318678.00 bytes/sec
total size is 1159018 speedup is 1.00
ok
get n02.mp3 (from origin...)
SHA256E-s1622113--03998dc10c4839d5ab9aeaceaa63f0363c9d728aaaca2a2707f025c7b9e920a3.mp3
1622113 100% 34.45MB/s 0:00:00 (xfer#1, to-check=0/1)
sent 1622459 bytes received 31 bytes 3244980.00 bytes/sec
total size is 1622113 speedup is 1.00
ok
...
...
–--> All 29 files (n01.mp3 to n29.mp3) successfully got
(Recording state in git...)
$ git annex status
$ stat * >../stat-before-umount
$ cd /
$ umount /mnt/transfer
$ mount /mnt/transfer
$ cd /mnt/transfer/transfer-repo
$ stat * >../stat-after-remount
$ git annex status
M n05.mp3
M n10.mp3
M n11.mp3
M n13.mp3
M n16.mp3
M n17.mp3
M n20.mp3
M n22.mp3
M n23.mp3
M n24.mp3
M n26.mp3
M n27.mp3
$ diff -u ../stat-before-umount ../stat-after-remount | grep -B8 "+Modifiziert" | grep -E "Datei:|Modifi"
Datei: „n05.mp3“
-Modifiziert: 2014-05-03 19:42:39.000000000 +0200
+Modifiziert: 2014-05-03 19:42:38.000000000 +0200
Datei: „n10.mp3“
-Modifiziert: 2014-05-03 19:43:05.000000000 +0200
+Modifiziert: 2014-05-03 19:43:04.000000000 +0200
Datei: „n11.mp3“
-Modifiziert: 2014-05-03 19:43:07.000000000 +0200
+Modifiziert: 2014-05-03 19:43:06.000000000 +0200
Datei: „n13.mp3“
-Modifiziert: 2014-05-03 19:43:15.000000000 +0200
+Modifiziert: 2014-05-03 19:43:14.000000000 +0200
Datei: „n16.mp3“
-Modifiziert: 2014-05-03 19:43:21.000000000 +0200
+Modifiziert: 2014-05-03 19:43:20.000000000 +0200
Datei: „n17.mp3“
-Modifiziert: 2014-05-03 19:43:29.000000000 +0200
+Modifiziert: 2014-05-03 19:43:28.000000000 +0200
Datei: „n20.mp3“
-Modifiziert: 2014-05-03 19:43:53.000000000 +0200
+Modifiziert: 2014-05-03 19:43:52.000000000 +0200
Datei: „n22.mp3“
-Modifiziert: 2014-05-03 19:44:13.000000000 +0200
+Modifiziert: 2014-05-03 19:44:12.000000000 +0200
Datei: „n23.mp3“
-Modifiziert: 2014-05-03 19:44:23.000000000 +0200
+Modifiziert: 2014-05-03 19:44:22.000000000 +0200
Datei: „n24.mp3“
-Modifiziert: 2014-05-03 19:44:31.000000000 +0200
+Modifiziert: 2014-05-03 19:44:30.000000000 +0200
Datei: „n26.mp3“
-Modifiziert: 2014-05-03 19:44:35.000000000 +0200
+Modifiziert: 2014-05-03 19:44:34.000000000 +0200
Datei: „n27.mp3“
-Modifiziert: 2014-05-03 19:44:39.000000000 +0200
+Modifiziert: 2014-05-03 19:44:38.000000000 +0200
> fixed [[done]] --[[Joey]]

18
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_10_13a35801805ea3d2d4428b1539f96b16._comment
View file

@ -1,18 +0,0 @@
[[!comment format=mdwn
username="martin"
ip="193.174.111.250"
subject="specification"
date="2014-06-11T05:43:02Z"
content="""
What you suggested (to not add if exact 1s or exact 1h time difference and changed checksum) would do the trick but it's hard for the user to test if this really works as expected and it would be more secure and IMHO more clear to do it like this:
If `git annex add` \"meets\" such files, `git annex add` should not really add / commit these pseudo-modified files but *only adapt the timestamps* (which make the software erroneously thinks the files were modified) to the vfat values. (if checksum is still correct) I guess the timestamps are in the annex branch.
`git annex add` could - instead of write: \"add ok\" - only write: \"corrected timestamp ok - no need to add\"
So the user sees whats really happen and after this these files appears again as what they are: unmodified. `git annex status` would say nothing (everything fine), and `git annex fsck` would checksum these files again.
I suppose that the way i suggest is harder to code :-( Unfortunately I'm not a good coder and not experienced in haskell for sending a patch myself / the open source way...
"""]]

14
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_11_632456a0a1d399ee2bbac76b7d63a5f1._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 11"
date="2014-06-11T17:22:12Z"
content="""
@martin, to the best of my knowledge and testing, what you're proposing `git annex add` do in this case is identical to what it already happens to do, except for the message displayed.
Do you have an example of it not doing that?
We seem to be talking past one-another, since I've now said three times this is what it does. And I've tested it twice.
I don't think that the current behavior of add, or your suggested behavior (which again, happens to be nearly identical) is sufficient to close this bug report with.
"""]]

23
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment
View file

@ -1,23 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 12"
date="2014-06-11T18:05:48Z"
content="""
The resolution problem does not seems to affect Windows, at least not on NTFS. In my tests, the mtime is fully preserved across reboots there.
However, any change to the timezone on Windows does manage to mess up all the timestamps. Presumably this same flawed approach is used for DST adjustments.
Example from inode cache after a 1 hour time zone change, which forced git-annex add to re-checksum:
<pre>
--1 2221 1395843799
+-1 2221 1395847399
</pre>
Of course, not all time zones are 1 hour offset, so as a heuristic, treating timestamps +- 60*60*Int as the same, would be pretty bad. Instead, it would probably make sense, on windows, to normalize the timestamp, using the current time zone, to get to the UTC timestamp. (Of course on unix, a file's timestamp is always given in UTC.)
Unfortunately, Data.Time.LocalTime.getCurrentTimeZone doesn't seem to really work on windows. It always returns UTC+1 in my tests.
Anyway, I'm now looking at this as two separate problems, the Windows Time Zone Sucks problem and the FAT Metadata Sucks problem. They will probably have different solutions..
"""]]

16
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_13_962cd8d7280cbc1d61778d69f3a393f0._comment
View file

@ -1,16 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="FAT MetaData Sucks: an approach"
date="2014-06-11T18:15:59Z"
content="""
git-annex already deals with FAT metadata sucking by using the inode sentinal file, to detect when a FAT filesystem has been remounted with new random inodes, and so ignore apparent inode changes.
So, when a InodeCache is compared in weak mode due to that, it could just treat all mtimes within 2 seconds as the same. This would limit the brain-damange to FAT.
One problem with this idea is that it's specific to linux's handling of FAT, with its random inodes. A FAT mounted on windows will have -1 for the inodes across remounts. So this method can't detect if a filesystem on windows is FAT, and has the problem, or NTFS and not.
But, I think the FAT side of this problem is also linux-specific. Linux dummies up good metadata for FAT, and then has to throw it away/degrade on unmount. Windows presumably uses real timestamps, with low resolution on FAT from the beginning.
I don't know how eg OSX handles this. If it used constant inodes but cached higher resolution mtimes for FAT, this approach would not work there.
"""]]

10
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_14_5b3bb068b62b12c7cc7504836a8acf32._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 14"
date="2014-06-11T18:59:49Z"
content="""
Opened a separate bug for [[Windows_file_timestamp_timezone_madness]].
Fixed FAT issue on Linux as discussed in my previous comment.
"""]]

19
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_15_5271ba4eed013adec8391ddfcc11eda8._comment
View file

@ -1,19 +0,0 @@
[[!comment format=mdwn
username="martin"
ip="89.183.21.108"
subject="In reply to comment 11"
date="2014-06-12T09:22:53Z"
content="""
Dear joey,
thanks a lot for fixing this!
Only for this protocol (not to have the last word ;-)
What `git annex add` already does now and what i suggested it could do better is indead the same (result) for uncorrupted files (the frequent case).
But i'am afraid, it could be slightly different if we deal with corrupted files. The preset behaviour would add this file, the suggested behaviour would not...
But this discussion is history now - i'm lucky :-))
Now i do some tests with daylight savings time change - hopefully there are no problems!
"""]]

8
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_1_7a536b79bae7d8f897f014d17dbb90b6._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="zardoz"
ip="92.227.51.179"
subject="comment 1"
date="2014-05-13T16:50:57Z"
content="""
A related issue is that a change from/to daylight-saving time will make files appear to be one hour older/younger. A modify-window couldn’t acommodate that. VFAT is really a huge pain…
"""]]

16
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_2_349959a6daa722c8350f73feb0b27162._comment
View file

@ -1,16 +0,0 @@
[[!comment format=mdwn
username="martin"
ip="89.183.46.169"
subject="Possible solution?"
date="2014-05-13T17:51:41Z"
content="""
How about this quick'n dirty vfat compromise:
For vfat only we do like this (at least for `git annex fsck` command, so that the user doesn't wonder about the strange effects of vfat and can repair this):
if we have an exact time difference of 1s (probably \"inode problem\") or 1h (\"utc problem\")
we treat this file as likely unmodified and check this via the normal checksum algorithm.
if checksum is ok, we give a message to the user, that the \"file has only a vfat timestamp problem\" but has correct checksum and if the user decides to do so git annex sets the timestamp in the filesystem to the value from annex' internal tables...
"""]]

22
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_3_923fc470727ecf21f0bb368b0486b15d._comment
View file

@ -1,22 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 3"
date="2014-06-05T17:06:40Z"
content="""
> if we have an exact time difference of 1s (probably \"inode problem\") or 1h (\"utc problem\") we treat this file as likely unmodified and check this via the normal checksum algorithm.
That sort of makes sense, but when is git-annex supposed to do that?
If `git annex add`, it already checksums the file, and already stages no change if the file's checksum is the same. And if the user has told git-annex to add the file and it's changed, the presumption is they know it's changed and want to add the new version.
> To do an git annex sync or git annex add is in my opinion not a good option, because one could add so Bad file content by accident...
If not in add or sync, then when?
----
I am actually having a hard time coming up with a scenario where this problem results in any more than extra checksumming work by git-annex.
The only scenario I see is: The drive is unmounted, gets corrupted, is remounted, and this timestamp nonsense causes git-annex to think a file (that has already gotten corrupted) has in fact changed, so it commits the corrupted version.
"""]]

8
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_4_68a8434018430a0d2671c4e23e9a3b12._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="martin"
ip="193.174.111.250"
subject="It confuses users"
date="2014-06-05T19:05:12Z"
content="""
Other scenario: User thinks, that his usb drive has a problem, because approx. 50% of the files are gone/changed without obvious reason. I spent several hours to find the reason for this... I think we should at least give kind of explanation/warning message to the user
"""]]

8
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_5_0b7d69489b9f10bb5ed617b5b62ae063._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="martin"
ip="193.174.111.250"
subject="another scenario"
date="2014-06-05T19:52:04Z"
content="""
If a user uses such a crippled filesystem as a transfer repo and he does an `git-annex get --auto` on the target pc for getting the content he gets only 50% of the content. (user gets only a strange message that git-annex cannot access the repo or something like this) The user does not have the intuition to do an extra `git-annex add` to get the content because from his perspective he did not made any changes... (sorry for my bad english - i hope you know what i mean)
"""]]

22
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment
View file

@ -1,22 +0,0 @@
[[!comment format=mdwn
username="martin"
ip="89.183.56.177"
subject="use case and answer to joey's question &quot;...then when...&quot;"
date="2014-06-08T04:59:42Z"
content="""
Hi joey,
i really think we should repair the timestamp instead of force the user to `git-annex add` possibly corrupted files/content (see your comment above) git-annex checksums are excellent for data integrity but they are useless if we bypass them in case of adding and propagating
potentially corrupted content with `git-annex add`
So here's for example a useful use case:
1. user fills his transfer repo in town A. He checks (`git annex fsck`) that everything is fine. He unmounts the drive and travels to town B.
2. In town B user mounts the drive and sees, that he suddenly doesn't have \"access\" to those \"crippled files\" on his transfer repo (the files seems modified for the user without a reason - why should he `git-annex add` them again?? - he'd rather think about data corruption) . He wonders whats going on and thats why he does a
3. `git-annex fsck` . `git annex fsck` should checksum also such crippled files, should report correct checksums if they are correct (so that the users knows their usb drive is working properly) and should give a message like this: \"checksum ok - crippled timestamp - repair with git-annex fsck --repair-timestamp or define a modify window \"- (to be implemented - in rsync the problem is already solved with this option \"--modify-window=NUM compare mod-times with reduced accuracy\")
In my case distance between town B and town A was approx 400km and in town B i didnt know what was going on. So i went back to town A without success for further investigation of my usb drive... :-((
"""]]

8
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_7_834c512e32ad5a157d8fa9fd472831b4._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 7"
date="2014-06-09T19:29:09Z"
content="""
A transfer repository is normally bare, so would not have this problem.
"""]]

41
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_8_2500e6f9545b916dfa41549140c053fd._comment
View file

@ -1,41 +0,0 @@
[[!comment format=mdwn
username="martin"
ip="89.183.78.73"
subject="`git-annex add` (called by sync) should do the job and bring the files back home (IMHO)"
date="2014-06-10T15:58:25Z"
content="""
If one does an `git annex sync` these crippled-pseudo-modified-files are *automatically* `git annex add`ed
git annex status
M datei1
M datei5
M datei6
git annex sync
commit add datei1 ok
add datei5 ok
add datei6 ok
To avoid the risk of adding and propagating potentially corrupted content `git-annex add` should
\"simply\" correct the timestamps (adjust to the new even inode values) for files with correct checksum but timestamp
difference of 1s or 1h
With this procedure i would have better sleep with this personal second use case:
repo1: on the computer (direct mode - client)
repo2: on usb stick - (direct mode - client - vfat - music for car)
From time to time mp3 files are transferred to the stick. Then stick
goes to the car and after some days back to the computer to be
synchronized again. Everytime approx. 50% of the recently new added files are
added again (via sync) because of these nonsens timestamps.
So i think, the clean solution is to correct only the timestamps instead
of adding again possibly corrupted files. If we dont do this users adapt to
add files again and again (they need not to be added) and one day they
add corrupted content. Like on windows (tm) you klick OK and OK again and
here you add again and again and one day one add once too much ;-)
Excuse me for this long comment...
P.S. git annex is an ingenious piece of software - thanks a lot for this joey!
"""]]

10
doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_9_e2dc3ff80bbd66837f00975b16e17126._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 9"
date="2014-06-10T19:27:55Z"
content="""
> To avoid the risk of adding and propagating potentially corrupted content git-annex add should \"simply\" correct the timestamps (adjust to the new even inode values) for files with correct checksum but timestamp difference of 1s or 1h
Since git-annex add already does that in this case, I think what you're actually suggesting is that, if the timestamp has a 1s or 1h diff, but the checksum has changed, git-annex add should refuse to add the files, on the grounds that it appears to be corrupt. Which obviously fails badly in at least the 1h case, because someone could add a file, then wait 1 hour and git-annex add a modified version.
"""]]

28
doc/bugs/Failed_to_compile_with_shakespeare_2.0.12.mdwn
View file

@ -1,28 +0,0 @@
[365 of 557] Compiling Assistant.WebApp.Form ( Assistant/WebApp/Form.hs, dist/build/git-annex/git-annex-tmp/Assistant/WebApp/Form.o )
Assistant/WebApp/Form.hs:61:60: error:
* Exception when trying to run compile-time code:
"
<a .btn .btn-default data-toggle="collapse" data-target="##{ident}">#{toggle}</a>
<div ##{ident} .collapse>
^{note}
" (line 2, column 45):
unexpected "d"
expecting ">"
CallStack (from HasCallStack):
error, called at ./Text/Hamlet.hs:421:21 in shakespeare-2.0.12-4ppL9xZ9sKD6RsPGnrhiq:Text.Hamlet
Code: Language.Haskell.TH.Quote.quoteExp
whamlet
"\n\
\<a .btn .btn-default data-toggle=\"collapse\" data-target=\"##{ident}\">#{toggle}</a>\n\
\<div ##{ident} .collapse>\n\
\ ^{note}\n"
* In the quasi-quotation:
[whamlet|
<a .btn .btn-default data-toggle="collapse" data-target="##{ident}">#{toggle}</a>
<div ##{ident} .collapse>
^{note}
|]
[[done]]

15
doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_1_5a8a92244018618134d1851c561c54c6._comment
View file

@ -1,15 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2016-12-27T21:19:35Z"
content="""
Seems that it's choking on the data-target arrtibute.
Is that legal HTML? It's used by Bootstrap.
In any case, it's strange that the new minor version of
Hamlet started choking on that when it didn't before.
See upstream issue which has a fix already:
<https://github.com/yesodweb/shakespeare/issues/200>
"""]]

9
doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_2_007f09c0bd8bb64a8e2c8f60b1a71612._comment
View file

@ -1,9 +0,0 @@
[[!comment format=mdwn
username="https://launchpad.net/~felixonmars"
nickname="felixonmars"
avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38"
subject="comment 2"
date="2016-12-28T03:04:52Z"
content="""
Thank you. I have patched shakespeare with that patch, and all went fine afterwards.
"""]]

52
doc/bugs/Files_in___34__here__34___not_known_to_git_annex.mdwn
View file

@ -1,52 +0,0 @@
### Please describe the problem.
Not sure how I created this mess. But here, I have my git annex repository:
$ cat .git/config
[annex]
uuid = 206e9fb3-0c68-4c45-a3d7-dad1d9425d28
version = 5
And judging from this, I would expect the file to be present:
$ git annex log Movies/Bad\ Taste\ -\ Englisch.avi
- 2015-10-28 20:51:42 Movies/Bad Taste - Englisch.avi | f53b3f8a-0f04-11e1-93ae-136c6986c818 -- jeff-media [kent]
+ 2014-10-13 00:12:50 Movies/Bad Taste - Englisch.avi | 206e9fb3-0c68-4c45-a3d7-dad1d9425d28 -- 1T
+ 2011-12-24 13:38:23 Movies/Bad Taste - Englisch.avi | 9dd8c662-296d-11e1-b28a-f3c66fd5e263 -- 500G
- 2011-12-18 14:59:38 Movies/Bad Taste - Englisch.avi | 9dd8c662-296d-11e1-b28a-f3c66fd5e263 -- 500G
+ 2011-12-18 12:48:17 Movies/Bad Taste - Englisch.avi | 9dd8c662-296d-11e1-b28a-f3c66fd5e263 -- 500G
+ 2011-11-14 22:15:57 Movies/Bad Taste - Englisch.avi | f53b3f8a-0f04-11e1-93ae-136c6986c818 -- jeff-media [kent]
$ ls -l Movies/Bad\ Taste\ -\ Englisch.avi
lrwxrwxrwx 1 jojo jojo 135 Okt 7 2014 Movies/Bad Taste - Englisch.avi -> ../.git/annex/objects/Wx/P0/WORM-s723351552-m1100368371--Bad Taste - Englisch.avi/WORM-s723351552-m1100368371--Bad Taste - Englisch.avi
$ ls -shL Movies/Bad\ Taste\ -\ Englisch.avi
690M Movies/Bad Taste - Englisch.avi
But git annex seems to be very confused:
$ git annex whereis Movies/Bad\ Taste\ -\ Englisch.avi
whereis Movies/Bad Taste - Englisch.avi (0 copies) failed
git-annex: whereis: 1 failed
$ git annex list Movies/Bad\ Taste\ -\ Englisch.avi
here
|kent-direct
||kent
|||web
||||bittorrent
|||||
_____ Movies/Bad Taste - Englisch.avi
$ git annex fsck Movies/Bad\ Taste\ -\ Englisch.avi
fsck Movies/Bad Taste - Englisch.avi (fixing location log)
** No known copies exist of Movies/Bad Taste - Englisch.avi
failed
(recording state in git...)
git-annex: fsck: 1 failed
The `fsck` call does not change anything about the problem.
File system is ext4.
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20151019-1, Debian unstable.
> improved fsck output [[done]] --[[Joey]]

41
doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_1_d72e2db413d0bc4179c50eaf7550f071._comment
View file

@ -1,41 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-11-02T15:28:09Z"
content="""
All the output of `git annex log`, `git annex whereis` and `git annex list`
seems internally consistent. Which makes sense as there are 3 different
views of the exact same data. Note that while `git annex log`
shows 2 repositories "1T" and "500G" that contain the file, I guess those
are both marked as dead, since whereis skipps dead repos and doesn't
show them. So, that's all red herrings.
The problem then is that fsck seems to say "fixing location log" but then
apparently doesn't fix it, since it still complains the file is missing
despite its contents being present.
I have replicated the situation but I don't reproduce that happening:
joey@darkstar:~/tmp/r>git annex setpresentkey WORM-s30-m1446479598--Bad\ Taste\ -\ Englisch.avi ebce24f6-3a26-4881-8855-62a0e0d33869 0
setpresentkey WORM-s30-m1446479598--Bad Taste - Englisch.avi ok
joey@darkstar:~/tmp/r>git annex whereis Movies/Bad\ Taste\ -\ Englisch.avi
whereis Movies/Bad Taste - Englisch.avi (0 copies) failed
git-annex: whereis: 1 failed
joey@darkstar:~/tmp/r>git annex fsck
fsck Movies/Bad Taste - Englisch.avi (fixing location log) ok
(recording state in git...)
joey@darkstar:~/tmp/r>git annex whereis
whereis Movies/Bad Taste - Englisch.avi (1 copy)
ebce24f6-3a26-4881-8855-62a0e0d33869 -- joey@darkstar:~/tmp/r [here]
ok
Please show the commit that fsck makes to the git-annex branch. Ie,
`git show git-annex` after running fsck. In my example above, that commit included:
--- a/33f/807/WORM-s30-m1446479598--Bad Taste - Englisch.avi.log
+++ b/33f/807/WORM-s30-m1446479598--Bad Taste - Englisch.avi.log
@@ -1 +1 @@
-1446479600.453526s 0 ebce24f6-3a26-4881-8855-62a0e0d33869
+1446479680.344119s 1 ebce24f6-3a26-4881-8855-62a0e0d33869
"""]]

16
doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_2_10b21c1565759c687b562721ed2cc5b8._comment
View file

@ -1,16 +0,0 @@
[[!comment format=mdwn
username="http://www.joachim-breitner.de/"
nickname="nomeata"
subject="comment 2"
date="2015-11-07T09:02:08Z"
content="""
> I guess those are both marked as dead, since whereis skipps dead repos and doesn't show them.
Well, only `500G` should be marked as dead, not `1T` – that is the repository I am working in!...
And indeed, `git annex semitrust 1T` solved it.
Maybe at one point I had re-used uuids, because I was copying repositories?
So this might have been an issue with PEBKAC, although maybe git-annex could warn, for examle in `git annex fsck` or in other commands, if the current repository is marked dead, or in `git annex sync` if very much alive looking remotes are marked as dead.
"""]]

16
doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_3_3b94625acd0fda06545243d9c163cfba._comment
View file

@ -1,16 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2015-11-10T18:06:36Z"
content="""
Aha, there is a bug indeed; fscking a dead repository always claims to
be "fixing location log", but the location log is fine and doesn't need
fixing. Fixed that.
As to discovering when you're in a dead repository, there are a lot of
things that could be done, but most of them seem to add special cases
that are complicating both to implement and for parsing the resulting
output (like putting "(dead)" next to the description/name of a
dead repository). Seems reasonable to have fsck note when the repository
it's checking is dead, and leave it at that.
"""]]

44
doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__.mdwn
View file

@ -1,44 +0,0 @@
### Please describe the problem.
Using the webapp to generate a new (local) repository instantly takes it to the following state:
[[!format sh """
user@local:~/Annex$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: uuid.log
#
user@local:~/Annex$ git branch
git-annex
* master
user@local:~/Annex$ git log
commit 90bfcaf17b0576d8ecdc48ae44dda22d41464acc
Author: local <user>
Date: Sun Nov 3 15:30:17 2013 +0100
created repository
user@local:~/Annex$ git show HEAD
commit 90bfcaf17b0576d8ecdc48ae44dda22d41464acc
Author: local <user>
Date: Sun Nov 3 15:30:17 2013 +0100
created repository
diff --git a/uuid.log b/uuid.log
new file mode 100644
index 0000000..9df3670
--- /dev/null
+++ b/uuid.log
@@ -0,0 +1 @@
+987e7b9a-aa9d-41db-ae92-23fcae7f6187 user@local:~/Annex timestamp=1383489017.181
user@local:~/Annex$
"""]]
I'm new to git-annex, so I'm not quite sure, but looking at [[internals]] this file should only exist in the git-annex branch, not in master. Furthermore, from this state it seems impossible to get "sync with your other devices" to work, because of a merge conflict on this change.
Perhaps some sort of a race-condition with the annex-assistant picking up the uuid.log file while the repository is being initialized?
### What version of git-annex are you using? On what operating system?
Ubuntu 13.10 with git-annex 4.20130815
> [[fixed|done]]; see comments. (This fix needs to be backported to Ubuntu.) --[[Joey]]

10
doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 1"
date="2013-11-03T16:48:25Z"
content="""
I can't reproduce this at all. What version of git do you have installed? Did you install git-annex from ubuntu's repository? Does the same thing happen if you install the standalone linux tarball and use it to make a new repository?
git-annex never creates a file named uuid.log on disk, so it's quite strange that it shows up in the initial commit to the master branch. It sort of looks like somehow git-annex's normal use of a separate index file to stage the uuid.log to the git-annex branch is failing. Since I have never seen any problem with that, I have to suspect that the ubuntu build is somehow badly broken. Or that the git in Ubuntu is for some reason ignoring `GIT_INDEX_FILE`.
"""]]

12
doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 2"
date="2013-11-03T17:02:47Z"
content="""
I made an Ubuntu saucy chroot, apt-get installed git-annex from universe, and ran the webapp in there. I did not reproduce this problem.
The cause of the problem, it seems, must be something local to your system. Perhaps you have an environment variable set that is messing up git. Or perhaps you have a different, broken version of git installed.
Can you \"git show git-annex\" in the repository? It should show a commit made to the git-annex branch that adds the uuid.log there.
"""]]

14
doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="tanen"
ip="83.128.159.25"
subject="comment 3"
date="2013-11-03T17:35:00Z"
content="""
Very strange: this is on a machine that I wiped and reinstalled just a few hours ago, it's a completely fresh Ubuntu 13.10 install with barely anything installed but the defaults. Git version is 1.8.3.2-1
I initially just pulled git-annex from the Ubuntu repo. After that I grabbed a more recent version from https://launchpad.net/ubuntu/+source/git-annex/4.20131101/+build/5189754 which is showing the same behavior.
\"git show git-annex\" indeed shows the commit creating the uuid.log file on the git-annex branch. master has just one commit, with description \"created repository\" and creates a \"uuid.log\" file. The contents of the master uuid.log are identical to the one in the git-annex branch.
I'm currently in the middle of trying out a git-annex setup so I can't switch versions again right now, but given the above I imagine a fresh 13.10 VM should show the same behavior.
"""]]

10
doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_4_8e0f489305ce30ad578b9f8526e86416._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 4"
date="2013-11-06T15:09:19Z"
content="""
Intriguing -- I was able to reproduce this bug after installing the Ubuntu server ISO in a VM.
Which is really strange, the only difference between this and my debootstrapped chroot should be the kernel..
"""]]

53
doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment
View file

@ -1,53 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 5"
date="2013-11-06T16:27:49Z"
content="""
Running the prebuilt tarball build of git-annex, the bug does not occur.
However, if I remove the git shipped with the prebuilt tarball, so it uses the system git, I do see the bug. So, it's apparently git version dependent.
Also, I was able to reproduce it in a amd64 chroot. My other chroot was i386. Somehow architecture specific bug?
---
Instrumenting all calls to git to be logged with the full environment and command, I found this:
<pre>
GIT_INDEX_FILE='/home/foo/annex/.git/annex/index'
--git-dir=/home/foo/annex/.git --work-tree=/home/foo/annex commit --quiet --allow-empty -m created repository
</pre>
This certainly looks like the index file setting for the git-annex branch is somehow leaking out past the branch commit operations. It continued setting that while setting up `gc.auto`; the next call to git after that stopped setting the index file.
The only way I can see offhand this could possibly happen is due to an exception. It may be that on ubuntu an exception is thrown by code that runs a git command with the index file set, for whatever reason, and this causes the code that normally resets it back to not run.
----
Ok, found it!
<pre>
\"withIndex entered\"
*** Please tell me who you are.
Run
git config --global user.email \"you@example.com\"
git config --global user.name \"Your Name\"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'foo@darkstar.(none)')
\"withIndex entered\"
\"withIndex cleaned up\"
</pre>
Note lack of clean up after the first withIndex call. Thus leaving the environment passed to git polluted for further calls.
This also explains why it's only happening on some systems, or with some versions of git. git's got all kinds of complexity around its username and email handling code.
I have fixed this in git.
"""]]

10
doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_6_786cb7e643811dfd2496ceeff8f34f44._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 6"
date="2013-11-06T16:40:57Z"
content="""
Ubuntu bug report about this: <https://bugs.launchpad.net/ubuntu/+source/git-annex/+bug/1248623>
It should be pretty easy to backport the fix to the version in Ubuntu. The relevant git commits are ee23be55fd3e7e202bc721c124f78b79d1aba6df and 81117e8a9d19d4739d3773d0515006e1ea41c266
"""]]

64
doc/bugs/IPv6_literal_ssh_servers_break_git_annex_webapp.mdwn
View file

@ -1,64 +0,0 @@
### Please describe the problem.
When trying to set up the Git Annex webapp to sync with an SSH server on Windows, specifying the remote server address ans an IPv6 literal address will result in an Internal Server Error like this:
`C:\Users\anovak\.ssh\git-annex\key.git-annex-fc2e:f79e:da52:bd92:74f8:b045:e365:5e9d-anovak_22_.2Fhome.2Fanovak.2Fannex: openFile: invalid argument (Invalid argument)`
I think the problem is that it's not escaping the colons, and you can't have colons in a filename on Windows.
### What steps will reproduce the problem?
1. Have Git Annex Webapp runnign on Windows.
2. Go to the "Adding a remote server using ssh" page.
3. Enter an IPv6 literal address (in brackets), like `[fc2e:f79e:da52:bd92:74f8:b045:e365:5e9d]`, under "Host name". I hyappen to be using cjdns addresses, but I bet you get the same issue with Internet addresses.
4. Add the server, and elect to combine repositories if prompted.
5. You should get the error.
### What version of git-annex are you using? On what operating system?
I have Git Annex: `Version: 6.20160613-g35dbe35` on Windows 7.
### 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
[2016-07-17 11:11:09.3554208] main: starting assistant version 6.20160613-g35dbe35
Warning: Couldn't open /dev/urandom
Warning: using system clock for seed instead (quality will be lower)
Launching web browser on file://C:\Users\anovak\annex\.git\annex\webapp.html
[2016-07-17 11:11:09.482428] Cronner: You should enable consistency checking to protect your data.
(scanning...) [2016-07-17 11:11:09.7544436] Watcher: Performing startup scan
(started...)
recv: failed (No error)
recv: failed (No error)
recv: failed (No error)
(recording state in git...)
Generating public/private rsa key pair.
Your identification has been saved in C:\Users\anovak\AppData\Local\Temp\git-annex-keygen.0\key.
Your public key has been saved in C:\Users\anovak\AppData\Local\Temp\git-annex-keygen.0\key.pub.
The key fingerprint is:
SHA256:sNwb2o1rp2ycVaMvEOxKZa2g6YlYVuOtbty8xybl3Uc anovak@Asteria
The key's randomart image is:
+---[RSA 2048]----+
| |
| |
| .. . |
| o..+= . o |
| o =o=So o . |
| o + oo==o E |
| + + *.*+=.o . |
|. . * =.X.+ o . |
| o. .B+o . . |
+----[SHA256]-----+
17/Jul/2016:11:15:48 -0700 [Error#yesod-core] C:\Users\anovak\.ssh\git-annex\key.git-annex-fc2e:f79e:da52:bd92:74f8:b045:e365:5e9d-anovak_22_.2Fhome.2Fanovak.2Fannex: openFile: invalid argument (Invalid argument) @(yesod_IAZWSEWTVsBHH7DfZiTwkc:Yesod.Core.Class.Yesod .\Yesod\Core\Class\Yesod.hs:628:5)
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yeah, it works great on my Linux machines. I'm just getting started with the web app, though; I'm trying to set up limited-access key-based SSH, and the web app seems to be also trying to do that...
> Fixed by escaping the hostname when it contains any unusual characters.
> [[done]] --[[Joey]]

35
doc/bugs/Installation_fails__58_____34__Duplicate_instance_declarations__34__.mdwn
View file

@ -1,35 +0,0 @@
### Please describe the problem.
[380 of 462] Compiling Assistant.WebApp.Types ( Assistant/WebApp/Types.hs, dist/build/git-annex/git-annex-tmp/Assistant/WebApp/Types.o )
Assistant/WebApp/Types.hs:157:10:
Duplicate instance declarations:
instance PathPiece Bool
-- Defined at Assistant/WebApp/Types.hs:157:10
instance PathPiece Bool
-- Defined in `path-pieces-0.1.4:Web.PathPieces'
cabal: Error: some packages failed to install:
git-annex-5.20140709 failed during the building phase. The exception was:
ExitFailure 1
### What steps will reproduce the problem?
cabal install git-annex --bindir=$HOME/bin
### What version of git-annex are you using? On what operating system?
git-annex-5.20140709, Fedora 20
### 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.
"""]]
> Already fixed in git yesterday. [[done]] --[[Joey]]

36
doc/bugs/Installing_from_git___58___local_doc_lacks_style.css.mdwn
View file

@ -1,36 +0,0 @@
### Please describe the problem.
Installing from git : local doc has no style.
Unstyled local documentation is less easy to read than the one on http://git-annex.branchable.com/ .
### What steps will reproduce the problem?
Follow steps in http://git-annex.branchable.com/install/fromsource/ .
Open share/doc/git-annex/html/index.html in a browser.
All text has same appearance.
Style on branchable.com is minimal yet efficient (very good result-over-cost ratio).
### What version of git-annex are you using? On what operating system?
commit c075b58d40f2745e4b79c54e24edf9b94748d7e9
Merge: 166d70d 455de2f
Author: Joey Hess <joeyh@joeyh.name>
Date: Fri Sep 30 19:52:14 2016 -0400
Merge branch 'master' of ssh://git-annex.branchable.com
(actually commit ade6ab403701b25a540ffee2fbaae89db4473a2c though it most certainly does not change any code)
OS is Debian 7.11 on AMD64.
### Please provide any additional information below.
Copying style.css from branchable.com brings styling.
Doc also refers to local.css which is only comments on branchable.com anyway.
### 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)
Been trying shortly git-annex a few times. Considering to put some important stuff inside now (1Tb photos/videos). I love git-annex concept and believes that you Joey have the eye for details that make rock-solid software possible (I do that for a living). I've been using Unison for about 15 years. Unison is nice enough for *sync* if storage devices are mounted always on same machine in same directory. For source code *history*, I've been relying on git with great satisfaction (and seen quite a few git repos wrecked by a missing or corrupted file in .git, good job remote repos come to the rescue). Since git allows to change remote URLs at any time and just work, I believe git-annex will bring the best of both worlds. Also I love your style: everything not essential is just not added, preserving efficiency. Best way for a solid system is adding only what's necessary.
> Ok, I've added the ikiwiki underlay to get the style sheets.
> [[done]] --[[Joey]]

37
doc/bugs/Internal_Server_Error__58___Unknown_UUID.mdwn
View file

@ -1,37 +0,0 @@
### Please describe the problem.
One of my repositories has no name:
http://screencast.com/t/3OjxFzpz
And when I try to disable it I get this error:
Internal Server Error
Unknown UUID
When I try to delete it I get this error:
Internal Server Error
unknown UUID; cannot modify
I think this was the result of adding a Local Computer Repo, and then that computer signed off. Maybe.
### What version of git-annex are you using? On what operating system?
git-annex version 4.20130601-g2b6c3f2
Mac OS 10.7.5
### Please provide any additional information below.
Maybe it's a glitch that only will happen this once, the problem is I can't get rid of it! Are there anyways of manually getting rid of a repo with uid?
> Also reported here:
> [[Missing_repo_uuid_after_local_pairing_with_older_annex]] and
> [[Internal_Server_Error_unknown_UUID;_cannot_modify]]
> and [[Local_network___40__ssh__41___fails_to_pair__47__sync]]
> and [[Internal_Server_Error:_Unknown_UUID]]
> --[[Joey]]
[[!meta title="local pairing leads to unknown UUID"]]
> This bug is [[fixed|done]]. The webapp will detect the problem and
> provides an interface to correct it. --[[Joey]]

37
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_1_f42f703a5d267557abf5e932f0890d4a._comment
View file

@ -1,37 +0,0 @@
[[!comment format=mdwn
username="carlo"
ip="118.208.1.126"
subject="comment 1"
date="2013-07-06T22:52:18Z"
content="""
I got the same error. Local repo has no name but in the logs I can see that it's trying to make a local connection:
[2013-07-07 08:29:51 EST] main: starting assistant version 4.20130627
[2013-07-07 08:29:51 EST] TransferScanner: Syncing with arkham.local_annex
(snip)
07/Jul/2013:08:41:56 +1000 [Error#yesod-core] Unknown UUID @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
ssh: Could not resolve hostname arkham.local: Name or service not known
ssh: Could not resolve hostname arkham.local: Name or service not known
fatal: The remote end hung up unexpectedly
git-annex: Unknown UUID
ssh: Could not resolve hostname arkham.local: Name or service not known
ssh: Could not resolve hostname arkham.local: Name or service not known
fatal: The remote end hung up unexpectedly
git-annex: Unknown UUID
ssh: Could not resolve hostname arkham.local: Name or service not known
ssh: Could not resolve hostname arkham.local: Name or service not known
fatal: The remote end hung up unexpectedly
git-annex: Unknown UUID
ssh: Could not resolve hostname arkham.local: Name or service not known
07/Jul/2013:08:42:32 +1000 [Error#yesod-core] Unknown UUID @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
ssh: Could not resolve hostname arkham.local: Name or service not known
fatal: The remote end hung up unexpectedly
git-annex: Unknown UUID
ssh: Could not resolve hostname arkham.local: Name or service not known
When I turn on arkham (the other laptop) I see transfers start up:
"""]]

18
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_2_eb1999f99c5babf3fcb1ff5d72ea6db6._comment
View file

@ -1,18 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkeyfC88gIU4fsEqqkvhzVlSKDUxbtZaTE"
nickname="Selem"
subject="comment 2"
date="2013-07-10T01:41:24Z"
content="""
I got the same problem (Mac OS X 10.8.4, whatever the latest download package, local computers same network repos)
To get rid of the noname repo, I just removed git remote in the annex dir.
# List remote
$ git remote -v
# Remove remote grabbed from running the previous command
$ git remote rm your_remote
After that, I added the second computer repo successfully.
"""]]

9
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_3_bda72b0d615843d18d6ef21f833432a8._comment
View file

@ -1,9 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.246.110"
subject="I can't reproduce this problem, but I see several people have reported it."
date="2013-07-27T22:11:15Z"
content="""
It would be helpful for anyone who can reproduce this problem to do so with debugging enabled on both sides
(run with --debug or turn it on in the Configuration page in webapp), and then send the `.git/annex/daemon.log`
"""]]

10
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_4_651440cda405ad40a04479f5d87d581e._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="https://launchpad.net/~subito"
nickname="subito"
subject="Same here for SSH remotes"
date="2013-07-29T19:05:55Z"
content="""
I get the problem while only adding an SSH remote. After deciding I want a git-repo on my server, it says \"Unknown UUID\" and created a remote with no name. I was unable to add any SSH remote (tried with two different servers and a couple different dirs - some completly unknown to my annex)
I used the Android webapp btw - latest Version. The same version works fine on my Debian maschines.
"""]]

8
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_5_21fa189b631c246ac5df16a49c3c0178._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.0.21"
subject="comment 5"
date="2013-07-30T16:59:50Z"
content="""
@subito I have tried as hard as I can to reproduce this problem, and cannot. I need the debug information I asked for in my other comment to get any further on this bug report.
"""]]

12
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_6_1f712693d2ded5abceb869fdb7f47ef3._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.0.21"
subject="finally!"
date="2013-07-31T16:47:39Z"
content="""
I've finally been clued in to the cause of this. If a ssh-agent is running, and has been configured to use a ssh key (by running `ssh-add`), this apparently prevents git-annex from using the key it sets up during local pairing. I have reproduced the described bug by this method.
Something similar might also affect adding a remote ssh server, I'm not sure about that yet.
"""]]

14
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_7_7a5ead0ce5c9429d4723ccce4f6a6d6c._comment
View file

@ -1,14 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.0.21"
subject="workaround"
date="2013-07-31T17:19:01Z"
content="""
Looks like the fix is to edit ~/.ssh/config and in each stanza added by git-annex, add this line:
IdentitiesOnly yes
This prevents the ssh-agent from using the normal key, and allows the git-annex key to be used instead.
People experiencing this bug can manually make that change. Then if you edit your git-annex repository's `.git/config` and delete the `annex-ignore` line, the assistant should finally learn the UUID and start syncing.
"""]]

10
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_8_a4683fd73ae452a9cd7f61d9930f6266._comment
View file

@ -1,10 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.0.21"
subject="comment 8"
date="2013-07-31T20:42:10Z"
content="""
I've updated the webapp to display nicely when a repository has stalled being set up, rather than crashing.
There's now an interface to check the status of such a stalled repository, and it will try to clean up after this bug too.
"""]]

8
doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_9_ced3516c3e7161e4d7e599232f62a511._comment
View file

@ -1,8 +0,0 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
nickname="Carlo"
subject="Tilde did it for me"
date="2013-10-06T21:59:43Z"
content="""
I had exactly the same error message, \"Internal Server Error: Unknown UUID\", when I used a path starting with a tilde. Absolute path for home directory worked.
"""]]

56
doc/bugs/Interrupted_command_broke_encfs_repository.mdwn
View file

@ -1,56 +0,0 @@
### Please describe the problem.
I use git annex on my phone on an encfs directory on a debian root put on a sdcard.
After an interruption, it may happens that git-annex (or git?) changes the
content of a file in the .git directory by a content in a file from the working
directory.
[[!format sh """
$ cat .git/config
../../../.git/annex/objects/f8/gZ/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG
$ cat .git/refs/remotes/master
../../../../.git/annex/objects/29/wQ/SHA256E-s2533743--ec986bdbe37257bb5a940469d1e1b64a6016902736ed87315bab5856de322f42.JPG/SHA256E-s2533743--ec986bdbe37257bb5a940469d1e1b64a6016902736ed87315bab5856de322f42.JPG
"""]]
I only experienced this behavior two or three times since I have been using git-annex (3 years ago).
Everything else works fine and fsck indicates no problem with the sdcard.
This is a strange behavior that is a pain to solve, but today, I experienced something
even stranger.
Instead of writing the content into the .git/ directory. It was put in the encoded file in the crypt directory, with the path correctly encoded.
[[!format sh """
$ cat repo/.git/config
cat: repo/.git/config: Input/output error
$ encfsctl encode crypt_repo/ .git/config
CqJBnbpfTEgKPAnmc8Sbo/IA-gS5lOzCF65DW9C7l-3MYU/OKritNqY4ewLnzQ,R2dtBXzW
$ cat crypt_repo/CqJBnbpfTEgKPAnmc8Sbo/IA-gS5lOzCF65DW9C7l-3MYU/OKritNqY4ewLnzQ,R2dtBXzW
../../../RSYdwqZh7kgnn3RSbEEx86ax/60jj4hZ60tqcDwSiXy-hHpD9/ebwg,0lJ7hi2iBbgF7HBfdqC/-muvnOVFmMIkfUtJAVyMGRUs/lRm4UHX0Dj2lW6IsCnnBBBSX/O9l1191uPE0a2D-FXhrOEG5,uWeGZHyJccAsw64vy16H3iTcRrxY-75YdRnnMzL27zpC5j0UUVnTaU0TBg0ze-xWCLpoJHZha48Uu8NaekYpn9C5QSSmUV08aZERdCdCfS3/GSOJ0Txna5LM9CLDD6Pw8x5pZ7D5YKFdNb-yx4APrKVm,EXauZiDQoXo6qOuVCMUI4KJB9kdnprlZ4Bw7h7w2jogW7Q1GDpqKVSgk7VYLuk5D7CpdaslquWbg0Ci5e9k9T7
$ encfs decode ../../../RSYdwqZh7kgnn3RSbEEx86ax/60jj4hZ60tqcDwSiXy-hHpD9/ebwg,0lJ7hi2iBbgF7HBfdqC/-muvnOVFmMIkfUtJAVyMGRUs/lRm4UHX0Dj2lW6IsCnnBBBSX/O9l1191uPE0a2D-FXhrOEG5,uWeGZHyJccAsw64vy16H3iTcRrxY-75YdRnnMzL27zpC5j0UUVnTaU0TBg0ze-xWCLpoJHZha48Uu8NaekYpn9C5QSSmUV08aZERdCdCfS3/GSOJ0
../../../.git/annex/objects/f8/gZ/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG
"""]]
### What steps will reproduce the problem?
Interruption of a git annex command, I guess an add or an import command.
### What version of git-annex are you using? On what operating system?
Android 4.3 Cyanogenmod/Samsung Galaxy S3, chrooted debian.
[[!format sh """
$ git annex version
git-annex version: 5.20141125
build flags: Assistant Pairing Testsuite S3 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 tahoe glacier ddar hook external
$ cat /etc/debian_version
8.0
"""]]
### Please provide any additional information below.
If you ask for additional information, I will gladly provide it.
> Incremented my `encfs_is_shite` counter; [[done]] --[[Joey]]

15
doc/bugs/Interrupted_command_broke_encfs_repository/comment_1_0b5fd2ca4b067becb930206e0ee82b3d._comment
View file

@ -1,15 +0,0 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-07-02T16:57:56Z"
content="""
git-annex contains no code whatsoever that writes to .git/config. It relies
entirely on `git config` to write that file. I'm pretty sure that `git
config` doesn't contain code to write garbage (in this case a symlink
target belonging to another file) to the .git/config file either.
The fact that you're having IO errors also points strongly at this being
a level above userspace, so either encfs or the SD card. I think your tech
stack contains at least one POS (namely encfs), and probably more problems
(SD card, whatever nonsense filesystem Android is using for it, etc).
"""]]

15
doc/bugs/Interrupted_command_broke_encfs_repository/comment_2_fc57759cfcec0c454ab80ef8e324aa91._comment
View file

@ -1,15 +0,0 @@
[[!comment format=mdwn
username="konubinix"
subject="Thank you for your answer"
date="2015-07-08T19:33:35Z"
content="""
The filesystem I use is ext4. I don't think the ext4 module of the linux kernel
present on my version of Android would be much different of the one on my
computer.
Therefore I guess I shall investigate in encfs. It is a pity there is no
alternative allowing to keep a directory encrypted without requiring
administrative privileges.
Thank you again.
"""]]

10
doc/bugs/It__39__s_July_not_June.mdwn
View file

@ -1,10 +0,0 @@
The new tag created today is named 6.20160619
Off-by-one bug ...
> I really need to automate generating those version numbers.
> I'm not going to re-release it though, and the version number meets
> all other requirements other than matching the release date, so [[done]] --[[Joey]]
>> JFTR, yesterday, I needed a tag to build the package against and pushed that to the
>> main repo. If you object, feel free to nuke. -- RichiH

1
doc/bugs/It__39__s_July_not_June/comment_1_RichiH._comment
View file

@ -1 +0,0 @@
Ah, saw this too late. Also see 2aa0841940d309b858eed5bc156262a7d90c949b

18
doc/bugs/Local_pairing_fails__58___PairListener_crashed.mdwn
View file

@ -1,18 +0,0 @@
What steps will reproduce the problem?
Attempting to pair between a local repository and a repository on a remote computer on my LAN. Pairing is initiated from my local machine and I'm interacting with the webapp on the remote machine via firefox running over an ssh -X connection. Pairing appears to work up to a point: I enter the secret at one end, the pairing request shows up at the other end. I then enter the secret at that end.
What is the expected output? What do you see instead?
Pairing should complete successfully. Instead I get the error message "PairListener crashed: bad comment in public key", followed by the public key. The pairing process then does not move beyond the 'awaiting pairing' pages.
What version of git-annex are you using? On what operating system?
Local Machine: 3.20121127, Debian Wheezy/Sid (the only package from unstable is git-annex).
Remote Machine: 3.20121113, Arch Linux (I installed the version from: https://aur.archlinux.org/packages/git-annex-bin/, which is supposedly the same as above, but reports the version specified here).
Please provide any additional information below.
None as yet. Let me know if there are any log files, etc. that I can post.
> So it was the period in the hostname! [[fixed|done]] --[[Joey]]

12
doc/bugs/Local_pairing_fails__58___PairListener_crashed/comment_1_d9c5d2147cf6d8d8477eb13b72081d46._comment
View file

@ -1,12 +0,0 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.72"
subject="comment 1"
date="2012-12-04T17:38:47Z"
content="""
On the machine that didn't crash, run:
ssh-keygen -P \"\" -f test; cat test.pub
Probably the non-alphanumeric character is part of the machine's hostname, or perhaps your username. We'll see..
"""]]

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