From 2ed947897bc6ceb2a59ff0f3d90a5ee185c8daa3 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog" Date: Wed, 16 Apr 2014 21:20:43 +0000 Subject: [PATCH 01/10] --- ...c_transfer_is_interrupted_and_resumed.mdwn | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn diff --git a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn new file mode 100644 index 0000000000..30dfb6eb72 --- /dev/null +++ b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn @@ -0,0 +1,28 @@ +### Please describe the problem. + +umask is 022 on both hosts +If one does ls -lL on source repo, the files are shown 644. + +Now, "git annex get" from a clone done over ssh generally preserves 644 ... except if the transfer (rsync) is interrupted, and then resumed. +In fact, looks like the temp files in .git/annex/tmp have the og+r bits cleared during the resumed transfer. + +So this is inconsistent: I don't see why permissions should be different, depending whether or not there was an interruption in the transfer. +Plus, og+r permissions can actually be important for setups like serving contents using Samba. + +### What steps will reproduce the problem? + + +### What version of git-annex are you using? On what operating system? + +git-annex version: 5.20140411-gda795e0 +Linux + +### 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. +"""]] From 5977b361c2e531f5cdcaf3f7db160f19bffcf576 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog" Date: Wed, 16 Apr 2014 21:24:51 +0000 Subject: [PATCH 02/10] --- ...sync_transfer_is_interrupted_and_resumed.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn index 30dfb6eb72..bb6870ba32 100644 --- a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn +++ b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn @@ -11,6 +11,22 @@ Plus, og+r permissions can actually be important for setups like serving content ### What steps will reproduce the problem? + cd dir1 + git init + git annex init + touch some-small-file + truncate -s 10G some-large-file + git annex add . + git commit -m 'new' + + git clone localhost:/path/to/dir1 dir2 + cd dir2 + git annex get + ctrl^c + ls -lL + ... see different perms + + ### What version of git-annex are you using? On what operating system? From 838ffcfe4ad869b618257cde6b831bdd1c7db5fc Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog" Date: Wed, 16 Apr 2014 21:28:42 +0000 Subject: [PATCH 03/10] --- ...ssions_when_rsync_transfer_is_interrupted_and_resumed.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn index bb6870ba32..861673fb37 100644 --- a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn +++ b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn @@ -14,8 +14,8 @@ Plus, og+r permissions can actually be important for setups like serving content cd dir1 git init git annex init - touch some-small-file - truncate -s 10G some-large-file + touch a + truncate -s 10G b git annex add . git commit -m 'new' From c170ecf0eb589c5c101d46b7635d660a61ba8be2 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog" Date: Wed, 16 Apr 2014 21:48:08 +0000 Subject: [PATCH 04/10] --- ...rmissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn index 861673fb37..2dfd694404 100644 --- a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn +++ b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn @@ -23,6 +23,7 @@ Plus, og+r permissions can actually be important for setups like serving content cd dir2 git annex get ctrl^c + git annex get ls -lL ... see different perms From b950425207581d5e7334562a05efeb110ebda1f2 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo" Date: Thu, 17 Apr 2014 07:40:28 +0000 Subject: [PATCH 05/10] Added a comment: remotedaemon in pre-built tarballs --- ...ment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment diff --git a/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment b/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment new file mode 100644 index 0000000000..5ff090ffde --- /dev/null +++ b/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo" + nickname="Georg" + subject=" remotedaemon in pre-built tarballs" + date="2014-04-17T07:40:25Z" + content=""" +Hi Joey, + +can you tell me when the pre-built Linux tarballs will include the remotedaemon? +Are they updated on a daily basis? + +Best regards, Georg +"""]] From 107dc6bde4c24a488635b555184b6c05c008d618 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8" Date: Thu, 17 Apr 2014 11:42:25 +0000 Subject: [PATCH 06/10] --- ...o_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn | 1 + 1 file changed, 1 insertion(+) create mode 100644 doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn diff --git a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn new file mode 100644 index 0000000000..00f500d100 --- /dev/null +++ b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn @@ -0,0 +1 @@ +One problem I keep having when using a direct repo is that in order to get to the previous versions of a file you have to convert that repo to indirect and then checkout previous commits this becomes problematic when the repo in question is large conversion takes a long time and applications gets confused if there are open files from the repo as they go from actual files to symlinks. Is it possible to have a separate annex command that will checkout a previous version of a file to a different directory so we can replace/inspect it. From ba84ca76616683d08274770b07052e533dcafc73 Mon Sep 17 00:00:00 2001 From: "http://schnouki.net/" Date: Thu, 17 Apr 2014 11:50:35 +0000 Subject: [PATCH 07/10] --- .../sync_stages_deletions_on_remote.mdwn | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 doc/forum/sync_stages_deletions_on_remote.mdwn diff --git a/doc/forum/sync_stages_deletions_on_remote.mdwn b/doc/forum/sync_stages_deletions_on_remote.mdwn new file mode 100644 index 0000000000..73a51d0b0a --- /dev/null +++ b/doc/forum/sync_stages_deletions_on_remote.mdwn @@ -0,0 +1,72 @@ +I'm having an issue with 2 repos: one on my laptop, the other on my NAS. Both are in indirect mode, running Arch Linux, and have the latest Git version. Laptop has git-annex 5.20140411-gda795e0, NAS has 5.20140319-g9aa31b7 (from prebuilt tarballs). + +The issue is quite simple. When I `git-annex add` new files on my laptop, commit them, and then `git-annex sync` them, they show up as staged for deletion on my NAS. + + laptop $ git annex add some-file + laptop $ git commit -m "Add some-file" + laptop $ git annex sync + commit ok + pull ds413j + ok + push ds413j + Counting objects: 133, done. + Delta compression using up to 8 threads. + Compressing objects: 100% (78/78), done. + Writing objects: 100% (80/80), 10.64 KiB | 0 bytes/s, done. + Total 80 (delta 12), reused 0 (delta 0) + To ssh://**/** + 1dcd188..8ef4249 git-annex -> synced/git-annex + c0f45a6..21711d6 master -> synced/master + ok + laptop $ ssh $NAS + nas $ git status + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + deleted: some-file + + nas $ + +If I run `git annex sync` on the NAS, it will create a new commit that deletes that file. So I have to play with `git reset`/`git checkout` by hand to make sure that the new file won't be deleted. + +I'm not sure when this started, but I think it was after I did some stupid mistake (`git checkout -B master synced/master`, kill a `git annex sync` with Ctrl+C, or something else that even resulted in my non-bare repo to have "bare=true" in .git/config...). And I haven't yet been able to fix this. + +Any idea what can have caused this, how to fix it, and how to prevent it from happening again in the future? + +.git/config on NAS: + + [core] + repositoryformatversion = 0 + filemode = true + logallrefupdates = true + [annex] + uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f + version = 5 + diskreserve = 1 megabyte + autoupgrade = ask + debug = false + +.git/config on laptop: + + [core] + repositoryformatversion = 0 + filemode = true + bare = false + logallrefupdates = true + [branch "master"] + [annex] + uuid = f20cb506-945d-4c78-af1a-0aa884bb899b + version = 5 + diskreserve = 20 gigabytes + autoupgrade = ask + debug = false + expireunused = 7d + genmetadata = true + [push] + default = matching + [remote "ds413j"] + url = ssh://**/** + fetch = +refs/heads/*:refs/remotes/ds413j/* + annex-uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f + annex-sync = true From ed46fe11a57af2e6d923bfa45432391765edd08a Mon Sep 17 00:00:00 2001 From: "http://schnouki.net/" Date: Thu, 17 Apr 2014 12:16:41 +0000 Subject: [PATCH 08/10] Added a comment --- .../comment_1_2b639066095e450c2d9be3b2775d24b3._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment b/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment new file mode 100644 index 0000000000..24495fd024 --- /dev/null +++ b/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://schnouki.net/" + nickname="Schnouki" + subject="comment 1" + date="2014-04-17T12:16:41Z" + content=""" +Here's the output of `git annex sync --debug` (for a different commit): +"""]] From 66f44f634eacef1f8bc9255809a2ec15963aff89 Mon Sep 17 00:00:00 2001 From: "http://id.clacke.se/" Date: Thu, 17 Apr 2014 14:04:33 +0000 Subject: [PATCH 09/10] Added a comment --- .../comment_3_e9c44ea364513f090844f46af2ea46a1._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment diff --git a/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment b/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment new file mode 100644 index 0000000000..063260ba10 --- /dev/null +++ b/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://id.clacke.se/" + nickname="Claes" + subject="comment 3" + date="2014-04-17T14:04:31Z" + content=""" +Yeah, git does not have the concept of checking out subdirectories that subversion does. You could, however, have different branches with different content that live in the same repo and therefore share the same git-annex backend, so there could be overlap between what files are in what branch without them using up much extra disk space. +"""]] From 4c8a31576b0130eda4fb4e07f1f07e3b72fb7a68 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 17 Apr 2014 17:25:30 +0000 Subject: [PATCH 10/10] Added a comment --- ...mment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment diff --git a/doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment b/doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment new file mode 100644 index 0000000000..bf120c20ab --- /dev/null +++ b/doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.191" + subject="comment 1" + date="2014-04-17T17:25:29Z" + content=""" +That error message is a git error message (from git's `wrapper.c`), not a git-annex error message. + +It's quite possible that git does not scale to as many file on Windows as it does on Unix, and git is known to not scale particularly well to vast numbers of files even on unix, although running out of memory is not the typical failure mode there. + +I think you should file a bug report on git. +"""]]