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

Browse source
This commit is contained in:
beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec 2025-01-31 00:22:45 +00:00 • committed by admin
parent 0c0f4a20f4
commit b9466ddce2
1 changed files with 45 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

45
doc/bugs/whereused_--key_forcing_--historical._exportree__63__.mdwn Normal file
View file

@ -0,0 +1,45 @@
### Please describe the problem.
Selectively auditing the files annexed on an S3 container, where the file is stored by keyname, I attempted to confirm that the file is also annexed locally.
When I run git-annex whereused --key <keyname>, nothing comes up. But if I look for the file locally, I can see that it exists.
If I add --historical, I can see the file exists in some previous commit that I thought had been successfully merged, and moved on from. It seems like this might be related to export trees, because that keyword is also present in the output with --historical
[[!format sh """
$ git-annex whereused --key SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
$ git-annex whereused --historical --key SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG remotes/origin/git-annex~12:export.tree/2010-08-21/042.JPG
$ git-annex contentlocation SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
.git/annex/objects/0Z/Z3/SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG/SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
$ ls -l $(git-annex contentlocation SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG)
-r--r--r-- 1 shaddy shaddy 1000013 May 21 2024 .git/annex/objects/0Z/Z3/SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG/SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
$ git-annex findkeys | grep -F SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
$ ls -l 2010-08-21/042.JPG
lrwxrwxrwx 1 shaddy shaddy 201 May 20 2024 2010-08-21/042.JPG -> ../.git/annex/objects/0Z/Z3/SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG/SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
$ ls -lL 2010-08-21/042.JPG
-r--r--r-- 1 shaddy shaddy 1000013 May 21 2024 2010-08-21/042.JPG
$
"""]]
My reading of the documentation is that the file being present in the local annex shouldn't require the --historical argument, which is much slower.
### What steps will reproduce the problem?
As per above
### What version of git-annex are you using? On what operating system?
git-annex/10.20241031-1~ndall+1 on Ubuntu 22.04 LTS:
Linux computer-ubul 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
### Please provide any additional information below.
Nil
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Love git-annex. Long time supporter.