From 1bb819f5973894aac9dfb76c83142ae34b01bc54 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 28 May 2024 12:07:58 -0400 Subject: [PATCH] retitle and comment --- ...ck-present_repo_removes_+x_permission.mdwn | 2 + ..._c081e6824b116ca4960dc31a0a20b81a._comment | 40 +++++++++++++++++++ 2 files changed, 42 insertions(+) create mode 100644 doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission/comment_1_c081e6824b116ca4960dc31a0a20b81a._comment diff --git a/doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission.mdwn b/doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission.mdwn index 5dd73cc7a0..516197c1a1 100644 --- a/doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission.mdwn +++ b/doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission.mdwn @@ -1,3 +1,5 @@ +[[!meta title="git-annex adjust --unlock does not copy execute bit of object files"]] + It seems that performing `git annex adjust --unlock-present` or `sync` will remove the +x permission from files. diff --git a/doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission/comment_1_c081e6824b116ca4960dc31a0a20b81a._comment b/doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission/comment_1_c081e6824b116ca4960dc31a0a20b81a._comment new file mode 100644 index 0000000000..4f5b009918 --- /dev/null +++ b/doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission/comment_1_c081e6824b116ca4960dc31a0a20b81a._comment @@ -0,0 +1,40 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2024-05-28T15:46:45Z" + content=""" +Notice that `git-annex unlock` does preserve the execute bit when the +object file has it set. + +Currently, generating an adjusted branch does not look at permissions of +object files. + +Now git-annex generally does not preserve execute bit on object files (eg +when storing in a special remote), and of course doesn't know the +permissions of an object file that's not currently present. So, if adjusted +branch generation did look at the permissions, running it twice in two +different repositories, or at different times in the same repository could +result in different adjusted branch trees being generated. + +That might or might not be a problem for interoperability? Adjusted branches +are not usually pushed anywhere, so might not matter much. + +It seems that in `instance AdjustTreeItem LinkAdjustment` it would no +longer be able to have `adjustmentIsStable` return True. Well, it could, but +then `git-annex adjust --unlock` followed by `git-annex get foo` when it +happens to get an object with the execute bit, followed by `git-annex +adjust --unlock` would not reflect the execute bit in the adjusted branch. + +So handling that case matters, re-adjusting would get slower. This might +impact users who have a large tree they are adjusting with --unlock. +(`git-annex adjust --unlock-present` is already not stable of course, so no +additional performance penalty there) + +Of course, statting every object file to check for execute bits would also +make adjusting a large tree somewhat slower. Probably on the order of less +than 10% slower I'd guess, because it currently has to catKey, which is slower +than stat. + +Overall, I think this is probably worth doing, just to be symmetric with +`git-annex unlock`. +"""]]