2013-12-25 21:53:24 +00:00
|
|
|
{- External special remote interface.
|
|
|
|
-
|
2020-01-15 17:01:22 +00:00
|
|
|
- Copyright 2013-2020 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
|
|
|
-}
|
|
|
|
|
2019-12-02 16:26:33 +00:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
|
|
|
|
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
|
2020-01-10 18:10:20 +00:00
|
|
|
import Types.ProposedAccepted
|
2013-12-25 21:53:24 +00:00
|
|
|
import qualified Git
|
|
|
|
import Config
|
2020-01-15 17:01:22 +00:00
|
|
|
import Git.Config (boolConfig)
|
2016-05-06 16:26:37 +00:00
|
|
|
import Git.Env
|
2020-01-15 17:01:22 +00:00
|
|
|
import Annex.SpecialRemote.Config
|
2013-12-25 21:53:24 +00:00
|
|
|
import Remote.Helper.Special
|
2019-02-20 19:55:01 +00:00
|
|
|
import Remote.Helper.ExportImport
|
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
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
import qualified Data.Set as S
|
2013-12-25 21:53:24 +00:00
|
|
|
|
|
|
|
remote :: RemoteType
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
remote = specialRemoteType $ RemoteType
|
2017-09-07 17:45:31 +00:00
|
|
|
{ typename = "external"
|
|
|
|
, enumerate = const (findSpecialRemotes "externaltype")
|
|
|
|
, generate = gen
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
, configParser = remoteConfigParser
|
2017-09-07 17:45:31 +00:00
|
|
|
, setup = externalSetup
|
2017-09-08 18:24:05 +00:00
|
|
|
, exportSupported = checkExportSupported
|
2019-02-20 19:55:01 +00:00
|
|
|
, importSupported = importUnsupported
|
2017-09-07 17:45:31 +00:00
|
|
|
}
|
2013-12-25 21:53:24 +00:00
|
|
|
|
2020-01-15 17:01:22 +00:00
|
|
|
externaltypeField :: RemoteConfigField
|
|
|
|
externaltypeField = Accepted "externaltype"
|
|
|
|
|
|
|
|
readonlyField :: RemoteConfigField
|
|
|
|
readonlyField = Accepted "readonly"
|
|
|
|
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
|
|
|
|
gen r u rc gc rs
|
2015-08-17 15:22:22 +00:00
|
|
|
-- readonly mode only downloads urls; does not use external program
|
2020-04-23 18:56:03 +00:00
|
|
|
| externaltype == "readonly" = do
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
c <- parsedRemoteConfig remote rc
|
2015-08-17 15:22:22 +00:00
|
|
|
cst <- remoteCost gc expensiveRemoteCost
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
mk c cst GloballyAvailable
|
2015-08-17 15:22:22 +00:00
|
|
|
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
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
c <- parsedRemoteConfig remote rc
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
external <- newExternal externaltype (Just u) c (Just gc) (Just rs)
|
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
|
2019-01-30 18:55:28 +00:00
|
|
|
then 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
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
mk c 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
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
mk c 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.
|
2018-09-25 19:32:50 +00:00
|
|
|
, retrievalSecurityPolicy = mkRetrievalVerifiableKeysSecure gc
|
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
|
2019-02-20 19:55:01 +00:00
|
|
|
, importActions = importUnsupported
|
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
|
2018-08-30 15:12:18 +00:00
|
|
|
, appendonly = False
|
2014-12-16 19:26:13 +00:00
|
|
|
, availability = avail
|
2017-09-08 18:24:05 +00:00
|
|
|
, remotetype = remote
|
|
|
|
{ exportSupported = cheapexportsupported }
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
, mkUnavailable = gen r u rc
|
add RemoteStateHandle
This solves the problem of sameas remotes trampling over per-remote
state. Used for:
* per-remote state, of course
* per-remote metadata, also of course
* per-remote content identifiers, because two remote implementations
could in theory generate the same content identifier for two different
peices of content
While chunk logs are per-remote data, they don't use this, because the
number and size of chunks stored is a common property across sameas
remotes.
External special remote had a complication, where it was theoretically
possible for a remote to send SETSTATE or GETSTATE during INITREMOTE or
EXPORTSUPPORTED. Since the uuid of the remote is typically generate in
Remote.setup, it would only be possible to pass a Maybe
RemoteStateHandle into it, and it would otherwise have to construct its
own. Rather than go that route, I decided to send an ERROR in this case.
It seems unlikely that any existing external special remote will be
affected. They would have to make up a git-annex key, and set state for
some reason during INITREMOTE. I can imagine such a hack, but it doesn't
seem worth complicating the code in such an ugly way to support it.
Unfortunately, both TestRemote and Annex.Import needed the Remote
to have a new field added that holds its RemoteStateHandle.
2019-10-14 16:33:27 +00:00
|
|
|
(gc { remoteAnnexExternalType = Just "!dne!" }) rs
|
2018-06-08 15:52:20 +00:00
|
|
|
, getInfo = togetinfo
|
2015-08-17 15:22:22 +00:00
|
|
|
, claimUrl = toclaimurl
|
|
|
|
, checkUrl = tocheckurl
|
add RemoteStateHandle
This solves the problem of sameas remotes trampling over per-remote
state. Used for:
* per-remote state, of course
* per-remote metadata, also of course
* per-remote content identifiers, because two remote implementations
could in theory generate the same content identifier for two different
peices of content
While chunk logs are per-remote data, they don't use this, because the
number and size of chunks stored is a common property across sameas
remotes.
External special remote had a complication, where it was theoretically
possible for a remote to send SETSTATE or GETSTATE during INITREMOTE or
EXPORTSUPPORTED. Since the uuid of the remote is typically generate in
Remote.setup, it would only be possible to pass a Maybe
RemoteStateHandle into it, and it would otherwise have to construct its
own. Rather than go that route, I decided to send an ERROR in this case.
It seems unlikely that any existing external special remote will be
affected. They would have to make up a git-annex key, and set state for
some reason during INITREMOTE. I can imagine such a hack, but it doesn't
seem worth complicating the code in such an ugly way to support it.
Unfortunately, both TestRemote and Annex.Import needed the Remote
to have a new field added that holds its RemoteStateHandle.
2019-10-14 16:33:27 +00:00
|
|
|
, remoteStateHandle = rs
|
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
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
pc <- either giveup return $ parseRemoteConfig c lenientRemoteConfigParser
|
2020-04-23 18:56:03 +00:00
|
|
|
let readonlyconfig = getRemoteConfigValue readonlyField pc == Just True
|
|
|
|
let externaltype = if readonlyconfig
|
|
|
|
then "readonly"
|
|
|
|
else fromMaybe (giveup "Specify externaltype=") $
|
|
|
|
getRemoteConfigValue externaltypeField pc
|
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
|
|
|
|
2020-04-23 18:56:03 +00:00
|
|
|
c'' <- if readonlyconfig
|
|
|
|
then do
|
|
|
|
-- Setting annex-readonly is not really necessary
|
|
|
|
-- anymore, but older versions of git-annex used
|
|
|
|
-- this, not externaltype=readonly, so still set
|
|
|
|
-- it.
|
2020-02-19 17:45:11 +00:00
|
|
|
setConfig (remoteAnnexConfig (fromJust (lookupName c)) "readonly") (boolConfig True)
|
2015-08-17 15:22:22 +00:00
|
|
|
return c'
|
2020-04-23 18:56:03 +00:00
|
|
|
else do
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
pc' <- either giveup return $ parseRemoteConfig c' lenientRemoteConfigParser
|
|
|
|
external <- newExternal externaltype (Just u) pc' (Just gc) Nothing
|
|
|
|
-- Now that we have an external, ask it to LISTCONFIGS,
|
|
|
|
-- and re-parse the RemoteConfig strictly, so we can
|
|
|
|
-- error out if the user provided an unexpected config.
|
2020-01-17 21:23:19 +00:00
|
|
|
_ <- either giveup return . parseRemoteConfig c'
|
2020-01-17 21:13:44 +00:00
|
|
|
=<< strictRemoteConfigParser external
|
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 ()
|
2020-02-27 18:09:18 +00:00
|
|
|
INITREMOTE_FAILURE errmsg -> Just $ giveup $
|
|
|
|
respErrorMessage "INITREMOTE" errmsg
|
2015-08-17 15:22:22 +00:00
|
|
|
_ -> Nothing
|
2020-01-15 17:01:22 +00:00
|
|
|
-- Any config changes the external made before
|
|
|
|
-- responding to INITREMOTE need to be applied to
|
|
|
|
-- the RemoteConfig.
|
|
|
|
changes <- withExternalState external $
|
|
|
|
liftIO . atomically . readTVar . externalConfigChanges
|
|
|
|
return (changes 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
|
|
|
|
2018-03-27 16:41:57 +00:00
|
|
|
gitConfigSpecialRemote u c'' [("externaltype", externaltype)]
|
external: stop storing readonly=true in remote.log
readonly=true is used to make an external special remote that does not
need the external program to be installed. It was stored in the
remote.log by default, and so every time it was specified in an
enableremote or initremote, whatever value was used became the new
default for subsequent enableremotes of that remote.
That was surprising, and I consider it to be a bug.
It does not make much sense to pass it to initremote because then how
would you populate that remote with anything? You would have to
enableremote elsewhere, and store content there. I'm assuming nobody
used it that way.
Someone might rely on passing it to enableremote once, and then that
being inherited in other clones. But that is not how it's documented to
be used. It is barely documented in git-annex at all, only in the
external special remote protocol, and the documentation there says to
"Document that this external special remote can be used in readonly
mode." (by the user of it passing readonly=true to enableremote). The
one external special remote that I know of that does document that is
<https://github.com/bgilbert/gcsannex> (the one that motivated adding
it). That one's docs do say to pass it to enableremote.
So, it seemed safe to make this behavior change. If someone was in fact
relying on one of those behaviors, all their current repos will still
work as they configured them (although they will need to deal
with the related change in 9f3c2dfedae7ec840365f9578763209abae1005c).
In new clones, they will find enableremote fails, complaining the
external program is not in path. An easy enough problem to recover from.
2020-04-23 18:59:38 +00:00
|
|
|
return (M.delete readonlyField 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
|
|
|
|
2020-01-15 17:01:22 +00:00
|
|
|
checkExportSupported :: ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool
|
2017-09-08 18:24:05 +00:00
|
|
|
checkExportSupported c gc = do
|
|
|
|
let externaltype = fromMaybe (giveup "Specify externaltype=") $
|
2020-01-15 17:01:22 +00:00
|
|
|
remoteAnnexExternalType gc <|> getRemoteConfigValue externaltypeField c
|
2020-04-23 18:56:03 +00:00
|
|
|
if externaltype == "readonly"
|
|
|
|
then return False
|
|
|
|
else checkExportSupported'
|
|
|
|
=<< newExternal externaltype Nothing c (Just gc) Nothing
|
2017-09-08 18:24:05 +00:00
|
|
|
|
|
|
|
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
|
2020-02-27 18:09:18 +00:00
|
|
|
warning $ respErrorMessage "TRANSFER" 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
|
2020-02-27 18:09:18 +00:00
|
|
|
| k == k' -> Just $ giveup $
|
|
|
|
respErrorMessage "TRANSFER" 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
|
2020-02-27 18:09:18 +00:00
|
|
|
warning $ respErrorMessage "REMOVE" 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
|
2020-02-27 18:09:18 +00:00
|
|
|
| k' == k -> result $ Left $
|
|
|
|
respErrorMessage "CHECKPRESENT" 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
|
2020-02-27 18:09:18 +00:00
|
|
|
warning $ respErrorMessage "TRANSFER" 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
|
2020-02-27 18:09:18 +00:00
|
|
|
warning $ respErrorMessage "TRANSFER" 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
|
2020-02-27 18:09:18 +00:00
|
|
|
| k' == k -> result $ Left $
|
|
|
|
respErrorMessage "CHECKPRESENT" errmsg
|
2018-06-08 15:52:20 +00:00
|
|
|
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
|
2020-02-27 18:09:18 +00:00
|
|
|
warning $ respErrorMessage "REMOVE" 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
|
|
|
|
2019-03-11 16:44:12 +00:00
|
|
|
renameExportM :: External -> Key -> ExportLocation -> ExportLocation -> Annex (Maybe Bool)
|
|
|
|
renameExportM external k src dest = safely' (Just False) $
|
2017-09-08 18:24:05 +00:00
|
|
|
handleRequestExport external src req k Nothing $ \resp -> case resp of
|
|
|
|
RENAMEEXPORT_SUCCESS k'
|
2019-03-11 16:44:12 +00:00
|
|
|
| k' == k -> result (Just True)
|
2017-09-08 18:24:05 +00:00
|
|
|
RENAMEEXPORT_FAILURE k'
|
2019-03-11 16:44:12 +00:00
|
|
|
| k' == k -> result (Just False)
|
|
|
|
UNSUPPORTED_REQUEST -> result Nothing
|
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
|
2019-03-11 16:44:12 +00:00
|
|
|
safely = safely' False
|
|
|
|
|
|
|
|
safely' :: a -> Annex a -> Annex a
|
|
|
|
safely' onerr 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)
|
2019-03-11 16:44:12 +00:00
|
|
|
return onerr
|
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) =
|
2019-12-11 18:12:22 +00:00
|
|
|
send $ VALUE $ fromRawFilePath $ hashDirMixed def k
|
2016-05-03 17:36:59 +00:00
|
|
|
handleRemoteRequest (DIRHASH_LOWER k) =
|
2019-12-11 18:12:22 +00:00
|
|
|
send $ VALUE $ fromRawFilePath $ hashDirLower def k
|
2013-12-27 16:37:23 +00:00
|
|
|
handleRemoteRequest (SETCONFIG setting value) =
|
2020-01-15 17:01:22 +00:00
|
|
|
liftIO $ atomically $ do
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
modifyTVar' (externalConfig st) $ \(ParsedRemoteConfig m c) ->
|
|
|
|
let m' = M.insert
|
|
|
|
(Accepted setting)
|
|
|
|
(RemoteConfigValue (PassedThrough value))
|
|
|
|
m
|
|
|
|
in ParsedRemoteConfig m' c
|
2020-01-15 17:01:22 +00:00
|
|
|
modifyTVar' (externalConfigChanges st) $ \f ->
|
|
|
|
f . M.insert (Accepted setting) (Accepted value)
|
2013-12-27 16:37:23 +00:00
|
|
|
handleRemoteRequest (GETCONFIG setting) = do
|
2020-03-09 16:38:04 +00:00
|
|
|
value <- maybe "" fromProposedAccepted
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
. (M.lookup (Accepted setting))
|
2020-03-09 16:38:04 +00:00
|
|
|
. unparsedRemoteConfig
|
2016-09-30 23:51:16 +00:00
|
|
|
<$> liftIO (atomically $ readTVar $ externalConfig st)
|
2014-01-02 00:12:20 +00:00
|
|
|
send $ VALUE value
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
handleRemoteRequest (SETCREDS setting login password) = case (externalUUID external, externalGitConfig external) of
|
|
|
|
(Just u, Just gc) -> do
|
|
|
|
let v = externalConfig st
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
(ParsedRemoteConfig m c) <- liftIO $ atomically $ readTVar v
|
|
|
|
m' <- setRemoteCredPair' RemoteConfigValue (\m' -> ParsedRemoteConfig m' c) encryptionAlreadySetup m gc
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
(credstorage setting u)
|
|
|
|
(Just (login, password))
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
void $ liftIO $ atomically $ swapTVar v (ParsedRemoteConfig m' c)
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
_ -> senderror "cannot send SETCREDS here"
|
|
|
|
handleRemoteRequest (GETCREDS setting) = case (externalUUID external, externalGitConfig external) of
|
|
|
|
(Just u, Just gc) -> do
|
|
|
|
c <- liftIO $ atomically $ readTVar $ externalConfig st
|
|
|
|
creds <- fromMaybe ("", "") <$>
|
|
|
|
getRemoteCredPair c gc (credstorage setting u)
|
|
|
|
send $ CREDS (fst creds) (snd creds)
|
|
|
|
_ -> senderror "cannot send GETCREDS here"
|
|
|
|
handleRemoteRequest GETUUID = case externalUUID external of
|
|
|
|
Just u -> send $ VALUE $ fromUUID u
|
|
|
|
Nothing -> senderror "cannot send GETUUID here"
|
2019-12-09 17:49:05 +00:00
|
|
|
handleRemoteRequest GETGITDIR =
|
|
|
|
send . VALUE . fromRawFilePath =<< fromRepo Git.localGitDir
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
handleRemoteRequest (SETWANTED expr) = case externalUUID external of
|
|
|
|
Just u -> preferredContentSet u expr
|
|
|
|
Nothing -> senderror "cannot send SETWANTED here"
|
|
|
|
handleRemoteRequest GETWANTED = case externalUUID external of
|
|
|
|
Just u -> do
|
|
|
|
expr <- fromMaybe "" . M.lookup u
|
|
|
|
<$> preferredContentMapRaw
|
|
|
|
send $ VALUE expr
|
|
|
|
Nothing -> senderror "cannot send GETWANTED here"
|
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) =
|
add RemoteStateHandle
This solves the problem of sameas remotes trampling over per-remote
state. Used for:
* per-remote state, of course
* per-remote metadata, also of course
* per-remote content identifiers, because two remote implementations
could in theory generate the same content identifier for two different
peices of content
While chunk logs are per-remote data, they don't use this, because the
number and size of chunks stored is a common property across sameas
remotes.
External special remote had a complication, where it was theoretically
possible for a remote to send SETSTATE or GETSTATE during INITREMOTE or
EXPORTSUPPORTED. Since the uuid of the remote is typically generate in
Remote.setup, it would only be possible to pass a Maybe
RemoteStateHandle into it, and it would otherwise have to construct its
own. Rather than go that route, I decided to send an ERROR in this case.
It seems unlikely that any existing external special remote will be
affected. They would have to make up a git-annex key, and set state for
some reason during INITREMOTE. I can imagine such a hack, but it doesn't
seem worth complicating the code in such an ugly way to support it.
Unfortunately, both TestRemote and Annex.Import needed the Remote
to have a new field added that holds its RemoteStateHandle.
2019-10-14 16:33:27 +00:00
|
|
|
case externalRemoteStateHandle external of
|
|
|
|
Just h -> setRemoteState h key state
|
|
|
|
Nothing -> senderror "cannot send SETSTATE here"
|
|
|
|
handleRemoteRequest (GETSTATE key) =
|
|
|
|
case externalRemoteStateHandle external of
|
|
|
|
Just h -> do
|
|
|
|
state <- fromMaybe ""
|
|
|
|
<$> getRemoteState h key
|
|
|
|
send $ VALUE state
|
|
|
|
Nothing -> senderror "cannot send GETSTATE here"
|
2014-12-08 23:14:24 +00:00
|
|
|
handleRemoteRequest (SETURLPRESENT key url) =
|
2018-10-04 21:33:25 +00:00
|
|
|
setUrlPresent key url
|
2014-12-08 23:14:24 +00:00
|
|
|
handleRemoteRequest (SETURLMISSING key url) =
|
2018-10-04 21:33:25 +00:00
|
|
|
setUrlMissing 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
|
add RemoteStateHandle
This solves the problem of sameas remotes trampling over per-remote
state. Used for:
* per-remote state, of course
* per-remote metadata, also of course
* per-remote content identifiers, because two remote implementations
could in theory generate the same content identifier for two different
peices of content
While chunk logs are per-remote data, they don't use this, because the
number and size of chunks stored is a common property across sameas
remotes.
External special remote had a complication, where it was theoretically
possible for a remote to send SETSTATE or GETSTATE during INITREMOTE or
EXPORTSUPPORTED. Since the uuid of the remote is typically generate in
Remote.setup, it would only be possible to pass a Maybe
RemoteStateHandle into it, and it would otherwise have to construct its
own. Rather than go that route, I decided to send an ERROR in this case.
It seems unlikely that any existing external special remote will be
affected. They would have to make up a git-annex key, and set state for
some reason during INITREMOTE. I can imagine such a hack, but it doesn't
seem worth complicating the code in such an ugly way to support it.
Unfortunately, both TestRemote and Annex.Import needed the Remote
to have a new field added that holds its RemoteStateHandle.
2019-10-14 16:33:27 +00:00
|
|
|
handleRemoteRequest (VERSION _) = senderror "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
|
add RemoteStateHandle
This solves the problem of sameas remotes trampling over per-remote
state. Used for:
* per-remote state, of course
* per-remote metadata, also of course
* per-remote content identifiers, because two remote implementations
could in theory generate the same content identifier for two different
peices of content
While chunk logs are per-remote data, they don't use this, because the
number and size of chunks stored is a common property across sameas
remotes.
External special remote had a complication, where it was theoretically
possible for a remote to send SETSTATE or GETSTATE during INITREMOTE or
EXPORTSUPPORTED. Since the uuid of the remote is typically generate in
Remote.setup, it would only be possible to pass a Maybe
RemoteStateHandle into it, and it would otherwise have to construct its
own. Rather than go that route, I decided to send an ERROR in this case.
It seems unlikely that any existing external special remote will be
affected. They would have to make up a git-annex key, and set state for
some reason during INITREMOTE. I can imagine such a hack, but it doesn't
seem worth complicating the code in such an ugly way to support it.
Unfortunately, both TestRemote and Annex.Import needed the Remote
to have a new field added that holds its RemoteStateHandle.
2019-10-14 16:33:27 +00:00
|
|
|
senderror = sendMessage st external . ERROR
|
2014-01-02 00:12:20 +00:00
|
|
|
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
credstorage setting u = CredPairStorage
|
2013-12-27 20:01:43 +00:00
|
|
|
{ credPairFile = base
|
|
|
|
, credPairEnvironment = (base ++ "login", base ++ "password")
|
2020-01-10 18:10:20 +00:00
|
|
|
, credPairRemoteField = Accepted setting
|
2013-12-27 20:01:43 +00:00
|
|
|
}
|
|
|
|
where
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
base = replace "/" "_" $ fromUUID u ++ "-" ++ 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
|
2020-01-15 17:01:22 +00:00
|
|
|
ccv <- newTVarIO id
|
2016-09-30 23:51:16 +00:00
|
|
|
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
|
2020-01-15 17:01:22 +00:00
|
|
|
, externalConfigChanges = ccv
|
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
|
2020-04-23 18:56:03 +00:00
|
|
|
let err = "Cannot run " ++ basecmd ++ " -- It is not installed in PATH (" ++ path ++ ")"
|
|
|
|
case (lookupName (unparsedRemoteConfig (externalDefaultConfig external)), remoteAnnexReadOnly <$> externalGitConfig external) of
|
|
|
|
(Just rname, Just True) -> giveup $ unlines
|
|
|
|
[ err
|
|
|
|
, "This remote has annex-readonly=true, and previous versions of"
|
|
|
|
, "git-annex would tried to download from it without"
|
|
|
|
, "installing " ++ basecmd ++ ". If you want that, you need to set:"
|
|
|
|
, "git config remote." ++ rname ++ ".annex-externaltype readonly"
|
|
|
|
]
|
|
|
|
_ -> giveup err
|
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
|
2020-02-27 18:09:18 +00:00
|
|
|
let errmsg' = respErrorMessage "PREPARE" errmsg
|
|
|
|
setprepared $ FailedPrepare errmsg'
|
|
|
|
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
|
|
|
|
2020-02-27 18:09:18 +00:00
|
|
|
respErrorMessage :: String -> String -> String
|
|
|
|
respErrorMessage req err
|
|
|
|
| null err = req ++ " failed with no reason given"
|
|
|
|
| otherwise = 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
|
|
|
{- 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 $
|
2020-05-11 18:04:56 +00:00
|
|
|
if null f then Nothing else Just f
|
2018-06-08 15:52:20 +00:00
|
|
|
CHECKURL_MULTI l -> result $ UrlMulti $ map mkmulti l
|
2020-02-27 18:09:18 +00:00
|
|
|
CHECKURL_FAILURE errmsg -> Just $ giveup $
|
|
|
|
respErrorMessage "CHECKURL" errmsg
|
2016-11-16 01:29:54 +00:00
|
|
|
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
|
2020-05-11 18:04:56 +00:00
|
|
|
mkmulti (u, s, f) = (u, s, 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
|
2020-01-22 20:13:48 +00:00
|
|
|
unlessM (withUrlOptions $ 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
|
2019-11-22 20:24:04 +00:00
|
|
|
anyM (\u -> withUrlOptions $ checkBoth u (fromKey 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
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
|
|
|
|
{- All unknown configs are passed through in case the external program
|
|
|
|
- uses them. -}
|
|
|
|
lenientRemoteConfigParser :: RemoteConfigParser
|
2020-01-20 20:56:34 +00:00
|
|
|
lenientRemoteConfigParser =
|
|
|
|
addRemoteConfigParser specialRemoteConfigParsers baseRemoteConfigParser
|
|
|
|
|
|
|
|
baseRemoteConfigParser :: RemoteConfigParser
|
|
|
|
baseRemoteConfigParser = RemoteConfigParser
|
|
|
|
{ remoteConfigFieldParsers =
|
|
|
|
[ optionalStringParser externaltypeField
|
|
|
|
(FieldDesc "type of external special remote to use")
|
|
|
|
, trueFalseParser readonlyField False
|
|
|
|
(FieldDesc "enable readonly mode")
|
|
|
|
]
|
|
|
|
, remoteConfigRestPassthrough = Just
|
|
|
|
( const True
|
|
|
|
, [("*", FieldDesc "all other parameters are passed to external special remote program")]
|
|
|
|
)
|
|
|
|
}
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
|
|
|
|
{- When the remote supports LISTCONFIGS, only accept the ones it listed.
|
|
|
|
- When it does not, accept all configs. -}
|
|
|
|
strictRemoteConfigParser :: External -> Annex RemoteConfigParser
|
|
|
|
strictRemoteConfigParser external = listConfigs external >>= \case
|
|
|
|
Nothing -> return lenientRemoteConfigParser
|
|
|
|
Just l -> do
|
|
|
|
let s = S.fromList (map fst l)
|
|
|
|
let listed f = S.member (fromProposedAccepted f) s
|
|
|
|
return $ lenientRemoteConfigParser
|
2020-01-20 20:23:35 +00:00
|
|
|
{ remoteConfigRestPassthrough = Just (listed, l) }
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
|
2020-01-20 20:23:35 +00:00
|
|
|
listConfigs :: External -> Annex (Maybe [(Setting, FieldDesc)])
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
listConfigs external = handleRequest external LISTCONFIGS Nothing (collect [])
|
|
|
|
where
|
|
|
|
collect l req = case req of
|
|
|
|
CONFIG s d -> Just $ return $
|
2020-01-20 20:23:35 +00:00
|
|
|
GetNextMessage $ collect ((s, FieldDesc d) : l)
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
CONFIGEND -> result (Just (reverse l))
|
|
|
|
UNSUPPORTED_REQUEST -> result Nothing
|
|
|
|
_ -> Nothing
|
|
|
|
|
|
|
|
remoteConfigParser :: RemoteConfig -> Annex RemoteConfigParser
|
|
|
|
remoteConfigParser c
|
2020-01-17 21:23:19 +00:00
|
|
|
-- No need to start the external when there is no config to parse,
|
|
|
|
-- or when everything in the config was already accepted; in those
|
|
|
|
-- cases the lenient parser will do the same thing as the strict
|
|
|
|
-- parser.
|
|
|
|
| M.null (M.filter isproposed c) = return lenientRemoteConfigParser
|
2020-01-20 20:56:34 +00:00
|
|
|
| otherwise = case parseRemoteConfig c baseRemoteConfigParser of
|
add LISTCONFIGS to external special remote protocol
Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.
The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.
configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.
Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.
Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.
initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.
2020-01-17 19:30:14 +00:00
|
|
|
Left _ -> return lenientRemoteConfigParser
|
|
|
|
Right pc -> case (getRemoteConfigValue externaltypeField pc, getRemoteConfigValue readonlyField pc) of
|
|
|
|
(Nothing, _) -> return lenientRemoteConfigParser
|
|
|
|
(_, Just True) -> return lenientRemoteConfigParser
|
|
|
|
(Just externaltype, _) -> do
|
|
|
|
external <- newExternal externaltype Nothing pc Nothing Nothing
|
|
|
|
strictRemoteConfigParser external
|
2020-01-17 21:23:19 +00:00
|
|
|
where
|
|
|
|
isproposed (Accepted _) = False
|
|
|
|
isproposed (Proposed _) = True
|