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.Backend
import Types.Key
2020-01-10 18:10:20 +00:00
import Types.ProposedAccepted
2017-09-04 20:39:56 +00:00
import Backend
2017-09-04 16:40:33 +00:00
import Remote.Helper.Encryptable ( isEncrypted )
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-05-15 18:32:45 +00:00
, removeExportDirectory = nope
2019-03-11 16:44:12 +00:00
, renameExport = \ _ _ _ -> return 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
2019-02-21 17:38:27 +00:00
{ listImportableContents = return 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
-- setting up a new remote, depending on exportSupported and importSupported.
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 =
ifM ( supported rt pc gc )
2019-03-04 20:02:56 +00:00
( case st of
Init
2020-01-14 16:35:08 +00:00
| configured pc && isEncrypted 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
2020-01-14 17:18:15 +00:00
Enable oldc -> 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
oldpc <- parsedRemoteConfig rt oldc
2020-01-14 17:18:15 +00:00
if configured pc /= configured oldpc
2020-01-14 16:35:08 +00:00
then giveup $ " cannot change " ++ fromProposedAccepted configfield ++ " of existing special remote "
else cont
, 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-01-14 16:35:08 +00:00
if importTree pc && not ( exportTree pc )
2019-03-04 20:02:56 +00:00
then giveup " cannot enable importtree=yes without also enabling exporttree=yes "
else setup rt st mu cp c gc
2019-03-04 21:50:41 +00:00
-- | Adjust a remote to support exporttree=yes and importree=yes.
2019-03-04 20:02:56 +00:00
--
2019-03-04 21:50:41 +00:00
-- Note that all remotes with importree=yes also have exporttree=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-01-14 16:35:08 +00:00
adjustExportImport r rs = case getRemoteConfigValue exportTreeField ( config r ) of
2019-03-04 21:50:41 +00:00
Nothing -> return $ notexport r
2020-01-14 16:35:08 +00:00
Just True -> ifM ( isExportSupported r )
( do
exportdbv <- prepexportdb
r' <- isexport exportdbv
if importTree ( config r )
then isimport r' exportdbv
else return r'
, return $ notexport r
)
Just False -> return $ notexport r
2017-09-07 17:45:31 +00:00
where
2019-03-04 21:50:41 +00:00
notexport r' = notimport r'
2017-09-13 16:05:53 +00:00
{ exportActions = exportUnsupported
2019-03-04 21:50:41 +00:00
, remotetype = ( remotetype r' )
2017-09-13 16:05:53 +00:00
{ exportSupported = exportUnsupported
}
}
2019-03-04 21:50:41 +00:00
notimport r' = r'
{ importActions = importUnsupported
, remotetype = ( remotetype r' )
{ importSupported = importUnsupported
}
}
2019-03-04 22:10:24 +00:00
isimport r' exportdbv = do
2019-03-05 19:42:39 +00:00
ciddbv <- prepciddb
2019-03-04 21:50:41 +00:00
2019-03-07 18:10:56 +00:00
let keycids k = do
2019-03-05 20:02:33 +00:00
db <- getciddb ciddbv
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
liftIO $ ContentIdentifier . getContentIdentifiers db rs k
2019-03-07 18:10:56 +00:00
let checkpresent k loc =
2019-03-05 20:02:33 +00:00
checkPresentExportWithContentIdentifier
( importActions r' )
2019-03-07 18:10:56 +00:00
k loc
=<< keycids k
2019-03-05 20:02:33 +00:00
2019-03-04 21:50:41 +00:00
return $ r'
{ exportActions = ( exportActions r' )
2019-03-05 18:20:14 +00:00
{ storeExport = \ f k loc p -> do
2019-03-05 19:42:39 +00:00
db <- getciddb ciddbv
2019-03-07 18:10:56 +00:00
exportdb <- getexportdb exportdbv
oldks <- liftIO $ Export . getExportTreeKey exportdb loc
oldcids <- liftIO $ concat
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
<$> mapM ( ContentIdentifier . getContentIdentifiers db rs ) oldks
2020-05-15 16:17:15 +00:00
newcid <- storeExportWithContentIdentifier ( importActions r' ) f k loc oldcids p
withExclusiveLock gitAnnexContentIdentifierLock $ do
liftIO $ ContentIdentifier . recordContentIdentifier db rs newcid k
liftIO $ ContentIdentifier . flushDbQueue db
recordContentIdentifier rs newcid k
2019-03-07 18:10:56 +00:00
, removeExport = \ k loc ->
2019-03-05 18:20:14 +00:00
removeExportWithContentIdentifier ( importActions r' ) k loc
2019-03-07 18:10:56 +00:00
=<< keycids k
2019-03-05 18:20:14 +00:00
, removeExportDirectory = removeExportDirectoryWhenEmpty ( importActions r' )
2019-03-05 18:57:48 +00:00
-- 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
2019-03-11 16:44:12 +00:00
, renameExport = \ _ _ _ -> return Nothing
2019-03-05 20:02:33 +00:00
, checkPresentExport = checkpresent
2019-03-04 21:50:41 +00:00
}
2019-03-05 20:02:33 +00:00
, checkPresent = if appendonly r'
then checkPresent r'
else \ k -> anyM ( checkpresent k )
=<< getexportlocs exportdbv k
2019-04-23 18:27:43 +00:00
, getInfo = do
is <- getInfo r'
return ( is ++ [ ( " import " , " yes " ) ] )
2019-03-04 21:50:41 +00:00
}
2019-03-05 20:02:33 +00:00
isexport dbv = return $ r
-- Storing a key on an export could be implemented,
-- but it would perform unncessary work
-- 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-05-13 18:03:00 +00:00
{ storeKey = \ _ _ _ ->
giveup " remote is configured with exporttree=yes; use `git-annex export` to store content on it "
2019-03-05 20:02:33 +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.
--
-- appendonly remotes have a key/value store,
-- so don't need to use retrieveExport. However,
-- fall back to it if retrieveKeyFile fails.
, retrieveKeyFile = \ k af dest p ->
let retrieveexport = retrieveKeyFileFromExport dbv k af dest p
in if appendonly r
2020-05-13 21:05:56 +00:00
then retrieveKeyFile r k af dest p
` catchNonAsync ` const retrieveexport
2019-03-05 20:02:33 +00:00
else retrieveexport
, retrieveKeyFileCheap = if appendonly r
then retrieveKeyFileCheap r
2020-05-13 21:05:56 +00:00
else Nothing
2019-03-05 20:02:33 +00:00
-- 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-05-14 18:08:09 +00:00
, removeKey = \ _k -> 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 "
2019-03-05 20:02:33 +00:00
-- 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.
--
-- (except for appendonly remotes)
, lockContent = if appendonly r
then lockContent r
else Nothing
-- Check if any of the files a key was exported to
-- are present. This doesn't guarantee the export
-- contains the right content, which is why export
-- remotes are untrusted.
--
-- (but appendonly remotes work the same as any
-- non-export remote)
, checkPresent = if appendonly r
then checkPresent r
else \ k -> anyM ( checkPresentExport ( exportActions r ) k )
=<< getexportlocs dbv k
-- 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.
, checkPresentCheap = False
, mkUnavailable = return Nothing
, getInfo = do
ts <- map fromRef . exportedTreeishes
<$> getExport ( uuid r )
is <- getInfo r
return ( is ++ [ ( " export " , " yes " ) , ( " exportedtree " , unwords ts ) ] )
}
2019-03-05 19:42:39 +00:00
prepciddb = do
lcklckv <- liftIO newEmptyTMVarIO
dbtv <- liftIO newEmptyTMVarIO
return ( dbtv , lcklckv )
prepexportdb = do
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
2019-03-07 18:10:56 +00:00
ContentIdentifier . needsUpdateFromLog db >>= \ case
Just v -> withExclusiveLock gitAnnexContentIdentifierLock $
ContentIdentifier . updateFromLog db v
Nothing -> noop
2019-03-06 18:35:16 +00:00
liftIO $ atomically $ putTMVar dbtv db
2019-03-05 19:42:39 +00:00
return db
-- 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.
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-02-26 18:57:29 +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-02-26 18:57:29 +00:00
updateexportdb db exportinconflict =
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
getexportlocs dbv k = do
db <- getexportdb dbv
liftIO $ Export . getExportTree db k
2019-03-05 19:42:39 +00:00
2020-05-13 21:05:56 +00:00
retrieveKeyFileFromExport dbv k _af dest p
| maybe False ( isJust . verifyKeyContent ) ( maybeLookupBackendVariety ( fromKey keyVariety k ) ) = do
locs <- getexportlocs dbv k
case locs of
[] -> ifM ( liftIO $ atomically $ readTVar $ getexportinconflict dbv )
( giveup " unknown export location, likely due to the export conflict "
, giveup " unknown export location "
)
( l : _ ) -> do
2020-05-15 16:51:09 +00:00
retrieveExport ( exportActions r ) k l dest p
2020-05-13 21:05:56 +00:00
return UnVerified
| otherwise = giveup $ " exported content cannot be verified due to using the " ++ decodeBS ( formatKeyVariety ( fromKey keyVariety k ) ) ++ " backend "