From c2b208a856908d215d45f580113af2567bbf107a Mon Sep 17 00:00:00 2001 From: "encryptio@2557a3f5b4ef0cddf8f011d7dbb3e76d46ed9c79" Date: Fri, 4 Dec 2015 03:19:29 +0000 Subject: Added a comment: git-annex-remote-b2 --- .../comment_29_8393a14f084d022986c8245ee01f4198._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment (limited to 'doc') diff --git a/doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment b/doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment new file mode 100644 index 000000000..c8a2fd054 --- /dev/null +++ b/doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="encryptio@2557a3f5b4ef0cddf8f011d7dbb3e76d46ed9c79" + nickname="encryptio" + subject="git-annex-remote-b2" + date="2015-12-04T03:19:29Z" + content=""" +I wrote an external remote for [Backblaze's B2](https://www.backblaze.com/b2/cloud-storage.html) object storage service: [git-annex-remote-b2](https://github.com/encryptio/git-annex-remote-b2). I can't be arsed to write a full page on it, but the README covers everything an experienced git-annex user needs to know to use it. +"""]] -- cgit v1.2.3 From a0d719675bcd8035a1c0b4ad101fe4ac8e15bde9 Mon Sep 17 00:00:00 2001 From: "wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d" Date: Fri, 4 Dec 2015 10:18:08 +0000 Subject: --- ..._47___disaster_recovery_with_an_encrypted_special_remote.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn (limited to 'doc') diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn new file mode 100644 index 000000000..8bc879de6 --- /dev/null +++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn @@ -0,0 +1,9 @@ +I am interested in using `git annex` to manage encrypted backups to Amazon S3/Glacier. So `git annex` will be used with the main file directory in direct mode and an encrypted S3 or Glacier remote set up in archive mode and then `git annex add .` and `git annex sync` will be run periodically. The intent is for this set up to be a backup for catastrophic failure, so I want to make sure I take care of future-proofing and disaster recovery properly. So my basic question is what would I need to have backed up and what would I have to do if the computer with the main repository died. I try to break that out into more specific questions below. + +0. Do the S3/Glacier remotes just store the contents of `.git/annex/objects` in encrypted form and nothing else? So if I was left with nothing but the AWS bucket and couldn't get `git annex` to work for whatever reason, I could recover my files by hand if I had the encryption key (though I wouldn't know the file names or directory structure)? + +1. For `shared` encryption, I see the cipher text in `remote.log` in the `git-annex` branch. Assuming I didn't have access to `git annex`, what would I need to do to convert that cipher text into a form that I could use with `gpg` to decrypt files? + +2. Same question but for `hybrid` encryption rather than `shared`. I assume the answer is similar but I need to decrypt the cipher first with my gpg key? How do I do that? + +3. Assuming I did have access to `git annex`, what would I need to create a new repo on a new computer with access to all of the files in the S3/Glacier bucket? I think I would need my Amazon credentials, my gpg key if using hybrid or public key encryption, and the `.git` folder as it was the last time files were pushed to the S3/Glacier remote (which would have the necessary decryption information for shared encryption). Is that right? I guess mainly I am checking that the remote does not store any metadata about the repo, so for `git annex` to be able to pull files back out I would need a backup of the `.git` directory and that back up would need to be up to date (can't just copy remote.log and have `git annex` work out the rest from the remote's contents). So for a full backup, my script would need to `tar` the `.git` directory, encrypt it, and push it to S3/Glacier separately after `git annex` does a sync. Then I could recover everything as long as I had a secure backup of my Amazon credentials and my encryption key(s). -- cgit v1.2.3 From c809a8cae278588b7baf2226fb96d5a6e570a367 Mon Sep 17 00:00:00 2001 From: OlivierBerger Date: Fri, 4 Dec 2015 10:21:26 +0000 Subject: Added a comment: Difficult to tell --- .../comment_3_1ef917c10f944e6c874aa40affae7602._comment | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/bugs/Watcher_crashed:_.git__92__annex__92__objects__92__...sha256....pdf__92__:_openTempFile:_does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment (limited to 'doc') 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 :-/ +"""]] -- cgit v1.2.3 From 6b898e8ded13c83fa8a8ff9c7e1b490f5589c66b Mon Sep 17 00:00:00 2001 From: OlivierBerger Date: Fri, 4 Dec 2015 12:24:07 +0000 Subject: Added a comment: Again, difficult to tell --- .../comment_4_2e5791aa8f568f86d0185a553227afa8._comment | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/bugs/Windows_:_git-annex:_failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment (limited to 'doc') 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. +"""]] -- cgit v1.2.3 From 88da25e6c206651c4fd7419cb4f053e71def46ab Mon Sep 17 00:00:00 2001 From: sts Date: Fri, 4 Dec 2015 12:57:59 +0000 Subject: --- ...onnect_to_freenet_cloud___40__webdav__41__.mdwn | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn (limited to 'doc') 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","\n\n Sabre\\DAV\\Exception\\NotImplemented\n + This server is not compatible with OS/X finder. Consider using a different WebDAV client or webserver.\n 1.8.6\n\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. -- cgit v1.2.3 From 8c5b6ab6e990b39753c0aa01ebe4e523f3d348ae Mon Sep 17 00:00:00 2001 From: "mellon85@e4812de7355433a8e232ce8ca4c231092d9afebb" Date: Fri, 4 Dec 2015 17:11:45 +0000 Subject: --- doc/forum/assistant_and_archive_folder.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/assistant_and_archive_folder.mdwn (limited to 'doc') diff --git a/doc/forum/assistant_and_archive_folder.mdwn b/doc/forum/assistant_and_archive_folder.mdwn new file mode 100644 index 000000000..6008d0fb8 --- /dev/null +++ b/doc/forum/assistant_and_archive_folder.mdwn @@ -0,0 +1,10 @@ +I have a setup with a windows desktop and a linux laptop with both an annex repository, interconnected via a backup repository in the middle (connected via ssh). +Both computers are setup as clients and all 3 machines are running the assistant. + +Today i tried creating an archive folder and a putting some files in it. To my understanding those files should have been dropped in the 2 machines but kept on the server.. instead I have them copied on each machine. Listing where the files are on both computers shows that both know that themselves and the server have a copy, but they don't know anything about each other. + +AFAIK it looks like the bug reported in https://git-annex.branchable.com/forum/question_about_assistant_and___47__archive__47__/ + +laptop: git-annex version: 5.20151116+gitg5416a1a-1~ndall+1 +server: git-annex version: 5.20151109-g08bb3b1 +windows: the latest build on the website -- cgit v1.2.3 From 3f6a4ca7cb336fd9e548cc825b78b646051c88c9 Mon Sep 17 00:00:00 2001 From: "mellon85@e4812de7355433a8e232ce8ca4c231092d9afebb" Date: Fri, 4 Dec 2015 17:15:34 +0000 Subject: --- doc/forum/assistant_and_archive_folder.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc') diff --git a/doc/forum/assistant_and_archive_folder.mdwn b/doc/forum/assistant_and_archive_folder.mdwn index 6008d0fb8..11f405736 100644 --- a/doc/forum/assistant_and_archive_folder.mdwn +++ b/doc/forum/assistant_and_archive_folder.mdwn @@ -6,5 +6,8 @@ Today i tried creating an archive folder and a putting some files in it. To my u AFAIK it looks like the bug reported in https://git-annex.branchable.com/forum/question_about_assistant_and___47__archive__47__/ laptop: git-annex version: 5.20151116+gitg5416a1a-1~ndall+1 + server: git-annex version: 5.20151109-g08bb3b1 + windows: the latest build on the website + -- cgit v1.2.3 From 3a3d1cfa390e01fb6567af899425d53ec0a14a77 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 4 Dec 2015 17:57:34 -0400 Subject: devblog --- doc/devblog/day_341__starting_smudge.mdwn | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/devblog/day_341__starting_smudge.mdwn (limited to 'doc') diff --git a/doc/devblog/day_341__starting_smudge.mdwn b/doc/devblog/day_341__starting_smudge.mdwn new file mode 100644 index 000000000..d212ca78a --- /dev/null +++ b/doc/devblog/day_341__starting_smudge.mdwn @@ -0,0 +1,24 @@ +I've gotten git-annex working as a smudge/clean filter today in the +`smudge` branch. It works ok in a local git repository. `git add` lets +git-annex decide if it wants to annex a file's content, and checking out +branches and other git commands involving those files works pretty well. + +It can sometimes be slow; git's smudge interface necessarily needs to +copy the content of files around, particularly when checking out files, +and so it's never going to be as fast as the good old git-annex symlink +approach. Most of the slow parts are things that can't be done in direct +mode repos though, like switching branches, so that isn't a regression. + +No git-annex commands to manage the annexed content work yet. That +will need a key to worktree file mapping to be maintained, and implementing +that mapping and ensuring its always consistent is probably going to be +the harder part of this. + +Also there's the question of how to handle upgrades from direct mode +repositories. This will be an upgrade from annex.version 5 to 6, and you +won't want to do it until all computers that have clones of a repository +have upgraded to git-annex 6.x, since older versions won't be able to work +with the upgraded repository. So, the repository upgrade will need to be +run manually initially, and it seems I'll need to keep supporting direct +mode for v5 repos in a transition period, which will probably be measured +in years. -- cgit v1.2.3 From 5d47b6385ea10158d63f5bcd8cd4cf46a27b4d74 Mon Sep 17 00:00:00 2001 From: "a@b34f238966e58f7c2ea550cc4cab3005c0e33150" Date: Sat, 5 Dec 2015 18:17:45 +0000 Subject: --- doc/forum/Find_out_if_file_is_in_annex__63__.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Find_out_if_file_is_in_annex__63__.mdwn (limited to 'doc') diff --git a/doc/forum/Find_out_if_file_is_in_annex__63__.mdwn b/doc/forum/Find_out_if_file_is_in_annex__63__.mdwn new file mode 100644 index 000000000..9d4680840 --- /dev/null +++ b/doc/forum/Find_out_if_file_is_in_annex__63__.mdwn @@ -0,0 +1,8 @@ +Hi, + +I am currently trying to move nearly all of my files into git-annex, and I was wondering if there is a (plumbing-level?) way to easily figure out if a file I find on a random hard disk is already contained in my annex repository? + +I.e., is there an easy way to compute the key for a file (which is not in an annex) and look up if the file is already contained in a given annex repository? I've looked a bit at the plumbing-level commands but none seem to exactly fit the bill :-/ + +Cheers, +Alex -- cgit v1.2.3 From e47e1d4793ff9c1a169e67b18b96531fce2135d0 Mon Sep 17 00:00:00 2001 From: spwhitton Date: Sat, 5 Dec 2015 19:52:17 +0000 Subject: Copy hints for Emacs users from propellor coding style page --- doc/coding_style.mdwn | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'doc') diff --git a/doc/coding_style.mdwn b/doc/coding_style.mdwn index 6968c9958..288f52446 100644 --- a/doc/coding_style.mdwn +++ b/doc/coding_style.mdwn @@ -98,3 +98,16 @@ If you feel that this coding style leads to excessive amounts of horizontal or vertical whitespace around your code, making it hard to fit enough of it on the screen, consider finding a better abstraction, so the code that does fit on the screen is easily understandable. ;) + +----- + +Note for emacs users: You can put the following snippet into a file called +`.dir-locals.el` at root of git-annex's source tree to use tabs for indentation: + + ((nil . ((indent-tabs-mode . t) + (tab-width . 8) + (fill-column . 80))) + ;; Warn about spaces used for indentation: + (haskell-mode . ((eval . (highlight-regexp "^ *"))))) + +Also consider [haskell-tab-indent-mode](https://spwhitton.name/tech/code/haskell-tab-indent/). The standard indentation modes that come with haskell-mode do not work well with tabs for indentation. This mode works well for hacking on Propellor. -- cgit v1.2.3 From 718cdfe3540305fd4fb1b15429bb88a261b246e9 Mon Sep 17 00:00:00 2001 From: spwhitton Date: Sat, 5 Dec 2015 19:52:38 +0000 Subject: m --- doc/coding_style.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/coding_style.mdwn b/doc/coding_style.mdwn index 288f52446..425665e37 100644 --- a/doc/coding_style.mdwn +++ b/doc/coding_style.mdwn @@ -110,4 +110,4 @@ Note for emacs users: You can put the following snippet into a file called ;; Warn about spaces used for indentation: (haskell-mode . ((eval . (highlight-regexp "^ *"))))) -Also consider [haskell-tab-indent-mode](https://spwhitton.name/tech/code/haskell-tab-indent/). The standard indentation modes that come with haskell-mode do not work well with tabs for indentation. This mode works well for hacking on Propellor. +Also consider [haskell-tab-indent-mode](https://spwhitton.name/tech/code/haskell-tab-indent/). The standard indentation modes that come with haskell-mode do not work well with tabs for indentation. This mode works well for hacking on git-annex. -- cgit v1.2.3 From b525272c5a7ff62b53c2c05034943acf8a3ff541 Mon Sep 17 00:00:00 2001 From: "samuel.hym+bugs@a85e9c44dc6369ad6b12e8e6a3896ad34f7df4a3" Date: Sun, 6 Dec 2015 10:01:00 +0000 Subject: Report bug due to broken createSymbolicLink --- ...teSymbolicLink___40__but_ln_-s_works__41__.mdwn | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn (limited to 'doc') 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..55d779c60 --- /dev/null +++ b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn @@ -0,0 +1,48 @@ +### 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! ;-) -- cgit v1.2.3 From 3de9c05ddc0c70a0110a4e14eff979aed8b264b9 Mon Sep 17 00:00:00 2001 From: "samuel.hym+bugs@a85e9c44dc6369ad6b12e8e6a3896ad34f7df4a3" Date: Sun, 6 Dec 2015 10:02:35 +0000 Subject: Fix broken link to other bug --- ...ortfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') 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 index 55d779c60..27316f1e3 100644 --- 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 @@ -4,7 +4,7 @@ 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). +This looks suspiciously like [this bug](../20151116_tests_fail_on_OS_X). ### What steps will reproduce the problem? -- cgit v1.2.3 From 29fe475e490840ffa859b85258353c174b87ee4d Mon Sep 17 00:00:00 2001 From: torpidus Date: Sun, 6 Dec 2015 18:51:12 +0000 Subject: --- .../Location_change_of_remote_DNS_ignored.mdwn | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/bugs/Location_change_of_remote_DNS_ignored.mdwn (limited to 'doc') 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 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! -- cgit v1.2.3 From 53912ffd3fcf75bf9f0ad3f1c2155e49bff61767 Mon Sep 17 00:00:00 2001 From: torpidus Date: Sun, 6 Dec 2015 20:29:26 +0000 Subject: Added a comment --- .../comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment (limited to 'doc') 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. +"""]] -- cgit v1.2.3 From ec356e3c121c9be66ffd99aa68fedf6267522f1c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 6 Dec 2015 16:50:37 -0400 Subject: fix temp filename Was not putting it inside the temp dir, but next to it! This was just wrong, and it led to a longer filename that desired being used, leading to some bug reports. --- Annex/ReplaceFile.hs | 2 +- debian/changelog | 2 ++ doc/bugs/20151116_tests_fail_on_OS_X.mdwn | 2 ++ ...ent_2_59f7803b9a9ee939a8a50605fe5c4682._comment | 12 +++++++++++ ...teSymbolicLink___40__but_ln_-s_works__41__.mdwn | 2 ++ ...ent_1_c831256a081b181a121910aca3151e45._comment | 24 ++++++++++++++++++++++ 6 files changed, 43 insertions(+), 1 deletion(-) create mode 100644 doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment create mode 100644 doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment (limited to 'doc') diff --git a/Annex/ReplaceFile.hs b/Annex/ReplaceFile.hs index b6126ba7e..94d2688a1 100644 --- a/Annex/ReplaceFile.hs +++ b/Annex/ReplaceFile.hs @@ -30,7 +30,7 @@ replaceFile file action = do filemax <- liftIO $ fileNameLengthLimit misctmpdir let basetmp = take (filemax `div` 2) (takeFileName file) withTmpDirIn misctmpdir basetmp $ \tmpdir -> do - let tmpfile = tmpdir <> basetmp + let tmpfile = tmpdir basetmp action tmpfile liftIO $ replaceFileFrom tmpfile file diff --git a/debian/changelog b/debian/changelog index fae4b598b..80a44c175 100644 --- a/debian/changelog +++ b/debian/changelog @@ -20,6 +20,8 @@ git-annex (5.20151117) UNRELEASED; urgency=medium This was a reversion caused by the relative path changes in 5.20150113. * dropunused: Make more robust when trying to drop an object that has already been dropped. + * Fix reversion in handling of long filenames, particularly when using + addurl/importfeed, which was introduced in the previous release. -- Joey Hess Mon, 16 Nov 2015 16:49:34 -0400 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/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 index 27316f1e3..74a3c6c22 100644 --- 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 @@ -46,3 +46,5 @@ Debian amd64 unstable package 5.20151116-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) 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. +"""]] -- cgit v1.2.3