2019-02-20 19:55:01 +00:00
|
|
|
{- Helper to make remotes support export and import (or not).
|
2017-09-01 17:02:07 +00:00
|
|
|
-
|
2019-02-20 19:55:01 +00:00
|
|
|
- Copyright 2017-2019 Joey Hess <id@joeyh.name>
|
2017-09-01 17:02:07 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2017-09-01 17:02:07 +00:00
|
|
|
-}
|
|
|
|
|
2019-03-04 21:50:41 +00:00
|
|
|
{-# LANGUAGE FlexibleInstances, FlexibleContexts #-}
|
2017-09-07 17:45:31 +00:00
|
|
|
|
2019-02-20 19:55:01 +00:00
|
|
|
module Remote.Helper.ExportImport where
|
2017-09-01 17:02:07 +00:00
|
|
|
|
|
|
|
import Annex.Common
|
|
|
|
import Types.Remote
|
2017-09-04 20:39:56 +00:00
|
|
|
import Types.Key
|
2020-01-10 18:10:20 +00:00
|
|
|
import Types.ProposedAccepted
|
2021-07-27 18:07:23 +00:00
|
|
|
import Annex.Verify
|
2020-12-15 16:08:08 +00:00
|
|
|
import Remote.Helper.Encryptable (encryptionIsEnabled)
|
2019-03-04 21:50:41 +00:00
|
|
|
import qualified Database.Export as Export
|
|
|
|
import qualified Database.ContentIdentifier as ContentIdentifier
|
2017-09-19 18:20:47 +00:00
|
|
|
import Annex.Export
|
2019-03-07 17:32:33 +00:00
|
|
|
import Annex.LockFile
|
2020-01-14 16:35:08 +00:00
|
|
|
import Annex.SpecialRemote.Config
|
2018-12-03 18:15:15 +00:00
|
|
|
import Git.Types (fromRef)
|
|
|
|
import Logs.Export
|
2019-03-04 22:20:12 +00:00
|
|
|
import Logs.ContentIdentifier (recordContentIdentifier)
|
2017-09-01 17:02:07 +00:00
|
|
|
|
2017-09-18 22:40:16 +00:00
|
|
|
import Control.Concurrent.STM
|
2017-09-04 16:40:33 +00:00
|
|
|
|
|
|
|
-- | Use for remotes that do not support exports.
|
2017-09-07 17:45:31 +00:00
|
|
|
class HasExportUnsupported a where
|
|
|
|
exportUnsupported :: a
|
2017-09-04 16:40:33 +00:00
|
|
|
|
2020-01-14 16:35:08 +00:00
|
|
|
instance HasExportUnsupported (ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool) where
|
2017-09-07 17:45:31 +00:00
|
|
|
exportUnsupported = \_ _ -> return False
|
|
|
|
|
2019-01-30 18:55:28 +00:00
|
|
|
instance HasExportUnsupported (ExportActions Annex) where
|
|
|
|
exportUnsupported = ExportActions
|
2020-05-15 16:17:15 +00:00
|
|
|
{ storeExport = nope
|
2020-05-15 16:51:09 +00:00
|
|
|
, retrieveExport = nope
|
2017-09-07 17:45:31 +00:00
|
|
|
, checkPresentExport = \_ _ -> return False
|
2020-05-15 18:11:59 +00:00
|
|
|
, removeExport = nope
|
2020-12-28 18:37:15 +00:00
|
|
|
, versionedExport = False
|
2020-05-15 18:32:45 +00:00
|
|
|
, removeExportDirectory = nope
|
2024-03-09 17:37:51 +00:00
|
|
|
, renameExport = Nothing
|
2017-09-07 17:45:31 +00:00
|
|
|
}
|
2020-05-15 16:17:15 +00:00
|
|
|
where
|
|
|
|
nope = giveup "export not supported"
|
2017-09-07 17:45:31 +00:00
|
|
|
|
2019-02-20 19:55:01 +00:00
|
|
|
-- | Use for remotes that do not support imports.
|
|
|
|
class HasImportUnsupported a where
|
|
|
|
importUnsupported :: a
|
|
|
|
|
2020-01-14 16:35:08 +00:00
|
|
|
instance HasImportUnsupported (ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool) where
|
2019-02-20 19:55:01 +00:00
|
|
|
importUnsupported = \_ _ -> return False
|
|
|
|
|
|
|
|
instance HasImportUnsupported (ImportActions Annex) where
|
|
|
|
importUnsupported = ImportActions
|
2020-12-22 18:20:11 +00:00
|
|
|
{ listImportableContents = nope
|
2020-07-03 17:41:57 +00:00
|
|
|
, importKey = Nothing
|
2020-05-15 16:51:09 +00:00
|
|
|
, retrieveExportWithContentIdentifier = nope
|
2020-05-15 16:17:15 +00:00
|
|
|
, storeExportWithContentIdentifier = nope
|
2020-05-15 18:11:59 +00:00
|
|
|
, removeExportWithContentIdentifier = nope
|
2020-05-15 18:32:45 +00:00
|
|
|
, removeExportDirectoryWhenEmpty = nope
|
2019-03-05 20:02:33 +00:00
|
|
|
, checkPresentExportWithContentIdentifier = \_ _ _ -> return False
|
2019-02-20 19:55:01 +00:00
|
|
|
}
|
2020-05-15 16:17:15 +00:00
|
|
|
where
|
|
|
|
nope = giveup "import not supported"
|
2019-02-20 19:55:01 +00:00
|
|
|
|
2020-01-14 16:35:08 +00:00
|
|
|
exportIsSupported :: ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool
|
2017-09-07 17:45:31 +00:00
|
|
|
exportIsSupported = \_ _ -> return True
|
|
|
|
|
2020-01-14 16:35:08 +00:00
|
|
|
importIsSupported :: ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool
|
2019-03-04 20:02:56 +00:00
|
|
|
importIsSupported = \_ _ -> return True
|
|
|
|
|
|
|
|
-- | Prevent or allow exporttree=yes and importtree=yes when
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
-- setting up a new remote, depending on the remote's capabilities.
|
2019-03-04 20:02:56 +00:00
|
|
|
adjustExportImportRemoteType :: RemoteType -> RemoteType
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
adjustExportImportRemoteType rt = rt { setup = setup' }
|
2017-09-07 17:45:31 +00:00
|
|
|
where
|
2020-01-14 16:35:08 +00:00
|
|
|
setup' st mu cp c gc = do
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
pc <- either giveup return . parseRemoteConfig c
|
|
|
|
=<< configParser rt c
|
2020-01-14 16:35:08 +00:00
|
|
|
let checkconfig supported configured configfield cont =
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
ifM (supported rt pc gc <&&> pure (not (thirdPartyPopulated rt)))
|
2019-03-04 20:02:56 +00:00
|
|
|
( case st of
|
|
|
|
Init
|
2020-12-15 16:08:08 +00:00
|
|
|
| configured pc && encryptionIsEnabled pc ->
|
2020-01-10 18:10:20 +00:00
|
|
|
giveup $ "cannot enable both encryption and " ++ fromProposedAccepted configfield
|
2019-03-04 20:02:56 +00:00
|
|
|
| otherwise -> cont
|
2021-03-17 13:41:12 +00:00
|
|
|
Enable oldc -> enable oldc pc configured configfield cont
|
|
|
|
AutoEnable oldc -> enable oldc pc configured configfield cont
|
2020-01-14 16:35:08 +00:00
|
|
|
, if configured pc
|
2020-01-10 18:10:20 +00:00
|
|
|
then giveup $ fromProposedAccepted configfield ++ " is not supported by this special remote"
|
2019-03-04 20:02:56 +00:00
|
|
|
else cont
|
|
|
|
)
|
2020-01-14 16:35:08 +00:00
|
|
|
checkconfig exportSupported exportTree exportTreeField $
|
2020-01-10 18:10:20 +00:00
|
|
|
checkconfig importSupported importTree importTreeField $
|
2020-12-10 17:17:40 +00:00
|
|
|
setup rt st mu cp c gc
|
2021-03-17 13:41:12 +00:00
|
|
|
|
|
|
|
enable oldc pc configured configfield cont = do
|
|
|
|
oldpc <- parsedRemoteConfig rt oldc
|
|
|
|
if configured pc /= configured oldpc
|
|
|
|
then giveup $ "cannot change " ++ fromProposedAccepted configfield ++ " of existing special remote"
|
|
|
|
else cont
|
2019-03-04 20:02:56 +00:00
|
|
|
|
2020-12-10 17:17:40 +00:00
|
|
|
-- | Adjust a remote to support exporttree=yes and/or importree=yes.
|
add RemoteStateHandle
This solves the problem of sameas remotes trampling over per-remote
state. Used for:
* per-remote state, of course
* per-remote metadata, also of course
* per-remote content identifiers, because two remote implementations
could in theory generate the same content identifier for two different
peices of content
While chunk logs are per-remote data, they don't use this, because the
number and size of chunks stored is a common property across sameas
remotes.
External special remote had a complication, where it was theoretically
possible for a remote to send SETSTATE or GETSTATE during INITREMOTE or
EXPORTSUPPORTED. Since the uuid of the remote is typically generate in
Remote.setup, it would only be possible to pass a Maybe
RemoteStateHandle into it, and it would otherwise have to construct its
own. Rather than go that route, I decided to send an ERROR in this case.
It seems unlikely that any existing external special remote will be
affected. They would have to make up a git-annex key, and set state for
some reason during INITREMOTE. I can imagine such a hack, but it doesn't
seem worth complicating the code in such an ugly way to support it.
Unfortunately, both TestRemote and Annex.Import needed the Remote
to have a new field added that holds its RemoteStateHandle.
2019-10-14 16:33:27 +00:00
|
|
|
adjustExportImport :: Remote -> RemoteStateHandle -> Annex Remote
|
2020-12-17 19:52:12 +00:00
|
|
|
adjustExportImport r rs = do
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
isexport <- pure (exportTree (config r))
|
|
|
|
<&&> isExportSupported r
|
|
|
|
-- When thirdPartyPopulated is True, the remote
|
|
|
|
-- does not need to be configured with importTree to support
|
|
|
|
-- imports.
|
2020-12-21 17:24:07 +00:00
|
|
|
isimport <- pure (importTree (config r) || thirdPartyPopulated (remotetype r))
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
<&&> isImportSupported r
|
2020-12-17 20:25:02 +00:00
|
|
|
let r' = r
|
2020-12-17 19:52:12 +00:00
|
|
|
{ remotetype = (remotetype r)
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
{ exportSupported = if isexport
|
2020-12-17 19:52:12 +00:00
|
|
|
then exportSupported (remotetype r)
|
|
|
|
else exportUnsupported
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
, importSupported = if isimport
|
2020-12-17 19:52:12 +00:00
|
|
|
then importSupported (remotetype r)
|
|
|
|
else importUnsupported
|
2017-09-13 16:05:53 +00:00
|
|
|
}
|
2020-12-17 20:25:02 +00:00
|
|
|
}
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
if not isexport && not isimport
|
2020-12-17 20:25:02 +00:00
|
|
|
then return r'
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
else adjustExportImport' isexport isimport r' rs
|
2020-12-17 20:25:02 +00:00
|
|
|
|
|
|
|
adjustExportImport' :: Bool -> Bool -> Remote -> RemoteStateHandle -> Annex Remote
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
adjustExportImport' isexport isimport r rs = do
|
2020-12-17 20:25:02 +00:00
|
|
|
dbv <- prepdbv
|
|
|
|
ciddbv <- prepciddb
|
2020-12-28 18:37:15 +00:00
|
|
|
let versioned = versionedExport (exportActions r)
|
2020-12-17 20:25:02 +00:00
|
|
|
return $ r
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
{ exportActions = if isexport
|
|
|
|
then if isimport
|
2020-12-17 19:52:12 +00:00
|
|
|
then exportActionsForImport dbv ciddbv (exportActions r)
|
|
|
|
else exportActions r
|
|
|
|
else exportUnsupported
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
, importActions = if isimport
|
2020-12-17 19:52:12 +00:00
|
|
|
then importActions r
|
|
|
|
else importUnsupported
|
|
|
|
, storeKey = \k af p ->
|
|
|
|
-- Storing a key on an export could be implemented,
|
2022-08-19 21:45:04 +00:00
|
|
|
-- but it would perform unnecessary work
|
2020-12-17 19:52:12 +00:00
|
|
|
-- when another repository has already stored the
|
|
|
|
-- key, and the local repository does not know
|
|
|
|
-- about it. To avoid unnecessary costs, don't do it.
|
2020-12-28 20:36:26 +00:00
|
|
|
if thirdpartypopulated
|
|
|
|
then giveup "remote is not populated by git-annex"
|
|
|
|
else if isexport
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
then giveup "remote is configured with exporttree=yes; use `git-annex export` to store content on it"
|
|
|
|
else if isimport
|
|
|
|
then giveup "remote is configured with importtree=yes and without exporttree=yes; cannot modify content stored on it"
|
|
|
|
else storeKey r k af p
|
2020-12-17 19:52:12 +00:00
|
|
|
, removeKey = \k ->
|
|
|
|
-- 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.
|
2020-12-28 20:36:26 +00:00
|
|
|
if thirdpartypopulated
|
2020-12-28 20:48:38 +00:00
|
|
|
then giveup "dropping content from this remote is not supported"
|
2020-12-28 20:36:26 +00:00
|
|
|
else if isexport
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
then giveup "dropping content from an export is not supported; use `git annex export` to export a tree that lacks the files you want to remove"
|
|
|
|
else if isimport
|
|
|
|
then giveup "dropping content from this remote is not supported because it is configured with importtree=yes"
|
|
|
|
else removeKey r k
|
2020-12-28 20:05:14 +00:00
|
|
|
, lockContent = if versioned
|
2020-12-17 17:46:34 +00:00
|
|
|
then lockContent r
|
|
|
|
else Nothing
|
2021-08-17 16:41:36 +00:00
|
|
|
, retrieveKeyFile = \k af dest p vc ->
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
if isimport
|
2021-08-17 16:41:36 +00:00
|
|
|
then supportversionedretrieve k af dest p vc $
|
2020-12-17 19:52:12 +00:00
|
|
|
retrieveKeyFileFromImport dbv ciddbv k af dest p
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
else if isexport
|
2021-08-17 16:41:36 +00:00
|
|
|
then supportversionedretrieve k af dest p vc $
|
2020-12-17 19:52:12 +00:00
|
|
|
retrieveKeyFileFromExport dbv k af dest p
|
2021-08-17 16:41:36 +00:00
|
|
|
else retrieveKeyFile r k af dest p vc
|
2020-12-28 18:57:23 +00:00
|
|
|
, retrieveKeyFileCheap = if versioned
|
2020-12-17 18:01:42 +00:00
|
|
|
then retrieveKeyFileCheap r
|
|
|
|
else Nothing
|
2020-12-28 18:37:15 +00:00
|
|
|
, checkPresent = \k -> if versioned
|
2020-12-17 19:52:12 +00:00
|
|
|
then checkPresent r k
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
else if isimport
|
2020-12-17 19:52:12 +00:00
|
|
|
then anyM (checkPresentImport ciddbv k)
|
2020-12-28 20:36:26 +00:00
|
|
|
=<< getanyexportlocs dbv k
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
else if isexport
|
2020-12-17 19:52:12 +00:00
|
|
|
-- Check if any of the files a key
|
|
|
|
-- was exported to are present. This
|
|
|
|
-- doesn't guarantee the export
|
|
|
|
-- contains the right content,
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
-- if the remote is an export,
|
|
|
|
-- or if something else can write
|
|
|
|
-- to it. Remotes that have such
|
|
|
|
-- problems are made untrusted,
|
|
|
|
-- so it's not worried about here.
|
2020-12-17 19:52:12 +00:00
|
|
|
then anyM (checkPresentExport (exportActions r) k)
|
2020-12-28 20:36:26 +00:00
|
|
|
=<< getanyexportlocs dbv k
|
2020-12-17 19:52:12 +00:00
|
|
|
else checkPresent r k
|
2020-12-17 18:01:42 +00:00
|
|
|
-- checkPresent from an export is more expensive
|
|
|
|
-- than otherwise, so not cheap. Also, this
|
|
|
|
-- avoids things that look at checkPresentCheap and
|
|
|
|
-- silently skip non-present files from behaving
|
|
|
|
-- in confusing ways when there's an export
|
|
|
|
-- conflict (or an import conflict).
|
2020-12-28 18:57:23 +00:00
|
|
|
, checkPresentCheap = False
|
2020-12-28 19:08:53 +00:00
|
|
|
-- Export/import remotes can lose content stored on them in
|
|
|
|
-- many ways. This is not a problem with versioned
|
|
|
|
-- ones though, since they still allow accessing by Key.
|
|
|
|
-- And for thirdPartyPopulated, it depends on how the
|
|
|
|
-- content gets actually stored in the remote, so
|
2023-03-14 02:39:16 +00:00
|
|
|
-- is not overridden here.
|
2020-12-28 19:08:53 +00:00
|
|
|
, untrustworthy =
|
|
|
|
if versioned || thirdPartyPopulated (remotetype r)
|
|
|
|
then untrustworthy r
|
2022-05-09 19:53:23 +00:00
|
|
|
else True
|
2020-12-17 18:01:42 +00:00
|
|
|
-- git-annex testremote cannot be used to test
|
|
|
|
-- import/export since it stores keys.
|
2020-12-28 18:57:23 +00:00
|
|
|
, mkUnavailable = return Nothing
|
2020-12-17 19:52:12 +00:00
|
|
|
, getInfo = do
|
|
|
|
is <- getInfo r
|
2020-12-28 20:36:26 +00:00
|
|
|
is' <- if isexport && not thirdpartypopulated
|
2020-12-17 19:52:12 +00:00
|
|
|
then do
|
|
|
|
ts <- map fromRef . exportedTreeishes
|
|
|
|
<$> getExport (uuid r)
|
2020-12-17 21:06:50 +00:00
|
|
|
return (is++[("exporttree", "yes"), ("exportedtree", unwords ts)])
|
2020-12-17 19:52:12 +00:00
|
|
|
else return is
|
2020-12-28 20:36:26 +00:00
|
|
|
return $ if isimport && not thirdpartypopulated
|
2020-12-17 21:06:50 +00:00
|
|
|
then (is'++[("importtree", "yes")])
|
2020-12-17 19:52:12 +00:00
|
|
|
else is'
|
2020-12-17 17:46:34 +00:00
|
|
|
}
|
2020-12-17 19:52:12 +00:00
|
|
|
where
|
2020-12-28 20:36:26 +00:00
|
|
|
thirdpartypopulated = thirdPartyPopulated (remotetype r)
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
|
2023-03-14 02:39:16 +00:00
|
|
|
-- exportActions adjusted to use the equivalent import actions,
|
2020-12-17 19:52:12 +00:00
|
|
|
-- which take ContentIdentifiers into account.
|
|
|
|
exportActionsForImport dbv ciddbv ea = ea
|
|
|
|
{ storeExport = \f k loc p -> do
|
|
|
|
db <- getciddb ciddbv
|
|
|
|
exportdb <- getexportdb dbv
|
|
|
|
oldks <- liftIO $ Export.getExportTreeKey exportdb loc
|
|
|
|
oldcids <- liftIO $ concat
|
|
|
|
<$> mapM (ContentIdentifier.getContentIdentifiers db rs) oldks
|
|
|
|
newcid <- storeExportWithContentIdentifier (importActions r) f k loc oldcids p
|
2022-08-11 20:57:44 +00:00
|
|
|
cidlck <- calcRepo' gitAnnexContentIdentifierLock
|
|
|
|
withExclusiveLock cidlck $ do
|
2020-12-17 19:52:12 +00:00
|
|
|
liftIO $ ContentIdentifier.recordContentIdentifier db rs newcid k
|
|
|
|
liftIO $ ContentIdentifier.flushDbQueue db
|
|
|
|
recordContentIdentifier rs newcid k
|
|
|
|
, removeExport = \k loc ->
|
|
|
|
removeExportWithContentIdentifier (importActions r) k loc
|
|
|
|
=<< getkeycids ciddbv k
|
|
|
|
, removeExportDirectory = removeExportDirectoryWhenEmpty (importActions r)
|
|
|
|
-- renameExport is optional, and the remote's
|
|
|
|
-- implementation may lose modifications to the file
|
|
|
|
-- (by eg copying and then deleting) so don't use it
|
2024-03-09 17:37:51 +00:00
|
|
|
, renameExport = Nothing
|
2020-12-17 19:52:12 +00:00
|
|
|
, checkPresentExport = checkPresentImport ciddbv
|
|
|
|
}
|
|
|
|
|
2019-03-05 19:42:39 +00:00
|
|
|
prepciddb = do
|
|
|
|
lcklckv <- liftIO newEmptyTMVarIO
|
|
|
|
dbtv <- liftIO newEmptyTMVarIO
|
|
|
|
return (dbtv, lcklckv)
|
|
|
|
|
2020-12-10 17:17:40 +00:00
|
|
|
prepdbv = do
|
2019-03-05 19:42:39 +00:00
|
|
|
lcklckv <- liftIO newEmptyTMVarIO
|
|
|
|
dbv <- liftIO newEmptyTMVarIO
|
|
|
|
exportinconflict <- liftIO $ newTVarIO False
|
2020-02-26 18:57:29 +00:00
|
|
|
return (dbv, lcklckv, exportinconflict)
|
2019-03-05 19:42:39 +00:00
|
|
|
|
2019-03-06 18:35:16 +00:00
|
|
|
-- Only open the database once it's needed.
|
2019-03-05 19:42:39 +00:00
|
|
|
getciddb (dbtv, lcklckv) =
|
|
|
|
liftIO (atomically (tryReadTMVar dbtv)) >>= \case
|
2019-03-06 18:35:16 +00:00
|
|
|
Just db -> return db
|
2019-03-05 19:42:39 +00:00
|
|
|
-- let only one thread take the lock
|
|
|
|
Nothing -> ifM (liftIO $ atomically $ tryPutTMVar lcklckv ())
|
|
|
|
( do
|
|
|
|
db <- ContentIdentifier.openDb
|
2023-06-02 17:30:30 +00:00
|
|
|
db' <- ContentIdentifier.needsUpdateFromLog db >>= \case
|
2022-08-11 20:57:44 +00:00
|
|
|
Just v -> do
|
|
|
|
cidlck <- calcRepo' gitAnnexContentIdentifierLock
|
|
|
|
withExclusiveLock cidlck $
|
|
|
|
ContentIdentifier.updateFromLog db v
|
2023-06-02 17:30:30 +00:00
|
|
|
Nothing -> pure db
|
|
|
|
liftIO $ atomically $ putTMVar dbtv db'
|
|
|
|
return db'
|
2019-03-05 19:42:39 +00:00
|
|
|
-- loser waits for winner to open the db and
|
|
|
|
-- can then also use its handle
|
2019-03-06 18:35:16 +00:00
|
|
|
, liftIO $ atomically (readTMVar dbtv)
|
2019-03-05 19:42:39 +00:00
|
|
|
)
|
|
|
|
|
2019-03-06 18:35:16 +00:00
|
|
|
-- Only open the database once it's needed.
|
2020-02-26 18:57:29 +00:00
|
|
|
--
|
|
|
|
-- After opening the database, check if the export log is
|
|
|
|
-- different than the database, and update the database, to notice
|
|
|
|
-- when an export has been updated from another repository.
|
2020-12-17 19:52:12 +00:00
|
|
|
getexportdb (dbv, lcklckv, exportinconflict) =
|
2019-03-05 19:42:39 +00:00
|
|
|
liftIO (atomically (tryReadTMVar dbv)) >>= \case
|
|
|
|
Just db -> return db
|
|
|
|
-- let only one thread take the lock
|
|
|
|
Nothing -> ifM (liftIO $ atomically $ tryPutTMVar lcklckv ())
|
|
|
|
( do
|
|
|
|
db <- Export.openDb (uuid r)
|
2020-12-17 19:52:12 +00:00
|
|
|
updateexportdb db exportinconflict
|
2019-03-05 19:42:39 +00:00
|
|
|
liftIO $ atomically $ putTMVar dbv db
|
|
|
|
return db
|
|
|
|
-- loser waits for winner to open the db and
|
|
|
|
-- can then also use its handle
|
|
|
|
, liftIO $ atomically (readTMVar dbv)
|
|
|
|
)
|
|
|
|
|
2020-02-26 18:57:29 +00:00
|
|
|
getexportinconflict (_, _, v) = v
|
2019-03-05 19:42:39 +00:00
|
|
|
|
2020-12-17 19:52:12 +00:00
|
|
|
updateexportdb db exportinconflict =
|
2020-02-26 18:57:29 +00:00
|
|
|
Export.updateExportTreeFromLog db >>= \case
|
|
|
|
Export.ExportUpdateSuccess -> return ()
|
|
|
|
Export.ExportUpdateConflict -> do
|
|
|
|
warnExportImportConflict r
|
|
|
|
liftIO $ atomically $
|
|
|
|
writeTVar exportinconflict True
|
2019-03-05 20:02:33 +00:00
|
|
|
|
2020-12-28 20:36:26 +00:00
|
|
|
getanyexportlocs dbv k = do
|
2020-12-17 19:52:12 +00:00
|
|
|
db <- getexportdb dbv
|
2019-03-05 20:02:33 +00:00
|
|
|
liftIO $ Export.getExportTree db k
|
2020-12-17 19:52:12 +00:00
|
|
|
|
2020-12-28 20:36:26 +00:00
|
|
|
getexportlocs dbv k = do
|
2020-12-17 19:52:12 +00:00
|
|
|
db <- getexportdb dbv
|
|
|
|
liftIO $ Export.getExportTree db k >>= \case
|
|
|
|
[] -> ifM (atomically $ readTVar $ getexportinconflict dbv)
|
|
|
|
( giveup "unknown export location, likely due to the export conflict"
|
2020-12-28 20:36:26 +00:00
|
|
|
, return []
|
2020-12-17 19:52:12 +00:00
|
|
|
)
|
2020-12-28 20:36:26 +00:00
|
|
|
ls -> return ls
|
2022-09-20 17:33:57 +00:00
|
|
|
|
|
|
|
tryexportlocs dbv k a =
|
|
|
|
go Nothing =<< getexportlocs dbv k
|
|
|
|
where
|
|
|
|
go Nothing [] = giveup "unknown export location"
|
|
|
|
go (Just ex) [] = throwM ex
|
|
|
|
go _ (l:ls) = tryNonAsync (a l) >>= \case
|
|
|
|
Right v -> return v
|
|
|
|
Left e -> go (Just e) ls
|
2020-12-17 19:52:12 +00:00
|
|
|
|
|
|
|
getkeycids ciddbv k = do
|
|
|
|
db <- getciddb ciddbv
|
|
|
|
liftIO $ ContentIdentifier.getContentIdentifiers db rs k
|
2019-03-05 19:42:39 +00:00
|
|
|
|
2020-12-17 19:52:12 +00:00
|
|
|
-- Keys can be retrieved using retrieveExport, but since that
|
|
|
|
-- retrieves from a path in the remote that another writer could
|
|
|
|
-- have replaced with content not of the requested key, the content
|
|
|
|
-- has to be strongly verified.
|
|
|
|
retrieveKeyFileFromExport dbv k _af dest p = ifM (isVerifiable k)
|
2022-09-20 17:33:57 +00:00
|
|
|
( tryexportlocs dbv k $ \loc ->
|
|
|
|
retrieveExport (exportActions r) k loc dest p >>= return . \case
|
2022-05-09 16:25:04 +00:00
|
|
|
UnVerified -> MustVerify
|
|
|
|
IncompleteVerify iv -> MustFinishIncompleteVerify iv
|
|
|
|
v -> v
|
2020-07-29 19:23:18 +00:00
|
|
|
, giveup $ "exported content cannot be verified due to using the " ++ decodeBS (formatKeyVariety (fromKey keyVariety k)) ++ " backend"
|
|
|
|
)
|
2020-12-17 19:52:12 +00:00
|
|
|
|
change retrieveExportWithContentIdentifier to take a list of ContentIdentifier
This partly fixes an issue where there are duplicate files in the
special remote, and the first file gets swapped with another duplicate,
or deleted. The swap case is fixed by this, the deleted case will need
other changes.
This makes retrieveExportWithContentIdentifier take a list of allowed
ContentIdentifier, same as storeExportWithContentIdentifier,
removeExportWithContentIdentifier, and
checkPresentExportWithContentIdentifier.
Of the special remotes that support importtree, borg is a special case
and does not use content identifiers, S3 I assume can't get mixed up
like this, directory certainly has the problem, and adb also appears to
have had the problem.
Sponsored-by: Graham Spencer on Patreon
2022-09-20 17:15:31 +00:00
|
|
|
retrieveKeyFileFromImport dbv ciddbv k af dest p = do
|
|
|
|
cids <- getkeycids ciddbv k
|
|
|
|
if not (null cids)
|
2022-09-20 17:33:57 +00:00
|
|
|
then tryexportlocs dbv k $ \loc ->
|
|
|
|
snd <$> retrieveExportWithContentIdentifier (importActions r) loc cids dest (Left k) p
|
2020-12-17 19:52:12 +00:00
|
|
|
-- In case a content identifier is somehow missing,
|
|
|
|
-- try this instead.
|
change retrieveExportWithContentIdentifier to take a list of ContentIdentifier
This partly fixes an issue where there are duplicate files in the
special remote, and the first file gets swapped with another duplicate,
or deleted. The swap case is fixed by this, the deleted case will need
other changes.
This makes retrieveExportWithContentIdentifier take a list of allowed
ContentIdentifier, same as storeExportWithContentIdentifier,
removeExportWithContentIdentifier, and
checkPresentExportWithContentIdentifier.
Of the special remotes that support importtree, borg is a special case
and does not use content identifiers, S3 I assume can't get mixed up
like this, directory certainly has the problem, and adb also appears to
have had the problem.
Sponsored-by: Graham Spencer on Patreon
2022-09-20 17:15:31 +00:00
|
|
|
else if isexport
|
2020-12-23 17:17:46 +00:00
|
|
|
then retrieveKeyFileFromExport dbv k af dest p
|
|
|
|
else giveup "no content identifier is recorded, unable to retrieve"
|
2020-12-17 19:52:12 +00:00
|
|
|
|
2020-12-28 18:37:15 +00:00
|
|
|
-- versionedExport remotes have a key/value store, so can use
|
2020-12-17 19:52:12 +00:00
|
|
|
-- the usual retrieveKeyFile, rather than an import/export
|
|
|
|
-- variant. However, fall back to that if retrieveKeyFile fails.
|
2021-08-17 16:41:36 +00:00
|
|
|
supportversionedretrieve k af dest p vc a
|
2020-12-28 18:37:15 +00:00
|
|
|
| versionedExport (exportActions r) =
|
2021-08-17 16:41:36 +00:00
|
|
|
retrieveKeyFile r k af dest p vc
|
2020-12-17 19:52:12 +00:00
|
|
|
`catchNonAsync` const a
|
|
|
|
| otherwise = a
|
|
|
|
|
|
|
|
checkPresentImport ciddbv k loc =
|
|
|
|
checkPresentExportWithContentIdentifier
|
|
|
|
(importActions r)
|
|
|
|
k loc
|
|
|
|
=<< getkeycids ciddbv k
|