2010-11-02 23:04:24 +00:00
|
|
|
{- git-annex command
|
|
|
|
-
|
2013-03-29 20:17:13 +00:00
|
|
|
- Copyright 2010, 2013 Joey Hess <joey@kitenet.net>
|
2010-11-02 23:04:24 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
2013-02-10 19:48:38 +00:00
|
|
|
{-# LANGUAGE CPP #-}
|
|
|
|
|
2010-11-02 23:04:24 +00:00
|
|
|
module Command.Add where
|
|
|
|
|
2013-05-11 20:03:00 +00:00
|
|
|
import System.PosixCompat.Files
|
|
|
|
|
2011-10-05 20:02:51 +00:00
|
|
|
import Common.Annex
|
2011-10-04 04:34:04 +00:00
|
|
|
import Annex.Exception
|
2010-11-02 23:04:24 +00:00
|
|
|
import Command
|
2012-06-20 20:07:14 +00:00
|
|
|
import Types.KeySource
|
2012-06-05 23:51:03 +00:00
|
|
|
import Backend
|
2011-10-15 20:21:08 +00:00
|
|
|
import Logs.Location
|
2011-10-04 04:40:47 +00:00
|
|
|
import Annex.Content
|
2012-12-24 17:37:29 +00:00
|
|
|
import Annex.Content.Direct
|
2012-06-06 00:28:34 +00:00
|
|
|
import Annex.Perms
|
fully support core.symlinks=false in all relevant symlink handling code
Refactored annex link code into nice clean new library.
Audited and dealt with calls to createSymbolicLink.
Remaining calls are all safe, because:
Annex/Link.hs: ( liftIO $ createSymbolicLink linktarget file
only when core.symlinks=true
Assistant/WebApp/Configurators/Local.hs: createSymbolicLink link link
test if symlinks can be made
Command/Fix.hs: liftIO $ createSymbolicLink link file
command only works in indirect mode
Command/FromKey.hs: liftIO $ createSymbolicLink link file
command only works in indirect mode
Command/Indirect.hs: liftIO $ createSymbolicLink l f
refuses to run if core.symlinks=false
Init.hs: createSymbolicLink f f2
test if symlinks can be made
Remote/Directory.hs: go [file] = catchBoolIO $ createSymbolicLink file f >> return True
fast key linking; catches failure to make symlink and falls back to copy
Remote/Git.hs: liftIO $ catchBoolIO $ createSymbolicLink loc file >> return True
ditto
Upgrade/V1.hs: liftIO $ createSymbolicLink link f
v1 repos could not be on a filesystem w/o symlinks
Audited and dealt with calls to readSymbolicLink.
Remaining calls are all safe, because:
Annex/Link.hs: ( liftIO $ catchMaybeIO $ readSymbolicLink file
only when core.symlinks=true
Assistant/Threads/Watcher.hs: ifM ((==) (Just link) <$> liftIO (catchMaybeIO $ readSymbolicLink file))
code that fixes real symlinks when inotify sees them
It's ok to not fix psdueo-symlinks.
Assistant/Threads/Watcher.hs: mlink <- liftIO (catchMaybeIO $ readSymbolicLink file)
ditto
Command/Fix.hs: stopUnless ((/=) (Just link) <$> liftIO (catchMaybeIO $ readSymbolicLink file)) $ do
command only works in indirect mode
Upgrade/V1.hs: getsymlink = takeFileName <$> readSymbolicLink file
v1 repos could not be on a filesystem w/o symlinks
Audited and dealt with calls to isSymbolicLink.
(Typically used with getSymbolicLinkStatus, but that is just used because
getFileStatus is not as robust; it also works on pseudolinks.)
Remaining calls are all safe, because:
Assistant/Threads/SanityChecker.hs: | isSymbolicLink s -> addsymlink file ms
only handles staging of symlinks that were somehow not staged
(might need to be updated to support pseudolinks, but this is
only a belt-and-suspenders check anyway, and I've never seen the code run)
Command/Add.hs: if isSymbolicLink s || not (isRegularFile s)
avoids adding symlinks to the annex, so not relevant
Command/Indirect.hs: | isSymbolicLink s -> void $ flip whenAnnexed f $
only allowed on systems that support symlinks
Command/Indirect.hs: whenM (liftIO $ not . isSymbolicLink <$> getSymbolicLinkStatus f) $ do
ditto
Seek.hs:notSymlink f = liftIO $ not . isSymbolicLink <$> getSymbolicLinkStatus f
used to find unlocked files, only relevant in indirect mode
Utility/FSEvents.hs: | Files.isSymbolicLink s = runhook addSymlinkHook $ Just s
Utility/FSEvents.hs: | Files.isSymbolicLink s ->
Utility/INotify.hs: | Files.isSymbolicLink s ->
Utility/INotify.hs: checkfiletype Files.isSymbolicLink addSymlinkHook f
Utility/Kqueue.hs: | Files.isSymbolicLink s = callhook addSymlinkHook (Just s) change
all above are lower-level, not relevant
Audited and dealt with calls to isSymLink.
Remaining calls are all safe, because:
Annex/Direct.hs: | isSymLink (getmode item) =
This is looking at git diff-tree objects, not files on disk
Command/Unused.hs: | isSymLink (LsTree.mode l) = do
This is looking at git ls-tree, not file on disk
Utility/FileMode.hs:isSymLink :: FileMode -> Bool
Utility/FileMode.hs:isSymLink = checkMode symbolicLinkMode
low-level
Done!!
2013-02-17 19:05:55 +00:00
|
|
|
import Annex.Link
|
|
|
|
import qualified Annex
|
|
|
|
import qualified Annex.Queue
|
2013-02-27 06:39:22 +00:00
|
|
|
#ifndef __ANDROID__
|
2011-08-20 20:11:42 +00:00
|
|
|
import Utility.Touch
|
2013-02-10 19:48:38 +00:00
|
|
|
#endif
|
2012-06-06 00:28:34 +00:00
|
|
|
import Utility.FileMode
|
2012-12-24 17:37:29 +00:00
|
|
|
import Config
|
2013-02-14 20:54:36 +00:00
|
|
|
import Utility.InodeCache
|
2013-03-29 20:17:13 +00:00
|
|
|
import Annex.FileMatcher
|
2013-05-17 19:59:37 +00:00
|
|
|
import Annex.ReplaceFile
|
2010-11-02 23:04:24 +00:00
|
|
|
|
2011-10-29 19:19:05 +00:00
|
|
|
def :: [Command]
|
2013-03-24 22:28:21 +00:00
|
|
|
def = [notBareRepo $ command "add" paramPaths seek SectionCommon
|
|
|
|
"add files to annex"]
|
2010-12-30 18:19:16 +00:00
|
|
|
|
2013-02-20 18:12:55 +00:00
|
|
|
{- Add acts on both files not checked into git yet, and unlocked files.
|
|
|
|
-
|
|
|
|
- In direct mode, it acts on any files that have changed. -}
|
2010-12-30 18:19:16 +00:00
|
|
|
seek :: [CommandSeek]
|
2013-01-06 21:24:22 +00:00
|
|
|
seek =
|
2013-03-29 20:17:13 +00:00
|
|
|
[ go withFilesNotInGit
|
|
|
|
, whenNotDirect $ go withFilesUnlocked
|
|
|
|
, whenDirect $ go withFilesMaybeModified
|
2013-01-06 21:24:22 +00:00
|
|
|
]
|
2013-03-29 20:17:13 +00:00
|
|
|
where
|
|
|
|
go a = withValue largeFilesMatcher $ \matcher ->
|
2013-03-29 20:20:15 +00:00
|
|
|
a $ \file -> ifM (checkFileMatcher matcher file <||> Annex.getState Annex.force)
|
2013-03-29 20:17:13 +00:00
|
|
|
( start file
|
|
|
|
, stop
|
|
|
|
)
|
2010-11-11 22:54:52 +00:00
|
|
|
|
2012-12-19 16:50:24 +00:00
|
|
|
{- The add subcommand annexes a file, generating a key for it using a
|
|
|
|
- backend, and then moving it into the annex directory and setting up
|
|
|
|
- the symlink pointing to its content. -}
|
2012-02-14 03:42:44 +00:00
|
|
|
start :: FilePath -> CommandStart
|
2013-02-20 17:37:46 +00:00
|
|
|
start file = ifAnnexed file addpresent add
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
|
|
|
add = do
|
2013-04-23 21:22:56 +00:00
|
|
|
ms <- liftIO $ catchMaybeIO $ getSymbolicLinkStatus file
|
|
|
|
case ms of
|
|
|
|
Nothing -> stop
|
|
|
|
Just s
|
|
|
|
| isSymbolicLink s || not (isRegularFile s) -> stop
|
|
|
|
| otherwise -> do
|
|
|
|
showStart "add" file
|
|
|
|
next $ perform file
|
2013-02-20 17:37:46 +00:00
|
|
|
addpresent (key, _) = ifM isDirect
|
|
|
|
( ifM (goodContent key file) ( stop , add )
|
|
|
|
, fixup key
|
|
|
|
)
|
|
|
|
fixup key = do
|
2012-11-12 05:05:04 +00:00
|
|
|
-- fixup from an interrupted add; the symlink
|
|
|
|
-- is present but not yet added to git
|
|
|
|
showStart "add" file
|
|
|
|
liftIO $ removeFile file
|
|
|
|
next $ next $ cleanup file key =<< inAnnex key
|
2010-11-02 23:04:24 +00:00
|
|
|
|
2012-06-06 00:28:34 +00:00
|
|
|
{- The file that's being added is locked down before a key is generated,
|
2013-06-12 18:02:31 +00:00
|
|
|
- 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.
|
|
|
|
- So a KeySource is returned. Its inodeCache can be used to detect any
|
|
|
|
- changes that might be made to the file after it was locked down.
|
2013-06-10 17:10:30 +00:00
|
|
|
-
|
2013-06-12 18:02:31 +00:00
|
|
|
- In indirect mode, the write bit is removed from the file as part of lock
|
|
|
|
- down to guard against further writes, and because objects in the annex
|
|
|
|
- have their write bit disabled anyway. This is not done in direct mode,
|
|
|
|
- because files there need to remain writable at all times.
|
2013-06-10 17:10:30 +00:00
|
|
|
-
|
2013-06-12 18:02:31 +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.
|
2013-01-14 19:02:13 +00:00
|
|
|
-
|
|
|
|
- Lockdown can fail if a file gets deleted, and Nothing will be returned.
|
|
|
|
-}
|
|
|
|
lockDown :: FilePath -> Annex (Maybe KeySource)
|
2013-02-14 18:10:36 +00:00
|
|
|
lockDown file = ifM (crippledFileSystem)
|
2013-06-10 17:10:30 +00:00
|
|
|
( liftIO $ catchMaybeIO nohardlink
|
2013-02-14 18:10:36 +00:00
|
|
|
, do
|
|
|
|
tmp <- fromRepo gitAnnexTmpDir
|
|
|
|
createAnnexDirectory tmp
|
2013-06-12 18:02:31 +00:00
|
|
|
unlessM (isDirect) $ liftIO $
|
|
|
|
void $ tryIO $ preventWrite file
|
2013-02-14 18:10:36 +00:00
|
|
|
liftIO $ catchMaybeIO $ do
|
|
|
|
(tmpfile, h) <- openTempFile tmp (takeFileName file)
|
|
|
|
hClose h
|
|
|
|
nukeFile tmpfile
|
2013-06-10 17:10:30 +00:00
|
|
|
withhardlink tmpfile `catchIO` const nohardlink
|
2013-02-14 18:10:36 +00:00
|
|
|
)
|
2013-06-10 17:10:30 +00:00
|
|
|
where
|
|
|
|
nohardlink = do
|
|
|
|
cache <- genInodeCache file
|
|
|
|
return $ KeySource
|
|
|
|
{ keyFilename = file
|
|
|
|
, contentLocation = file
|
|
|
|
, inodeCache = cache
|
|
|
|
}
|
|
|
|
withhardlink tmpfile = do
|
|
|
|
createLink file tmpfile
|
|
|
|
cache <- genInodeCache tmpfile
|
|
|
|
return $ KeySource
|
|
|
|
{ keyFilename = file
|
|
|
|
, contentLocation = tmpfile
|
|
|
|
, inodeCache = cache
|
|
|
|
}
|
2012-06-06 17:07:30 +00:00
|
|
|
|
2013-02-14 18:10:36 +00:00
|
|
|
{- Ingests a locked down file into the annex.
|
2012-12-24 17:37:29 +00:00
|
|
|
-
|
2013-01-06 21:24:22 +00:00
|
|
|
- In direct mode, leaves the file alone, and just updates bookkeeping
|
2012-12-24 17:37:29 +00:00
|
|
|
- information.
|
|
|
|
-}
|
2013-01-14 19:02:13 +00:00
|
|
|
ingest :: (Maybe KeySource) -> Annex (Maybe Key)
|
|
|
|
ingest Nothing = return Nothing
|
|
|
|
ingest (Just source) = do
|
2012-06-16 02:06:59 +00:00
|
|
|
backend <- chooseBackend $ keyFilename source
|
2013-02-14 20:54:36 +00:00
|
|
|
k <- genKey source backend
|
|
|
|
cache <- liftIO $ genInodeCache $ contentLocation source
|
2013-03-11 06:57:48 +00:00
|
|
|
case (cache, inodeCache source) of
|
|
|
|
(_, Nothing) -> go k cache
|
|
|
|
(Just newc, Just c) | compareStrong c newc -> go k cache
|
2013-04-23 22:09:00 +00:00
|
|
|
_ -> failure "changed while it was being added"
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
2013-02-14 20:54:36 +00:00
|
|
|
go k cache = ifM isDirect ( godirect k cache , goindirect k cache )
|
|
|
|
|
|
|
|
goindirect (Just (key, _)) _ = do
|
Switch to MonadCatchIO-transformers for better handling of state while catching exceptions.
As seen in this bug report, the lifted exception handling using the StateT
monad throws away state changes when an action throws an exception.
http://git-annex.branchable.com/bugs/git_annex_fork_bombs_on_gpg_file/
.. Which can result in cached values being redundantly calculated, or other
possibly worse bugs when the annex state gets out of sync with reality.
This switches from a StateT AnnexState to a ReaderT (MVar AnnexState).
All changes to the state go via the MVar. So when an Annex action is
running inside an exception handler, and it makes some changes, they
immediately go into affect in the MVar. If it then throws an exception
(or even crashes its thread!), the state changes are still in effect.
The MonadCatchIO-transformers change is actually only incidental.
I could have kept on using lifted-base for the exception handling.
However, I'd have needed to write a new instance of MonadBaseControl
for the new monad.. and I didn't write the old instance.. I begged Bas
and he kindly sent it to me. Happily, MonadCatchIO-transformers is
able to derive a MonadCatchIO instance for my monad.
This is a deep level change. It passes the test suite! What could it break?
Well.. The most likely breakage would be to code that runs an Annex action
in an exception handler, and *wants* state changes to be thrown away.
Perhaps the state changes leaves the state inconsistent, or wrong. Since
there are relatively few places in git-annex that catch exceptions in the
Annex monad, and the AnnexState is generally just used to cache calculated
data, this is unlikely to be a problem.
Oh yeah, this change also makes Assistant.Types.ThreadedMonad a bit
redundant. It's now entirely possible to run concurrent Annex actions in
different threads, all sharing access to the same state! The ThreadedMonad
just adds some extra work on top of that, with its own MVar, and avoids
such actions possibly stepping on one-another's toes. I have not gotten
rid of it, but might try that later. Being able to run concurrent Annex
actions would simplify parts of the Assistant code.
2013-05-19 18:16:36 +00:00
|
|
|
catchAnnex (moveAnnex key $ contentLocation source)
|
|
|
|
(undo (keyFilename source) key)
|
2012-12-29 19:32:29 +00:00
|
|
|
liftIO $ nukeFile $ keyFilename source
|
|
|
|
return $ Just key
|
2013-04-23 22:09:00 +00:00
|
|
|
goindirect Nothing _ = failure "failed to generate a key"
|
2012-12-29 19:32:29 +00:00
|
|
|
|
2013-02-14 20:54:36 +00:00
|
|
|
godirect (Just (key, _)) (Just cache) = do
|
2013-04-06 20:01:39 +00:00
|
|
|
addInodeCache key cache
|
2013-03-11 18:14:45 +00:00
|
|
|
finishIngestDirect key source
|
2013-02-14 20:54:36 +00:00
|
|
|
return $ Just key
|
2013-04-23 22:09:00 +00:00
|
|
|
godirect _ _ = failure "failed to generate a key"
|
2012-12-29 19:32:29 +00:00
|
|
|
|
2013-04-23 22:09:00 +00:00
|
|
|
failure msg = do
|
|
|
|
warning $ keyFilename source ++ " " ++ msg
|
2013-02-14 18:10:36 +00:00
|
|
|
when (contentLocation source /= keyFilename source) $
|
|
|
|
liftIO $ nukeFile $ contentLocation source
|
2012-12-29 19:32:29 +00:00
|
|
|
return Nothing
|
2010-11-02 23:04:24 +00:00
|
|
|
|
2013-03-11 18:14:45 +00:00
|
|
|
finishIngestDirect :: Key -> KeySource -> Annex ()
|
|
|
|
finishIngestDirect key source = do
|
|
|
|
void $ addAssociatedFile key $ keyFilename source
|
|
|
|
when (contentLocation source /= keyFilename source) $
|
|
|
|
liftIO $ nukeFile $ contentLocation source
|
|
|
|
|
2013-05-17 19:59:37 +00:00
|
|
|
{- Copy to any other locations using the same key. -}
|
|
|
|
otherfs <- filter (/= keyFilename source) <$> associatedFiles key
|
|
|
|
forM_ otherfs $
|
|
|
|
addContentWhenNotPresent key (keyFilename source)
|
|
|
|
|
2012-06-06 17:07:30 +00:00
|
|
|
perform :: FilePath -> CommandPerform
|
2012-06-16 02:06:59 +00:00
|
|
|
perform file =
|
|
|
|
maybe stop (\key -> next $ cleanup file key True)
|
|
|
|
=<< ingest =<< lockDown file
|
2012-06-06 00:28:34 +00:00
|
|
|
|
2011-07-08 01:29:31 +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. -}
|
|
|
|
undo :: FilePath -> Key -> IOException -> Annex a
|
|
|
|
undo file key e = do
|
2012-03-06 18:12:15 +00:00
|
|
|
whenM (inAnnex key) $ do
|
2012-06-06 17:13:13 +00:00
|
|
|
liftIO $ nukeFile file
|
Switch to MonadCatchIO-transformers for better handling of state while catching exceptions.
As seen in this bug report, the lifted exception handling using the StateT
monad throws away state changes when an action throws an exception.
http://git-annex.branchable.com/bugs/git_annex_fork_bombs_on_gpg_file/
.. Which can result in cached values being redundantly calculated, or other
possibly worse bugs when the annex state gets out of sync with reality.
This switches from a StateT AnnexState to a ReaderT (MVar AnnexState).
All changes to the state go via the MVar. So when an Annex action is
running inside an exception handler, and it makes some changes, they
immediately go into affect in the MVar. If it then throws an exception
(or even crashes its thread!), the state changes are still in effect.
The MonadCatchIO-transformers change is actually only incidental.
I could have kept on using lifted-base for the exception handling.
However, I'd have needed to write a new instance of MonadBaseControl
for the new monad.. and I didn't write the old instance.. I begged Bas
and he kindly sent it to me. Happily, MonadCatchIO-transformers is
able to derive a MonadCatchIO instance for my monad.
This is a deep level change. It passes the test suite! What could it break?
Well.. The most likely breakage would be to code that runs an Annex action
in an exception handler, and *wants* state changes to be thrown away.
Perhaps the state changes leaves the state inconsistent, or wrong. Since
there are relatively few places in git-annex that catch exceptions in the
Annex monad, and the AnnexState is generally just used to cache calculated
data, this is unlikely to be a problem.
Oh yeah, this change also makes Assistant.Types.ThreadedMonad a bit
redundant. It's now entirely possible to run concurrent Annex actions in
different threads, all sharing access to the same state! The ThreadedMonad
just adds some extra work on top of that, with its own MVar, and avoids
such actions possibly stepping on one-another's toes. I have not gotten
rid of it, but might try that later. Being able to run concurrent Annex
actions would simplify parts of the Assistant code.
2013-05-19 18:16:36 +00:00
|
|
|
catchAnnex (fromAnnex key file) tryharder
|
2012-03-06 18:12:15 +00:00
|
|
|
logStatus key InfoMissing
|
2013-06-02 19:01:58 +00:00
|
|
|
throwAnnex e
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
|
|
|
-- fromAnnex could fail if the file ownership is weird
|
|
|
|
tryharder :: IOException -> Annex ()
|
|
|
|
tryharder _ = do
|
2013-04-04 19:46:33 +00:00
|
|
|
src <- calcRepo $ gitAnnexLocation key
|
2012-11-12 05:05:04 +00:00
|
|
|
liftIO $ moveFile src file
|
2011-07-07 23:29:36 +00:00
|
|
|
|
2012-06-19 06:40:21 +00:00
|
|
|
{- Creates the symlink to the annexed content, returns the link target. -}
|
|
|
|
link :: FilePath -> Key -> Bool -> Annex String
|
Switch to MonadCatchIO-transformers for better handling of state while catching exceptions.
As seen in this bug report, the lifted exception handling using the StateT
monad throws away state changes when an action throws an exception.
http://git-annex.branchable.com/bugs/git_annex_fork_bombs_on_gpg_file/
.. Which can result in cached values being redundantly calculated, or other
possibly worse bugs when the annex state gets out of sync with reality.
This switches from a StateT AnnexState to a ReaderT (MVar AnnexState).
All changes to the state go via the MVar. So when an Annex action is
running inside an exception handler, and it makes some changes, they
immediately go into affect in the MVar. If it then throws an exception
(or even crashes its thread!), the state changes are still in effect.
The MonadCatchIO-transformers change is actually only incidental.
I could have kept on using lifted-base for the exception handling.
However, I'd have needed to write a new instance of MonadBaseControl
for the new monad.. and I didn't write the old instance.. I begged Bas
and he kindly sent it to me. Happily, MonadCatchIO-transformers is
able to derive a MonadCatchIO instance for my monad.
This is a deep level change. It passes the test suite! What could it break?
Well.. The most likely breakage would be to code that runs an Annex action
in an exception handler, and *wants* state changes to be thrown away.
Perhaps the state changes leaves the state inconsistent, or wrong. Since
there are relatively few places in git-annex that catch exceptions in the
Annex monad, and the AnnexState is generally just used to cache calculated
data, this is unlikely to be a problem.
Oh yeah, this change also makes Assistant.Types.ThreadedMonad a bit
redundant. It's now entirely possible to run concurrent Annex actions in
different threads, all sharing access to the same state! The ThreadedMonad
just adds some extra work on top of that, with its own MVar, and avoids
such actions possibly stepping on one-another's toes. I have not gotten
rid of it, but might try that later. Being able to run concurrent Annex
actions would simplify parts of the Assistant code.
2013-05-19 18:16:36 +00:00
|
|
|
link file key hascontent = flip catchAnnex (undo file key) $ do
|
2013-04-04 19:46:33 +00:00
|
|
|
l <- inRepo $ gitAnnexLink file key
|
2013-04-02 17:13:42 +00:00
|
|
|
replaceFile file $ makeAnnexLink l
|
2011-08-06 18:57:22 +00:00
|
|
|
|
2013-02-27 06:39:22 +00:00
|
|
|
#ifndef __ANDROID__
|
2012-06-06 17:07:30 +00:00
|
|
|
when hascontent $ do
|
|
|
|
-- touch the symlink to have the same mtime as the
|
|
|
|
-- file it points to
|
|
|
|
liftIO $ do
|
|
|
|
mtime <- modificationTime <$> getFileStatus file
|
|
|
|
touch file (TimeSpec mtime) False
|
2013-02-10 19:48:38 +00:00
|
|
|
#endif
|
2011-03-15 03:00:23 +00:00
|
|
|
|
2012-06-19 06:40:21 +00:00
|
|
|
return l
|
|
|
|
|
2013-04-11 17:35:52 +00:00
|
|
|
{- Creates the symlink to the annexed content, and stages it in git.
|
|
|
|
-
|
|
|
|
- As long as the filesystem supports symlinks, we use
|
fully support core.symlinks=false in all relevant symlink handling code
Refactored annex link code into nice clean new library.
Audited and dealt with calls to createSymbolicLink.
Remaining calls are all safe, because:
Annex/Link.hs: ( liftIO $ createSymbolicLink linktarget file
only when core.symlinks=true
Assistant/WebApp/Configurators/Local.hs: createSymbolicLink link link
test if symlinks can be made
Command/Fix.hs: liftIO $ createSymbolicLink link file
command only works in indirect mode
Command/FromKey.hs: liftIO $ createSymbolicLink link file
command only works in indirect mode
Command/Indirect.hs: liftIO $ createSymbolicLink l f
refuses to run if core.symlinks=false
Init.hs: createSymbolicLink f f2
test if symlinks can be made
Remote/Directory.hs: go [file] = catchBoolIO $ createSymbolicLink file f >> return True
fast key linking; catches failure to make symlink and falls back to copy
Remote/Git.hs: liftIO $ catchBoolIO $ createSymbolicLink loc file >> return True
ditto
Upgrade/V1.hs: liftIO $ createSymbolicLink link f
v1 repos could not be on a filesystem w/o symlinks
Audited and dealt with calls to readSymbolicLink.
Remaining calls are all safe, because:
Annex/Link.hs: ( liftIO $ catchMaybeIO $ readSymbolicLink file
only when core.symlinks=true
Assistant/Threads/Watcher.hs: ifM ((==) (Just link) <$> liftIO (catchMaybeIO $ readSymbolicLink file))
code that fixes real symlinks when inotify sees them
It's ok to not fix psdueo-symlinks.
Assistant/Threads/Watcher.hs: mlink <- liftIO (catchMaybeIO $ readSymbolicLink file)
ditto
Command/Fix.hs: stopUnless ((/=) (Just link) <$> liftIO (catchMaybeIO $ readSymbolicLink file)) $ do
command only works in indirect mode
Upgrade/V1.hs: getsymlink = takeFileName <$> readSymbolicLink file
v1 repos could not be on a filesystem w/o symlinks
Audited and dealt with calls to isSymbolicLink.
(Typically used with getSymbolicLinkStatus, but that is just used because
getFileStatus is not as robust; it also works on pseudolinks.)
Remaining calls are all safe, because:
Assistant/Threads/SanityChecker.hs: | isSymbolicLink s -> addsymlink file ms
only handles staging of symlinks that were somehow not staged
(might need to be updated to support pseudolinks, but this is
only a belt-and-suspenders check anyway, and I've never seen the code run)
Command/Add.hs: if isSymbolicLink s || not (isRegularFile s)
avoids adding symlinks to the annex, so not relevant
Command/Indirect.hs: | isSymbolicLink s -> void $ flip whenAnnexed f $
only allowed on systems that support symlinks
Command/Indirect.hs: whenM (liftIO $ not . isSymbolicLink <$> getSymbolicLinkStatus f) $ do
ditto
Seek.hs:notSymlink f = liftIO $ not . isSymbolicLink <$> getSymbolicLinkStatus f
used to find unlocked files, only relevant in indirect mode
Utility/FSEvents.hs: | Files.isSymbolicLink s = runhook addSymlinkHook $ Just s
Utility/FSEvents.hs: | Files.isSymbolicLink s ->
Utility/INotify.hs: | Files.isSymbolicLink s ->
Utility/INotify.hs: checkfiletype Files.isSymbolicLink addSymlinkHook f
Utility/Kqueue.hs: | Files.isSymbolicLink s = callhook addSymlinkHook (Just s) change
all above are lower-level, not relevant
Audited and dealt with calls to isSymLink.
Remaining calls are all safe, because:
Annex/Direct.hs: | isSymLink (getmode item) =
This is looking at git diff-tree objects, not files on disk
Command/Unused.hs: | isSymLink (LsTree.mode l) = do
This is looking at git ls-tree, not file on disk
Utility/FileMode.hs:isSymLink :: FileMode -> Bool
Utility/FileMode.hs:isSymLink = checkMode symbolicLinkMode
low-level
Done!!
2013-02-17 19:05:55 +00:00
|
|
|
- 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.
|
|
|
|
-}
|
2013-04-11 17:35:52 +00:00
|
|
|
addLink :: FilePath -> Key -> Bool -> Annex ()
|
|
|
|
addLink file key hascontent = ifM (coreSymlinks <$> Annex.getGitConfig)
|
|
|
|
( do
|
|
|
|
_ <- link file key hascontent
|
|
|
|
params <- ifM (Annex.getState Annex.force)
|
|
|
|
( return [Param "-f"]
|
|
|
|
, return []
|
|
|
|
)
|
|
|
|
Annex.Queue.addCommand "add" (params++[Param "--"]) [file]
|
|
|
|
, do
|
|
|
|
l <- link file key hascontent
|
|
|
|
addAnnexLink l file
|
|
|
|
)
|
|
|
|
|
2012-06-06 17:07:30 +00:00
|
|
|
cleanup :: FilePath -> Key -> Bool -> CommandCleanup
|
2013-02-05 17:41:48 +00:00
|
|
|
cleanup file key hascontent = do
|
|
|
|
when hascontent $
|
|
|
|
logStatus key InfoPresent
|
|
|
|
ifM (isDirect <&&> pure hascontent)
|
2013-04-04 19:46:33 +00:00
|
|
|
( do
|
|
|
|
l <- inRepo $ gitAnnexLink file key
|
|
|
|
stageSymlink file =<< hashSymlink l
|
2013-04-11 17:35:52 +00:00
|
|
|
, addLink file key hascontent
|
2013-02-05 17:41:48 +00:00
|
|
|
)
|
|
|
|
return True
|