strong verification on retrieval from annexobjects location
The file in the annexobjects location may have been renamed from a previously exported file that got deleted in a subsequent export. Or it may be renamed to annexobjects temporarily before being renamed to another name (to handle eg pairwise renames). But, an exported file is not guaranteed to contain the content of the key that the local repository last exported there. Another tree could have been exported from elsewhere in the meantime. So, files in annexobjects do not necessarily have the content of their key. And so have to be strongly verified when retrieving. The same as is done when retrieving exported files.
This commit is contained in:
parent
fe01a1e7e1
commit
ee076b68f5
3 changed files with 29 additions and 31 deletions
|
@ -80,8 +80,6 @@ also remove from the objects location.
|
|||
|
||||
----
|
||||
|
||||
# trust
|
||||
|
||||
Could a remote with annexobjects=yet and exporttree=yes but without
|
||||
importtree=yes not be forced to be untrusted?
|
||||
|
||||
|
@ -92,11 +90,12 @@ If the annexobjects directory only gets keys uploaded to it, and never had
|
|||
exported files renamed into it, its content will always be as expected, and
|
||||
perhaps the remote does not need to be untrusted.
|
||||
|
||||
OTOH, if an exported file that is being deleted in an updated export gets
|
||||
renamed into the annexobjects directory, it's possible that the file has in
|
||||
fact been overwritten with other content (by git-annex in another clone of
|
||||
the repository), and so the object in annexobjects would not be as
|
||||
expected. So unfortunately, it seems that rename can't be done.
|
||||
OTOH, if an exported file that is being deleted (or pairwise renamed) in an
|
||||
updated export gets renamed into the annexobjects directory, it's possible
|
||||
that the file has in fact been overwritten with other content (by git-annex
|
||||
in another clone of the repository), and so the object in annexobjects
|
||||
would not be as expected. So unfortunately, it seems that rename can't be
|
||||
done without forcing untrusted.
|
||||
|
||||
Note that, exporting a new tree can still delete any file at any time.
|
||||
If the remote is not untrusted, that could violate numcopies.
|
||||
|
@ -114,6 +113,10 @@ the annexobjects directory, and the other for the exported files. This
|
|||
clean separation avoids the above problem. But would be confusing for the
|
||||
user. HOWEVER, what if the two were treated as parts of the same cluster....?
|
||||
|
||||
This may be worth revisiting later, but for now, I am leaning to keeping it
|
||||
untrusted, and following down that line to make it as performant as
|
||||
possible.
|
||||
|
||||
---
|
||||
|
||||
Implementing in the "exportreeplus" branch --[[Joey]]
|
||||
|
|
|
@ -36,13 +36,6 @@ Planned schedule of work:
|
|||
* `git-annex export` when renaming an exported file to a temporary name
|
||||
should use the annexobjects location.
|
||||
|
||||
* Make annexobjects=true remotes not be untrusted, if possible. See todo.
|
||||
|
||||
Alternatively, if they do need to be untrusted, the retrieval from the
|
||||
annexobjects location may also need to do strong verification of the
|
||||
content, if exported files ever get renamed into the annexobjects
|
||||
location.
|
||||
|
||||
## items deferred until later for p2p protocol over http
|
||||
|
||||
* `git-annex p2phttp` should support serving several repositories at the same
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue