response

1 files changed, 22 insertions, 0 deletions

diff --git a/doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_2_0619eec44cddf3d3b1aae27c7bd1389a._comment b/doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_2_0619eec44cddf3d3b1aae27c7bd1389a._comment
new file mode 100644
index 000000000..5ee888e6a
--- /dev/null
+++ b/doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_2_0619eec44cddf3d3b1aae27c7bd1389a._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-10-10T17:23:14Z"
+ content="""
+The write bit is necessary so that the files can be opened in write mode to
+lock them. Normally the write bit is temporarily enabled and then disabled
+for locking, but in a shared repository, some other user may own the file,
+which prevents the user from changing its permissions.
+
+Similarly, the parent directory is not made unwritable in a shared
+repository, because other users won't be able to temporarily flip the write
+bit on when making changes.
+
+[[!commit 0d432dd1a4f718225c4192d0834a4e0a34b3e4bd]] used the latter as a
+rationalle to allow the former.
+
+I suppose it could use separate lock files from the content file, 
+as is already done in direct mode. However interaction between different
+versions of git-annex with different ideas about locking could result in
+`git annex drop` losing data.
+"""]]