2015-07-02 21:44:25 +00:00
|
|
|
{- git-annex command
|
|
|
|
-
|
|
|
|
- Copyright 2010, 2015 Joey Hess <joey@kitenet.net>
|
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Command.SetKey where
|
|
|
|
|
|
|
|
import Command
|
|
|
|
import Logs.Location
|
|
|
|
import Annex.Content
|
|
|
|
|
2015-07-08 16:33:27 +00:00
|
|
|
cmd :: Command
|
2015-07-08 19:08:02 +00:00
|
|
|
cmd = command "setkey" SectionPlumbing "sets annexed content for a key"
|
|
|
|
(paramPair paramKey paramPath)
|
|
|
|
(withParams seek)
|
2015-07-02 21:44:25 +00:00
|
|
|
|
2015-07-08 19:08:02 +00:00
|
|
|
seek :: CmdParams -> CommandSeek
|
2015-07-02 21:44:25 +00:00
|
|
|
seek = withWords start
|
|
|
|
|
|
|
|
start :: [String] -> CommandStart
|
|
|
|
start (keyname:file:[]) = do
|
|
|
|
showStart "setkey" file
|
|
|
|
next $ perform file (mkKey keyname)
|
|
|
|
start _ = error "specify a key and a content file"
|
|
|
|
|
|
|
|
mkKey :: String -> Key
|
|
|
|
mkKey = fromMaybe (error "bad key") . file2key
|
|
|
|
|
|
|
|
perform :: FilePath -> Key -> CommandPerform
|
|
|
|
perform file key = do
|
2015-07-07 18:48:23 +00:00
|
|
|
-- the file might be on a different filesystem, so moveFile is used
|
2015-07-02 21:44:25 +00:00
|
|
|
-- rather than simply calling moveAnnex; disk space is also
|
|
|
|
-- checked this way.
|
other 80% of avoding verification when hard linking to objects in shared repo
In c6632ee5c8e66c26ef18317f56ae02bae1e7e280, it actually only handled
uploading objects to a shared repository. To avoid verification when
downloading objects from a shared repository, was a lot harder.
On the plus side, if the process of downloading a file from a remote
is able to verify its content on the side, the remote can indicate this
now, and avoid the extra post-download verification.
As of yet, I don't have any remotes (except Git) using this ability.
Some more work would be needed to support it in special remotes.
It would make sense for tahoe to implicitly verify things downloaded from it;
as long as you trust your tahoe server (which typically runs locally),
there's cryptographic integrity. OTOH, despite bup being based on shas,
a bup repo under an attacker's control could have the git ref used for an
object changed, and so a bup repo shouldn't implicitly verify. Indeed,
tahoe seems unique in being trustworthy enough to implicitly verify.
2015-10-02 17:56:42 +00:00
|
|
|
ok <- getViaTmp DefaultVerify key $ \dest -> unVerified $
|
2015-07-02 21:44:25 +00:00
|
|
|
if dest /= file
|
2015-07-07 18:48:23 +00:00
|
|
|
then liftIO $ catchBoolIO $ do
|
|
|
|
moveFile file dest
|
|
|
|
return True
|
2015-07-02 21:44:25 +00:00
|
|
|
else return True
|
|
|
|
if ok
|
|
|
|
then next $ cleanup key
|
|
|
|
else error "mv failed!"
|
|
|
|
|
|
|
|
cleanup :: Key -> CommandCleanup
|
|
|
|
cleanup key = do
|
|
|
|
logStatus key InfoPresent
|
|
|
|
return True
|