2012-02-16 20:36:35 +00:00
|
|
|
{- git-annex command
|
|
|
|
-
|
2015-01-21 16:50:09 +00:00
|
|
|
- Copyright 2012 Joey Hess <id@joeyh.name>
|
2012-02-16 20:36:35 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Command.ReKey where
|
|
|
|
|
|
|
|
import Common.Annex
|
|
|
|
import Command
|
|
|
|
import qualified Annex
|
|
|
|
import Types.Key
|
|
|
|
import Annex.Content
|
2012-02-17 02:36:56 +00:00
|
|
|
import qualified Command.Add
|
|
|
|
import Logs.Web
|
2013-04-11 17:35:52 +00:00
|
|
|
import Logs.Location
|
2013-02-15 17:51:50 +00:00
|
|
|
import Utility.CopyFile
|
2014-12-08 23:14:24 +00:00
|
|
|
import qualified Remote
|
2012-02-16 20:36:35 +00:00
|
|
|
|
2015-07-08 16:33:27 +00:00
|
|
|
cmd :: Command
|
2015-07-08 19:08:02 +00:00
|
|
|
cmd = notDirect $
|
|
|
|
command "rekey" SectionPlumbing
|
|
|
|
"change keys used for files"
|
|
|
|
(paramRepeating $ paramPair paramPath paramKey)
|
|
|
|
(withParams seek)
|
2012-02-16 20:36:35 +00:00
|
|
|
|
2015-07-08 19:08:02 +00:00
|
|
|
seek :: CmdParams -> CommandSeek
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
seek = withPairs start
|
2012-02-16 20:36:35 +00:00
|
|
|
|
|
|
|
start :: (FilePath, String) -> CommandStart
|
|
|
|
start (file, keyname) = ifAnnexed file go stop
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
|
|
|
newkey = fromMaybe (error "bad key") $ file2key keyname
|
2014-04-17 22:03:39 +00:00
|
|
|
go oldkey
|
2012-11-12 05:05:04 +00:00
|
|
|
| oldkey == newkey = stop
|
|
|
|
| otherwise = do
|
|
|
|
showStart "rekey" file
|
|
|
|
next $ perform file oldkey newkey
|
2012-02-16 20:36:35 +00:00
|
|
|
|
|
|
|
perform :: FilePath -> Key -> Key -> CommandPerform
|
|
|
|
perform file oldkey newkey = do
|
|
|
|
present <- inAnnex oldkey
|
|
|
|
_ <- if present
|
2012-02-17 02:36:56 +00:00
|
|
|
then linkKey oldkey newkey
|
2012-02-16 20:36:35 +00:00
|
|
|
else do
|
|
|
|
unlessM (Annex.getState Annex.force) $
|
|
|
|
error $ file ++ " is not available (use --force to override)"
|
|
|
|
return True
|
2012-02-17 02:36:56 +00:00
|
|
|
next $ cleanup file oldkey newkey
|
|
|
|
|
2013-06-10 17:10:30 +00:00
|
|
|
{- Make a hard link to the old key content (when supported),
|
|
|
|
- to avoid wasting disk space. -}
|
2012-02-17 02:36:56 +00:00
|
|
|
linkKey :: Key -> Key -> Annex Bool
|
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
|
|
|
linkKey oldkey newkey = getViaTmp' DefaultVerify newkey $ \tmp -> unVerified $ do
|
2013-04-04 19:46:33 +00:00
|
|
|
src <- calcRepo $ gitAnnexLocation oldkey
|
2013-06-10 17:10:30 +00:00
|
|
|
liftIO $ ifM (doesFileExist tmp)
|
2013-02-15 17:51:50 +00:00
|
|
|
( return True
|
2013-06-10 17:10:30 +00:00
|
|
|
, createLinkOrCopy src tmp
|
2013-02-15 17:51:50 +00:00
|
|
|
)
|
2012-02-17 02:36:56 +00:00
|
|
|
|
|
|
|
cleanup :: FilePath -> Key -> Key -> CommandCleanup
|
|
|
|
cleanup file oldkey newkey = do
|
|
|
|
-- If the old key had some associated urls, record them for
|
|
|
|
-- the new key as well.
|
|
|
|
urls <- getUrls oldkey
|
2014-12-08 23:14:24 +00:00
|
|
|
forM_ urls $ \url -> do
|
2014-12-11 18:09:57 +00:00
|
|
|
r <- Remote.claimingUrl url
|
2014-12-08 23:14:24 +00:00
|
|
|
setUrlPresent (Remote.uuid r) newkey url
|
2012-02-17 02:36:56 +00:00
|
|
|
|
2012-02-17 02:38:08 +00:00
|
|
|
-- Update symlink to use the new key.
|
|
|
|
liftIO $ removeFile file
|
2013-09-25 20:07:11 +00:00
|
|
|
Command.Add.addLink file newkey Nothing
|
2013-04-11 17:35:52 +00:00
|
|
|
logStatus newkey InfoPresent
|
|
|
|
return True
|