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

Added a comment

Browse source
This commit is contained in:
jgoerzen 2023-06-05 19:32:29 +00:00 • committed by admin
parent 1f0f774ab7
commit 432e7cd9f3
1 changed files with 24 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
doc/bugs/importtree_spends_hours_reading_cidsdb/comment_13_6043be5152ba2d44fb9aac4063060b56._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="jgoerzen"
avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
subject="comment 13"
date="2023-06-05T19:32:28Z"
content="""
My apologies for forgetting that.
So initially I thought it was after the last \"import source... ok\". I'm no longer convinced that it happens after the last one. There is clearly a phase before this starts, and a separate phase exhibiting this behavior.
The last output from one of these runs was:
```
/acrypt/git-annex/bind-ro/testdata/dvd/var..redacted..: openBinaryFile: permission denied (Permission denied)
^Mok
Failed to import some files from source. Re-run command to resume import.
```
And indeed there were about 2 dozen files out of that source set that it didn't have the permission to read.
I'm sorry it looked like expansion of scope. This is not really on NTFS; it's still on ZFS as it has been from the beginning. I had been testing with one of the repos on NTFS previously but in an effort to rule that out, I've been 100% on ZFS since before reporting this issue. \"acrypt\" is just the name of my ZFS pool and that refers to that it's atop LUKS (I don't believe this to be relevant, since the CPU time is in git-annex, not kcryptd)
"""]]