2015-12-22 17:23:33 +00:00
|
|
|
{- git-annex content ingestion
|
|
|
|
-
|
2022-06-14 18:40:55 +00:00
|
|
|
- Copyright 2010-2022 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
|
|
|
-}
|
|
|
|
|
2023-04-10 16:56:45 +00:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
|
|
|
|
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,
|
2021-09-02 17:45:21 +00:00
|
|
|
checkLockedDownWritePerms,
|
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,
|
2022-06-14 17:56:17 +00:00
|
|
|
addSymlink,
|
2023-12-06 19:38:01 +00:00
|
|
|
genSymlink,
|
2015-12-22 17:23:33 +00:00
|
|
|
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
|
2023-12-06 19:38:01 +00:00
|
|
|
import qualified Git
|
2015-12-22 17:23:33 +00:00
|
|
|
import qualified Annex
|
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
|
|
|
|
2023-03-01 19:55:58 +00:00
|
|
|
import System.PosixCompat.Files (fileMode)
|
|
|
|
|
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
|
2023-03-28 17:40:17 +00:00
|
|
|
-- ^ hard link to temp directory
|
2021-09-02 17:45:21 +00:00
|
|
|
, checkWritePerms :: Bool
|
|
|
|
-- ^ check that write perms are successfully removed
|
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.
|
|
|
|
-
|
2021-08-27 18:33:01 +00:00
|
|
|
- Lockdown can fail if a file gets deleted, or if it's unable to remove
|
|
|
|
- write permissions, and Nothing will be returned.
|
2015-12-22 17:23:33 +00:00
|
|
|
-}
|
2021-09-02 17:45:21 +00:00
|
|
|
lockDown :: LockDownConfig-> FilePath -> Annex (Maybe LockedDown)
|
2016-01-07 21:39:59 +00:00
|
|
|
lockDown cfg file = either
|
filter out control characters in warning messages
Converted warning and similar to use StringContainingQuotedPath. Most
warnings are static strings, some do refer to filepaths that need to be
quoted, and others don't need quoting.
Note that, since quote filters out control characters of even
UnquotedString, this makes all warnings safe, even when an attacker
sneaks in a control character in some other way.
When json is being output, no quoting is done, since json gets its own
quoting.
This does, as a side effect, make warning messages in json output not
be indented. The indentation is only needed to offset warning messages
underneath the display of the file they apply to, so that's ok.
Sponsored-by: Brett Eisenberg on Patreon
2023-04-10 18:47:32 +00:00
|
|
|
(\e -> warning (UnquotedString (show e)) >> return Nothing)
|
2015-12-22 17:23:33 +00:00
|
|
|
(return . Just)
|
2016-01-07 21:39:59 +00:00
|
|
|
=<< lockDown' cfg file
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2021-08-27 18:33:01 +00:00
|
|
|
lockDown' :: LockDownConfig -> FilePath -> Annex (Either SomeException LockedDown)
|
|
|
|
lockDown' cfg file = tryNonAsync $ ifM crippledFileSystem
|
2019-05-07 17:04:39 +00:00
|
|
|
( 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
|
|
|
|
|
2021-08-27 18:33:01 +00:00
|
|
|
nohardlink = do
|
|
|
|
setperms
|
|
|
|
withTSDelta $ liftIO . nohardlink'
|
2019-05-07 17:04:39 +00:00
|
|
|
|
|
|
|
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
|
2021-08-27 18:33:01 +00:00
|
|
|
setperms
|
2019-05-07 17:04:39 +00:00
|
|
|
withTSDelta $ \delta -> liftIO $ do
|
2021-08-30 17:05:02 +00:00
|
|
|
(tmpfile, h) <- openTmpFileIn (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
|
2023-03-01 19:55:58 +00:00
|
|
|
let tmpfile' = toRawFilePath tmpfile
|
|
|
|
R.createLink file' tmpfile'
|
|
|
|
cache <- genInodeCache tmpfile' delta
|
2016-01-07 21:39:59 +00:00
|
|
|
return $ LockedDown cfg $ KeySource
|
2020-02-21 13:34:59 +00:00
|
|
|
{ keyFilename = file'
|
2023-03-01 19:55:58 +00:00
|
|
|
, contentLocation = tmpfile'
|
2015-12-22 17:23:33 +00:00
|
|
|
, inodeCache = cache
|
|
|
|
}
|
2021-08-27 18:33:01 +00:00
|
|
|
|
|
|
|
setperms = when (lockingFile cfg) $ do
|
|
|
|
freezeContent file'
|
2023-04-10 16:56:45 +00:00
|
|
|
when (checkWritePerms cfg) $ do
|
|
|
|
qp <- coreQuotePath <$> Annex.getGitConfig
|
|
|
|
maybe noop (giveup . decodeBS . quote qp)
|
|
|
|
=<< checkLockedDownWritePerms file' file'
|
2021-09-02 17:45:21 +00:00
|
|
|
|
2023-04-10 16:56:45 +00:00
|
|
|
checkLockedDownWritePerms :: RawFilePath -> RawFilePath -> Annex (Maybe StringContainingQuotedPath)
|
2021-09-02 17:45:21 +00:00
|
|
|
checkLockedDownWritePerms file displayfile = checkContentWritePerm file >>= return . \case
|
2023-04-10 16:56:45 +00:00
|
|
|
Just False -> Just $ "Unable to remove all write permissions from "
|
|
|
|
<> QuotedPath displayfile
|
|
|
|
<> " -- perhaps it has an xattr or ACL set."
|
2021-09-02 17:45:21 +00:00
|
|
|
_ -> Nothing
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2016-02-16 18:43:43 +00:00
|
|
|
{- Ingests a locked down file into the annex. Updates the work tree and
|
|
|
|
- index. -}
|
fix add overwrite race with git-annex add to annex
This is not a complete fix for all such races, only the one where a
large file gets changed while adding and gets added to git rather than
to the annex.
addLink needs to go away, any caller of it is probably subject to the
same kind of race. (Also, addLink itself fails to check gitignore when
symlinks are not supported.)
ingestAdd no longer checks gitignore. (It didn't check it consistently
before either, since there were cases where it did not run git add!)
When git-annex import calls it, it's already checked gitignore itself
earlier. When git-annex add calls it, it's usually on files found
by withFilesNotInGit, which handles checking ignores.
There was one other case, when git-annex add --batch calls it. In that
case, old git-annex behaved rather badly, it would seem to add the file,
but git add would later fail, leaving the file as an unstaged annex symlink.
That behavior has also been fixed.
Sponsored-by: Brett Eisenberg on Patreon
2022-06-14 17:20:42 +00:00
|
|
|
ingestAdd :: MeterUpdate -> Maybe LockedDown -> Annex (Maybe Key)
|
|
|
|
ingestAdd meterupdate ld = ingestAdd' meterupdate ld Nothing
|
2017-02-09 19:32:22 +00:00
|
|
|
|
fix add overwrite race with git-annex add to annex
This is not a complete fix for all such races, only the one where a
large file gets changed while adding and gets added to git rather than
to the annex.
addLink needs to go away, any caller of it is probably subject to the
same kind of race. (Also, addLink itself fails to check gitignore when
symlinks are not supported.)
ingestAdd no longer checks gitignore. (It didn't check it consistently
before either, since there were cases where it did not run git add!)
When git-annex import calls it, it's already checked gitignore itself
earlier. When git-annex add calls it, it's usually on files found
by withFilesNotInGit, which handles checking ignores.
There was one other case, when git-annex add --batch calls it. In that
case, old git-annex behaved rather badly, it would seem to add the file,
but git add would later fail, leaving the file as an unstaged annex symlink.
That behavior has also been fixed.
Sponsored-by: Brett Eisenberg on Patreon
2022-06-14 17:20:42 +00:00
|
|
|
ingestAdd' :: MeterUpdate -> Maybe LockedDown -> Maybe Key -> Annex (Maybe Key)
|
|
|
|
ingestAdd' _ Nothing _ = return Nothing
|
|
|
|
ingestAdd' 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
|
fix add overwrite race with git-annex add to annex
This is not a complete fix for all such races, only the one where a
large file gets changed while adding and gets added to git rather than
to the annex.
addLink needs to go away, any caller of it is probably subject to the
same kind of race. (Also, addLink itself fails to check gitignore when
symlinks are not supported.)
ingestAdd no longer checks gitignore. (It didn't check it consistently
before either, since there were cases where it did not run git add!)
When git-annex import calls it, it's already checked gitignore itself
earlier. When git-annex add calls it, it's usually on files found
by withFilesNotInGit, which handles checking ignores.
There was one other case, when git-annex add --batch calls it. In that
case, old git-annex behaved rather badly, it would seem to add the file,
but git add would later fail, leaving the file as an unstaged annex symlink.
That behavior has also been fixed.
Sponsored-by: Brett Eisenberg on Patreon
2022-06-14 17:20:42 +00:00
|
|
|
then addSymlink 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)
|
2023-03-27 19:10:46 +00:00
|
|
|
return
|
2020-02-21 13:34:59 +00:00
|
|
|
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
|
2021-12-09 19:25:59 +00:00
|
|
|
(_, Nothing) -> go k mcache
|
|
|
|
(Just newc, Just c) | compareStrong c newc -> go k mcache
|
2015-12-22 17:23:33 +00:00
|
|
|
_ -> failure "changed while it was being added"
|
|
|
|
where
|
2021-12-09 19:25:59 +00:00
|
|
|
go key mcache
|
|
|
|
| lockingFile cfg = golocked key mcache
|
|
|
|
| otherwise = gounlocked key mcache
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2021-12-09 19:25:59 +00:00
|
|
|
golocked key mcache =
|
2020-11-16 18:09:55 +00:00
|
|
|
tryNonAsync (moveAnnex key naf (contentLocation source)) >>= \case
|
2021-12-09 19:25:59 +00:00
|
|
|
Right True -> success key mcache
|
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 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
|
|
|
|
|
2021-12-09 19:25:59 +00:00
|
|
|
gounlocked key (Just cache) = 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"
|
2021-06-15 13:32:12 +00:00
|
|
|
lar -> do
|
|
|
|
finishIngestUnlocked' key source restage (Just lar)
|
2021-12-09 19:25:59 +00:00
|
|
|
success key (Just cache)
|
|
|
|
gounlocked _ _ = failure "failed statting file"
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2021-12-09 19:25:59 +00:00
|
|
|
success k mcache = do
|
|
|
|
genMetaData k (keyFilename source) (fmap inodeCacheToMtime mcache)
|
2015-12-22 19:23:27 +00:00
|
|
|
return (Just k, mcache)
|
2015-12-22 17:23:33 +00:00
|
|
|
|
|
|
|
failure msg = do
|
filter out control characters in warning messages
Converted warning and similar to use StringContainingQuotedPath. Most
warnings are static strings, some do refer to filepaths that need to be
quoted, and others don't need quoting.
Note that, since quote filters out control characters of even
UnquotedString, this makes all warnings safe, even when an attacker
sneaks in a control character in some other way.
When json is being output, no quoting is done, since json gets its own
quoting.
This does, as a side effect, make warning messages in json output not
be indented. The indentation is only needed to offset warning messages
underneath the display of the file they apply to, so that's ok.
Sponsored-by: Brett Eisenberg on Patreon
2023-04-10 18:47:32 +00:00
|
|
|
warning $ QuotedPath (keyFilename source) <> " " <> UnquotedString 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
|
2021-06-15 13:32:12 +00:00
|
|
|
finishIngestUnlocked' key source (Restage True) Nothing
|
2015-12-22 22:03:47 +00:00
|
|
|
|
2021-06-15 13:32:12 +00:00
|
|
|
finishIngestUnlocked' :: Key -> KeySource -> Restage -> Maybe LinkAnnexResult -> Annex ()
|
|
|
|
finishIngestUnlocked' key source restage lar = 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))
|
2021-06-15 13:32:12 +00:00
|
|
|
populateUnlockedFiles key source restage lar
|
|
|
|
|
|
|
|
{- Copy to any other unlocked files using the same key.
|
|
|
|
-
|
|
|
|
- When linkToAnnex did not have to do anything, the object file
|
|
|
|
- was already present, and so other unlocked files are already populated,
|
|
|
|
- and nothing needs to be done here.
|
|
|
|
-}
|
|
|
|
populateUnlockedFiles :: Key -> KeySource -> Restage -> Maybe LinkAnnexResult -> Annex ()
|
|
|
|
populateUnlockedFiles _ _ _ (Just LinkAnnexNoop) = return ()
|
2021-06-15 15:11:55 +00:00
|
|
|
populateUnlockedFiles key source restage _ = do
|
2021-06-15 13:32:12 +00:00
|
|
|
obj <- calcRepo (gitAnnexLocation key)
|
|
|
|
g <- Annex.gitRepo
|
|
|
|
ingestedf <- flip fromTopFilePath g
|
|
|
|
<$> inRepo (toTopFilePath (keyFilename source))
|
|
|
|
afs <- map (`fromTopFilePath` g) <$> Database.Keys.getAssociatedFiles key
|
|
|
|
forM_ (filter (/= ingestedf) afs) $
|
|
|
|
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)) $
|
filter out control characters in warning messages
Converted warning and similar to use StringContainingQuotedPath. Most
warnings are static strings, some do refer to filepaths that need to be
quoted, and others don't need quoting.
Note that, since quote filters out control characters of even
UnquotedString, this makes all warnings safe, even when an attacker
sneaks in a control character in some other way.
When json is being output, no quoting is done, since json gets its own
quoting.
This does, as a side effect, make warning messages in json output not
be indented. The indentation is only needed to offset warning messages
underneath the display of the file they apply to, so that's ok.
Sponsored-by: Brett Eisenberg on Patreon
2023-04-10 18:47:32 +00:00
|
|
|
warning $ "Unable to restore content of " <> QuotedPath file <> "; it should be located in " <> QuotedPath (toRawFilePath 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
|
2023-10-26 17:36:49 +00:00
|
|
|
replaceWorkTreeFile file' $ makeAnnexLink l
|
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
|
|
|
|
2022-06-14 18:40:55 +00:00
|
|
|
{- Creates the symlink to the annexed content, and stages it in git. -}
|
fix add overwrite race with git-annex add to annex
This is not a complete fix for all such races, only the one where a
large file gets changed while adding and gets added to git rather than
to the annex.
addLink needs to go away, any caller of it is probably subject to the
same kind of race. (Also, addLink itself fails to check gitignore when
symlinks are not supported.)
ingestAdd no longer checks gitignore. (It didn't check it consistently
before either, since there were cases where it did not run git add!)
When git-annex import calls it, it's already checked gitignore itself
earlier. When git-annex add calls it, it's usually on files found
by withFilesNotInGit, which handles checking ignores.
There was one other case, when git-annex add --batch calls it. In that
case, old git-annex behaved rather badly, it would seem to add the file,
but git add would later fail, leaving the file as an unstaged annex symlink.
That behavior has also been fixed.
Sponsored-by: Brett Eisenberg on Patreon
2022-06-14 17:20:42 +00:00
|
|
|
addSymlink :: RawFilePath -> Key -> Maybe InodeCache -> Annex ()
|
2023-12-06 19:38:01 +00:00
|
|
|
addSymlink file key mcache = stageSymlink file =<< genSymlink file key mcache
|
|
|
|
|
|
|
|
genSymlink :: RawFilePath -> Key -> Maybe InodeCache -> Annex Git.Sha
|
|
|
|
genSymlink file key mcache = do
|
2022-06-14 18:30:12 +00:00
|
|
|
linktarget <- makeLink file key mcache
|
2023-12-06 19:38:01 +00:00
|
|
|
hashSymlink linktarget
|
fix add overwrite race with git-annex add to annex
This is not a complete fix for all such races, only the one where a
large file gets changed while adding and gets added to git rather than
to the annex.
addLink needs to go away, any caller of it is probably subject to the
same kind of race. (Also, addLink itself fails to check gitignore when
symlinks are not supported.)
ingestAdd no longer checks gitignore. (It didn't check it consistently
before either, since there were cases where it did not run git add!)
When git-annex import calls it, it's already checked gitignore itself
earlier. When git-annex add calls it, it's usually on files found
by withFilesNotInGit, which handles checking ignores.
There was one other case, when git-annex add --batch calls it. In that
case, old git-annex behaved rather badly, it would seem to add the file,
but git add would later fail, leaving the file as an unstaged annex symlink.
That behavior has also been fixed.
Sponsored-by: Brett Eisenberg on Patreon
2022-06-14 17:20:42 +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]
|
2022-06-28 19:28:14 +00:00
|
|
|
gitAddParams (CheckGitIgnore True) = ifM (Annex.getRead 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.
|
2021-01-25 17:55:01 +00:00
|
|
|
- Also, when in an adjusted branch that unlocked files, always add files
|
|
|
|
- unlocked.
|
2016-03-29 17:26:06 +00:00
|
|
|
-}
|
2021-01-25 17:55:01 +00:00
|
|
|
addUnlocked :: AddUnlockedMatcher -> MatchInfo -> Bool -> Annex Bool
|
|
|
|
addUnlocked matcher mi contentpresent =
|
2019-08-30 17:54:57 +00:00
|
|
|
((not . coreSymlinks <$> Annex.getGitConfig) <||>
|
2019-12-20 19:01:34 +00:00
|
|
|
(checkAddUnlockedMatcher matcher mi) <||>
|
2021-01-25 17:55:01 +00:00
|
|
|
(maybe False go . snd <$> getCurrentBranch)
|
2016-02-16 18:43:43 +00:00
|
|
|
)
|
2018-10-18 16:51:20 +00:00
|
|
|
where
|
2021-01-25 17:55:01 +00:00
|
|
|
go (LinkAdjustment UnlockAdjustment) = True
|
|
|
|
go (LinkAdjustment LockAdjustment) = False
|
|
|
|
go (LinkAdjustment FixAdjustment) = False
|
|
|
|
go (LinkAdjustment UnFixAdjustment) = False
|
|
|
|
go (PresenceAdjustment _ (Just la)) = go (LinkAdjustment la)
|
|
|
|
go (PresenceAdjustment _ Nothing) = False
|
|
|
|
go (LinkPresentAdjustment UnlockPresentAdjustment) = contentpresent
|
|
|
|
go (LinkPresentAdjustment LockPresentAdjustment) = 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.
|
|
|
|
-}
|
2022-06-14 18:40:55 +00:00
|
|
|
addAnnexedFile :: AddUnlockedMatcher -> RawFilePath -> Key -> Maybe RawFilePath -> Annex Bool
|
|
|
|
addAnnexedFile matcher file key mtmp = ifM (addUnlocked matcher mi (isJust mtmp))
|
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
|
2022-06-14 18:40:55 +00:00
|
|
|
addSymlink 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
|
2021-03-01 20:34:40 +00:00
|
|
|
{ contentFile = tmp
|
2020-11-03 14:11:04 +00:00
|
|
|
, matchFile = file
|
2020-12-15 14:37:07 +00:00
|
|
|
, matchKey = Just key
|
2019-12-20 19:01:34 +00:00
|
|
|
}
|
fromkey unlocked files support
fromkey: Create an unlocked file when used in an adjusted branch where the
file should be unlocked, or when configured by annex.addunlocked.
There is some overlap with code in Annex.Ingest, however it's not quite the
same because ingesting has a temp file with the content, where here the
content, if any, is in the annex object file. So it eg, makes sense for
Annex.Ingest to copy the execute mode of the content file, but it does not make
sense for fromkey to do that.
Also changed in passing to stage the file in git directly, rather than
using git add. One consequence of that is that if the file is gitignored,
it will still get added, rather than the old behavior:
The following paths are ignored by one of your .gitignore files:
ignored
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"
git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] exited 123)
That old behavior was a surprise to me, and so I consider it a bug, and doubt
anyone would have relied on it.
Note that, when on an --hide-missing branch, it is possible to fromkey a key
that is not present (needs --force). The annex link or pointer file still gets
written in this case. It doesn't seem to make any sense not to write it,
because then fromkey would not do anything useful in this case, and this way
the file can be committed and synced to master, and the branch re-adjusted to
hide the new missing file.
This commit was sponsored by Noam Kremen on Patreon.
2021-05-03 15:26:18 +00:00
|
|
|
Nothing -> keyMatchInfoWithoutContent key file
|
2019-12-20 19:01:34 +00:00
|
|
|
|
2020-11-03 14:11:04 +00:00
|
|
|
linkunlocked mode = linkFromAnnex key file mode >>= \case
|
fromkey unlocked files support
fromkey: Create an unlocked file when used in an adjusted branch where the
file should be unlocked, or when configured by annex.addunlocked.
There is some overlap with code in Annex.Ingest, however it's not quite the
same because ingesting has a temp file with the content, where here the
content, if any, is in the annex object file. So it eg, makes sense for
Annex.Ingest to copy the execute mode of the content file, but it does not make
sense for fromkey to do that.
Also changed in passing to stage the file in git directly, rather than
using git add. One consequence of that is that if the file is gitignored,
it will still get added, rather than the old behavior:
The following paths are ignored by one of your .gitignore files:
ignored
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"
git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] exited 123)
That old behavior was a surprise to me, and so I consider it a bug, and doubt
anyone would have relied on it.
Note that, when on an --hide-missing branch, it is possible to fromkey a key
that is not present (needs --force). The annex link or pointer file still gets
written in this case. It doesn't seem to make any sense not to write it,
because then fromkey would not do anything useful in this case, and this way
the file can be committed and synced to master, and the branch re-adjusted to
hide the new missing file.
This commit was sponsored by Noam Kremen on Patreon.
2021-05-03 15:26:18 +00:00
|
|
|
LinkAnnexFailed -> 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
|
filter out control characters in warning messages
Converted warning and similar to use StringContainingQuotedPath. Most
warnings are static strings, some do refer to filepaths that need to be
quoted, and others don't need quoting.
Note that, since quote filters out control characters of even
UnquotedString, this makes all warnings safe, even when an attacker
sneaks in a control character in some other way.
When json is being output, no quoting is done, since json gets its own
quoting.
This does, as a side effect, make warning messages in json output not
be indented. The indentation is only needed to offset warning messages
underneath the display of the file they apply to, so that's ok.
Sponsored-by: Brett Eisenberg on Patreon
2023-04-10 18:47:32 +00:00
|
|
|
warning $
|
|
|
|
QuotedPath f
|
|
|
|
<> " is a git-annex "
|
|
|
|
<> if islink then "symlink." else "pointer file."
|
|
|
|
<> " Its content is not available in this repository."
|
|
|
|
<> " (Maybe " <> QuotedPath f <> " was copied from another repository?)"
|
2020-11-10 16:10:51 +00:00
|
|
|
a
|