diff options
Diffstat (limited to 'doc/bugs')
9 files changed, 178 insertions, 0 deletions
diff --git a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn index e1db603cb..17b66bbab 100644 --- a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn +++ b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn @@ -36,3 +36,5 @@ FAIL (0.29s) (This could be due to a bug in git-annex, or an incompatability with utilities, such as git, installed on this system.) ``` + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment b/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment new file mode 100644 index 000000000..01da6e824 --- /dev/null +++ b/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2015-12-06T20:02:49Z" + content=""" +Ok, this involves where the test suite is run. +The addurl test adds `file://`pwd`/somefile`, and that will create a file +with a name like `_home_you_sub_dir_path_here_somefile`. Which can easily +exceed filename length limits of 255 bytes. + +There was indeed a reversion in addurl's handling of that. +"""]] diff --git a/doc/bugs/Location_change_of_remote_DNS_ignored.mdwn b/doc/bugs/Location_change_of_remote_DNS_ignored.mdwn new file mode 100644 index 000000000..b35f66068 --- /dev/null +++ b/doc/bugs/Location_change_of_remote_DNS_ignored.mdwn @@ -0,0 +1,28 @@ +### Please describe the problem. +git-annex ignores changing of remote location in .git/config + +### What steps will reproduce the problem? +1. Change Hostname of previously working remote so that the existing remote will no longer work and produce "ssh: connect to host <DNS hostname> port 22: Network is unreachable" errors. +2. Stop all running git-annex processes. +3. Edit DNS name in corresponding remote .git/config. +4. Restart git-annex. +5. Turns out: git-annex still uses the old remote's DNS name. + +### What version of git-annex are you using? On what operating system? +newest one available. +5.20151116-gbe86081 + +### Please provide any additional information below. +See following entry in log, occurring plenty often: +[[!format sh """ +ssh: connect to host some.unreachable.dns.net port 22: Network is unreachable +rsync: connection unexpec + rsync failed -- run git annex again to resume file transfer +tedly closed (0 bytes received so far) [Receiver] +rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.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) +Trust me I love git-annex. Had dreams of something like git-annex for almost 10 years. I instantly got stuck on git-annex when I have read the first few sentences about it. Since then, things in my life have changed in a quite serious manner. + +THANKS for your help! diff --git a/doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment b/doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment new file mode 100644 index 000000000..4f81c4348 --- /dev/null +++ b/doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="torpidus" + subject="comment 1" + date="2015-12-06T20:29:25Z" + content=""" +**self-edit**: +Changed location of .git/config once again as described but instead of re-starting assistant, I ran \"git-annex sync\" which ended with no errors. After that, assistant started correctly and also had the corrected remote location. From my point of view, this thread has been resolved - even though I wonder what changed the value back to the old one in the first place. +"""]] diff --git a/doc/bugs/Watcher_crashed:_.git__92__annex__92__objects__92__...sha256....pdf__92__:_openTempFile:_does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment b/doc/bugs/Watcher_crashed:_.git__92__annex__92__objects__92__...sha256....pdf__92__:_openTempFile:_does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment new file mode 100644 index 000000000..9830d3dce --- /dev/null +++ b/doc/bugs/Watcher_crashed:_.git__92__annex__92__objects__92__...sha256....pdf__92__:_openTempFile:_does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="OlivierBerger" + subject="Difficult to tell" + date="2015-12-04T10:21:26Z" + content=""" +Sorry, Joey, but I don't have the details of the version which crahed on us, and we updated afterwards : no time to try and reproduce fully : really busy producing videos, and anxious to find a solution on backing up videos reliably (which by the way I solved like this : https://www-public.tem-tsp.eu/~berger_o/weblog/2015/11/26/handling-video-files-produced-for-a-mooc-on-windows-with-git-and-git-annex/). + +I don't see however how we could have touched the contents of the .git/ : we were only doing Windows explorer actions : dragging files here and there, renaming dirs, saving stuff in Camtasia, but all inside subdirs of the git clone. + +Sorry for the poor quality of the report, but we were in a real hurry and had to find solutions without distracting us from the main topic : video editing :-/ +"""]] diff --git a/doc/bugs/Windows_:_git-annex:_failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment b/doc/bugs/Windows_:_git-annex:_failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment new file mode 100644 index 000000000..31a51db95 --- /dev/null +++ b/doc/bugs/Windows_:_git-annex:_failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="OlivierBerger" + subject="Again, difficult to tell" + date="2015-12-04T12:24:06Z" + content=""" +Well, I really don't understand either what may have caused the crashes... but the path issue might be a hint. I think our repo was cloned in a path something like : \"C:\Users\Majdi\git\git-annex.tem-tsp.eu\testscpo\" which already takes around 48 chars. +"""]] diff --git a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn new file mode 100644 index 000000000..bc7c3e429 --- /dev/null +++ b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn @@ -0,0 +1,36 @@ +### Please describe the problem. + +git-annex's WebDAV support does not like (aka it does not work) the WebDAV server of the freenet cloud. + +### What steps will reproduce the problem? + +My first attempt was: + + WEBDAV_USERNAME='XXX' WEBDAV_PASSWORD='XXX' git annex initremote webdav type=webdav url='https://webmail.freenet.de/webdav' encryption=none + initremote webdav (testing WebDAV server...) + git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 401, statusMessage = "Unauthorized"}) [("Date","Fri, 04 Dec 2015 12:20:57 GMT"),("Server","Apache/2.2.16 (Debian)"),("WWW-Authenticate","Basic realm=\"MD-Cloud\""), + ("Vary","Accept-Encoding"),("Content-Encoding","gzip"),("Content-Length","20"),("Connection","close"),("Content-Type","text/html; charset=iso-8859-15"),("X-Response-Body-Start",""),("X-Request-URL","MKCOL https://webmail.freenet.de:443/webdav/tmp")] + (CJ {expose = []}): user error failed + git-annex: initremote: 1 failed + +Ok this fails (what is the error?). However, it does create a folder "tmp" in the "cloud". A second attempt yields another error: + + WEBDAV_USERNAME='XXX' WEBDAV_PASSWORD='XXX' git annex initremote webdav type=webdav url='https://webmail.freenet.de/webdav' encryption=none + initremote webdav (testing WebDAV server...) + git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 501, statusMessage = "Not Implemented"}) [("Date","Fri, 04 Dec 2015 12:21:22 GMT"),("Server","Apache/2.2.16 (Debian)"),("Content-Length","349"),("Connection","close"), + ("Content-Type","application/xml; charset=utf-8"),("X-Response-Body-Start","<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n <s:exception>Sabre\\DAV\\Exception\\NotImplemented</s:exception>\n + <s:message>This server is not compatible with OS/X finder. Consider using a different WebDAV client or webserver.</s:message>\n <s:sabredav-version>1.8.6</s:sabredav-version>\n</d:error>\n"),("X-Request-URL","PUT https://webmail.freenet.de:443/webdav + /tmp/git-annex-test")] (CJ {expose = []}): user error failed + git-annex: initremote: 1 failed + +which is I guess the same. The WebDAV server does support writing and locking files. I tried writing using davfs2 and locking-unlocking using cadaver. I guess in the end that it's the server's fault, but it would be great to know what exactly fails at this point :). + +### What version of git-annex are you using? On what operating system? + +git-annex version: 5.20151116-gbe86081 + +Gentoo Linux + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +First time trying WebDAV support. diff --git a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn new file mode 100644 index 000000000..74a3c6c22 --- /dev/null +++ b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn @@ -0,0 +1,50 @@ +### Please describe the problem. + +`git-annex importfeed` fails to import some feed with the error `createSymbolicLink: invalid argument (File name too long)` in a case in which `ln -s` works. The item of the feed is not added, and the importing aborts at this entry. + +This is a regression: some entries that trigger the problem where imported just fine three months ago. + +This looks suspiciously like [this bug](../20151116_tests_fail_on_OS_X). + + +### What steps will reproduce the problem? + +In a freshly `git init`-ed and `git-annex init`-ed repo: + +[[!format sh """ +$ git-annex importfeed --relaxed http://www.rtve.es/api/programas/1938/audios.rss +(checking known urls...) importfeed http://www.rtve.es/api/programas/1938/audios.rss +/tmp/feed1907 100%[================================================================>] 91,96K 31,4KB/s en 2,9s +addurl Documentos_RNE/Documentos_RNE___La_guerra__un_recorrido_por_la_historia_de_la_peor_lacra_de_la_Humanidad___05_1215.mp3 ok +addurl Documentos_RNE/Documentos_RNE___El_proceso_de_Burgos._El_juicio_contra_ETA_que_arrinconó_al_Franquismo___28_11_15.mp3 ok +addurl Documentos_RNE/Documentos_RNE___Carmen_Martín_Gaite__la_escritura__como_afición_y_refugio___21_11_15.mp3 ok +addurl Documentos_RNE/Documentos_RNE___El_crimen_del_Expreso_de_Andalucía___14_11_15.mp3 ok +addurl Documentos_RNE/Documentos_RNE___La_Belle_Époque._La_Europa_que_bailaba_al_borde_del_abismo___07_11_15.mp3 ok +addurl Documentos_RNE/Documentos_RNE___Cruz_Roja_Española._Siglo_y_medio_de_labor_humanitaria__de_los_heridos_de_guerra_a_los_excluidos_de_la_crisis___31_10_15.mp3 +git-annex: ../.git/annex/objects/F7/x3/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42: createSymbolicLink: invalid argument (File name too long) +failed +(recording state in git...) +git-annex: importfeed: 1 failed +"""]] + +Just to make sure, I checked that the link can be created: + +[[!format sh """ +$ ln -s '../.git/annex/objects/F7/x3/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42' Documentos_RNE/Documentos_RNE___Cruz_Roja_Española._Siglo_y_medio_de_labor_humanitaria__de_los_heridos_de_guerra_a_los_excluidos_de_la_crisis___31_10_15.mp3 +"""]] + +I also checked in ghci that System.Posix.Files.createSymbolicLink succeeds in creating the same link. +(But I didn’t compile git-annex myself, so I’m not sure that the version of the lib used in the debian package is the same as the one I checked; and I’m not sure whether git-annex uses exactly that function or another with the same name, by the way). + + +### What version of git-annex are you using? On what operating system? + +Debian amd64 unstable package 5.20151116-1. +(I also tried version i386, with the same result). + + +### 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) + +That’s just a little hiccup in, up to now, various months of merry use! ;-) + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment new file mode 100644 index 000000000..b60e0f308 --- /dev/null +++ b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-12-06T19:50:59Z" + content=""" +I can reproduce this. + + symlink("../.git/annex/objects/fK/9M/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4", ".git/annex/misctmp/Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3.0Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3") = -1 ENAMETOOLONG (File name too long) + +The problem is not the length of the link target, which is only 170 +characters and will work on any OS. The basename of the symlink +being created is pretty long, 294 characters, and that's the +cause of the failure. + + joey@darkstar:~>ln -s /dev/null $(perl -e 'print ("a" x 294)') + ln: failed to create symbolic link ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’ -> ‘/dev/null’: File name too long + +The limit is 255 characters in a single path component (`pathconf _PC_NAME_MAX`). + +So, the issue is caused by the rss feed having a long title for this +item. + +And this used to work; it's a recent reversion. Fixing. +"""]] |