Added a comment

1 files changed, 18 insertions, 0 deletions

diff --git a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed/comment_1_0fc5c7251ead7a0fbbcd357a8bc53f05._comment b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed/comment_1_0fc5c7251ead7a0fbbcd357a8bc53f05._comment
new file mode 100644
index 000000000..48069eebd
--- /dev/null
+++ b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed/comment_1_0fc5c7251ead7a0fbbcd357a8bc53f05._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 1"
+ date="2014-04-17T18:32:40Z"
+ content="""
+(I think you forgot to mention you were using direct mode.)
+
+Like git, git-annex does not preserve file permissions. If you want to ensure that a group or everyone can read file in a git repository, you have to use the core.sharedRepository git configuration. git-annex will also honor that.
+
+git-annex will try to preserve the execute bit, since git does support that single permission bit. But even this cannot be guaranteed. (Eg, when using special remotes which have no concept of file permissions.)
+
+Interrupting rsync and resuming it does cause rsync to not transfer through permissions. This is rsync's normal behavior when not using -p. git-annex used to use rsync -p to preserve whatever file permissions there were. However, <http://bugs.debian.org/700282>, and then [[!commit f92eaf631509d02491c1b0ebfbb15145f80df797]].
+
+It looks like I could preserve the execute bit across interrupt and resume by using rsync's --executability option.
+
+Or, I could use the -p when git-annex is running in a non-crippled filesystem.
+"""]]