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

followup

Browse source
This commit is contained in:
Joey Hess 2022-06-22 13:19:35 -04:00
parent 87751092fd
commit cfc65ee9fc
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 52 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_1_fdad38ba9decc434e0d04a446f0a02e5._comment Normal file
View file

@ -0,0 +1,52 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-06-22T16:42:25Z"
content="""
I tried to construct a test case that I can from from these transcripts.
key=XDLRA--refs
mkdir $base/repo
cd $base/repo
git -c diff.ignoreSubmodules=none -C $base/repo init --bare
git config -z -l --show-origin
git -c diff.ignoreSubmodules=none config annex.private true
git -c diff.ignoreSubmodules=none annex init
git config -z -l --show-origin
git annex version --raw
git -c diff.ignoreSubmodules=none annex initremote origin type=directory directory=$remote encryption=none -c annex.dotfiles=true
git config -z -l --show-origin
git -c diff.ignoreSubmodules=none cat-file blob git-annex:remote.log
git -c diff.ignoreSubmodules=none annex fsck -f origin --fast --key $key -c annex.dotfiles=true
git -c diff.ignoreSubmodules=none annex drop --force --key $key -c annex.dotfiles=true
git -c diff.ignoreSubmodules=none annex get --key $key -c annex.dotfiles=true
git -c diff.ignoreSubmodules=none annex contentlocation $key -c annex.dotfiles=true
git -c diff.ignoreSubmodules=none annex drop --force --all -c annex.dotfiles=true
Now, this would normally fail at the fsck step, since no object file exists for
XDLRA--refs. I suppose that you must have pre-populated the special remote with
it, somehow, and left that part out. The fsck would then learn that the object
does exist there.
It seems to me that how you prepopulated it might be a crucial detail, since
that object file gets copied from the special remote and perhaps something to
do with its permissions etc are what is later preventing deleting the copy.
You're also using an external backend for whatever reason, and it would
simplify the test case if that external backend were not needed and it just
used a built-in backend. Using key=WORM--refs seems like it should behave the
same, unless your external backend is doing something very strange. If the
external backend is necessary to reproduce it, I will need some kind of minimal
version of it.
So, I've tried pre-populating the file in the remote like this:
mkdir -p $remote/06b/f75/WORM--refs
echo hi > $remote/06b/f75/WORM--refs/WORM--refs
With that, I've gotten as far as getting the test case to succeed on linux.
But I don't think it's worth the bother of getting a windows environment set up
and running these commands on it, without first knowing how you prepopulated
the special remote with the object file.
"""]]