2013-12-25 21:53:24 +00:00
|
|
|
|
{- External special remote interface.
|
|
|
|
|
-
|
|
|
|
|
- Copyright 2013 Joey Hess <joey@kitenet.net>
|
|
|
|
|
-
|
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
|
-}
|
|
|
|
|
|
|
|
|
|
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
|
2013-12-25 21:53:24 +00:00
|
|
|
|
import Common.Annex
|
|
|
|
|
import Types.Remote
|
|
|
|
|
import qualified Git
|
|
|
|
|
import Config
|
|
|
|
|
import Remote.Helper.Special
|
|
|
|
|
import Remote.Helper.Encryptable
|
|
|
|
|
import Crypto
|
|
|
|
|
import Utility.Metered
|
|
|
|
|
import Logs.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
|
2013-12-25 21:53:24 +00:00
|
|
|
|
import Config.Cost
|
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.Content
|
|
|
|
|
import Annex.UUID
|
|
|
|
|
import Annex.Exception
|
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
|
|
|
|
|
import System.Process (std_in, std_out, std_err)
|
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-27 16:21:55 +00:00
|
|
|
|
import qualified Data.ByteString.Lazy as L
|
2013-12-25 21:53:24 +00:00
|
|
|
|
|
|
|
|
|
remote :: RemoteType
|
|
|
|
|
remote = RemoteType {
|
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
|
|
|
|
typename = "external",
|
|
|
|
|
enumerate = findSpecialRemotes "externaltype",
|
2013-12-25 21:53:24 +00:00
|
|
|
|
generate = gen,
|
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
|
|
|
|
setup = externalSetup
|
2013-12-25 21:53:24 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> Annex (Maybe Remote)
|
|
|
|
|
gen r u c gc = do
|
2013-12-27 20:01:43 +00:00
|
|
|
|
external <- newExternal externaltype u c
|
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
|
|
|
|
Annex.addCleanup (fromUUID u) $ stopExternal external
|
|
|
|
|
cst <- getCost external r gc
|
2014-01-13 18:41:10 +00:00
|
|
|
|
avail <- getAvailability external r gc
|
2013-12-25 21:53:24 +00:00
|
|
|
|
return $ Just $ encryptableRemote c
|
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
|
|
|
|
(storeEncrypted external $ getGpgEncParams (c,gc))
|
|
|
|
|
(retrieveEncrypted external)
|
2013-12-25 21:53:24 +00:00
|
|
|
|
Remote {
|
|
|
|
|
uuid = u,
|
|
|
|
|
cost = cst,
|
|
|
|
|
name = Git.repoDescribe r,
|
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
|
|
|
|
storeKey = store external,
|
|
|
|
|
retrieveKeyFile = retrieve external,
|
2013-12-27 16:21:55 +00:00
|
|
|
|
retrieveKeyFileCheap = \_ _ -> return 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
|
|
|
|
removeKey = remove external,
|
|
|
|
|
hasKey = checkPresent external,
|
2013-12-25 21:53:24 +00:00
|
|
|
|
hasKeyCheap = False,
|
|
|
|
|
whereisKey = Nothing,
|
|
|
|
|
remoteFsck = Nothing,
|
|
|
|
|
repairRepo = Nothing,
|
|
|
|
|
config = c,
|
|
|
|
|
localpath = Nothing,
|
|
|
|
|
repo = r,
|
|
|
|
|
gitconfig = gc,
|
|
|
|
|
readonly = False,
|
2014-01-13 18:41:10 +00:00
|
|
|
|
availability = avail,
|
2013-12-25 21:53:24 +00:00
|
|
|
|
remotetype = remote
|
|
|
|
|
}
|
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-01-13 18:41:10 +00:00
|
|
|
|
externaltype = fromMaybe (error "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
|
|
|
|
|
|
|
|
|
externalSetup :: Maybe UUID -> RemoteConfig -> Annex (RemoteConfig, UUID)
|
|
|
|
|
externalSetup mu c = do
|
|
|
|
|
u <- maybe (liftIO genUUID) return mu
|
|
|
|
|
let externaltype = fromMaybe (error "Specify externaltype=") $
|
|
|
|
|
M.lookup "externaltype" c
|
|
|
|
|
c' <- encryptionSetup c
|
|
|
|
|
|
2013-12-27 20:01:43 +00:00
|
|
|
|
external <- newExternal externaltype u c'
|
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 INITREMOTE Nothing $ \resp -> case resp of
|
|
|
|
|
INITREMOTE_SUCCESS -> Just noop
|
|
|
|
|
INITREMOTE_FAILURE errmsg -> Just $ error errmsg
|
|
|
|
|
_ -> Nothing
|
2013-12-27 16:37:23 +00:00
|
|
|
|
c'' <- liftIO $ atomically $ readTMVar $ externalConfig external
|
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-27 16:37:23 +00:00
|
|
|
|
gitConfigSpecialRemote u c'' "externaltype" externaltype
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
store :: External -> Key -> AssociatedFile -> MeterUpdate -> Annex Bool
|
2013-12-27 16:21:55 +00:00
|
|
|
|
store external k _f p = sendAnnex k rollback $ \f ->
|
2014-02-11 01:33:22 +00:00
|
|
|
|
metered (Just p) k $
|
|
|
|
|
storeHelper external k f
|
2013-12-27 16:21:55 +00:00
|
|
|
|
where
|
|
|
|
|
rollback = void $ remove external k
|
|
|
|
|
|
|
|
|
|
storeEncrypted :: External -> [CommandParam] -> (Cipher, Key) -> Key -> MeterUpdate -> Annex Bool
|
|
|
|
|
storeEncrypted external gpgOpts (cipher, enck) k p = withTmp enck $ \tmp ->
|
|
|
|
|
sendAnnex k rollback $ \src -> do
|
2014-02-11 01:33:22 +00:00
|
|
|
|
metered (Just p) k $ \meterupdate -> do
|
|
|
|
|
liftIO $ encrypt gpgOpts cipher (feedFile src) $
|
|
|
|
|
readBytes $ L.writeFile tmp
|
|
|
|
|
storeHelper external enck tmp meterupdate
|
2013-12-27 16:21:55 +00:00
|
|
|
|
where
|
|
|
|
|
rollback = void $ remove external enck
|
|
|
|
|
|
|
|
|
|
storeHelper :: External -> Key -> FilePath -> MeterUpdate -> Annex Bool
|
|
|
|
|
storeHelper external k f p = safely $
|
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 (TRANSFER Upload k f) (Just p) $ \resp ->
|
|
|
|
|
case resp of
|
2013-12-27 16:21:55 +00:00
|
|
|
|
TRANSFER_SUCCESS Upload k' | k == k' ->
|
|
|
|
|
Just $ return True
|
|
|
|
|
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
|
|
|
|
|
return False
|
|
|
|
|
_ -> Nothing
|
|
|
|
|
|
|
|
|
|
retrieve :: External -> Key -> AssociatedFile -> FilePath -> MeterUpdate -> Annex Bool
|
2014-02-11 01:33:22 +00:00
|
|
|
|
retrieve external k _f d p = metered (Just p) k $
|
|
|
|
|
retrieveHelper external k d
|
2013-12-27 16:21:55 +00:00
|
|
|
|
|
|
|
|
|
retrieveEncrypted :: External -> (Cipher, Key) -> Key -> FilePath -> MeterUpdate -> Annex Bool
|
2014-02-11 01:33:22 +00:00
|
|
|
|
retrieveEncrypted external (cipher, enck) k f p = withTmp enck $ \tmp ->
|
|
|
|
|
metered (Just p) k $ \meterupdate ->
|
|
|
|
|
ifM (retrieveHelper external enck tmp meterupdate)
|
|
|
|
|
( liftIO $ catchBoolIO $ do
|
|
|
|
|
decrypt cipher (feedFile tmp) $
|
|
|
|
|
readBytes $ L.writeFile f
|
|
|
|
|
return True
|
|
|
|
|
, return False
|
|
|
|
|
)
|
2013-12-27 16:21:55 +00:00
|
|
|
|
|
|
|
|
|
retrieveHelper :: External -> Key -> FilePath -> MeterUpdate -> Annex Bool
|
|
|
|
|
retrieveHelper external k d p = safely $
|
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 (TRANSFER Download k d) (Just p) $ \resp ->
|
|
|
|
|
case resp of
|
|
|
|
|
TRANSFER_SUCCESS Download k'
|
|
|
|
|
| k == k' -> Just $ return True
|
|
|
|
|
TRANSFER_FAILURE Download k' errmsg
|
|
|
|
|
| k == k' -> Just $ do
|
|
|
|
|
warning errmsg
|
|
|
|
|
return False
|
|
|
|
|
_ -> Nothing
|
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
|
|
|
|
remove :: External -> Key -> Annex Bool
|
|
|
|
|
remove external k = safely $
|
|
|
|
|
handleRequest external (REMOVE k) Nothing $ \resp ->
|
|
|
|
|
case resp of
|
|
|
|
|
REMOVE_SUCCESS k'
|
|
|
|
|
| k == k' -> Just $ return True
|
|
|
|
|
REMOVE_FAILURE k' errmsg
|
|
|
|
|
| k == k' -> Just $ do
|
|
|
|
|
warning errmsg
|
|
|
|
|
return False
|
|
|
|
|
_ -> Nothing
|
|
|
|
|
|
|
|
|
|
checkPresent :: External -> Key -> Annex (Either String Bool)
|
|
|
|
|
checkPresent external k = either (Left . show) id <$> tryAnnex go
|
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
|
|
|
|
go = handleRequest external (CHECKPRESENT k) Nothing $ \resp ->
|
|
|
|
|
case resp of
|
|
|
|
|
CHECKPRESENT_SUCCESS k'
|
|
|
|
|
| k' == k -> Just $ return $ Right True
|
|
|
|
|
CHECKPRESENT_FAILURE k'
|
|
|
|
|
| k' == k -> Just $ return $ Right False
|
|
|
|
|
CHECKPRESENT_UNKNOWN k' errmsg
|
|
|
|
|
| k' == k -> Just $ return $ Left errmsg
|
|
|
|
|
_ -> Nothing
|
|
|
|
|
|
|
|
|
|
safely :: Annex Bool -> Annex Bool
|
|
|
|
|
safely a = go =<< tryAnnex a
|
|
|
|
|
where
|
|
|
|
|
go (Right r) = return r
|
|
|
|
|
go (Left e) = do
|
|
|
|
|
warning $ show e
|
|
|
|
|
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.
|
|
|
|
|
-
|
|
|
|
|
- Only one request can be made at a time, so locking is used.
|
|
|
|
|
-
|
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
|
|
|
|
-}
|
|
|
|
|
handleRequest :: External -> Request -> Maybe MeterUpdate -> (Response -> Maybe (Annex a)) -> Annex a
|
|
|
|
|
handleRequest external req mp responsehandler =
|
|
|
|
|
withExternalLock external $ \lck ->
|
|
|
|
|
handleRequest' lck external req mp responsehandler
|
|
|
|
|
|
|
|
|
|
handleRequest' :: ExternalLock -> External -> Request -> Maybe MeterUpdate -> (Response -> Maybe (Annex a)) -> Annex a
|
2013-12-29 17:39:25 +00:00
|
|
|
|
handleRequest' lck external req mp responsehandler
|
|
|
|
|
| needsPREPARE req = do
|
2013-12-27 06:49:10 +00:00
|
|
|
|
checkPrepared lck 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
|
2013-12-29 17:39:25 +00:00
|
|
|
|
go = do
|
|
|
|
|
sendMessage lck external req
|
|
|
|
|
loop
|
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
|
|
|
|
loop = receiveMessage lck external responsehandler
|
|
|
|
|
(\rreq -> Just $ handleRemoteRequest rreq >> loop)
|
|
|
|
|
(\msg -> Just $ handleAsyncMessage msg >> loop)
|
|
|
|
|
|
|
|
|
|
handleRemoteRequest (PROGRESS bytesprocessed) =
|
|
|
|
|
maybe noop (\a -> liftIO $ a bytesprocessed) mp
|
|
|
|
|
handleRemoteRequest (DIRHASH k) =
|
2014-01-02 00:12:20 +00:00
|
|
|
|
send $ VALUE $ hashDirMixed k
|
2013-12-27 16:37:23 +00:00
|
|
|
|
handleRemoteRequest (SETCONFIG setting value) =
|
|
|
|
|
liftIO $ atomically $ do
|
|
|
|
|
let v = externalConfig external
|
|
|
|
|
m <- takeTMVar v
|
|
|
|
|
putTMVar v $ M.insert setting value m
|
|
|
|
|
handleRemoteRequest (GETCONFIG setting) = do
|
|
|
|
|
value <- fromMaybe "" . M.lookup setting
|
|
|
|
|
<$> liftIO (atomically $ readTMVar $ externalConfig external)
|
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
|
|
|
|
|
c <- liftIO $ atomically $ readTMVar $ externalConfig external
|
|
|
|
|
c' <- setRemoteCredPair' c (credstorage setting)
|
|
|
|
|
(login, password)
|
|
|
|
|
void $ liftIO $ atomically $ swapTMVar (externalConfig external) c'
|
|
|
|
|
handleRemoteRequest (GETCREDS setting) = do
|
|
|
|
|
c <- liftIO $ atomically $ readTMVar $ externalConfig external
|
|
|
|
|
creds <- fromMaybe ("", "") <$>
|
|
|
|
|
getRemoteCredPair c (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-01-07 17:23:58 +00:00
|
|
|
|
handleRemoteRequest (DEBUG msg) = liftIO $ debugM "external" 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 _) =
|
2013-12-27 20:01:43 +00:00
|
|
|
|
sendMessage lck 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
|
|
|
|
|
|
|
|
|
handleAsyncMessage (ERROR err) = error $ "external special remote error: " ++ err
|
|
|
|
|
|
2014-01-02 00:12:20 +00:00
|
|
|
|
send = sendMessage lck external
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
sendMessage :: Sendable m => ExternalLock -> External -> m -> Annex ()
|
|
|
|
|
sendMessage lck external m =
|
|
|
|
|
fromExternal lck external externalSend $ \h ->
|
2013-12-27 07:10:00 +00:00
|
|
|
|
liftIO $ do
|
|
|
|
|
protocolDebug external True line
|
|
|
|
|
hPutStrLn h line
|
2013-12-27 17:22:06 +00:00
|
|
|
|
hFlush h
|
2013-12-27 07:10:00 +00:00
|
|
|
|
where
|
|
|
|
|
line = unwords $ formatMessage m
|
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
|
|
|
|
|
:: ExternalLock
|
|
|
|
|
-> External
|
|
|
|
|
-> (Response -> Maybe (Annex a))
|
|
|
|
|
-> (RemoteRequest -> Maybe (Annex a))
|
|
|
|
|
-> (AsyncMessage -> Maybe (Annex a))
|
|
|
|
|
-> Annex a
|
2013-12-27 21:14:44 +00:00
|
|
|
|
receiveMessage lck external handleresponse handlerequest handleasync =
|
|
|
|
|
go =<< fromExternal lck external externalReceive
|
|
|
|
|
(liftIO . catchMaybeIO . hGetLine)
|
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
|
|
|
|
|
liftIO $ protocolDebug external False s
|
|
|
|
|
case parseMessage s :: Maybe Response of
|
|
|
|
|
Just resp -> maybe (protocolError True s) id (handleresponse resp)
|
|
|
|
|
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
|
2013-12-27 18:03:35 +00:00
|
|
|
|
protocolError parsed s = error $ "external special remote protocol error, unexpectedly received \"" ++ s ++ "\" " ++
|
|
|
|
|
if parsed then "(command not allowed at this time)" else "(unable to parse command)"
|
2013-12-25 21:53:24 +00:00
|
|
|
|
|
2013-12-27 07:10:00 +00:00
|
|
|
|
protocolDebug :: External -> Bool -> String -> IO ()
|
|
|
|
|
protocolDebug external sendto line = debugM "external" $ unwords
|
|
|
|
|
[ externalRemoteProgram (externalType external)
|
|
|
|
|
, if sendto then "<--" else "-->"
|
|
|
|
|
, line
|
|
|
|
|
]
|
|
|
|
|
|
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
|
|
|
|
{- Starts up the external remote if it's not yet running,
|
|
|
|
|
- and passes a value extracted from its state to an action.
|
|
|
|
|
-}
|
|
|
|
|
fromExternal :: ExternalLock -> External -> (ExternalState -> v) -> (v -> Annex a) -> Annex a
|
|
|
|
|
fromExternal lck external extractor a =
|
|
|
|
|
go =<< liftIO (atomically (tryReadTMVar v))
|
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
|
|
|
|
go (Just st) = run st
|
|
|
|
|
go Nothing = do
|
|
|
|
|
st <- startExternal $ externalType external
|
2013-12-27 17:17:22 +00:00
|
|
|
|
void $ liftIO $ atomically $ do
|
|
|
|
|
void $ tryReadTMVar v
|
|
|
|
|
putTMVar v 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
|
|
|
|
|
|
|
|
|
{- Handle initial protocol startup; check the VERSION
|
2013-12-27 06:49:10 +00:00
|
|
|
|
- the remote sends. -}
|
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
|
|
|
|
receiveMessage lck external
|
|
|
|
|
(const Nothing)
|
|
|
|
|
(checkVersion lck external)
|
|
|
|
|
(const Nothing)
|
2013-12-27 06:49:10 +00:00
|
|
|
|
|
|
|
|
|
run 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
|
|
|
|
|
|
|
|
|
run st = a $ extractor st
|
|
|
|
|
v = externalState external
|
|
|
|
|
|
|
|
|
|
{- Starts an external remote process running, but does not handle checking
|
|
|
|
|
- VERSION, etc. -}
|
|
|
|
|
startExternal :: ExternalType -> Annex ExternalState
|
|
|
|
|
startExternal externaltype = liftIO $ do
|
2013-12-27 21:14:44 +00:00
|
|
|
|
(Just hin, Just hout, _, pid) <- createProcess $ (proc cmd [])
|
|
|
|
|
{ std_in = CreatePipe
|
|
|
|
|
, std_out = CreatePipe
|
|
|
|
|
, std_err = Inherit
|
|
|
|
|
}
|
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
|
|
|
|
fileEncoding hin
|
|
|
|
|
fileEncoding hout
|
2013-12-27 21:14:44 +00:00
|
|
|
|
checkearlytermination =<< getProcessExitCode pid
|
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 $ ExternalState
|
|
|
|
|
{ externalSend = hin
|
|
|
|
|
, externalReceive = hout
|
|
|
|
|
, externalPid = pid
|
2013-12-29 17:39:25 +00:00
|
|
|
|
, externalPrepared = Unprepared
|
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-27 21:14:44 +00:00
|
|
|
|
where
|
|
|
|
|
cmd = externalRemoteProgram externaltype
|
|
|
|
|
|
|
|
|
|
checkearlytermination Nothing = noop
|
|
|
|
|
checkearlytermination (Just exitcode) = ifM (inPath cmd)
|
|
|
|
|
( error $ unwords [ "failed to run", cmd, "(" ++ show exitcode ++ ")" ]
|
2014-01-07 16:59:26 +00:00
|
|
|
|
, do
|
|
|
|
|
path <- intercalate ":" <$> getSearchPath
|
|
|
|
|
error $ cmd ++ " is not installed in PATH (" ++ path ++ ")"
|
2013-12-27 21:14:44 +00:00
|
|
|
|
)
|
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 ()
|
|
|
|
|
stopExternal external = liftIO $ stop =<< atomically (tryReadTMVar v)
|
|
|
|
|
where
|
|
|
|
|
stop Nothing = noop
|
|
|
|
|
stop (Just st) = do
|
|
|
|
|
void $ atomically $ tryTakeTMVar v
|
|
|
|
|
hClose $ externalSend st
|
|
|
|
|
hClose $ externalReceive st
|
|
|
|
|
void $ waitForProcess $ externalPid st
|
|
|
|
|
v = externalState external
|
|
|
|
|
|
|
|
|
|
externalRemoteProgram :: ExternalType -> String
|
|
|
|
|
externalRemoteProgram externaltype = "git-annex-remote-" ++ externaltype
|
|
|
|
|
|
|
|
|
|
checkVersion :: ExternalLock -> External -> RemoteRequest -> Maybe (Annex ())
|
|
|
|
|
checkVersion lck external (VERSION v) = Just $
|
|
|
|
|
if v `elem` supportedProtocolVersions
|
|
|
|
|
then noop
|
|
|
|
|
else sendMessage lck external (ERROR "unsupported VERSION")
|
|
|
|
|
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. -}
|
2013-12-27 06:49:10 +00:00
|
|
|
|
checkPrepared :: ExternalLock -> External -> Annex ()
|
|
|
|
|
checkPrepared lck external =
|
|
|
|
|
fromExternal lck external externalPrepared $ \prepared ->
|
2013-12-29 17:39:25 +00:00
|
|
|
|
case prepared of
|
|
|
|
|
Prepared -> noop
|
|
|
|
|
FailedPrepare errmsg -> error errmsg
|
|
|
|
|
Unprepared ->
|
|
|
|
|
handleRequest' lck external PREPARE Nothing $ \resp ->
|
|
|
|
|
case resp of
|
|
|
|
|
PREPARE_SUCCESS -> Just $
|
|
|
|
|
setprepared Prepared
|
|
|
|
|
PREPARE_FAILURE errmsg -> Just $ do
|
|
|
|
|
setprepared $ FailedPrepare errmsg
|
|
|
|
|
error errmsg
|
|
|
|
|
_ -> Nothing
|
|
|
|
|
where
|
|
|
|
|
setprepared status = liftIO . atomically $ do
|
|
|
|
|
let v = externalState external
|
|
|
|
|
st <- takeTMVar v
|
|
|
|
|
void $ putTMVar v $ st { externalPrepared = 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
|
|
|
|
|
getCost external r gc = go =<< remoteCost' gc
|
|
|
|
|
where
|
|
|
|
|
go (Just c) = return c
|
|
|
|
|
go Nothing = do
|
|
|
|
|
c <- handleRequest external GETCOST Nothing $ \req -> case req of
|
|
|
|
|
COST c -> Just $ return c
|
2013-12-27 06:08:29 +00:00
|
|
|
|
UNSUPPORTED_REQUEST -> Just $ return expensiveRemoteCost
|
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
|
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
|
|
|
|
|
getAvailability external r gc = maybe query return (remoteAnnexAvailability gc)
|
|
|
|
|
where
|
|
|
|
|
query = do
|
|
|
|
|
avail <- handleRequest external GETAVAILABILITY Nothing $ \req -> case req of
|
|
|
|
|
AVAILABILITY avail -> Just $ return avail
|
|
|
|
|
UNSUPPORTED_REQUEST -> Just $ return GloballyAvailable
|
|
|
|
|
_ -> Nothing
|
|
|
|
|
setRemoteAvailability r avail
|
|
|
|
|
return avail
|