mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

retitle and comment

Browse source
This commit is contained in:
Joey Hess 2024-05-28 12:07:58 -04:00
parent e19f56e7d8
commit 1bb819f597
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 42 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission.mdwn
View file

@ -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.

40
doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission/comment_1_c081e6824b116ca4960dc31a0a20b81a._comment Normal file
View file

@ -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`.
"""]]