2013-12-25 21:53:24 +00:00
|
|
|
{- External special remote interface.
|
|
|
|
-
|
2018-06-08 15:52:20 +00:00
|
|
|
- Copyright 2013-2018 Joey Hess <id@joeyh.name>
|
2013-12-25 21:53:24 +00:00
|
|
|
-
|
2018-06-08 15:52:20 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2013-12-25 21:53:24 +00:00
|
|
|
-}
|
|
|
|
|
|
|
|
module Remote.External (remote) where
|
|
|
|
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
import Remote.External.Types
|
|
|
|
import qualified Annex
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2013-12-25 21:53:24 +00:00
|
|
|
import Types.Remote
|
2017-09-15 20:34:45 +00:00
|
|
|
import Types.Export
|
2014-03-13 23:06:26 +00:00
|
|
|
import Types.CleanupActions
|
2014-12-11 19:32:42 +00:00
|
|
|
import Types.UrlContents
|
2013-12-25 21:53:24 +00:00
|
|
|
import qualified Git
|
|
|
|
import Config
|
2015-08-17 15:22:22 +00:00
|
|
|
import Git.Config (isTrue, boolConfig)
|
2016-05-06 16:26:37 +00:00
|
|
|
import Git.Env
|
2013-12-25 21:53:24 +00:00
|
|
|
import Remote.Helper.Special
|
2017-09-01 17:02:07 +00:00
|
|
|
import Remote.Helper.Export
|
2017-09-28 19:44:45 +00:00
|
|
|
import Annex.Export
|
2015-08-17 15:22:22 +00:00
|
|
|
import Remote.Helper.ReadOnly
|
|
|
|
import Remote.Helper.Messages
|
2013-12-25 21:53:24 +00:00
|
|
|
import Utility.Metered
|
2016-09-05 16:09:23 +00:00
|
|
|
import Utility.Shell
|
2015-04-04 18:53:17 +00:00
|
|
|
import Messages.Progress
|
2016-08-03 16:37:12 +00:00
|
|
|
import Types.Transfer
|
2014-01-02 00:12:20 +00:00
|
|
|
import Logs.PreferredContent.Raw
|
add remote state logs
This allows a remote to store a piece of arbitrary state associated with a
key. This is needed to support Tahoe, where the file-cap is calculated from
the data stored in it, and used to retrieve a key later. Glacier also would
be much improved by using this.
GETSTATE and SETSTATE are added to the external special remote protocol.
Note that the state is left as-is even when a key is removed from a remote.
It's up to the remote to decide when it wants to clear the state.
The remote state log, $KEY.log.rmt, is a UUID-based log. However,
rather than using the old UUID-based log format, I created a new variant
of that format. The new varient is more space efficient (since it lacks the
"timestamp=" hack, and easier to parse (and the parser doesn't mess with
whitespace in the value), and avoids compatability cruft in the old one.
This seemed worth cleaning up for these new files, since there could be a
lot of them, while before UUID-based logs were only used for a few log
files at the top of the git-annex branch. The transition code has also
been updated to handle these new UUID-based logs.
This commit was sponsored by Daniel Hofer.
2014-01-03 20:35:57 +00:00
|
|
|
import Logs.RemoteState
|
2014-12-08 17:32:27 +00:00
|
|
|
import Logs.Web
|
2013-12-25 21:53:24 +00:00
|
|
|
import Config.Cost
|
2015-08-17 15:22:22 +00:00
|
|
|
import Annex.Content
|
|
|
|
import Annex.Url
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
import Annex.UUID
|
2013-12-27 20:01:43 +00:00
|
|
|
import Creds
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
|
|
|
import Control.Concurrent.STM
|
2015-04-04 18:53:17 +00:00
|
|
|
import Control.Concurrent.Async
|
2013-12-27 07:10:00 +00:00
|
|
|
import System.Log.Logger (debugM)
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
import qualified Data.Map as M
|
2013-12-25 21:53:24 +00:00
|
|
|
|
|
|
|
remote :: RemoteType
|
2017-09-07 17:45:31 +00:00
|
|
|
remote = RemoteType
|
|
|
|
{ typename = "external"
|
|
|
|
, enumerate = const (findSpecialRemotes "externaltype")
|
|
|
|
, generate = gen
|
|
|
|
, setup = externalSetup
|
2017-09-08 18:24:05 +00:00
|
|
|
, exportSupported = checkExportSupported
|
2017-09-07 17:45:31 +00:00
|
|
|
}
|
2013-12-25 21:53:24 +00:00
|
|
|
|
|
|
|
gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> Annex (Maybe Remote)
|
2015-08-17 15:22:22 +00:00
|
|
|
gen r u c gc
|
|
|
|
-- readonly mode only downloads urls; does not use external program
|
|
|
|
| remoteAnnexReadOnly gc = do
|
|
|
|
cst <- remoteCost gc expensiveRemoteCost
|
|
|
|
mk cst GloballyAvailable
|
|
|
|
readonlyStorer
|
|
|
|
retrieveUrl
|
|
|
|
readonlyRemoveKey
|
|
|
|
(checkKeyUrl r)
|
|
|
|
Nothing
|
2018-06-08 15:52:20 +00:00
|
|
|
(externalInfo externaltype)
|
2015-08-17 15:22:22 +00:00
|
|
|
Nothing
|
|
|
|
Nothing
|
2017-09-08 18:24:05 +00:00
|
|
|
exportUnsupported
|
|
|
|
exportUnsupported
|
2015-08-17 15:22:22 +00:00
|
|
|
| otherwise = do
|
2016-05-23 21:03:20 +00:00
|
|
|
external <- newExternal externaltype u c gc
|
2015-08-17 15:22:22 +00:00
|
|
|
Annex.addCleanup (RemoteCleanup u) $ stopExternal external
|
|
|
|
cst <- getCost external r gc
|
|
|
|
avail <- getAvailability external r gc
|
2017-09-28 19:44:45 +00:00
|
|
|
exportsupported <- if exportTree c
|
|
|
|
then checkExportSupported' external
|
|
|
|
else return False
|
2017-09-08 18:24:05 +00:00
|
|
|
let exportactions = if exportsupported
|
2017-09-12 20:59:04 +00:00
|
|
|
then return $ ExportActions
|
2017-09-15 17:15:47 +00:00
|
|
|
{ storeExport = storeExportM external
|
|
|
|
, retrieveExport = retrieveExportM external
|
|
|
|
, removeExport = removeExportM external
|
|
|
|
, checkPresentExport = checkPresentExportM external
|
|
|
|
, removeExportDirectory = Just $ removeExportDirectoryM external
|
|
|
|
, renameExport = renameExportM external
|
2017-09-08 18:24:05 +00:00
|
|
|
}
|
|
|
|
else exportUnsupported
|
|
|
|
-- Cheap exportSupported that replaces the expensive
|
|
|
|
-- checkExportSupported now that we've already checked it.
|
|
|
|
let cheapexportsupported = if exportsupported
|
|
|
|
then exportIsSupported
|
|
|
|
else exportUnsupported
|
2015-08-17 15:22:22 +00:00
|
|
|
mk cst avail
|
2017-09-15 17:15:47 +00:00
|
|
|
(storeKeyM external)
|
|
|
|
(retrieveKeyFileM external)
|
|
|
|
(removeKeyM external)
|
|
|
|
(checkPresentM external)
|
|
|
|
(Just (whereisKeyM external))
|
2018-06-08 15:52:20 +00:00
|
|
|
(getInfoM external)
|
2017-09-15 17:15:47 +00:00
|
|
|
(Just (claimUrlM external))
|
|
|
|
(Just (checkUrlM external))
|
2017-09-08 18:24:05 +00:00
|
|
|
exportactions
|
|
|
|
cheapexportsupported
|
2015-08-17 15:22:22 +00:00
|
|
|
where
|
2018-06-08 15:52:20 +00:00
|
|
|
mk cst avail tostore toretrieve toremove tocheckkey towhereis togetinfo toclaimurl tocheckurl exportactions cheapexportsupported = do
|
2015-08-17 15:22:22 +00:00
|
|
|
let rmt = Remote
|
2014-12-16 19:26:13 +00:00
|
|
|
{ uuid = u
|
|
|
|
, cost = cst
|
|
|
|
, name = Git.repoDescribe r
|
|
|
|
, storeKey = storeKeyDummy
|
|
|
|
, retrieveKeyFile = retreiveKeyFileDummy
|
2015-04-14 20:35:10 +00:00
|
|
|
, retrieveKeyFileCheap = \_ _ _ -> return False
|
2018-06-21 15:35:27 +00:00
|
|
|
-- External special remotes use many http libraries
|
|
|
|
-- and have no protection against redirects to
|
|
|
|
-- local private web servers, or in some cases
|
|
|
|
-- to file:// urls.
|
|
|
|
, retrievalSecurityPolicy = RetrievalVerifiableKeysSecure
|
2014-12-16 19:26:13 +00:00
|
|
|
, removeKey = removeKeyDummy
|
2015-10-08 19:01:38 +00:00
|
|
|
, lockContent = Nothing
|
2014-12-16 19:26:13 +00:00
|
|
|
, checkPresent = checkPresentDummy
|
|
|
|
, checkPresentCheap = False
|
2017-09-08 18:24:05 +00:00
|
|
|
, exportActions = exportactions
|
2015-08-17 15:22:22 +00:00
|
|
|
, whereisKey = towhereis
|
2014-12-16 19:26:13 +00:00
|
|
|
, remoteFsck = Nothing
|
|
|
|
, repairRepo = Nothing
|
|
|
|
, config = c
|
|
|
|
, localpath = Nothing
|
2018-06-04 18:31:55 +00:00
|
|
|
, getRepo = return r
|
2014-12-16 19:26:13 +00:00
|
|
|
, gitconfig = gc
|
|
|
|
, readonly = False
|
|
|
|
, availability = avail
|
2017-09-08 18:24:05 +00:00
|
|
|
, remotetype = remote
|
|
|
|
{ exportSupported = cheapexportsupported }
|
2014-12-16 19:26:13 +00:00
|
|
|
, mkUnavailable = gen r u c $
|
|
|
|
gc { remoteAnnexExternalType = Just "!dne!" }
|
2018-06-08 15:52:20 +00:00
|
|
|
, getInfo = togetinfo
|
2015-08-17 15:22:22 +00:00
|
|
|
, claimUrl = toclaimurl
|
|
|
|
, checkUrl = tocheckurl
|
2014-12-16 19:26:13 +00:00
|
|
|
}
|
2015-08-17 15:22:22 +00:00
|
|
|
return $ Just $ specialRemote c
|
|
|
|
(simplyPrepare tostore)
|
|
|
|
(simplyPrepare toretrieve)
|
|
|
|
(simplyPrepare toremove)
|
|
|
|
(simplyPrepare tocheckkey)
|
|
|
|
rmt
|
2016-11-16 01:29:54 +00:00
|
|
|
externaltype = fromMaybe (giveup "missing externaltype") (remoteAnnexExternalType gc)
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2017-02-07 18:35:58 +00:00
|
|
|
externalSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
|
|
|
|
externalSetup _ mu _ c gc = do
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
u <- maybe (liftIO genUUID) return mu
|
2016-11-16 01:29:54 +00:00
|
|
|
let externaltype = fromMaybe (giveup "Specify externaltype=") $
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
M.lookup "externaltype" c
|
2016-05-23 21:27:15 +00:00
|
|
|
(c', _encsetup) <- encryptionSetup c gc
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2015-08-17 15:22:22 +00:00
|
|
|
c'' <- case M.lookup "readonly" c of
|
|
|
|
Just v | isTrue v == Just True -> do
|
|
|
|
setConfig (remoteConfig (fromJust (M.lookup "name" c)) "readonly") (boolConfig True)
|
|
|
|
return c'
|
|
|
|
_ -> do
|
2016-05-23 21:03:20 +00:00
|
|
|
external <- newExternal externaltype u c' gc
|
2015-08-17 15:22:22 +00:00
|
|
|
handleRequest external INITREMOTE Nothing $ \resp -> case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
INITREMOTE_SUCCESS -> result ()
|
2016-11-16 01:29:54 +00:00
|
|
|
INITREMOTE_FAILURE errmsg -> Just $ giveup errmsg
|
2015-08-17 15:22:22 +00:00
|
|
|
_ -> Nothing
|
2016-09-30 18:29:02 +00:00
|
|
|
withExternalState external $
|
2016-09-30 23:51:16 +00:00
|
|
|
liftIO . atomically . readTVar . externalConfig
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2018-03-27 16:41:57 +00:00
|
|
|
gitConfigSpecialRemote u c'' [("externaltype", externaltype)]
|
2013-12-27 16:37:23 +00:00
|
|
|
return (c'', u)
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2017-09-08 18:24:05 +00:00
|
|
|
checkExportSupported :: RemoteConfig -> RemoteGitConfig -> Annex Bool
|
|
|
|
checkExportSupported c gc = do
|
|
|
|
let externaltype = fromMaybe (giveup "Specify externaltype=") $
|
|
|
|
remoteAnnexExternalType gc <|> M.lookup "externaltype" c
|
|
|
|
checkExportSupported'
|
|
|
|
=<< newExternal externaltype NoUUID c gc
|
|
|
|
|
|
|
|
checkExportSupported' :: External -> Annex Bool
|
2017-09-28 19:44:45 +00:00
|
|
|
checkExportSupported' external = go `catchNonAsync` (const (return False))
|
|
|
|
where
|
|
|
|
go = handleRequest external EXPORTSUPPORTED Nothing $ \resp -> case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
EXPORTSUPPORTED_SUCCESS -> result True
|
|
|
|
EXPORTSUPPORTED_FAILURE -> result False
|
|
|
|
UNSUPPORTED_REQUEST -> result False
|
2017-09-08 18:24:05 +00:00
|
|
|
_ -> Nothing
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
storeKeyM :: External -> Storer
|
|
|
|
storeKeyM external = fileStorer $ \k f p ->
|
external: nice error message for keys with spaces in their name
External special remotes will refuse to operate on keys with spaces in
their names. That has never worked correctly due to the design of the
external special remote protocol. Display an error message suggesting
migration.
Not super happy with this, but it's a pragmatic solution. Better than
complicating the external special remote interface and all external special
remotes.
Note that I only made it use SafeKey in Request, not Response. git-annex
does not construct a Response, so that would not add any safety. And
presumably, if git-annex avoids feeding any such keys to an external
special remote, it will never have a reason to make a Response using such a
key. If it did, it would result in a protocol error anyway.
There's still a Serializeable instance for Key; it's used by P2P.Protocol.
There, the Key is always in the final position, so it's ok if it contains
spaces.
Note that the protocol documentation has been fixed to say that the File
may contain spaces. One way that can happen, even though the Key can't,
is when using direct mode, and the work tree filename contains spaces.
When sending such a file to the external special remote the worktree
filename is used.
This commit was sponsored by Thom May on Patreon.
2017-08-17 20:08:35 +00:00
|
|
|
handleRequestKey external (\sk -> TRANSFER Upload sk f) k (Just p) $ \resp ->
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
TRANSFER_SUCCESS Upload k' | k == k' -> result True
|
2013-12-27 16:21:55 +00:00
|
|
|
TRANSFER_FAILURE Upload k' errmsg | k == k' ->
|
|
|
|
Just $ do
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
warning errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
_ -> Nothing
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
retrieveKeyFileM :: External -> Retriever
|
|
|
|
retrieveKeyFileM external = fileRetriever $ \d k p ->
|
external: nice error message for keys with spaces in their name
External special remotes will refuse to operate on keys with spaces in
their names. That has never worked correctly due to the design of the
external special remote protocol. Display an error message suggesting
migration.
Not super happy with this, but it's a pragmatic solution. Better than
complicating the external special remote interface and all external special
remotes.
Note that I only made it use SafeKey in Request, not Response. git-annex
does not construct a Response, so that would not add any safety. And
presumably, if git-annex avoids feeding any such keys to an external
special remote, it will never have a reason to make a Response using such a
key. If it did, it would result in a protocol error anyway.
There's still a Serializeable instance for Key; it's used by P2P.Protocol.
There, the Key is always in the final position, so it's ok if it contains
spaces.
Note that the protocol documentation has been fixed to say that the File
may contain spaces. One way that can happen, even though the Key can't,
is when using direct mode, and the work tree filename contains spaces.
When sending such a file to the external special remote the worktree
filename is used.
This commit was sponsored by Thom May on Patreon.
2017-08-17 20:08:35 +00:00
|
|
|
handleRequestKey external (\sk -> TRANSFER Download sk d) k (Just p) $ \resp ->
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
case resp of
|
|
|
|
TRANSFER_SUCCESS Download k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k == k' -> result ()
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
TRANSFER_FAILURE Download k' errmsg
|
2016-11-16 01:29:54 +00:00
|
|
|
| k == k' -> Just $ giveup errmsg
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
_ -> Nothing
|
2013-12-25 21:53:24 +00:00
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
removeKeyM :: External -> Remover
|
|
|
|
removeKeyM external k = safely $
|
external: nice error message for keys with spaces in their name
External special remotes will refuse to operate on keys with spaces in
their names. That has never worked correctly due to the design of the
external special remote protocol. Display an error message suggesting
migration.
Not super happy with this, but it's a pragmatic solution. Better than
complicating the external special remote interface and all external special
remotes.
Note that I only made it use SafeKey in Request, not Response. git-annex
does not construct a Response, so that would not add any safety. And
presumably, if git-annex avoids feeding any such keys to an external
special remote, it will never have a reason to make a Response using such a
key. If it did, it would result in a protocol error anyway.
There's still a Serializeable instance for Key; it's used by P2P.Protocol.
There, the Key is always in the final position, so it's ok if it contains
spaces.
Note that the protocol documentation has been fixed to say that the File
may contain spaces. One way that can happen, even though the Key can't,
is when using direct mode, and the work tree filename contains spaces.
When sending such a file to the external special remote the worktree
filename is used.
This commit was sponsored by Thom May on Patreon.
2017-08-17 20:08:35 +00:00
|
|
|
handleRequestKey external REMOVE k Nothing $ \resp ->
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
case resp of
|
|
|
|
REMOVE_SUCCESS k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k == k' -> result True
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
REMOVE_FAILURE k' errmsg
|
|
|
|
| k == k' -> Just $ do
|
|
|
|
warning errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
_ -> Nothing
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
checkPresentM :: External -> CheckPresent
|
|
|
|
checkPresentM external k = either giveup id <$> go
|
2013-12-25 21:53:24 +00:00
|
|
|
where
|
external: nice error message for keys with spaces in their name
External special remotes will refuse to operate on keys with spaces in
their names. That has never worked correctly due to the design of the
external special remote protocol. Display an error message suggesting
migration.
Not super happy with this, but it's a pragmatic solution. Better than
complicating the external special remote interface and all external special
remotes.
Note that I only made it use SafeKey in Request, not Response. git-annex
does not construct a Response, so that would not add any safety. And
presumably, if git-annex avoids feeding any such keys to an external
special remote, it will never have a reason to make a Response using such a
key. If it did, it would result in a protocol error anyway.
There's still a Serializeable instance for Key; it's used by P2P.Protocol.
There, the Key is always in the final position, so it's ok if it contains
spaces.
Note that the protocol documentation has been fixed to say that the File
may contain spaces. One way that can happen, even though the Key can't,
is when using direct mode, and the work tree filename contains spaces.
When sending such a file to the external special remote the worktree
filename is used.
This commit was sponsored by Thom May on Patreon.
2017-08-17 20:08:35 +00:00
|
|
|
go = handleRequestKey external CHECKPRESENT k Nothing $ \resp ->
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
case resp of
|
|
|
|
CHECKPRESENT_SUCCESS k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result $ Right True
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
CHECKPRESENT_FAILURE k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result $ Right False
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
CHECKPRESENT_UNKNOWN k' errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result $ Left errmsg
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
_ -> Nothing
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
whereisKeyM :: External -> Key -> Annex [String]
|
|
|
|
whereisKeyM external k = handleRequestKey external WHEREIS k Nothing $ \resp -> case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
WHEREIS_SUCCESS s -> result [s]
|
|
|
|
WHEREIS_FAILURE -> result []
|
|
|
|
UNSUPPORTED_REQUEST -> result []
|
2015-08-13 21:26:09 +00:00
|
|
|
_ -> Nothing
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
storeExportM :: External -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex Bool
|
|
|
|
storeExportM external f k loc p = safely $
|
2017-09-08 18:24:05 +00:00
|
|
|
handleRequestExport external loc req k (Just p) $ \resp -> case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
TRANSFER_SUCCESS Upload k' | k == k' -> result True
|
2017-09-08 18:24:05 +00:00
|
|
|
TRANSFER_FAILURE Upload k' errmsg | k == k' ->
|
|
|
|
Just $ do
|
|
|
|
warning errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
2017-09-08 18:24:05 +00:00
|
|
|
UNSUPPORTED_REQUEST -> Just $ do
|
|
|
|
warning "TRANSFEREXPORT not implemented by external special remote"
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
2017-09-08 18:24:05 +00:00
|
|
|
_ -> Nothing
|
|
|
|
where
|
|
|
|
req sk = TRANSFEREXPORT Upload sk f
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
retrieveExportM :: External -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Bool
|
|
|
|
retrieveExportM external k loc d p = safely $
|
2017-09-08 18:24:05 +00:00
|
|
|
handleRequestExport external loc req k (Just p) $ \resp -> case resp of
|
|
|
|
TRANSFER_SUCCESS Download k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k == k' -> result True
|
2017-09-08 18:24:05 +00:00
|
|
|
TRANSFER_FAILURE Download k' errmsg
|
|
|
|
| k == k' -> Just $ do
|
|
|
|
warning errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
2017-09-08 18:24:05 +00:00
|
|
|
UNSUPPORTED_REQUEST -> Just $ do
|
|
|
|
warning "TRANSFEREXPORT not implemented by external special remote"
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
2017-09-08 18:24:05 +00:00
|
|
|
_ -> Nothing
|
|
|
|
where
|
|
|
|
req sk = TRANSFEREXPORT Download sk d
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
checkPresentExportM :: External -> Key -> ExportLocation -> Annex Bool
|
|
|
|
checkPresentExportM external k loc = either giveup id <$> go
|
|
|
|
where
|
|
|
|
go = handleRequestExport external loc CHECKPRESENTEXPORT k Nothing $ \resp -> case resp of
|
|
|
|
CHECKPRESENT_SUCCESS k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result $ Right True
|
2017-09-15 17:15:47 +00:00
|
|
|
CHECKPRESENT_FAILURE k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result $ Right False
|
2017-09-15 17:15:47 +00:00
|
|
|
CHECKPRESENT_UNKNOWN k' errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result $ Left errmsg
|
|
|
|
UNSUPPORTED_REQUEST -> result $
|
2017-09-15 17:15:47 +00:00
|
|
|
Left "CHECKPRESENTEXPORT not implemented by external special remote"
|
|
|
|
_ -> Nothing
|
|
|
|
|
|
|
|
removeExportM :: External -> Key -> ExportLocation -> Annex Bool
|
|
|
|
removeExportM external k loc = safely $
|
2017-09-08 18:24:05 +00:00
|
|
|
handleRequestExport external loc REMOVEEXPORT k Nothing $ \resp -> case resp of
|
|
|
|
REMOVE_SUCCESS k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k == k' -> result True
|
2017-09-08 18:24:05 +00:00
|
|
|
REMOVE_FAILURE k' errmsg
|
|
|
|
| k == k' -> Just $ do
|
|
|
|
warning errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
2017-09-08 18:24:05 +00:00
|
|
|
UNSUPPORTED_REQUEST -> Just $ do
|
|
|
|
warning "REMOVEEXPORT not implemented by external special remote"
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result False)
|
2017-09-08 18:24:05 +00:00
|
|
|
_ -> Nothing
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
removeExportDirectoryM :: External -> ExportDirectory -> Annex Bool
|
|
|
|
removeExportDirectoryM external dir = safely $
|
|
|
|
handleRequest external req Nothing $ \resp -> case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
REMOVEEXPORTDIRECTORY_SUCCESS -> result True
|
|
|
|
REMOVEEXPORTDIRECTORY_FAILURE -> result False
|
|
|
|
UNSUPPORTED_REQUEST -> result True
|
2017-09-15 18:32:56 +00:00
|
|
|
_ -> Nothing
|
2017-09-08 18:24:05 +00:00
|
|
|
where
|
2017-09-15 17:15:47 +00:00
|
|
|
req = REMOVEEXPORTDIRECTORY dir
|
2017-09-08 18:24:05 +00:00
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
renameExportM :: External -> Key -> ExportLocation -> ExportLocation -> Annex Bool
|
|
|
|
renameExportM external k src dest = safely $
|
2017-09-08 18:24:05 +00:00
|
|
|
handleRequestExport external src req k Nothing $ \resp -> case resp of
|
|
|
|
RENAMEEXPORT_SUCCESS k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result True
|
2017-09-08 18:24:05 +00:00
|
|
|
RENAMEEXPORT_FAILURE k'
|
2018-06-08 15:52:20 +00:00
|
|
|
| k' == k -> result False
|
|
|
|
UNSUPPORTED_REQUEST -> result False
|
2017-09-08 18:24:05 +00:00
|
|
|
_ -> Nothing
|
|
|
|
where
|
|
|
|
req sk = RENAMEEXPORT sk dest
|
|
|
|
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
safely :: Annex Bool -> Annex Bool
|
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 = go =<< tryNonAsync a
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
where
|
|
|
|
go (Right r) = return r
|
|
|
|
go (Left e) = do
|
2017-09-28 19:44:45 +00:00
|
|
|
toplevelWarning False (show e)
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
return False
|
2013-12-25 21:53:24 +00:00
|
|
|
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
{- Sends a Request to the external remote, and waits for it to generate
|
2013-12-27 06:08:29 +00:00
|
|
|
- a Response. That is fed into the responsehandler, which should return
|
|
|
|
- the action to run for it (or Nothing if there's a protocol error).
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
-
|
|
|
|
- While the external remote is processing the Request, it may send
|
|
|
|
- any number of RemoteRequests, that are handled here.
|
|
|
|
-
|
2016-09-30 18:29:02 +00:00
|
|
|
- An external remote process can only handle one request at a time.
|
|
|
|
- Concurrent requests will start up additional processes.
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
-
|
2013-12-29 17:39:25 +00:00
|
|
|
- May throw exceptions, for example on protocol errors, or
|
|
|
|
- when the repository cannot be used.
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
-}
|
2018-06-08 15:52:20 +00:00
|
|
|
handleRequest :: External -> Request -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
handleRequest external req mp responsehandler =
|
2016-09-30 18:29:02 +00:00
|
|
|
withExternalState external $ \st ->
|
|
|
|
handleRequest' st external req mp responsehandler
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2018-06-08 15:52:20 +00:00
|
|
|
handleRequestKey :: External -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
|
external: nice error message for keys with spaces in their name
External special remotes will refuse to operate on keys with spaces in
their names. That has never worked correctly due to the design of the
external special remote protocol. Display an error message suggesting
migration.
Not super happy with this, but it's a pragmatic solution. Better than
complicating the external special remote interface and all external special
remotes.
Note that I only made it use SafeKey in Request, not Response. git-annex
does not construct a Response, so that would not add any safety. And
presumably, if git-annex avoids feeding any such keys to an external
special remote, it will never have a reason to make a Response using such a
key. If it did, it would result in a protocol error anyway.
There's still a Serializeable instance for Key; it's used by P2P.Protocol.
There, the Key is always in the final position, so it's ok if it contains
spaces.
Note that the protocol documentation has been fixed to say that the File
may contain spaces. One way that can happen, even though the Key can't,
is when using direct mode, and the work tree filename contains spaces.
When sending such a file to the external special remote the worktree
filename is used.
This commit was sponsored by Thom May on Patreon.
2017-08-17 20:08:35 +00:00
|
|
|
handleRequestKey external mkreq k mp responsehandler = case mkSafeKey k of
|
|
|
|
Right sk -> handleRequest external (mkreq sk) mp responsehandler
|
|
|
|
Left e -> giveup e
|
|
|
|
|
2017-09-08 18:24:05 +00:00
|
|
|
{- Export location is first sent in an EXPORT message before
|
|
|
|
- the main request. This is done because the ExportLocation can
|
|
|
|
- contain spaces etc. -}
|
2018-06-08 15:52:20 +00:00
|
|
|
handleRequestExport :: External -> ExportLocation -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
|
2017-09-08 18:24:05 +00:00
|
|
|
handleRequestExport external loc mkreq k mp responsehandler = do
|
|
|
|
withExternalState external $ \st -> do
|
|
|
|
checkPrepared st external
|
|
|
|
sendMessage st external (EXPORT loc)
|
|
|
|
handleRequestKey external mkreq k mp responsehandler
|
|
|
|
|
2018-06-08 15:52:20 +00:00
|
|
|
handleRequest' :: ExternalState -> External -> Request -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
|
2016-09-30 18:29:02 +00:00
|
|
|
handleRequest' st external req mp responsehandler
|
2013-12-29 17:39:25 +00:00
|
|
|
| needsPREPARE req = do
|
2016-09-30 18:29:02 +00:00
|
|
|
checkPrepared st external
|
2013-12-29 17:39:25 +00:00
|
|
|
go
|
|
|
|
| otherwise = go
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
where
|
2014-10-09 18:53:13 +00:00
|
|
|
go = do
|
2016-09-30 18:29:02 +00:00
|
|
|
sendMessage st external req
|
2013-12-29 17:39:25 +00:00
|
|
|
loop
|
2016-09-30 18:29:02 +00:00
|
|
|
loop = receiveMessage st external responsehandler
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
(\rreq -> Just $ handleRemoteRequest rreq >> loop)
|
|
|
|
(\msg -> Just $ handleAsyncMessage msg >> loop)
|
|
|
|
|
|
|
|
handleRemoteRequest (PROGRESS bytesprocessed) =
|
|
|
|
maybe noop (\a -> liftIO $ a bytesprocessed) mp
|
|
|
|
handleRemoteRequest (DIRHASH k) =
|
2015-01-28 19:55:17 +00:00
|
|
|
send $ VALUE $ hashDirMixed def k
|
2016-05-03 17:36:59 +00:00
|
|
|
handleRemoteRequest (DIRHASH_LOWER k) =
|
|
|
|
send $ VALUE $ hashDirLower def k
|
2013-12-27 16:37:23 +00:00
|
|
|
handleRemoteRequest (SETCONFIG setting value) =
|
2016-09-30 23:51:16 +00:00
|
|
|
liftIO $ atomically $ modifyTVar' (externalConfig st) $
|
|
|
|
M.insert setting value
|
2013-12-27 16:37:23 +00:00
|
|
|
handleRemoteRequest (GETCONFIG setting) = do
|
2016-09-30 18:29:02 +00:00
|
|
|
value <- fromMaybe "" . M.lookup setting
|
2016-09-30 23:51:16 +00:00
|
|
|
<$> liftIO (atomically $ readTVar $ externalConfig st)
|
2014-01-02 00:12:20 +00:00
|
|
|
send $ VALUE value
|
2013-12-27 20:01:43 +00:00
|
|
|
handleRemoteRequest (SETCREDS setting login password) = do
|
2016-09-30 18:29:02 +00:00
|
|
|
let v = externalConfig st
|
2016-09-30 23:51:16 +00:00
|
|
|
c <- liftIO $ atomically $ readTVar v
|
2016-09-30 18:29:02 +00:00
|
|
|
let gc = externalGitConfig external
|
|
|
|
c' <- setRemoteCredPair encryptionAlreadySetup c gc
|
|
|
|
(credstorage setting)
|
|
|
|
(Just (login, password))
|
2016-09-30 23:51:16 +00:00
|
|
|
void $ liftIO $ atomically $ swapTVar v c'
|
2013-12-27 20:01:43 +00:00
|
|
|
handleRemoteRequest (GETCREDS setting) = do
|
2016-09-30 23:51:16 +00:00
|
|
|
c <- liftIO $ atomically $ readTVar $ externalConfig st
|
2016-09-30 17:17:49 +00:00
|
|
|
let gc = externalGitConfig external
|
2013-12-27 20:01:43 +00:00
|
|
|
creds <- fromMaybe ("", "") <$>
|
2016-05-23 21:03:20 +00:00
|
|
|
getRemoteCredPair c gc (credstorage setting)
|
2014-01-02 00:12:20 +00:00
|
|
|
send $ CREDS (fst creds) (snd creds)
|
|
|
|
handleRemoteRequest GETUUID = send $
|
2013-12-31 17:50:18 +00:00
|
|
|
VALUE $ fromUUID $ externalUUID external
|
2014-01-13 18:00:09 +00:00
|
|
|
handleRemoteRequest GETGITDIR = send . VALUE =<< fromRepo Git.localGitDir
|
2014-01-02 00:12:20 +00:00
|
|
|
handleRemoteRequest (SETWANTED expr) =
|
|
|
|
preferredContentSet (externalUUID external) expr
|
|
|
|
handleRemoteRequest GETWANTED = do
|
|
|
|
expr <- fromMaybe "" . M.lookup (externalUUID external)
|
|
|
|
<$> preferredContentMapRaw
|
|
|
|
send $ VALUE expr
|
add remote state logs
This allows a remote to store a piece of arbitrary state associated with a
key. This is needed to support Tahoe, where the file-cap is calculated from
the data stored in it, and used to retrieve a key later. Glacier also would
be much improved by using this.
GETSTATE and SETSTATE are added to the external special remote protocol.
Note that the state is left as-is even when a key is removed from a remote.
It's up to the remote to decide when it wants to clear the state.
The remote state log, $KEY.log.rmt, is a UUID-based log. However,
rather than using the old UUID-based log format, I created a new variant
of that format. The new varient is more space efficient (since it lacks the
"timestamp=" hack, and easier to parse (and the parser doesn't mess with
whitespace in the value), and avoids compatability cruft in the old one.
This seemed worth cleaning up for these new files, since there could be a
lot of them, while before UUID-based logs were only used for a few log
files at the top of the git-annex branch. The transition code has also
been updated to handle these new UUID-based logs.
This commit was sponsored by Daniel Hofer.
2014-01-03 20:35:57 +00:00
|
|
|
handleRemoteRequest (SETSTATE key state) =
|
|
|
|
setRemoteState (externalUUID external) key state
|
|
|
|
handleRemoteRequest (GETSTATE key) = do
|
|
|
|
state <- fromMaybe ""
|
|
|
|
<$> getRemoteState (externalUUID external) key
|
|
|
|
send $ VALUE state
|
2014-12-08 23:14:24 +00:00
|
|
|
handleRemoteRequest (SETURLPRESENT key url) =
|
|
|
|
setUrlPresent (externalUUID external) key url
|
|
|
|
handleRemoteRequest (SETURLMISSING key url) =
|
|
|
|
setUrlMissing (externalUUID external) key url
|
2015-03-05 17:50:15 +00:00
|
|
|
handleRemoteRequest (SETURIPRESENT key uri) =
|
|
|
|
withurl (SETURLPRESENT key) uri
|
|
|
|
handleRemoteRequest (SETURIMISSING key uri) =
|
|
|
|
withurl (SETURLMISSING key) uri
|
2014-12-08 17:32:27 +00:00
|
|
|
handleRemoteRequest (GETURLS key prefix) = do
|
2015-03-27 22:49:03 +00:00
|
|
|
mapM_ (send . VALUE) =<< getUrlsWithPrefix key prefix
|
2014-12-08 17:32:27 +00:00
|
|
|
send (VALUE "") -- end of list
|
2014-01-07 17:23:58 +00:00
|
|
|
handleRemoteRequest (DEBUG msg) = liftIO $ debugM "external" msg
|
2018-02-06 17:03:55 +00:00
|
|
|
handleRemoteRequest (INFO msg) = showInfo msg
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
handleRemoteRequest (VERSION _) =
|
2016-09-30 18:29:02 +00:00
|
|
|
sendMessage st external (ERROR "too late to send VERSION")
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2016-11-16 01:29:54 +00:00
|
|
|
handleAsyncMessage (ERROR err) = giveup $ "external special remote error: " ++ err
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2016-09-30 18:29:02 +00:00
|
|
|
send = sendMessage st external
|
2014-01-02 00:12:20 +00:00
|
|
|
|
2013-12-27 20:01:43 +00:00
|
|
|
credstorage setting = CredPairStorage
|
|
|
|
{ credPairFile = base
|
|
|
|
, credPairEnvironment = (base ++ "login", base ++ "password")
|
|
|
|
, credPairRemoteKey = Just setting
|
|
|
|
}
|
|
|
|
where
|
|
|
|
base = replace "/" "_" $ fromUUID (externalUUID external) ++ "-" ++ setting
|
2015-03-05 17:50:15 +00:00
|
|
|
|
|
|
|
withurl mk uri = handleRemoteRequest $ mk $
|
|
|
|
setDownloader (show uri) OtherDownloader
|
2013-12-27 20:01:43 +00:00
|
|
|
|
2016-09-30 18:29:02 +00:00
|
|
|
sendMessage :: Sendable m => ExternalState -> External -> m -> Annex ()
|
|
|
|
sendMessage st external m = liftIO $ do
|
2016-09-30 18:42:48 +00:00
|
|
|
protocolDebug external st True line
|
2016-09-30 18:29:02 +00:00
|
|
|
hPutStrLn h line
|
|
|
|
hFlush h
|
2013-12-27 07:10:00 +00:00
|
|
|
where
|
|
|
|
line = unwords $ formatMessage m
|
2016-09-30 18:29:02 +00:00
|
|
|
h = externalSend st
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
2018-06-08 15:52:20 +00:00
|
|
|
{- A response handler can yeild a result, or it can request that another
|
|
|
|
- message be consumed from the external result. -}
|
|
|
|
data ResponseHandlerResult a
|
|
|
|
= Result a
|
|
|
|
| GetNextMessage (ResponseHandler a)
|
|
|
|
|
|
|
|
type ResponseHandler a = Response -> Maybe (Annex (ResponseHandlerResult a))
|
|
|
|
|
|
|
|
result :: a -> Maybe (Annex (ResponseHandlerResult a))
|
|
|
|
result = Just . return . Result
|
|
|
|
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
{- Waits for a message from the external remote, and passes it to the
|
|
|
|
- apppropriate handler.
|
|
|
|
-
|
|
|
|
- If the handler returns Nothing, this is a protocol error.-}
|
|
|
|
receiveMessage
|
2016-09-30 18:29:02 +00:00
|
|
|
:: ExternalState
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
-> External
|
2018-06-08 15:52:20 +00:00
|
|
|
-> ResponseHandler a
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
-> (RemoteRequest -> Maybe (Annex a))
|
|
|
|
-> (AsyncMessage -> Maybe (Annex a))
|
|
|
|
-> Annex a
|
2016-09-30 18:29:02 +00:00
|
|
|
receiveMessage st external handleresponse handlerequest handleasync =
|
|
|
|
go =<< liftIO (catchMaybeIO $ hGetLine $ externalReceive st)
|
2013-12-25 21:53:24 +00:00
|
|
|
where
|
2013-12-27 21:14:44 +00:00
|
|
|
go Nothing = protocolError False ""
|
|
|
|
go (Just s) = do
|
2016-09-30 18:42:48 +00:00
|
|
|
liftIO $ protocolDebug external st False s
|
2013-12-27 21:14:44 +00:00
|
|
|
case parseMessage s :: Maybe Response of
|
2018-06-08 15:52:20 +00:00
|
|
|
Just resp -> case handleresponse resp of
|
|
|
|
Nothing -> protocolError True s
|
|
|
|
Just callback -> callback >>= \case
|
|
|
|
Result a -> return a
|
|
|
|
GetNextMessage handleresponse' ->
|
|
|
|
receiveMessage st external handleresponse' handlerequest handleasync
|
2013-12-27 21:14:44 +00:00
|
|
|
Nothing -> case parseMessage s :: Maybe RemoteRequest of
|
|
|
|
Just req -> maybe (protocolError True s) id (handlerequest req)
|
|
|
|
Nothing -> case parseMessage s :: Maybe AsyncMessage of
|
|
|
|
Just msg -> maybe (protocolError True s) id (handleasync msg)
|
|
|
|
Nothing -> protocolError False s
|
2016-11-16 01:29:54 +00:00
|
|
|
protocolError parsed s = giveup $ "external special remote protocol error, unexpectedly received \"" ++ s ++ "\" " ++
|
2018-06-08 15:52:20 +00:00
|
|
|
if parsed
|
|
|
|
then "(command not allowed at this time)"
|
|
|
|
else "(unable to parse command)"
|
2013-12-25 21:53:24 +00:00
|
|
|
|
2016-09-30 18:42:48 +00:00
|
|
|
protocolDebug :: External -> ExternalState -> Bool -> String -> IO ()
|
|
|
|
protocolDebug external st sendto line = debugM "external" $ unwords
|
|
|
|
[ externalRemoteProgram (externalType external) ++
|
|
|
|
"[" ++ show (externalPid st) ++ "]"
|
2013-12-27 07:10:00 +00:00
|
|
|
, if sendto then "<--" else "-->"
|
|
|
|
, line
|
|
|
|
]
|
|
|
|
|
2016-09-30 18:29:02 +00:00
|
|
|
{- While the action is running, the ExternalState provided to it will not
|
|
|
|
- be available to any other calls.
|
|
|
|
-
|
|
|
|
- Starts up a new process if no ExternalStates are available. -}
|
|
|
|
withExternalState :: External -> (ExternalState -> Annex a) -> Annex a
|
|
|
|
withExternalState external = bracket alloc dealloc
|
2013-12-25 21:53:24 +00:00
|
|
|
where
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
v = externalState external
|
|
|
|
|
2016-09-30 18:29:02 +00:00
|
|
|
alloc = do
|
|
|
|
ms <- liftIO $ atomically $ do
|
2016-09-30 23:51:16 +00:00
|
|
|
l <- readTVar v
|
2016-09-30 18:29:02 +00:00
|
|
|
case l of
|
2016-09-30 23:51:16 +00:00
|
|
|
[] -> return Nothing
|
2016-09-30 18:29:02 +00:00
|
|
|
(st:rest) -> do
|
2016-09-30 23:51:16 +00:00
|
|
|
writeTVar v rest
|
2016-09-30 18:29:02 +00:00
|
|
|
return (Just st)
|
|
|
|
maybe (startExternal external) return ms
|
|
|
|
|
2016-09-30 23:51:16 +00:00
|
|
|
dealloc st = liftIO $ atomically $ modifyTVar' v (st:)
|
2016-09-30 18:29:02 +00:00
|
|
|
|
2018-02-07 19:02:12 +00:00
|
|
|
{- Starts an external remote process running, and checks VERSION and
|
|
|
|
- exchanges EXTENSIONS. -}
|
2016-09-30 17:36:50 +00:00
|
|
|
startExternal :: External -> Annex ExternalState
|
|
|
|
startExternal external = do
|
2015-04-04 18:53:17 +00:00
|
|
|
errrelayer <- mkStderrRelayer
|
2016-09-30 18:29:02 +00:00
|
|
|
st <- start errrelayer =<< Annex.gitRepo
|
|
|
|
receiveMessage st external
|
|
|
|
(const Nothing)
|
|
|
|
(checkVersion st external)
|
|
|
|
(const Nothing)
|
2018-02-07 19:02:12 +00:00
|
|
|
sendMessage st external (EXTENSIONS supportedExtensionList)
|
|
|
|
-- It responds with a EXTENSIONS_RESPONSE; that extensions list
|
|
|
|
-- is reserved for future expansion. UNSUPPORTED_REQUEST is also
|
|
|
|
-- accepted.
|
|
|
|
receiveMessage st external
|
|
|
|
(\resp -> case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
EXTENSIONS_RESPONSE _ -> result ()
|
|
|
|
UNSUPPORTED_REQUEST -> result ()
|
2018-02-07 19:02:12 +00:00
|
|
|
_ -> Nothing
|
|
|
|
)
|
|
|
|
(const Nothing)
|
|
|
|
(const Nothing)
|
2016-09-30 18:29:02 +00:00
|
|
|
return st
|
|
|
|
where
|
|
|
|
start errrelayer g = liftIO $ do
|
2017-03-08 19:56:55 +00:00
|
|
|
cmdpath <- searchPath basecmd
|
|
|
|
(cmd, ps) <- maybe (pure (basecmd, [])) findShellCommand cmdpath
|
2016-09-05 16:09:23 +00:00
|
|
|
let basep = (proc cmd (toCommand ps))
|
|
|
|
{ std_in = CreatePipe
|
|
|
|
, std_out = CreatePipe
|
|
|
|
, std_err = CreatePipe
|
|
|
|
}
|
|
|
|
p <- propgit g basep
|
2016-09-30 18:42:48 +00:00
|
|
|
(Just hin, Just hout, Just herr, ph) <-
|
2017-03-08 19:56:55 +00:00
|
|
|
createProcess p `catchIO` runerr cmdpath
|
2015-04-04 18:53:17 +00:00
|
|
|
stderrelay <- async $ errrelayer herr
|
2016-09-30 23:51:16 +00:00
|
|
|
cv <- newTVarIO $ externalDefaultConfig external
|
|
|
|
pv <- newTVarIO Unprepared
|
2016-09-30 18:42:48 +00:00
|
|
|
pid <- atomically $ do
|
2016-09-30 23:51:16 +00:00
|
|
|
n <- succ <$> readTVar (externalLastPid external)
|
|
|
|
writeTVar (externalLastPid external) n
|
2016-09-30 18:42:48 +00:00
|
|
|
return n
|
2015-04-04 18:53:17 +00:00
|
|
|
return $ ExternalState
|
|
|
|
{ externalSend = hin
|
|
|
|
, externalReceive = hout
|
2016-09-30 18:42:48 +00:00
|
|
|
, externalPid = pid
|
2015-04-04 18:53:17 +00:00
|
|
|
, externalShutdown = do
|
|
|
|
cancel stderrelay
|
2016-09-30 18:42:48 +00:00
|
|
|
void $ waitForProcess ph
|
2016-09-30 18:29:02 +00:00
|
|
|
, externalPrepared = pv
|
2016-09-30 17:36:50 +00:00
|
|
|
, externalConfig = cv
|
2015-04-04 18:53:17 +00:00
|
|
|
}
|
2016-09-30 18:29:02 +00:00
|
|
|
|
2016-09-30 17:36:50 +00:00
|
|
|
basecmd = externalRemoteProgram $ externalType external
|
2016-09-05 16:09:23 +00:00
|
|
|
|
2016-05-06 16:26:37 +00:00
|
|
|
propgit g p = do
|
|
|
|
environ <- propGitEnv g
|
|
|
|
return $ p { env = Just environ }
|
2015-11-18 16:30:01 +00:00
|
|
|
|
2017-03-08 19:56:55 +00:00
|
|
|
runerr (Just cmd) _ =
|
|
|
|
giveup $ "Cannot run " ++ cmd ++ " -- Make sure it's executable and that its dependencies are installed."
|
|
|
|
runerr Nothing _ = do
|
|
|
|
path <- intercalate ":" <$> getSearchPath
|
|
|
|
giveup $ "Cannot run " ++ basecmd ++ " -- It is not installed in PATH (" ++ path ++ ")"
|
2013-12-25 21:53:24 +00:00
|
|
|
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
stopExternal :: External -> Annex ()
|
2016-09-30 18:29:02 +00:00
|
|
|
stopExternal external = liftIO $ do
|
2016-09-30 23:51:16 +00:00
|
|
|
l <- atomically $ swapTVar (externalState external) []
|
2016-09-30 18:29:02 +00:00
|
|
|
mapM_ stop l
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
where
|
2016-09-30 18:29:02 +00:00
|
|
|
stop st = do
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
hClose $ externalSend st
|
|
|
|
hClose $ externalReceive st
|
2015-04-04 18:53:17 +00:00
|
|
|
externalShutdown st
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
|
|
|
|
externalRemoteProgram :: ExternalType -> String
|
|
|
|
externalRemoteProgram externaltype = "git-annex-remote-" ++ externaltype
|
|
|
|
|
2016-09-30 18:29:02 +00:00
|
|
|
checkVersion :: ExternalState -> External -> RemoteRequest -> Maybe (Annex ())
|
|
|
|
checkVersion st external (VERSION v) = Just $
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
if v `elem` supportedProtocolVersions
|
|
|
|
then noop
|
2016-09-30 18:29:02 +00:00
|
|
|
else sendMessage st external (ERROR "unsupported VERSION")
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
checkVersion _ _ _ = Nothing
|
|
|
|
|
2013-12-29 17:39:25 +00:00
|
|
|
{- If repo has not been prepared, sends PREPARE.
|
|
|
|
-
|
|
|
|
- If the repo fails to prepare, or failed before, throws an exception with
|
|
|
|
- the error message. -}
|
2016-09-30 18:29:02 +00:00
|
|
|
checkPrepared :: ExternalState -> External -> Annex ()
|
|
|
|
checkPrepared st external = do
|
2016-09-30 23:51:16 +00:00
|
|
|
v <- liftIO $ atomically $ readTVar $ externalPrepared st
|
2016-09-30 18:29:02 +00:00
|
|
|
case v of
|
|
|
|
Prepared -> noop
|
2016-11-16 01:29:54 +00:00
|
|
|
FailedPrepare errmsg -> giveup errmsg
|
2016-09-30 18:29:02 +00:00
|
|
|
Unprepared ->
|
|
|
|
handleRequest' st external PREPARE Nothing $ \resp ->
|
|
|
|
case resp of
|
2018-06-08 15:52:20 +00:00
|
|
|
PREPARE_SUCCESS -> Just $ do
|
2016-09-30 18:29:02 +00:00
|
|
|
setprepared Prepared
|
2018-06-08 15:52:20 +00:00
|
|
|
return (Result ())
|
2016-09-30 18:29:02 +00:00
|
|
|
PREPARE_FAILURE errmsg -> Just $ do
|
|
|
|
setprepared $ FailedPrepare errmsg
|
2016-11-16 01:29:54 +00:00
|
|
|
giveup errmsg
|
2016-09-30 18:29:02 +00:00
|
|
|
_ -> Nothing
|
2013-12-29 17:39:25 +00:00
|
|
|
where
|
2016-09-30 18:29:02 +00:00
|
|
|
setprepared status = liftIO $ atomically $ void $
|
2016-09-30 23:51:16 +00:00
|
|
|
swapTVar (externalPrepared st) status
|
2013-12-27 06:49:10 +00:00
|
|
|
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
{- Caches the cost in the git config to avoid needing to start up an
|
|
|
|
- external special remote every time time just to ask it what its
|
|
|
|
- cost is. -}
|
|
|
|
getCost :: External -> Git.Repo -> RemoteGitConfig -> Annex Cost
|
2018-06-08 15:52:20 +00:00
|
|
|
getCost external r gc =
|
|
|
|
(go =<< remoteCost' gc) `catchNonAsync` const (pure defcst)
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
where
|
|
|
|
go (Just c) = return c
|
|
|
|
go Nothing = do
|
|
|
|
c <- handleRequest external GETCOST Nothing $ \req -> case req of
|
2018-06-08 15:52:20 +00:00
|
|
|
COST c -> result c
|
|
|
|
UNSUPPORTED_REQUEST -> result defcst
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
_ -> Nothing
|
|
|
|
setRemoteCost r c
|
|
|
|
return c
|
2018-06-08 15:52:20 +00:00
|
|
|
defcst = expensiveRemoteCost
|
2014-01-13 18:41:10 +00:00
|
|
|
|
|
|
|
{- Caches the availability in the git config to avoid needing to start up an
|
|
|
|
- external special remote every time time just to ask it what its
|
|
|
|
- availability is.
|
|
|
|
-
|
|
|
|
- Most remotes do not bother to implement a reply to this request;
|
|
|
|
- globally available is the default.
|
|
|
|
-}
|
|
|
|
getAvailability :: External -> Git.Repo -> RemoteGitConfig -> Annex Availability
|
2016-07-05 20:34:39 +00:00
|
|
|
getAvailability external r gc =
|
2018-06-08 15:52:20 +00:00
|
|
|
maybe (catchNonAsync query (const (pure defavail))) return
|
|
|
|
(remoteAnnexAvailability gc)
|
2014-01-13 18:41:10 +00:00
|
|
|
where
|
|
|
|
query = do
|
|
|
|
avail <- handleRequest external GETAVAILABILITY Nothing $ \req -> case req of
|
2018-06-08 15:52:20 +00:00
|
|
|
AVAILABILITY avail -> result avail
|
|
|
|
UNSUPPORTED_REQUEST -> result defavail
|
2014-01-13 18:41:10 +00:00
|
|
|
_ -> Nothing
|
|
|
|
setRemoteAvailability r avail
|
|
|
|
return avail
|
2018-06-08 15:52:20 +00:00
|
|
|
defavail = GloballyAvailable
|
2014-12-08 17:57:13 +00:00
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
claimUrlM :: External -> URLString -> Annex Bool
|
|
|
|
claimUrlM external url =
|
2014-12-08 17:57:13 +00:00
|
|
|
handleRequest external (CLAIMURL url) Nothing $ \req -> case req of
|
2018-06-08 15:52:20 +00:00
|
|
|
CLAIMURL_SUCCESS -> result True
|
|
|
|
CLAIMURL_FAILURE -> result False
|
|
|
|
UNSUPPORTED_REQUEST -> result False
|
2014-12-08 17:57:13 +00:00
|
|
|
_ -> Nothing
|
|
|
|
|
2017-09-15 17:15:47 +00:00
|
|
|
checkUrlM :: External -> URLString -> Annex UrlContents
|
|
|
|
checkUrlM external url =
|
2014-12-08 23:14:24 +00:00
|
|
|
handleRequest external (CHECKURL url) Nothing $ \req -> case req of
|
2018-06-08 15:52:20 +00:00
|
|
|
CHECKURL_CONTENTS sz f -> result $ UrlContents sz $
|
|
|
|
if null f then Nothing else Just $ mkSafeFilePath f
|
2014-12-11 21:44:27 +00:00
|
|
|
-- Treat a single item multi response specially to
|
|
|
|
-- simplify the external remote implementation.
|
|
|
|
CHECKURL_MULTI ((_, sz, f):[]) ->
|
2018-06-08 15:52:20 +00:00
|
|
|
result $ UrlContents sz $ Just $ mkSafeFilePath f
|
|
|
|
CHECKURL_MULTI l -> result $ UrlMulti $ map mkmulti l
|
2016-11-16 01:29:54 +00:00
|
|
|
CHECKURL_FAILURE errmsg -> Just $ giveup errmsg
|
|
|
|
UNSUPPORTED_REQUEST -> giveup "CHECKURL not implemented by external special remote"
|
2014-12-08 23:14:24 +00:00
|
|
|
_ -> Nothing
|
2014-12-12 00:08:49 +00:00
|
|
|
where
|
|
|
|
mkmulti (u, s, f) = (u, s, mkSafeFilePath f)
|
2015-08-17 15:22:22 +00:00
|
|
|
|
|
|
|
retrieveUrl :: Retriever
|
2015-11-17 01:00:54 +00:00
|
|
|
retrieveUrl = fileRetriever $ \f k p -> do
|
2015-08-17 15:22:22 +00:00
|
|
|
us <- getWebUrls k
|
2015-11-17 01:00:54 +00:00
|
|
|
unlessM (downloadUrl k p us f) $
|
2016-11-16 01:29:54 +00:00
|
|
|
giveup "failed to download content"
|
2015-08-17 15:22:22 +00:00
|
|
|
|
|
|
|
checkKeyUrl :: Git.Repo -> CheckPresent
|
|
|
|
checkKeyUrl r k = do
|
|
|
|
showChecking r
|
|
|
|
us <- getWebUrls k
|
2018-04-04 19:00:51 +00:00
|
|
|
anyM (\u -> withUrlOptions $ liftIO . checkBoth u (keySize k)) us
|
2015-08-17 15:22:22 +00:00
|
|
|
|
|
|
|
getWebUrls :: Key -> Annex [URLString]
|
|
|
|
getWebUrls key = filter supported <$> getUrls key
|
|
|
|
where
|
|
|
|
supported u = snd (getDownloader u) == WebDownloader
|
2018-06-08 15:52:20 +00:00
|
|
|
|
|
|
|
externalInfo :: ExternalType -> Annex [(String, String)]
|
|
|
|
externalInfo et = return [("externaltype", et)]
|
|
|
|
|
|
|
|
getInfoM :: External -> Annex [(String, String)]
|
|
|
|
getInfoM external = (++)
|
|
|
|
<$> externalInfo (externalType external)
|
|
|
|
<*> handleRequest external GETINFO Nothing (collect [])
|
|
|
|
where
|
|
|
|
collect l req = case req of
|
|
|
|
INFOFIELD f -> Just $ return $
|
|
|
|
GetNextMessage $ collectvalue l f
|
|
|
|
INFOEND -> result (reverse l)
|
|
|
|
UNSUPPORTED_REQUEST -> result []
|
|
|
|
_ -> Nothing
|
|
|
|
|
|
|
|
collectvalue l f req = case req of
|
|
|
|
INFOVALUE v -> Just $ return $
|
|
|
|
GetNextMessage $ collect ((f, v) : l)
|
|
|
|
_ -> Nothing
|