2014-08-03 19:35:23 +00:00
|
|
|
{- helpers for special remotes
|
2011-03-30 18:00:54 +00:00
|
|
|
-
|
2015-01-21 16:50:09 +00:00
|
|
|
- Copyright 2011-2014 Joey Hess <id@joeyh.name>
|
2011-03-30 18:00:54 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
2014-08-03 19:35:23 +00:00
|
|
|
module Remote.Helper.Special (
|
|
|
|
findSpecialRemotes,
|
|
|
|
gitConfigSpecialRemote,
|
|
|
|
Preparer,
|
|
|
|
Storer,
|
|
|
|
Retriever,
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
Remover,
|
|
|
|
CheckPresent,
|
2014-08-03 19:35:23 +00:00
|
|
|
simplyPrepare,
|
|
|
|
ContentSource,
|
|
|
|
checkPrepare,
|
|
|
|
resourcePrepare,
|
|
|
|
fileStorer,
|
|
|
|
byteStorer,
|
|
|
|
fileRetriever,
|
|
|
|
byteRetriever,
|
|
|
|
storeKeyDummy,
|
|
|
|
retreiveKeyFileDummy,
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
removeKeyDummy,
|
|
|
|
checkPresentDummy,
|
2014-08-03 19:35:23 +00:00
|
|
|
SpecialRemoteCfg(..),
|
|
|
|
specialRemoteCfg,
|
|
|
|
specialRemote,
|
|
|
|
specialRemote',
|
|
|
|
module X
|
|
|
|
) where
|
2011-03-30 18:00:54 +00:00
|
|
|
|
2011-10-05 20:02:51 +00:00
|
|
|
import Common.Annex
|
2014-08-03 19:35:23 +00:00
|
|
|
import Types.StoreRetrieve
|
2011-06-02 01:56:04 +00:00
|
|
|
import Types.Remote
|
2014-08-03 19:35:23 +00:00
|
|
|
import Crypto
|
|
|
|
import Config.Cost
|
|
|
|
import Utility.Metered
|
|
|
|
import Remote.Helper.Chunked as X
|
convert WebDAV to new special remote interface, adding new-style chunking support
Reusing http connection when operating on chunks is not done yet,
I had to submit some patches to DAV to support that. However, this is no
slower than old-style chunking was.
Note that it's a fileRetriever and a fileStorer, despite DAV using
bytestrings that would allow streaming. As a result, upload/download of
encrypted files is made a bit more expensive, since it spools them to temp
files. This was needed to get the progress meters to work.
There are probably ways to avoid that.. But it turns out that the current
DAV interface buffers the whole file content in memory, and I have
sent in a patch to DAV to improve its interfaces. Using the new interfaces,
it's certainly going to need to be a fileStorer, in order to read the file
size from the file (getting the size of a bytestring would destroy
laziness). It should be possible to use the new interface to make it be a
byteRetriever, so I'll change that when I get to it.
This commit was sponsored by Andreas Olsson.
2014-08-06 20:55:32 +00:00
|
|
|
import Remote.Helper.Encryptable as X
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
import Remote.Helper.Messages
|
2014-08-03 19:35:23 +00:00
|
|
|
import Annex.Content
|
2011-06-30 17:16:57 +00:00
|
|
|
import qualified Git
|
2011-12-14 19:56:11 +00:00
|
|
|
import qualified Git.Command
|
2011-12-13 19:05:07 +00:00
|
|
|
import qualified Git.Construct
|
2011-03-30 18:00:54 +00:00
|
|
|
|
2014-08-03 19:35:23 +00:00
|
|
|
import qualified Data.ByteString.Lazy as L
|
|
|
|
import qualified Data.Map as M
|
|
|
|
|
2011-03-30 18:00:54 +00:00
|
|
|
{- Special remotes don't have a configured url, so Git.Repo does not
|
|
|
|
- automatically generate remotes for them. This looks for a different
|
|
|
|
- configuration key instead.
|
|
|
|
-}
|
|
|
|
findSpecialRemotes :: String -> Annex [Git.Repo]
|
|
|
|
findSpecialRemotes s = do
|
2011-12-14 19:30:14 +00:00
|
|
|
m <- fromRepo Git.config
|
|
|
|
liftIO $ mapM construct $ remotepairs m
|
2012-11-11 04:51:07 +00:00
|
|
|
where
|
|
|
|
remotepairs = M.toList . M.filterWithKey match
|
|
|
|
construct (k,_) = Git.Construct.remoteNamedFromKey k Git.Construct.fromUnknown
|
|
|
|
match k _ = startswith "remote." k && endswith (".annex-"++s) k
|
2011-03-30 18:00:54 +00:00
|
|
|
|
|
|
|
{- Sets up configuration for a special remote in .git/config. -}
|
2011-04-15 19:09:36 +00:00
|
|
|
gitConfigSpecialRemote :: UUID -> RemoteConfig -> String -> String -> Annex ()
|
2011-03-30 18:32:08 +00:00
|
|
|
gitConfigSpecialRemote u c k v = do
|
2011-11-08 19:34:10 +00:00
|
|
|
set ("annex-"++k) v
|
|
|
|
set ("annex-uuid") (fromUUID u)
|
2012-11-11 04:51:07 +00:00
|
|
|
where
|
2013-03-03 17:39:07 +00:00
|
|
|
set a b = inRepo $ Git.Command.run
|
|
|
|
[Param "config", Param (configsetting a), Param b]
|
2012-11-11 04:51:07 +00:00
|
|
|
remotename = fromJust (M.lookup "name" c)
|
|
|
|
configsetting s = "remote." ++ remotename ++ "." ++ s
|
2014-08-03 19:35:23 +00:00
|
|
|
|
|
|
|
-- Use when nothing needs to be done to prepare a helper.
|
|
|
|
simplyPrepare :: helper -> Preparer helper
|
|
|
|
simplyPrepare helper _ a = a $ Just helper
|
|
|
|
|
|
|
|
-- Use to run a check when preparing a helper.
|
|
|
|
checkPrepare :: (Key -> Annex Bool) -> helper -> Preparer helper
|
|
|
|
checkPrepare checker helper k a = ifM (checker k)
|
|
|
|
( a (Just helper)
|
|
|
|
, a Nothing
|
|
|
|
)
|
|
|
|
|
|
|
|
-- Use to acquire a resource when preparing a helper.
|
|
|
|
resourcePrepare :: (Key -> (r -> Annex Bool) -> Annex Bool) -> (r -> helper) -> Preparer helper
|
|
|
|
resourcePrepare withr helper k a = withr k $ \r ->
|
2014-10-09 19:09:26 +00:00
|
|
|
a (Just (helper r))
|
2014-08-03 19:35:23 +00:00
|
|
|
|
|
|
|
-- A Storer that expects to be provided with a file containing
|
|
|
|
-- the content of the key to store.
|
|
|
|
fileStorer :: (Key -> FilePath -> MeterUpdate -> Annex Bool) -> Storer
|
|
|
|
fileStorer a k (FileContent f) m = a k f m
|
|
|
|
fileStorer a k (ByteContent b) m = withTmp k $ \f -> do
|
|
|
|
liftIO $ L.writeFile f b
|
|
|
|
a k f m
|
|
|
|
|
|
|
|
-- A Storer that expects to be provided with a L.ByteString of
|
|
|
|
-- the content to store.
|
|
|
|
byteStorer :: (Key -> L.ByteString -> MeterUpdate -> Annex Bool) -> Storer
|
|
|
|
byteStorer a k c m = withBytes c $ \b -> a k b m
|
|
|
|
|
|
|
|
-- A Retriever that writes the content of a Key to a provided file.
|
|
|
|
-- It is responsible for updating the progress meter as it retrieves data.
|
|
|
|
fileRetriever :: (FilePath -> Key -> MeterUpdate -> Annex ()) -> Retriever
|
|
|
|
fileRetriever a k m callback = do
|
|
|
|
f <- prepTmp k
|
|
|
|
a f k m
|
|
|
|
callback (FileContent f)
|
|
|
|
|
|
|
|
-- A Retriever that generates a lazy ByteString containing the Key's
|
|
|
|
-- content, and passes it to a callback action which will fully consume it
|
|
|
|
-- before returning.
|
|
|
|
byteRetriever :: (Key -> (L.ByteString -> Annex Bool) -> Annex Bool) -> Retriever
|
|
|
|
byteRetriever a k _m callback = a k (callback . ByteContent)
|
|
|
|
|
|
|
|
{- The base Remote that is provided to specialRemote needs to have
|
convert WebDAV to new special remote interface, adding new-style chunking support
Reusing http connection when operating on chunks is not done yet,
I had to submit some patches to DAV to support that. However, this is no
slower than old-style chunking was.
Note that it's a fileRetriever and a fileStorer, despite DAV using
bytestrings that would allow streaming. As a result, upload/download of
encrypted files is made a bit more expensive, since it spools them to temp
files. This was needed to get the progress meters to work.
There are probably ways to avoid that.. But it turns out that the current
DAV interface buffers the whole file content in memory, and I have
sent in a patch to DAV to improve its interfaces. Using the new interfaces,
it's certainly going to need to be a fileStorer, in order to read the file
size from the file (getting the size of a bytestring would destroy
laziness). It should be possible to use the new interface to make it be a
byteRetriever, so I'll change that when I get to it.
This commit was sponsored by Andreas Olsson.
2014-08-06 20:55:32 +00:00
|
|
|
- storeKey, retrieveKeyFile, removeKey, and checkPresent methods,
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
- but they are never actually used (since specialRemote replaces them).
|
2014-08-03 19:35:23 +00:00
|
|
|
- Here are some dummy ones.
|
|
|
|
-}
|
|
|
|
storeKeyDummy :: Key -> AssociatedFile -> MeterUpdate -> Annex Bool
|
|
|
|
storeKeyDummy _ _ _ = return False
|
|
|
|
retreiveKeyFileDummy :: Key -> AssociatedFile -> FilePath -> MeterUpdate -> Annex Bool
|
|
|
|
retreiveKeyFileDummy _ _ _ _ = return False
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
removeKeyDummy :: Key -> Annex Bool
|
|
|
|
removeKeyDummy _ = return False
|
|
|
|
checkPresentDummy :: Key -> Annex Bool
|
|
|
|
checkPresentDummy _ = error "missing checkPresent implementation"
|
|
|
|
|
|
|
|
type RemoteModifier
|
|
|
|
= RemoteConfig
|
|
|
|
-> Preparer Storer
|
|
|
|
-> Preparer Retriever
|
|
|
|
-> Preparer Remover
|
|
|
|
-> Preparer CheckPresent
|
|
|
|
-> Remote
|
|
|
|
-> Remote
|
2014-08-03 19:35:23 +00:00
|
|
|
|
|
|
|
data SpecialRemoteCfg = SpecialRemoteCfg
|
|
|
|
{ chunkConfig :: ChunkConfig
|
|
|
|
, displayProgress :: Bool
|
|
|
|
}
|
|
|
|
|
|
|
|
specialRemoteCfg :: RemoteConfig -> SpecialRemoteCfg
|
|
|
|
specialRemoteCfg c = SpecialRemoteCfg (getChunkConfig c) True
|
|
|
|
|
|
|
|
-- Modifies a base Remote to support both chunking and encryption,
|
|
|
|
-- which special remotes typically should support.
|
|
|
|
specialRemote :: RemoteModifier
|
|
|
|
specialRemote c = specialRemote' (specialRemoteCfg c) c
|
|
|
|
|
|
|
|
specialRemote' :: SpecialRemoteCfg -> RemoteModifier
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
specialRemote' cfg c preparestorer prepareretriever prepareremover preparecheckpresent baser = encr
|
2014-08-03 19:35:23 +00:00
|
|
|
where
|
|
|
|
encr = baser
|
|
|
|
{ storeKey = \k _f p -> cip >>= storeKeyGen k p
|
|
|
|
, retrieveKeyFile = \k _f d p -> cip >>= retrieveKeyFileGen k d p
|
|
|
|
, retrieveKeyFileCheap = \k d -> cip >>= maybe
|
|
|
|
(retrieveKeyFileCheap baser k d)
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
-- retrieval of encrypted keys is never cheap
|
2014-08-03 19:35:23 +00:00
|
|
|
(\_ -> return False)
|
|
|
|
, removeKey = \k -> cip >>= removeKeyGen k
|
2014-08-06 17:45:19 +00:00
|
|
|
, checkPresent = \k -> cip >>= checkPresentGen k
|
2014-08-03 19:35:23 +00:00
|
|
|
, cost = maybe
|
|
|
|
(cost baser)
|
|
|
|
(const $ cost baser + encryptedRemoteCostAdj)
|
|
|
|
(extractCipher c)
|
2014-10-21 18:36:09 +00:00
|
|
|
, getInfo = do
|
|
|
|
l <- getInfo baser
|
|
|
|
return $ l ++
|
|
|
|
[ ("encryption", describeEncryption c)
|
|
|
|
, ("chunking", describeChunkConfig (chunkConfig cfg))
|
|
|
|
]
|
2014-08-03 19:35:23 +00:00
|
|
|
}
|
|
|
|
cip = cipherKey c
|
|
|
|
gpgopts = getGpgEncParams encr
|
|
|
|
|
unify exception handling into Utility.Exception
Removed old extensible-exceptions, only needed for very old ghc.
Made webdav use Utility.Exception, to work after some changes in DAV's
exception handling.
Removed Annex.Exception. Mostly this was trivial, but note that
tryAnnex is replaced with tryNonAsync and catchAnnex replaced with
catchNonAsync. In theory that could be a behavior change, since the former
caught all exceptions, and the latter don't catch async exceptions.
However, in practice, nothing in the Annex monad uses async exceptions.
Grepping for throwTo and killThread only find stuff in the assistant,
which does not seem related.
Command.Add.undo is changed to accept a SomeException, and things
that use it for rollback now catch non-async exceptions, rather than
only IOExceptions.
2014-08-08 01:55:44 +00:00
|
|
|
safely a = catchNonAsync a (\e -> warning (show e) >> return False)
|
2014-08-03 19:35:23 +00:00
|
|
|
|
|
|
|
-- chunk, then encrypt, then feed to the storer
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
storeKeyGen k p enc = safely $ preparestorer k $ safely . go
|
2014-08-03 19:35:23 +00:00
|
|
|
where
|
|
|
|
go (Just storer) = sendAnnex k rollback $ \src ->
|
|
|
|
displayprogress p k $ \p' ->
|
|
|
|
storeChunks (uuid baser) chunkconfig k src p'
|
|
|
|
(storechunk enc storer)
|
2014-08-06 17:45:19 +00:00
|
|
|
(checkPresent baser)
|
2014-08-03 19:35:23 +00:00
|
|
|
go Nothing = return False
|
|
|
|
rollback = void $ removeKey encr k
|
|
|
|
|
|
|
|
storechunk Nothing storer k content p = storer k content p
|
|
|
|
storechunk (Just (cipher, enck)) storer k content p =
|
|
|
|
withBytes content $ \b ->
|
|
|
|
encrypt gpgopts cipher (feedBytes b) $
|
|
|
|
readBytes $ \encb ->
|
|
|
|
storer (enck k) (ByteContent encb) p
|
|
|
|
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
-- call retrieve-r to get chunks; decrypt them; stream to dest file
|
2014-08-03 19:35:23 +00:00
|
|
|
retrieveKeyFileGen k dest p enc =
|
|
|
|
safely $ prepareretriever k $ safely . go
|
|
|
|
where
|
2014-10-09 18:53:13 +00:00
|
|
|
go (Just retriever) = displayprogress p k $ \p' ->
|
2014-08-03 19:35:23 +00:00
|
|
|
retrieveChunks retriever (uuid baser) chunkconfig
|
|
|
|
enck k dest p' (sink dest enc)
|
|
|
|
go Nothing = return False
|
|
|
|
enck = maybe id snd enc
|
|
|
|
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
removeKeyGen k enc = safely $ prepareremover k $ safely . go
|
2014-08-03 19:35:23 +00:00
|
|
|
where
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
go (Just remover) = removeChunks remover (uuid baser) chunkconfig enck k
|
|
|
|
go Nothing = return False
|
2014-08-03 19:35:23 +00:00
|
|
|
enck = maybe id snd enc
|
|
|
|
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
checkPresentGen k enc = preparecheckpresent k go
|
2014-08-03 19:35:23 +00:00
|
|
|
where
|
2014-10-09 18:53:13 +00:00
|
|
|
go (Just checker) = checkPresentChunks checker (uuid baser) chunkconfig enck k
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
go Nothing = cantCheck baser
|
2014-08-03 19:35:23 +00:00
|
|
|
enck = maybe id snd enc
|
|
|
|
|
|
|
|
chunkconfig = chunkConfig cfg
|
|
|
|
|
|
|
|
displayprogress p k a
|
|
|
|
| displayProgress cfg = metered (Just p) k a
|
|
|
|
| otherwise = a p
|
|
|
|
|
|
|
|
{- Sink callback for retrieveChunks. Stores the file content into the
|
|
|
|
- provided Handle, decrypting it first if necessary.
|
|
|
|
-
|
|
|
|
- If the remote did not store the content using chunks, no Handle
|
|
|
|
- will be provided, and it's up to us to open the destination file.
|
|
|
|
-
|
|
|
|
- Note that when neither chunking nor encryption is used, and the remote
|
|
|
|
- provides FileContent, that file only needs to be renamed
|
|
|
|
- into place. (And it may even already be in the right place..)
|
|
|
|
-}
|
|
|
|
sink
|
|
|
|
:: FilePath
|
|
|
|
-> Maybe (Cipher, EncKey)
|
|
|
|
-> Maybe Handle
|
|
|
|
-> Maybe MeterUpdate
|
|
|
|
-> ContentSource
|
|
|
|
-> Annex Bool
|
|
|
|
sink dest enc mh mp content = do
|
|
|
|
case (enc, mh, content) of
|
|
|
|
(Nothing, Nothing, FileContent f)
|
|
|
|
| f == dest -> noop
|
|
|
|
| otherwise -> liftIO $ moveFile f dest
|
|
|
|
(Just (cipher, _), _, ByteContent b) ->
|
|
|
|
decrypt cipher (feedBytes b) $
|
|
|
|
readBytes write
|
|
|
|
(Just (cipher, _), _, FileContent f) -> do
|
|
|
|
withBytes content $ \b ->
|
|
|
|
decrypt cipher (feedBytes b) $
|
|
|
|
readBytes write
|
|
|
|
liftIO $ nukeFile f
|
|
|
|
(Nothing, _, FileContent f) -> do
|
|
|
|
withBytes content write
|
|
|
|
liftIO $ nukeFile f
|
|
|
|
(Nothing, _, ByteContent b) -> write b
|
|
|
|
return True
|
|
|
|
where
|
|
|
|
write b = case mh of
|
|
|
|
Just h -> liftIO $ b `streamto` h
|
|
|
|
Nothing -> liftIO $ bracket opendest hClose (b `streamto`)
|
|
|
|
streamto b h = case mp of
|
|
|
|
Just p -> meteredWrite p h b
|
|
|
|
Nothing -> L.hPut h b
|
|
|
|
opendest = openBinaryFile dest WriteMode
|
|
|
|
|
|
|
|
withBytes :: ContentSource -> (L.ByteString -> Annex a) -> Annex a
|
|
|
|
withBytes (ByteContent b) a = a b
|
|
|
|
withBytes (FileContent f) a = a =<< liftIO (L.readFile f)
|