From 7a735c7a4f334bd208890164c3e505bdde9438ee Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 7 Jan 2025 13:37:57 -0400 Subject: [PATCH] comment --- ..._fcd6d9b8a9c569710ffdbd7f9be74352._comment | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/bugs/git-remote-annex_doesn__39__t_work_on_Windows___40__perms__41__/comment_3_fcd6d9b8a9c569710ffdbd7f9be74352._comment diff --git a/doc/bugs/git-remote-annex_doesn__39__t_work_on_Windows___40__perms__41__/comment_3_fcd6d9b8a9c569710ffdbd7f9be74352._comment b/doc/bugs/git-remote-annex_doesn__39__t_work_on_Windows___40__perms__41__/comment_3_fcd6d9b8a9c569710ffdbd7f9be74352._comment new file mode 100644 index 0000000000..0e9bb9f44b --- /dev/null +++ b/doc/bugs/git-remote-annex_doesn__39__t_work_on_Windows___40__perms__41__/comment_3_fcd6d9b8a9c569710ffdbd7f9be74352._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2025-01-07T17:29:57Z" + content=""" +Only way I can see thawing removing write perms if is you have +core.sharedrepository configured to a particular umask value. + +But it certainly is possible that some other part of git-annex removes +write perms. + +And in particular the directory special remote does, when content is stored +in it. And you're using that. + +So, new theory: The GITBUNDLE object is stored on the directory special +remote. When it later gets pulled from it, the file has readonly attribute +set. + +Can you check if the directory special remote contains files with the +readonly attribute set, and see if clearing that attribute prevents the +problem from happening? +"""]]