|author||Joey Hess <email@example.com>||2017-10-10 13:37:46 -0400|
|committer||Joey Hess <firstname.lastname@example.org>||2017-10-10 13:37:46 -0400|
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
@@ -0,0 +1,22 @@
+ subject="""comment 2"""
+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.