2015-12-22 17:23:33 +00:00
|
|
|
{- git-annex content ingestion
|
|
|
|
-
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
- Copyright 2010-2020 Joey Hess <id@joeyh.name>
|
2015-12-22 17:23:33 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2015-12-22 17:23:33 +00:00
|
|
|
-}
|
|
|
|
|
|
|
|
module Annex.Ingest (
|
2015-12-22 19:23:27 +00:00
|
|
|
LockedDown(..),
|
2016-01-07 21:39:59 +00:00
|
|
|
LockDownConfig(..),
|
2015-12-22 17:23:33 +00:00
|
|
|
lockDown,
|
2016-02-16 18:43:43 +00:00
|
|
|
ingestAdd,
|
2017-02-09 19:32:22 +00:00
|
|
|
ingestAdd',
|
2015-12-22 17:23:33 +00:00
|
|
|
ingest,
|
2016-06-09 19:17:08 +00:00
|
|
|
ingest',
|
2015-12-22 20:22:28 +00:00
|
|
|
finishIngestUnlocked,
|
2015-12-22 20:55:49 +00:00
|
|
|
cleanOldKeys,
|
2015-12-22 17:23:33 +00:00
|
|
|
addLink,
|
|
|
|
makeLink,
|
2016-02-16 18:43:43 +00:00
|
|
|
addUnlocked,
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
CheckGitIgnore(..),
|
|
|
|
gitAddParams,
|
2016-02-16 18:43:43 +00:00
|
|
|
addAnnexedFile,
|
2020-11-10 16:10:51 +00:00
|
|
|
addingExistingLink,
|
2015-12-22 17:23:33 +00:00
|
|
|
) where
|
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2015-12-22 17:23:33 +00:00
|
|
|
import Types.KeySource
|
2019-12-20 19:01:34 +00:00
|
|
|
import Types.FileMatcher
|
2015-12-22 17:23:33 +00:00
|
|
|
import Backend
|
|
|
|
import Annex.Content
|
|
|
|
import Annex.Perms
|
|
|
|
import Annex.Link
|
|
|
|
import Annex.MetaData
|
2018-10-19 19:17:48 +00:00
|
|
|
import Annex.CurrentBranch
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
import Annex.CheckIgnore
|
2015-12-22 20:55:49 +00:00
|
|
|
import Logs.Location
|
2015-12-22 17:23:33 +00:00
|
|
|
import qualified Annex
|
|
|
|
import qualified Annex.Queue
|
2015-12-22 20:22:28 +00:00
|
|
|
import qualified Database.Keys
|
2015-12-22 17:23:33 +00:00
|
|
|
import Config
|
|
|
|
import Utility.InodeCache
|
|
|
|
import Annex.ReplaceFile
|
|
|
|
import Utility.Tmp
|
|
|
|
import Utility.CopyFile
|
2016-02-15 15:47:33 +00:00
|
|
|
import Utility.Touch
|
2019-06-25 15:37:52 +00:00
|
|
|
import Utility.Metered
|
2016-01-05 21:22:19 +00:00
|
|
|
import Git.FilePath
|
2015-12-22 17:23:33 +00:00
|
|
|
import Annex.InodeSentinal
|
2016-03-29 17:26:06 +00:00
|
|
|
import Annex.AdjustedBranch
|
2019-12-20 19:01:34 +00:00
|
|
|
import Annex.FileMatcher
|
2020-11-24 16:38:12 +00:00
|
|
|
import qualified Utility.RawFilePath as R
|
2015-12-22 17:23:33 +00:00
|
|
|
|
|
|
|
import Control.Exception (IOException)
|
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
data LockedDown = LockedDown
|
2016-01-07 21:39:59 +00:00
|
|
|
{ lockDownConfig :: LockDownConfig
|
2015-12-22 19:23:27 +00:00
|
|
|
, keySource :: KeySource
|
|
|
|
}
|
|
|
|
deriving (Show)
|
|
|
|
|
2016-01-07 21:39:59 +00:00
|
|
|
data LockDownConfig = LockDownConfig
|
2019-05-07 17:04:39 +00:00
|
|
|
{ lockingFile :: Bool
|
|
|
|
-- ^ write bit removed during lock down
|
2020-11-03 14:11:04 +00:00
|
|
|
, hardlinkFileTmpDir :: Maybe RawFilePath
|
2019-05-07 17:04:39 +00:00
|
|
|
-- ^ hard link to temp directory
|
2016-01-07 21:39:59 +00:00
|
|
|
}
|
|
|
|
deriving (Show)
|
|
|
|
|
2015-12-22 17:23:33 +00:00
|
|
|
{- The file that's being ingested is locked down before a key is generated,
|
|
|
|
- to prevent it from being modified in between. This lock down is not
|
|
|
|
- perfect at best (and pretty weak at worst). For example, it does not
|
|
|
|
- guard against files that are already opened for write by another process.
|
2015-12-22 19:23:27 +00:00
|
|
|
- So, the InodeCache can be used to detect any changes that might be made
|
|
|
|
- to the file after it was locked down.
|
2015-12-22 17:23:33 +00:00
|
|
|
-
|
|
|
|
- When possible, the file is hard linked to a temp directory. This guards
|
|
|
|
- against some changes, like deletion or overwrite of the file, and
|
|
|
|
- allows lsof checks to be done more efficiently when adding a lot of files.
|
|
|
|
-
|
|
|
|
- Lockdown can fail if a file gets deleted, and Nothing will be returned.
|
|
|
|
-}
|
2016-01-07 21:39:59 +00:00
|
|
|
lockDown :: LockDownConfig -> FilePath -> Annex (Maybe LockedDown)
|
|
|
|
lockDown cfg file = either
|
2015-12-22 17:23:33 +00:00
|
|
|
(\e -> warning (show e) >> return Nothing)
|
|
|
|
(return . Just)
|
2016-01-07 21:39:59 +00:00
|
|
|
=<< lockDown' cfg file
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2016-01-07 21:39:59 +00:00
|
|
|
lockDown' :: LockDownConfig -> FilePath -> Annex (Either IOException LockedDown)
|
2019-05-07 17:04:39 +00:00
|
|
|
lockDown' cfg file = tryIO $ ifM crippledFileSystem
|
|
|
|
( nohardlink
|
|
|
|
, case hardlinkFileTmpDir cfg of
|
|
|
|
Nothing -> nohardlink
|
|
|
|
Just tmpdir -> withhardlink tmpdir
|
2015-12-22 19:23:27 +00:00
|
|
|
)
|
|
|
|
where
|
2020-02-21 13:34:59 +00:00
|
|
|
file' = toRawFilePath file
|
|
|
|
|
2019-05-07 17:04:39 +00:00
|
|
|
nohardlink = withTSDelta $ liftIO . nohardlink'
|
|
|
|
|
|
|
|
nohardlink' delta = do
|
2020-11-04 18:20:37 +00:00
|
|
|
cache <- genInodeCache file' delta
|
2016-01-07 21:39:59 +00:00
|
|
|
return $ LockedDown cfg $ KeySource
|
2020-02-21 13:34:59 +00:00
|
|
|
{ keyFilename = file'
|
|
|
|
, contentLocation = file'
|
2015-12-22 17:23:33 +00:00
|
|
|
, inodeCache = cache
|
|
|
|
}
|
2019-05-07 17:04:39 +00:00
|
|
|
|
|
|
|
withhardlink tmpdir = do
|
|
|
|
when (lockingFile cfg) $
|
2020-11-06 18:10:58 +00:00
|
|
|
freezeContent file'
|
2019-05-07 17:04:39 +00:00
|
|
|
withTSDelta $ \delta -> liftIO $ do
|
2020-11-03 14:11:04 +00:00
|
|
|
(tmpfile, h) <- openTempFile (fromRawFilePath tmpdir) $
|
2019-05-07 17:04:39 +00:00
|
|
|
relatedTemplate $ "ingest-" ++ takeFileName file
|
|
|
|
hClose h
|
2020-11-24 16:38:12 +00:00
|
|
|
removeWhenExistsWith R.removeLink (toRawFilePath tmpfile)
|
2019-05-07 17:04:39 +00:00
|
|
|
withhardlink' delta tmpfile
|
|
|
|
`catchIO` const (nohardlink' delta)
|
|
|
|
|
|
|
|
withhardlink' delta tmpfile = do
|
2015-12-22 17:23:33 +00:00
|
|
|
createLink file tmpfile
|
2019-12-11 18:12:22 +00:00
|
|
|
cache <- genInodeCache (toRawFilePath tmpfile) delta
|
2016-01-07 21:39:59 +00:00
|
|
|
return $ LockedDown cfg $ KeySource
|
2020-02-21 13:34:59 +00:00
|
|
|
{ keyFilename = file'
|
|
|
|
, contentLocation = toRawFilePath tmpfile
|
2015-12-22 17:23:33 +00:00
|
|
|
, inodeCache = cache
|
|
|
|
}
|
|
|
|
|
2016-02-16 18:43:43 +00:00
|
|
|
{- Ingests a locked down file into the annex. Updates the work tree and
|
|
|
|
- index. -}
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
ingestAdd :: CheckGitIgnore -> MeterUpdate -> Maybe LockedDown -> Annex (Maybe Key)
|
|
|
|
ingestAdd ci meterupdate ld = ingestAdd' ci meterupdate ld Nothing
|
2017-02-09 19:32:22 +00:00
|
|
|
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
ingestAdd' :: CheckGitIgnore -> MeterUpdate -> Maybe LockedDown -> Maybe Key -> Annex (Maybe Key)
|
|
|
|
ingestAdd' _ _ Nothing _ = return Nothing
|
|
|
|
ingestAdd' ci meterupdate ld@(Just (LockedDown cfg source)) mk = do
|
2019-06-25 15:37:52 +00:00
|
|
|
(mk', mic) <- ingest meterupdate ld mk
|
2017-02-09 19:32:22 +00:00
|
|
|
case mk' of
|
2016-02-16 18:43:43 +00:00
|
|
|
Nothing -> return Nothing
|
|
|
|
Just k -> do
|
|
|
|
let f = keyFilename source
|
|
|
|
if lockingFile cfg
|
2020-11-03 14:11:04 +00:00
|
|
|
then addLink ci f k mic
|
2019-08-26 19:52:19 +00:00
|
|
|
else do
|
2020-02-21 13:34:59 +00:00
|
|
|
mode <- liftIO $ catchMaybeIO $
|
|
|
|
fileMode <$> R.getFileStatus (contentLocation source)
|
|
|
|
stagePointerFile f mode =<< hashPointerFile k
|
2016-02-16 18:43:43 +00:00
|
|
|
return (Just k)
|
|
|
|
|
|
|
|
{- Ingests a locked down file into the annex. Does not update the working
|
2018-08-14 18:22:23 +00:00
|
|
|
- tree or the index. -}
|
2019-06-25 15:37:52 +00:00
|
|
|
ingest :: MeterUpdate -> Maybe LockedDown -> Maybe Key -> Annex (Maybe Key, Maybe InodeCache)
|
|
|
|
ingest meterupdate ld mk = ingest' Nothing meterupdate ld mk (Restage True)
|
2016-06-09 19:17:08 +00:00
|
|
|
|
2019-06-25 15:37:52 +00:00
|
|
|
ingest' :: Maybe Backend -> MeterUpdate -> Maybe LockedDown -> Maybe Key -> Restage -> Annex (Maybe Key, Maybe InodeCache)
|
|
|
|
ingest' _ _ Nothing _ _ = return (Nothing, Nothing)
|
|
|
|
ingest' preferredbackend meterupdate (Just (LockedDown cfg source)) mk restage = withTSDelta $ \delta -> do
|
2017-02-09 19:32:22 +00:00
|
|
|
k <- case mk of
|
|
|
|
Nothing -> do
|
2020-02-21 13:34:59 +00:00
|
|
|
backend <- maybe
|
2020-10-30 19:55:59 +00:00
|
|
|
(chooseBackend $ keyFilename source)
|
2020-02-21 13:34:59 +00:00
|
|
|
(return . Just)
|
|
|
|
preferredbackend
|
2020-05-15 16:51:09 +00:00
|
|
|
fst <$> genKey source meterupdate backend
|
|
|
|
Just k -> return k
|
2015-12-22 17:23:33 +00:00
|
|
|
let src = contentLocation source
|
2020-02-21 13:34:59 +00:00
|
|
|
ms <- liftIO $ catchMaybeIO $ R.getFileStatus src
|
2020-11-05 15:26:34 +00:00
|
|
|
mcache <- maybe (pure Nothing) (liftIO . toInodeCache delta src) ms
|
2015-12-22 17:23:33 +00:00
|
|
|
case (mcache, inodeCache source) of
|
|
|
|
(_, Nothing) -> go k mcache ms
|
|
|
|
(Just newc, Just c) | compareStrong c newc -> go k mcache ms
|
|
|
|
_ -> failure "changed while it was being added"
|
|
|
|
where
|
2020-05-15 16:51:09 +00:00
|
|
|
go key mcache (Just s)
|
2016-01-07 21:39:59 +00:00
|
|
|
| lockingFile cfg = golocked key mcache s
|
2019-08-26 19:52:19 +00:00
|
|
|
| otherwise = gounlocked key mcache s
|
2020-05-15 18:31:50 +00:00
|
|
|
go _ _ Nothing = failure "failed to generate a key"
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2017-11-15 20:55:38 +00:00
|
|
|
golocked key mcache s =
|
2020-11-16 18:09:55 +00:00
|
|
|
tryNonAsync (moveAnnex key naf (contentLocation source)) >>= \case
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
Right True -> do
|
2018-08-14 18:22:23 +00:00
|
|
|
populateAssociatedFiles key source restage
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
success key mcache s
|
|
|
|
Right False -> giveup "failed to add content to annex"
|
2020-11-06 18:10:58 +00:00
|
|
|
Left e -> restoreFile (keyFilename source) key e
|
2015-12-22 19:23:27 +00:00
|
|
|
|
2020-11-16 18:09:55 +00:00
|
|
|
-- moveAnnex uses the AssociatedFile provided to it to unlock
|
|
|
|
-- locked files when getting a file in an adjusted branch.
|
|
|
|
-- That case does not apply here, where we're adding an unlocked
|
|
|
|
-- file, so provide it nothing.
|
|
|
|
naf = AssociatedFile Nothing
|
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
gounlocked key (Just cache) s = do
|
2015-12-22 20:22:28 +00:00
|
|
|
-- Remove temp directory hard link first because
|
2015-12-27 19:59:59 +00:00
|
|
|
-- linkToAnnex falls back to copying if a file
|
2015-12-22 20:22:28 +00:00
|
|
|
-- already has a hard link.
|
|
|
|
cleanCruft source
|
2015-12-22 20:55:49 +00:00
|
|
|
cleanOldKeys (keyFilename source) key
|
2020-10-30 19:55:59 +00:00
|
|
|
linkToAnnex key (keyFilename source) (Just cache) >>= \case
|
2015-12-22 19:23:27 +00:00
|
|
|
LinkAnnexFailed -> failure "failed to link to annex"
|
2015-12-22 20:22:28 +00:00
|
|
|
_ -> do
|
2018-08-14 18:22:23 +00:00
|
|
|
finishIngestUnlocked' key source restage
|
2015-12-22 20:22:28 +00:00
|
|
|
success key (Just cache) s
|
2015-12-22 19:23:27 +00:00
|
|
|
gounlocked _ _ _ = failure "failed statting file"
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
success k mcache s = do
|
2020-02-21 13:34:59 +00:00
|
|
|
genMetaData k (keyFilename source) s
|
2015-12-22 19:23:27 +00:00
|
|
|
return (Just k, mcache)
|
2015-12-22 17:23:33 +00:00
|
|
|
|
|
|
|
failure msg = do
|
2020-02-21 13:34:59 +00:00
|
|
|
warning $ fromRawFilePath (keyFilename source) ++ " " ++ msg
|
2015-12-22 19:23:27 +00:00
|
|
|
cleanCruft source
|
2015-12-22 17:23:33 +00:00
|
|
|
return (Nothing, Nothing)
|
|
|
|
|
2015-12-22 20:22:28 +00:00
|
|
|
finishIngestUnlocked :: Key -> KeySource -> Annex ()
|
|
|
|
finishIngestUnlocked key source = do
|
2015-12-22 22:03:47 +00:00
|
|
|
cleanCruft source
|
2018-08-14 18:22:23 +00:00
|
|
|
finishIngestUnlocked' key source (Restage True)
|
2015-12-22 22:03:47 +00:00
|
|
|
|
2018-08-14 18:22:23 +00:00
|
|
|
finishIngestUnlocked' :: Key -> KeySource -> Restage -> Annex ()
|
|
|
|
finishIngestUnlocked' key source restage = do
|
2019-12-09 17:49:05 +00:00
|
|
|
Database.Keys.addAssociatedFile key
|
2020-02-21 13:34:59 +00:00
|
|
|
=<< inRepo (toTopFilePath (keyFilename source))
|
2018-08-14 18:22:23 +00:00
|
|
|
populateAssociatedFiles key source restage
|
2015-12-22 20:22:28 +00:00
|
|
|
|
|
|
|
{- Copy to any other locations using the same key. -}
|
2018-08-14 18:22:23 +00:00
|
|
|
populateAssociatedFiles :: Key -> KeySource -> Restage -> Annex ()
|
|
|
|
populateAssociatedFiles key source restage = do
|
2019-12-11 18:12:22 +00:00
|
|
|
obj <- calcRepo (gitAnnexLocation key)
|
2016-01-05 21:22:19 +00:00
|
|
|
g <- Annex.gitRepo
|
|
|
|
ingestedf <- flip fromTopFilePath g
|
2020-02-21 13:34:59 +00:00
|
|
|
<$> inRepo (toTopFilePath (keyFilename source))
|
2016-01-05 21:22:19 +00:00
|
|
|
afs <- map (`fromTopFilePath` g) <$> Database.Keys.getAssociatedFiles key
|
|
|
|
forM_ (filter (/= ingestedf) afs) $
|
2019-12-09 17:49:05 +00:00
|
|
|
populatePointerFile restage key obj
|
2015-12-22 20:22:28 +00:00
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
cleanCruft :: KeySource -> Annex ()
|
|
|
|
cleanCruft source = when (contentLocation source /= keyFilename source) $
|
2020-10-29 14:33:12 +00:00
|
|
|
liftIO $ removeWhenExistsWith R.removeLink $ contentLocation source
|
2015-12-22 19:23:27 +00:00
|
|
|
|
2015-12-22 20:55:49 +00:00
|
|
|
-- If a worktree file was was hard linked to an annex object before,
|
|
|
|
-- modifying the file would have caused the object to have the wrong
|
|
|
|
-- content. Clean up from that.
|
2020-02-21 13:34:59 +00:00
|
|
|
cleanOldKeys :: RawFilePath -> Key -> Annex ()
|
2015-12-22 20:55:49 +00:00
|
|
|
cleanOldKeys file newkey = do
|
2016-01-05 21:22:19 +00:00
|
|
|
g <- Annex.gitRepo
|
2020-02-21 13:34:59 +00:00
|
|
|
topf <- inRepo (toTopFilePath file)
|
2019-12-09 17:49:05 +00:00
|
|
|
ingestedf <- fromRepo $ fromTopFilePath topf
|
2015-12-22 20:55:49 +00:00
|
|
|
oldkeys <- filter (/= newkey)
|
2016-01-05 21:22:19 +00:00
|
|
|
<$> Database.Keys.getAssociatedKey topf
|
lock: Fix edge cases where data loss could occur in v6 mode.
In the case where the pointer file is in place, and not the content
of the object, lock's performNew was called with filemodified=True,
which caused it to try to repopulate the object from an unmodified
associated file, of which there were none. So, the content of the object
got thrown away incorrectly. This was the cause (although not the root
cause) of data loss in https://github.com/datalad/datalad/issues/1020
The same problem could also occur when the work tree file is modified,
but the object is not, and lock is called with --force. Added a test case
for this, since it's excercising the same code path and is easier to set up
than the problem above.
Note that this only occurred when the keys database did not have an inode
cache recorded for the annex object. Normally, the annex object would be in
there, but there are of course circumstances where the inode cache is out
of sync with reality, since it's only a cache.
Fixed by checking if the object is unmodified; if so we don't need to
try to repopulate it. This does add an additional checksum to the unlock
path, but it's already checksumming the worktree file in another case,
so it doesn't slow it down overall.
Further investigation found a similar problem occurred when smudge --clean
is called on a file and the inode cache is not populated. cleanOldKeys
deleted the unmodified old object file in this case. This was also
fixed by checking if the object is unmodified.
In general, use of getInodeCaches and sameInodeCache is potentially
dangerous if the inode cache has not gotten populated for some reason.
Better to use isUnmodified. I breifly auited other places that check the
inode cache, and did not see any immediate problems, but it would be easy
to miss this kind of problem.
2016-10-17 16:56:26 +00:00
|
|
|
forM_ oldkeys $ \key ->
|
|
|
|
unlessM (isUnmodified key =<< calcRepo (gitAnnexLocation key)) $ do
|
|
|
|
caches <- Database.Keys.getInodeCaches key
|
2015-12-22 20:55:49 +00:00
|
|
|
unlinkAnnex key
|
2019-12-11 18:12:22 +00:00
|
|
|
fs <- filter (/= ingestedf)
|
2016-01-05 21:22:19 +00:00
|
|
|
. map (`fromTopFilePath` g)
|
2015-12-22 20:55:49 +00:00
|
|
|
<$> Database.Keys.getAssociatedFiles key
|
2017-11-15 20:55:38 +00:00
|
|
|
filterM (`sameInodeCache` caches) fs >>= \case
|
2015-12-27 19:59:59 +00:00
|
|
|
-- If linkToAnnex fails, the associated
|
2015-12-22 20:55:49 +00:00
|
|
|
-- file with the content is still present,
|
|
|
|
-- so no need for any recovery.
|
|
|
|
(f:_) -> do
|
|
|
|
ic <- withTSDelta (liftIO . genInodeCache f)
|
2020-10-30 19:55:59 +00:00
|
|
|
void $ linkToAnnex key f ic
|
2016-01-05 21:22:19 +00:00
|
|
|
_ -> logStatus key InfoMissing
|
2015-12-22 20:55:49 +00:00
|
|
|
|
2015-12-22 17:23:33 +00:00
|
|
|
{- On error, put the file back so it doesn't seem to have vanished.
|
|
|
|
- This can be called before or after the symlink is in place. -}
|
2020-11-06 18:10:58 +00:00
|
|
|
restoreFile :: RawFilePath -> Key -> SomeException -> Annex a
|
2015-12-22 17:23:33 +00:00
|
|
|
restoreFile file key e = do
|
|
|
|
whenM (inAnnex key) $ do
|
2020-11-06 18:10:58 +00:00
|
|
|
liftIO $ removeWhenExistsWith R.removeLink file
|
2015-12-22 17:23:33 +00:00
|
|
|
-- The key could be used by other files too, so leave the
|
|
|
|
-- content in the annex, and make a copy back to the file.
|
2019-12-11 18:12:22 +00:00
|
|
|
obj <- fromRawFilePath <$> calcRepo (gitAnnexLocation key)
|
2020-11-06 18:10:58 +00:00
|
|
|
unlessM (liftIO $ copyFileExternal CopyTimeStamps obj (fromRawFilePath file)) $
|
|
|
|
warning $ "Unable to restore content of " ++ fromRawFilePath file ++ "; it should be located in " ++ obj
|
2015-12-22 17:23:33 +00:00
|
|
|
thawContent file
|
|
|
|
throwM e
|
|
|
|
|
|
|
|
{- Creates the symlink to the annexed content, returns the link target. -}
|
2020-11-03 14:11:04 +00:00
|
|
|
makeLink :: RawFilePath -> Key -> Maybe InodeCache -> Annex LinkTarget
|
2020-11-06 18:10:58 +00:00
|
|
|
makeLink file key mcache = flip catchNonAsync (restoreFile file key) $ do
|
2020-11-03 14:11:04 +00:00
|
|
|
l <- calcRepo $ gitAnnexLink file key
|
|
|
|
replaceWorkTreeFile file' $ makeAnnexLink l . toRawFilePath
|
2015-12-22 17:23:33 +00:00
|
|
|
|
|
|
|
-- touch symlink to have same time as the original file,
|
|
|
|
-- as provided in the InodeCache
|
|
|
|
case mcache of
|
2018-10-30 02:22:36 +00:00
|
|
|
Just c -> liftIO $ touch file (inodeCacheToMtime c) False
|
2015-12-22 17:23:33 +00:00
|
|
|
Nothing -> noop
|
|
|
|
|
|
|
|
return l
|
2020-11-03 14:11:04 +00:00
|
|
|
where
|
|
|
|
file' = fromRawFilePath file
|
2015-12-22 17:23:33 +00:00
|
|
|
|
|
|
|
{- Creates the symlink to the annexed content, and stages it in git.
|
|
|
|
-
|
|
|
|
- As long as the filesystem supports symlinks, we use
|
|
|
|
- git add, rather than directly staging the symlink to git.
|
|
|
|
- Using git add is best because it allows the queuing to work
|
|
|
|
- and is faster (staging the symlink runs hash-object commands each time).
|
|
|
|
- Also, using git add allows it to skip gitignored files, unless forced
|
|
|
|
- to include them.
|
|
|
|
-}
|
2020-11-03 14:11:04 +00:00
|
|
|
addLink :: CheckGitIgnore -> RawFilePath -> Key -> Maybe InodeCache -> Annex ()
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
addLink ci file key mcache = ifM (coreSymlinks <$> Annex.getGitConfig)
|
2015-12-22 17:23:33 +00:00
|
|
|
( do
|
|
|
|
_ <- makeLink file key mcache
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
ps <- gitAddParams ci
|
2020-11-03 14:11:04 +00:00
|
|
|
Annex.Queue.addCommand "add" (ps++[Param "--"]) [fromRawFilePath file]
|
2015-12-22 17:23:33 +00:00
|
|
|
, do
|
|
|
|
l <- makeLink file key mcache
|
2020-11-03 14:11:04 +00:00
|
|
|
addAnnexLink l file
|
2015-12-22 17:23:33 +00:00
|
|
|
)
|
|
|
|
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
{- Parameters to pass to git add, forcing addition of ignored files.
|
|
|
|
-
|
|
|
|
- Note that, when git add is being run on an ignored file that is already
|
|
|
|
- checked in, CheckGitIgnore True has no effect.
|
|
|
|
-}
|
|
|
|
gitAddParams :: CheckGitIgnore -> Annex [CommandParam]
|
|
|
|
gitAddParams (CheckGitIgnore True) = ifM (Annex.getState Annex.force)
|
2015-12-22 17:23:33 +00:00
|
|
|
( return [Param "-f"]
|
|
|
|
, return []
|
|
|
|
)
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
gitAddParams (CheckGitIgnore False) = return [Param "-f"]
|
2016-02-16 18:43:43 +00:00
|
|
|
|
|
|
|
{- Whether a file should be added unlocked or not. Default is to not,
|
2016-03-29 17:26:06 +00:00
|
|
|
- unless symlinks are not supported. annex.addunlocked can override that.
|
|
|
|
- Also, when in an adjusted unlocked branch, always add files unlocked.
|
|
|
|
-}
|
2019-12-20 19:01:34 +00:00
|
|
|
addUnlocked :: AddUnlockedMatcher -> MatchInfo -> Annex Bool
|
|
|
|
addUnlocked matcher mi =
|
2019-08-30 17:54:57 +00:00
|
|
|
((not . coreSymlinks <$> Annex.getGitConfig) <||>
|
2019-12-20 19:01:34 +00:00
|
|
|
(checkAddUnlockedMatcher matcher mi) <||>
|
2019-08-30 17:54:57 +00:00
|
|
|
(maybe False isadjustedunlocked . snd <$> getCurrentBranch)
|
2016-02-16 18:43:43 +00:00
|
|
|
)
|
2018-10-18 16:51:20 +00:00
|
|
|
where
|
2018-10-19 19:17:48 +00:00
|
|
|
isadjustedunlocked (LinkAdjustment UnlockAdjustment) = True
|
|
|
|
isadjustedunlocked (PresenceAdjustment _ (Just UnlockAdjustment)) = True
|
2018-10-18 16:51:20 +00:00
|
|
|
isadjustedunlocked _ = False
|
2016-02-16 18:43:43 +00:00
|
|
|
|
|
|
|
{- Adds a file to the work tree for the key, and stages it in the index.
|
|
|
|
- The content of the key may be provided in a temp file, which will be
|
2019-12-20 19:01:34 +00:00
|
|
|
- moved into place. If no content is provided, adds an annex link but does
|
|
|
|
- not ingest the content.
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
-
|
|
|
|
- When the content of the key is not accepted into the annex, returns False.
|
|
|
|
-}
|
2020-11-03 14:11:04 +00:00
|
|
|
addAnnexedFile :: CheckGitIgnore -> AddUnlockedMatcher -> RawFilePath -> Key -> Maybe RawFilePath -> Annex Bool
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
addAnnexedFile ci matcher file key mtmp = ifM (addUnlocked matcher mi)
|
2016-02-16 18:43:43 +00:00
|
|
|
( do
|
2016-04-14 18:30:15 +00:00
|
|
|
mode <- maybe
|
|
|
|
(pure Nothing)
|
2020-11-03 14:11:04 +00:00
|
|
|
(\tmp -> liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus tmp)
|
2016-04-14 18:30:15 +00:00
|
|
|
mtmp
|
2020-11-03 14:11:04 +00:00
|
|
|
stagePointerFile file mode =<< hashPointerFile key
|
|
|
|
Database.Keys.addAssociatedFile key =<< inRepo (toTopFilePath file)
|
2016-02-16 18:43:43 +00:00
|
|
|
case mtmp of
|
2020-11-16 18:09:55 +00:00
|
|
|
Just tmp -> ifM (moveAnnex key af tmp)
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
( linkunlocked mode >> return True
|
|
|
|
, writepointer mode >> return False
|
|
|
|
)
|
2016-02-16 18:43:43 +00:00
|
|
|
Nothing -> ifM (inAnnex key)
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
( linkunlocked mode >> return True
|
|
|
|
, writepointer mode >> return True
|
2016-02-16 18:43:43 +00:00
|
|
|
)
|
|
|
|
, do
|
Added --no-check-gitignore option for finer grained control than using --force.
add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.
(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)
addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.
In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.
2020-09-18 17:12:04 +00:00
|
|
|
addLink ci file key Nothing
|
2016-02-16 18:43:43 +00:00
|
|
|
case mtmp of
|
2020-11-16 18:09:55 +00:00
|
|
|
Just tmp -> moveAnnex key af tmp
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
Nothing -> return True
|
2016-02-16 18:43:43 +00:00
|
|
|
)
|
|
|
|
where
|
2020-11-16 18:09:55 +00:00
|
|
|
af = AssociatedFile (Just file)
|
2019-12-20 19:01:34 +00:00
|
|
|
mi = case mtmp of
|
|
|
|
Just tmp -> MatchingFile $ FileInfo
|
2020-11-03 14:11:04 +00:00
|
|
|
{ contentFile = Just tmp
|
|
|
|
, matchFile = file
|
2019-12-20 19:01:34 +00:00
|
|
|
}
|
|
|
|
-- Provide as much info as we can without access to the
|
2020-09-28 16:06:10 +00:00
|
|
|
-- file's content.
|
2019-12-20 19:01:34 +00:00
|
|
|
Nothing -> MatchingInfo $ ProvidedInfo
|
2020-11-03 14:11:04 +00:00
|
|
|
{ providedFilePath = file
|
2020-09-28 16:06:10 +00:00
|
|
|
, providedKey = Just key
|
|
|
|
, providedFileSize = fromMaybe 0 $
|
2019-12-20 19:01:34 +00:00
|
|
|
keySize `fromKey` key
|
2020-09-28 16:06:10 +00:00
|
|
|
, providedMimeType = Nothing
|
|
|
|
, providedMimeEncoding = Nothing
|
2019-12-20 19:01:34 +00:00
|
|
|
}
|
|
|
|
|
2020-11-03 14:11:04 +00:00
|
|
|
linkunlocked mode = linkFromAnnex key file mode >>= \case
|
|
|
|
LinkAnnexFailed -> liftIO $ writepointer mode
|
2017-11-15 20:55:38 +00:00
|
|
|
_ -> return ()
|
2020-11-03 14:11:04 +00:00
|
|
|
|
|
|
|
writepointer mode = liftIO $ writePointerFile file key mode
|
2020-11-10 16:10:51 +00:00
|
|
|
|
|
|
|
{- Use with actions that add an already existing annex symlink or pointer
|
|
|
|
- file. The warning avoids a confusing situation where the file got copied
|
|
|
|
- from another git-annex repo, probably by accident. -}
|
|
|
|
addingExistingLink :: RawFilePath -> Key -> Annex a -> Annex a
|
|
|
|
addingExistingLink f k a = do
|
|
|
|
unlessM (isKnownKey k <||> inAnnex k) $ do
|
|
|
|
islink <- isJust <$> isAnnexLink f
|
|
|
|
warning $ unwords
|
|
|
|
[ fromRawFilePath f
|
|
|
|
, "is a git-annex"
|
|
|
|
, if islink then "symlink." else "pointer file."
|
|
|
|
, "Its content is not available in this repository."
|
|
|
|
, "(Maybe " ++ fromRawFilePath f ++ " was copied from another repository?)"
|
|
|
|
]
|
|
|
|
a
|