don't support removing content from export with removeKey

There does not seem to be a use case for supporting that, and it would
need a lot of complication to support it in a way that allows eventual
consistency when two repositories are updating the same export.

This commit was sponsored by Henrik Riomar on Patreon.
This commit is contained in:
Joey Hess 2017-09-17 17:56:33 -04:00
parent ac4c8df2ca
commit 4a45f34fe1
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 9 additions and 46 deletions

View file

@ -117,20 +117,15 @@ adjustExportable r = case M.lookup "exporttree" (config r) of
warning $ "exported content cannot be verified due to using the " ++ formatKeyVariety (keyVariety k) ++ " backend"
return False
, retrieveKeyFileCheap = \_ _ _ -> return False
-- Remove all files a key was exported to.
, removeKey = \k -> do
locs <- liftIO $ getExportLocation db k
ea <- exportActions r
oks <- forM locs $ \loc ->
ifM (removeExport ea k loc)
( do
liftIO $ do
removeExportLocation db k loc
flushDbQueue db
removeEmptyDirectories ea db loc [k]
, return False
)
return (and oks)
-- Removing a key from an export would need to
-- change the tree in the export log to not include
-- the file. Otherwise, conflicts when removing
-- files would not be dealt with correctly.
-- There does not seem to be a good use case for
-- removing a key from an export in any case.
, removeKey = \_k -> do
warning "dropping content from an export is not supported; use `git annex export` to export a tree that lacks the files you want to remove"
return False
-- Can't lock content on exports, since they're
-- not key/value stores, and someone else could
-- change what's exported to a file at any time.

View file

@ -38,38 +38,6 @@ Work is in progress. Todo list:
Updating the export db could diff the last exported treeish with the
logged treeish. Add/delete exported files from the database to get
it to the same state as the remote database.
But, removeKey from an export makes the diff approach problimatic;
see below.
* removeKey from an export is problimatic in distributed context
A file can be removed from an export via removeKey,
which updates the export db and location log, but does not update
the export log. This is problimatic when multiple repos are updating
an export.
1. In repo A, file F with content K is exported
2. In repo B, file F with content K' is exported, since F changed in the
exported treeish.
3. In repo A, file F is removed from the export, which results in
K being removed from the location log for the export.
Did #3 happen before or after #2?
If #3 occurred before #2, then K' is present in the export
and the location log is correct.
If #3 occurred after #2, and A and B's git-annex branches
were not synced, then K' was accidentially removed
from the export, and the location log is now wrong.
Is there any reason to allow removeKey from an export?
Why would someone want to drop a single file from an export?
Why not remove the file from a tree, and export the new tree?
(Alternatively, removeKey could itself update the exported tree,
removing the file from it, and update the export log accordingly.
This would avoid the problem. But that's complication and it would be
rather slow and bloat the git repo with a lot of intermediate trees
when dropping multiple keys.)
* git-annex sync to export and export tracking branch