2012-06-19 06:40:21 +00:00
|
|
|
{- git-annex assistant commit thread
|
2012-06-13 16:36:33 +00:00
|
|
|
-
|
2021-07-13 16:15:40 +00:00
|
|
|
- Copyright 2012-2021 Joey Hess <id@joeyh.name>
|
2012-06-23 05:20:40 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2012-06-13 16:36:33 +00:00
|
|
|
-}
|
|
|
|
|
2013-07-26 22:42:22 +00:00
|
|
|
{-# LANGUAGE CPP #-}
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
|
2012-06-25 20:10:10 +00:00
|
|
|
module Assistant.Threads.Committer where
|
2012-06-13 16:36:33 +00:00
|
|
|
|
2012-07-20 23:29:59 +00:00
|
|
|
import Assistant.Common
|
2012-06-19 06:40:21 +00:00
|
|
|
import Assistant.Changes
|
2012-10-29 23:30:23 +00:00
|
|
|
import Assistant.Types.Changes
|
2012-06-22 17:39:44 +00:00
|
|
|
import Assistant.Commits
|
2012-08-02 13:03:04 +00:00
|
|
|
import Assistant.Alert
|
2012-10-30 18:34:48 +00:00
|
|
|
import Assistant.DaemonStatus
|
2012-07-05 16:21:22 +00:00
|
|
|
import Assistant.TransferQueue
|
2013-03-10 22:16:03 +00:00
|
|
|
import Assistant.Drop
|
2016-08-03 16:37:12 +00:00
|
|
|
import Types.Transfer
|
2013-02-05 17:41:48 +00:00
|
|
|
import Logs.Location
|
2012-06-13 16:36:33 +00:00
|
|
|
import qualified Annex.Queue
|
2012-06-13 21:54:23 +00:00
|
|
|
import Utility.ThreadScheduler
|
2012-06-16 02:35:29 +00:00
|
|
|
import qualified Utility.Lsof as Lsof
|
2012-06-19 06:40:21 +00:00
|
|
|
import qualified Utility.DirWatcher as DirWatcher
|
2012-06-20 20:07:14 +00:00
|
|
|
import Types.KeySource
|
2020-09-15 20:22:44 +00:00
|
|
|
import Types.Command
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
import Config
|
2012-12-24 17:37:29 +00:00
|
|
|
import Annex.Content
|
2015-12-22 17:23:33 +00:00
|
|
|
import Annex.Ingest
|
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
|
2019-05-07 17:04:39 +00:00
|
|
|
import Annex.Perms
|
2013-03-11 16:56:47 +00:00
|
|
|
import Annex.CatFile
|
2015-12-09 19:42:16 +00:00
|
|
|
import Annex.InodeSentinal
|
2018-10-19 19:17:48 +00:00
|
|
|
import Annex.CurrentBranch
|
2021-07-13 16:15:40 +00:00
|
|
|
import Annex.FileMatcher
|
2012-12-30 03:10:18 +00:00
|
|
|
import qualified Annex
|
2013-03-11 16:56:47 +00:00
|
|
|
import Utility.InodeCache
|
2015-12-21 22:41:15 +00:00
|
|
|
import qualified Database.Keys
|
2013-12-01 17:59:39 +00:00
|
|
|
import qualified Command.Sync
|
2017-05-16 03:32:17 +00:00
|
|
|
import Utility.Tuple
|
2019-06-25 15:37:52 +00:00
|
|
|
import Utility.Metered
|
2023-03-01 19:55:58 +00:00
|
|
|
import qualified Utility.RawFilePath as R
|
2012-06-13 16:36:33 +00:00
|
|
|
|
|
|
|
import Data.Time.Clock
|
2012-06-16 02:35:29 +00:00
|
|
|
import qualified Data.Set as S
|
2013-03-11 16:56:47 +00:00
|
|
|
import qualified Data.Map as M
|
2012-06-20 23:04:16 +00:00
|
|
|
import Data.Either
|
2013-03-11 01:36:13 +00:00
|
|
|
import Control.Concurrent
|
2023-03-01 19:55:58 +00:00
|
|
|
import System.PosixCompat.Files (fileID, deviceID, fileMode)
|
2012-06-13 16:36:33 +00:00
|
|
|
|
|
|
|
{- This thread makes git commits at appropriate times. -}
|
2012-10-29 15:40:22 +00:00
|
|
|
commitThread :: NamedThread
|
2013-01-26 06:09:33 +00:00
|
|
|
commitThread = namedThread "Committer" $ do
|
2021-02-02 23:01:45 +00:00
|
|
|
havelsof <- liftIO $ inSearchPath "lsof"
|
2012-12-30 03:10:18 +00:00
|
|
|
delayadd <- liftAnnex $
|
2019-08-30 17:54:57 +00:00
|
|
|
fmap Seconds . annexDelayAdd <$> Annex.getGitConfig
|
2021-07-13 16:15:40 +00:00
|
|
|
largefilematcher <- liftAnnex largeFilesMatcher
|
2015-02-11 17:33:55 +00:00
|
|
|
msg <- liftAnnex Command.Sync.commitMsg
|
2019-05-07 17:04:39 +00:00
|
|
|
lockdowndir <- liftAnnex $ fromRepo gitAnnexTmpWatcherDir
|
|
|
|
liftAnnex $ do
|
|
|
|
-- Clean up anything left behind by a previous process
|
|
|
|
-- on unclean shutdown.
|
2020-11-04 18:20:37 +00:00
|
|
|
void $ liftIO $ tryIO $ removeDirectoryRecursive
|
|
|
|
(fromRawFilePath lockdowndir)
|
2019-05-07 17:04:39 +00:00
|
|
|
void $ createAnnexDirectory lockdowndir
|
2013-03-11 01:36:13 +00:00
|
|
|
waitChangeTime $ \(changes, time) -> do
|
2021-07-13 16:15:40 +00:00
|
|
|
readychanges <- handleAdds (fromRawFilePath lockdowndir) havelsof largefilematcher delayadd $
|
2015-12-22 21:52:39 +00:00
|
|
|
simplifyChanges changes
|
2013-12-16 19:43:28 +00:00
|
|
|
if shouldCommit False time (length readychanges) readychanges
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
then do
|
2013-03-11 01:36:13 +00:00
|
|
|
debug
|
|
|
|
[ "committing"
|
|
|
|
, show (length readychanges)
|
|
|
|
, "changes"
|
|
|
|
]
|
|
|
|
void $ alertWhile commitAlert $
|
2015-02-11 17:33:55 +00:00
|
|
|
liftAnnex $ commitStaged msg
|
2013-03-11 01:36:13 +00:00
|
|
|
recordCommit
|
2017-09-20 18:37:20 +00:00
|
|
|
recordExportCommit
|
2013-04-25 04:44:52 +00:00
|
|
|
let numchanges = length readychanges
|
2013-03-11 01:36:13 +00:00
|
|
|
mapM_ checkChangeContent readychanges
|
2013-04-25 04:44:52 +00:00
|
|
|
return numchanges
|
|
|
|
else do
|
|
|
|
refill readychanges
|
|
|
|
return 0
|
2013-03-11 01:36:13 +00:00
|
|
|
|
|
|
|
refill :: [Change] -> Assistant ()
|
|
|
|
refill [] = noop
|
|
|
|
refill cs = do
|
|
|
|
debug ["delaying commit of", show (length cs), "changes"]
|
|
|
|
refillChanges cs
|
|
|
|
|
2013-07-27 21:41:41 +00:00
|
|
|
{- Wait for one or more changes to arrive to be committed, and then
|
|
|
|
- runs an action to commit them. If more changes arrive while this is
|
|
|
|
- going on, they're handled intelligently, batching up changes into
|
|
|
|
- large commits where possible, doing rename detection, and
|
|
|
|
- commiting immediately otherwise. -}
|
2013-04-25 04:44:52 +00:00
|
|
|
waitChangeTime :: (([Change], UTCTime) -> Assistant Int) -> Assistant ()
|
2013-07-27 21:41:41 +00:00
|
|
|
waitChangeTime a = waitchanges 0
|
2013-03-11 01:36:13 +00:00
|
|
|
where
|
2013-07-27 21:41:41 +00:00
|
|
|
waitchanges lastcommitsize = do
|
2013-04-25 04:44:52 +00:00
|
|
|
-- Wait one one second as a simple rate limiter.
|
|
|
|
liftIO $ threadDelaySeconds (Seconds 1)
|
|
|
|
-- Now, wait until at least one change is available for
|
|
|
|
-- processing.
|
|
|
|
cs <- getChanges
|
2013-07-27 21:41:41 +00:00
|
|
|
handlechanges cs lastcommitsize
|
|
|
|
handlechanges changes lastcommitsize = do
|
2013-04-25 04:44:52 +00:00
|
|
|
let len = length changes
|
|
|
|
-- See if now's a good time to commit.
|
|
|
|
now <- liftIO getCurrentTime
|
2013-12-16 19:43:28 +00:00
|
|
|
scanning <- not . scanComplete <$> getDaemonStatus
|
|
|
|
case (lastcommitsize >= maxCommitSize, shouldCommit scanning now len changes, possiblyrename changes) of
|
2013-04-25 04:44:52 +00:00
|
|
|
(True, True, _)
|
|
|
|
| len > maxCommitSize ->
|
2013-12-16 20:24:57 +00:00
|
|
|
a (changes, now) >>= waitchanges
|
2013-04-25 04:44:52 +00:00
|
|
|
| otherwise -> aftermaxcommit changes
|
|
|
|
(_, True, False) ->
|
2013-12-16 20:24:57 +00:00
|
|
|
a (changes, now) >>= waitchanges
|
2013-04-25 04:44:52 +00:00
|
|
|
(_, True, True) -> do
|
|
|
|
morechanges <- getrelatedchanges changes
|
2013-12-16 20:24:57 +00:00
|
|
|
a (changes ++ morechanges, now) >>= waitchanges
|
2013-04-25 04:44:52 +00:00
|
|
|
_ -> do
|
|
|
|
refill changes
|
2013-07-27 21:41:41 +00:00
|
|
|
waitchanges lastcommitsize
|
2013-04-25 04:44:52 +00:00
|
|
|
|
2013-03-11 01:36:13 +00:00
|
|
|
{- Did we perhaps only get one of the AddChange and RmChange pair
|
2013-03-11 19:14:42 +00:00
|
|
|
- that make up a file rename? Or some of the pairs that make up
|
|
|
|
- a directory rename?
|
|
|
|
-}
|
2013-10-03 02:59:07 +00:00
|
|
|
possiblyrename = all renamepart
|
2013-03-11 19:14:42 +00:00
|
|
|
|
|
|
|
renamepart (PendingAddChange _ _) = True
|
|
|
|
renamepart c = isRmChange c
|
2013-03-11 01:36:13 +00:00
|
|
|
|
2013-03-11 19:46:09 +00:00
|
|
|
{- Gets changes related to the passed changes, without blocking
|
|
|
|
- very long.
|
|
|
|
-
|
|
|
|
- If there are multiple RmChanges, this is probably a directory
|
|
|
|
- rename, in which case it may be necessary to wait longer to get
|
|
|
|
- all the Changes involved.
|
|
|
|
-}
|
|
|
|
getrelatedchanges oldchanges
|
|
|
|
| length (filter isRmChange oldchanges) > 1 =
|
|
|
|
concat <$> getbatchchanges []
|
|
|
|
| otherwise = do
|
|
|
|
liftIO humanImperceptibleDelay
|
|
|
|
getAnyChanges
|
|
|
|
getbatchchanges cs = do
|
|
|
|
liftIO $ threadDelay $ fromIntegral $ oneSecond `div` 10
|
|
|
|
cs' <- getAnyChanges
|
|
|
|
if null cs'
|
|
|
|
then return cs
|
|
|
|
else getbatchchanges (cs':cs)
|
|
|
|
|
2013-04-25 04:44:52 +00:00
|
|
|
{- The last commit was maximum size, so it's very likely there
|
|
|
|
- are more changes and we'd like to ensure we make another commit
|
|
|
|
- of maximum size if possible.
|
|
|
|
-
|
|
|
|
- But, it can take a while for the Watcher to wake back up
|
|
|
|
- after a commit. It can get blocked by another thread
|
|
|
|
- that is using the Annex state, such as a git-annex branch
|
|
|
|
- commit. Especially after such a large commit, this can
|
|
|
|
- take several seconds. When this happens, it defeats the
|
|
|
|
- normal commit batching, which sees some old changes the
|
|
|
|
- Watcher found while the commit was being prepared, and sees
|
|
|
|
- no recent ones, and wants to commit immediately.
|
|
|
|
-
|
|
|
|
- All that we need to do, then, is wait for the Watcher to
|
|
|
|
- wake up, and queue up one more change.
|
|
|
|
-
|
|
|
|
- However, it's also possible that we're at the end of changes for
|
|
|
|
- now. So to avoid waiting a really long time before committing
|
|
|
|
- those changes we have, poll for up to 30 seconds, and then
|
|
|
|
- commit them.
|
|
|
|
-
|
|
|
|
- Also, try to run something in Annex, to ensure we block
|
|
|
|
- longer if the Annex state is indeed blocked.
|
|
|
|
-}
|
|
|
|
aftermaxcommit oldchanges = loop (30 :: Int)
|
|
|
|
where
|
2014-10-09 18:53:13 +00:00
|
|
|
loop 0 = continue oldchanges
|
|
|
|
loop n = do
|
2013-04-25 04:44:52 +00:00
|
|
|
liftAnnex noop -- ensure Annex state is free
|
|
|
|
liftIO $ threadDelaySeconds (Seconds 1)
|
|
|
|
changes <- getAnyChanges
|
|
|
|
if null changes
|
|
|
|
then loop (n - 1)
|
2013-07-27 21:41:41 +00:00
|
|
|
else continue (oldchanges ++ changes)
|
|
|
|
continue cs
|
|
|
|
| null cs = waitchanges 0
|
|
|
|
| otherwise = handlechanges cs 0
|
2013-04-25 04:44:52 +00:00
|
|
|
|
2013-03-11 16:56:47 +00:00
|
|
|
isRmChange :: Change -> Bool
|
|
|
|
isRmChange (Change { changeInfo = i }) | i == RmChange = True
|
|
|
|
isRmChange _ = False
|
|
|
|
|
2013-03-11 01:36:13 +00:00
|
|
|
{- An amount of time that is hopefully imperceptably short for humans,
|
|
|
|
- while long enough for a computer to get some work done.
|
|
|
|
- Note that 0.001 is a little too short for rename change batching to
|
|
|
|
- work. -}
|
|
|
|
humanImperceptibleInterval :: NominalDiffTime
|
|
|
|
humanImperceptibleInterval = 0.01
|
|
|
|
|
|
|
|
humanImperceptibleDelay :: IO ()
|
|
|
|
humanImperceptibleDelay = threadDelay $
|
|
|
|
truncate $ humanImperceptibleInterval * fromIntegral oneSecond
|
|
|
|
|
2013-04-25 04:44:52 +00:00
|
|
|
maxCommitSize :: Int
|
|
|
|
maxCommitSize = 5000
|
|
|
|
|
2013-03-11 01:36:13 +00:00
|
|
|
{- Decide if now is a good time to make a commit.
|
2015-04-19 04:38:29 +00:00
|
|
|
- Note that the list of changes has a random order.
|
2013-03-11 01:36:13 +00:00
|
|
|
-
|
|
|
|
- Current strategy: If there have been 10 changes within the past second,
|
|
|
|
- a batch activity is taking place, so wait for later.
|
|
|
|
-}
|
2013-12-16 19:43:28 +00:00
|
|
|
shouldCommit :: Bool -> UTCTime -> Int -> [Change] -> Bool
|
|
|
|
shouldCommit scanning now len changes
|
|
|
|
| scanning = len >= maxCommitSize
|
2013-03-11 01:36:13 +00:00
|
|
|
| len == 0 = False
|
2013-04-25 04:44:52 +00:00
|
|
|
| len >= maxCommitSize = True
|
2013-03-11 01:36:13 +00:00
|
|
|
| length recentchanges < 10 = True
|
|
|
|
| otherwise = False -- batch activity
|
2012-10-29 15:40:22 +00:00
|
|
|
where
|
2013-03-11 01:36:13 +00:00
|
|
|
thissecond c = timeDelta c <= 1
|
|
|
|
recentchanges = filter thissecond changes
|
|
|
|
timeDelta c = now `diffUTCTime` changeTime c
|
2012-06-13 16:36:33 +00:00
|
|
|
|
2015-02-11 17:33:55 +00:00
|
|
|
commitStaged :: String -> Annex Bool
|
|
|
|
commitStaged msg = do
|
2012-10-02 22:04:06 +00:00
|
|
|
{- This could fail if there's another commit being made by
|
|
|
|
- something else. -}
|
unify exception handling into Utility.Exception
Removed old extensible-exceptions, only needed for very old ghc.
Made webdav use Utility.Exception, to work after some changes in DAV's
exception handling.
Removed Annex.Exception. Mostly this was trivial, but note that
tryAnnex is replaced with tryNonAsync and catchAnnex replaced with
catchNonAsync. In theory that could be a behavior change, since the former
caught all exceptions, and the latter don't catch async exceptions.
However, in practice, nothing in the Annex monad uses async exceptions.
Grepping for throwTo and killThread only find stuff in the assistant,
which does not seem related.
Command.Add.undo is changed to accept a SomeException, and things
that use it for rollback now catch non-async exceptions, rather than
only IOExceptions.
2014-08-08 01:55:44 +00:00
|
|
|
v <- tryNonAsync Annex.Queue.flush
|
2012-10-02 22:04:06 +00:00
|
|
|
case v of
|
|
|
|
Left _ -> return False
|
2014-06-16 15:32:13 +00:00
|
|
|
Right _ -> do
|
2019-11-11 22:20:35 +00:00
|
|
|
cmode <- annexCommitMode <$> Annex.getGitConfig
|
2019-11-11 20:15:05 +00:00
|
|
|
ok <- Command.Sync.commitStaged cmode msg
|
2014-06-16 15:32:13 +00:00
|
|
|
when ok $
|
2018-10-20 18:12:04 +00:00
|
|
|
Command.Sync.updateBranches =<< getCurrentBranch
|
2014-06-16 15:32:13 +00:00
|
|
|
return ok
|
2012-06-13 16:36:33 +00:00
|
|
|
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
{- If there are PendingAddChanges, or InProcessAddChanges, the files
|
2021-07-13 16:15:40 +00:00
|
|
|
- have not yet actually been added, and that has to be done
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
- now, before committing.
|
2012-06-16 00:44:34 +00:00
|
|
|
-
|
|
|
|
- Deferring the adds to this point causes batches to be bundled together,
|
|
|
|
- which allows faster checking with lsof that the files are not still open
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
- for write by some other process, and faster checking with git-ls-files
|
|
|
|
- that the files are not already checked into git.
|
2012-06-16 00:44:34 +00:00
|
|
|
-
|
2015-12-21 22:41:15 +00:00
|
|
|
- When a file is added in locked mode, Inotify will notice the new symlink.
|
|
|
|
- So this waits for additional Changes to arrive, so that the symlink has
|
|
|
|
- hopefully been staged before returning, and will be committed immediately.
|
|
|
|
- (OTOH, for kqueue, eventsCoalesce, so instead the symlink is directly
|
|
|
|
- created and staged.)
|
2012-06-20 23:04:16 +00:00
|
|
|
-
|
|
|
|
- Returns a list of all changes that are ready to be committed.
|
|
|
|
- Any pending adds that are not ready yet are put back into the ChangeChan,
|
|
|
|
- where they will be retried later.
|
2012-06-16 00:44:34 +00:00
|
|
|
-}
|
2021-07-13 16:15:40 +00:00
|
|
|
handleAdds :: FilePath -> Bool -> GetFileMatcher -> Maybe Seconds -> [Change] -> Assistant [Change]
|
|
|
|
handleAdds lockdowndir havelsof largefilematcher delayadd cs = returnWhen (null incomplete) $ do
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
let (pending, inprocess) = partition isPendingAddChange incomplete
|
2016-01-07 21:39:59 +00:00
|
|
|
let lockdownconfig = LockDownConfig
|
2019-08-30 17:54:57 +00:00
|
|
|
{ lockingFile = False
|
2020-11-04 18:20:37 +00:00
|
|
|
, hardlinkFileTmpDir = Just (toRawFilePath lockdowndir)
|
2021-09-02 17:45:21 +00:00
|
|
|
, checkWritePerms = True
|
2016-01-07 21:39:59 +00:00
|
|
|
}
|
2015-12-22 19:23:27 +00:00
|
|
|
(postponed, toadd) <- partitionEithers
|
2019-08-30 17:54:57 +00:00
|
|
|
<$> safeToAdd lockdowndir lockdownconfig havelsof delayadd pending inprocess
|
2012-06-20 23:04:16 +00:00
|
|
|
|
|
|
|
unless (null postponed) $
|
2012-10-29 23:30:23 +00:00
|
|
|
refillChanges postponed
|
2012-06-20 23:04:16 +00:00
|
|
|
|
|
|
|
returnWhen (null toadd) $ do
|
2021-07-13 16:15:40 +00:00
|
|
|
(toaddannexed, toaddsmall) <- partitionEithers
|
|
|
|
<$> mapM checksmall toadd
|
|
|
|
addsmall toaddsmall
|
|
|
|
addedannexed <- addaction toadd $
|
|
|
|
catMaybes <$> addannexed toaddannexed
|
|
|
|
return $ addedannexed ++ toaddsmall ++ otherchanges
|
2012-10-29 15:40:22 +00:00
|
|
|
where
|
|
|
|
(incomplete, otherchanges) = partition (\c -> isPendingAddChange c || isInProcessAddChange c) cs
|
|
|
|
|
|
|
|
returnWhen c a
|
|
|
|
| c = return otherchanges
|
|
|
|
| otherwise = a
|
2012-06-20 23:04:16 +00:00
|
|
|
|
2021-07-13 16:15:40 +00:00
|
|
|
checksmall change =
|
|
|
|
ifM (liftAnnex $ checkFileMatcher largefilematcher (toRawFilePath (changeFile change)))
|
|
|
|
( return (Left change)
|
|
|
|
, return (Right change)
|
|
|
|
)
|
|
|
|
|
|
|
|
addsmall [] = noop
|
|
|
|
addsmall toadd = liftAnnex $ Annex.Queue.addCommand [] "add"
|
|
|
|
[ Param "--force", Param "--"] (map changeFile toadd)
|
2012-06-16 00:44:34 +00:00
|
|
|
|
2015-12-21 22:41:15 +00:00
|
|
|
{- Avoid overhead of re-injesting a renamed unlocked file, by
|
|
|
|
- examining the other Changes to see if a removed file has the
|
|
|
|
- same InodeCache as the new file. If so, we can just update
|
|
|
|
- bookkeeping, and stage the file in git.
|
2013-03-11 16:56:47 +00:00
|
|
|
-}
|
2021-07-13 16:15:40 +00:00
|
|
|
addannexed :: [Change] -> Assistant [Maybe Change]
|
|
|
|
addannexed [] = return []
|
|
|
|
addannexed toadd = do
|
2013-03-11 16:56:47 +00:00
|
|
|
ct <- liftAnnex compareInodeCachesWith
|
2019-08-26 19:52:19 +00:00
|
|
|
m <- liftAnnex $ removedKeysMap ct cs
|
fix for Windows file timestamp timezone madness
On Windows, changing the time zone causes the apparent mtime of files to
change. This confuses git-annex, which natually thinks this means the files
have actually been modified (since THAT'S WHAT A MTIME IS FOR, BILL <sheesh>).
Work around this stupidity, by using the inode sentinal file to detect if
the timezone has changed, and calculate a TSDelta, which will be applied
when generating InodeCaches.
This should add no overhead at all on unix. Indeed, I sped up a few
things slightly in the refactoring.
Seems to basically work! But it has a big known problem:
If the timezone changes while the assistant (or a long-running command)
runs, it won't notice, since it only checks the inode cache once, and
so will use the old delta for all new inode caches it generates for new
files it's added. Which will result in them seeming changed the next time
it runs.
This commit was sponsored by Vincent Demeester.
2014-06-11 21:51:12 +00:00
|
|
|
delta <- liftAnnex getTSDelta
|
2016-01-07 21:39:59 +00:00
|
|
|
let cfg = LockDownConfig
|
|
|
|
{ lockingFile = False
|
2020-11-04 18:20:37 +00:00
|
|
|
, hardlinkFileTmpDir = Just (toRawFilePath lockdowndir)
|
2021-09-02 17:45:21 +00:00
|
|
|
, checkWritePerms = True
|
2016-01-07 21:39:59 +00:00
|
|
|
}
|
2013-03-11 16:56:47 +00:00
|
|
|
if M.null m
|
2021-07-13 16:15:40 +00:00
|
|
|
then forM toadd (addannexed' cfg)
|
2013-03-11 16:56:47 +00:00
|
|
|
else forM toadd $ \c -> do
|
2019-12-11 18:12:22 +00:00
|
|
|
mcache <- liftIO $ genInodeCache (toRawFilePath (changeFile c)) delta
|
2013-03-11 16:56:47 +00:00
|
|
|
case mcache of
|
2021-07-13 16:15:40 +00:00
|
|
|
Nothing -> addannexed' cfg c
|
2013-03-11 16:56:47 +00:00
|
|
|
Just cache ->
|
|
|
|
case M.lookup (inodeCacheToKey ct cache) m of
|
2021-07-13 16:15:40 +00:00
|
|
|
Nothing -> addannexed' cfg c
|
2019-08-26 19:52:19 +00:00
|
|
|
Just k -> fastadd c k
|
2015-12-22 19:23:27 +00:00
|
|
|
|
2021-07-13 16:15:40 +00:00
|
|
|
addannexed' :: LockDownConfig -> Change -> Assistant (Maybe Change)
|
|
|
|
addannexed' lockdownconfig change@(InProcessAddChange { lockedDown = ld }) =
|
|
|
|
catchDefaultIO Nothing <~> doadd
|
|
|
|
where
|
|
|
|
ks = keySource ld
|
|
|
|
doadd = sanitycheck ks $ do
|
|
|
|
(mkey, _mcache) <- liftAnnex $ do
|
|
|
|
showStart "add" (keyFilename ks) (SeekInput [])
|
|
|
|
ingest nullMeterUpdate (Just $ LockedDown lockdownconfig ks) Nothing
|
|
|
|
maybe (failedingest change) (done change $ fromRawFilePath $ keyFilename ks) mkey
|
|
|
|
addannexed' _ _ = return Nothing
|
|
|
|
|
2019-08-26 19:52:19 +00:00
|
|
|
fastadd :: Change -> Key -> Assistant (Maybe Change)
|
|
|
|
fastadd change key = do
|
2015-12-22 19:23:27 +00:00
|
|
|
let source = keySource $ lockedDown change
|
2019-08-26 19:52:19 +00:00
|
|
|
liftAnnex $ finishIngestUnlocked key source
|
2020-02-21 13:34:59 +00:00
|
|
|
done change (fromRawFilePath $ keyFilename source) key
|
2013-03-11 16:56:47 +00:00
|
|
|
|
2019-08-26 19:52:19 +00:00
|
|
|
removedKeysMap :: InodeComparisonType -> [Change] -> Annex (M.Map InodeCacheKey Key)
|
|
|
|
removedKeysMap ct l = do
|
2013-03-11 16:56:47 +00:00
|
|
|
mks <- forM (filter isRmChange l) $ \c ->
|
2019-12-05 19:10:23 +00:00
|
|
|
catKeyFile $ toRawFilePath $ changeFile c
|
2013-04-06 20:01:39 +00:00
|
|
|
M.fromList . concat <$> mapM mkpairs (catMaybes mks)
|
2013-03-11 16:56:47 +00:00
|
|
|
where
|
2013-04-06 20:01:39 +00:00
|
|
|
mkpairs k = map (\c -> (inodeCacheToKey ct c, k)) <$>
|
2019-08-26 19:52:19 +00:00
|
|
|
Database.Keys.getInodeCaches k
|
2013-03-11 16:56:47 +00:00
|
|
|
|
2013-04-23 22:23:04 +00:00
|
|
|
failedingest change = do
|
2013-04-24 20:26:55 +00:00
|
|
|
refill [retryChange change]
|
2012-10-29 15:40:22 +00:00
|
|
|
liftAnnex showEndFail
|
|
|
|
return Nothing
|
2013-03-10 22:16:03 +00:00
|
|
|
|
2019-08-30 17:54:57 +00:00
|
|
|
done change file key = liftAnnex $ do
|
2013-03-11 18:14:45 +00:00
|
|
|
logStatus key InfoPresent
|
2023-03-01 19:55:58 +00:00
|
|
|
mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus (toRawFilePath file)
|
2019-12-05 19:10:23 +00:00
|
|
|
stagePointerFile (toRawFilePath file) mode =<< hashPointerFile key
|
2013-03-17 21:01:43 +00:00
|
|
|
showEndOk
|
2013-03-10 22:16:03 +00:00
|
|
|
return $ Just $ finishedChange change key
|
2012-06-16 02:35:29 +00:00
|
|
|
|
2012-10-29 15:40:22 +00:00
|
|
|
{- Check that the keysource's keyFilename still exists,
|
|
|
|
- and is still a hard link to its contentLocation,
|
|
|
|
- before ingesting it. -}
|
|
|
|
sanitycheck keysource a = do
|
2023-03-01 19:55:58 +00:00
|
|
|
fs <- liftIO $ R.getSymbolicLinkStatus $ keyFilename keysource
|
|
|
|
ks <- liftIO $ R.getSymbolicLinkStatus $ contentLocation keysource
|
2012-10-29 15:40:22 +00:00
|
|
|
if deviceID ks == deviceID fs && fileID ks == fileID fs
|
|
|
|
then a
|
2012-11-29 20:46:59 +00:00
|
|
|
else do
|
|
|
|
-- remove the hard link
|
2013-02-14 18:10:36 +00:00
|
|
|
when (contentLocation keysource /= keyFilename keysource) $
|
2020-02-21 13:34:59 +00:00
|
|
|
void $ liftIO $ tryIO $ removeFile $ fromRawFilePath $ contentLocation keysource
|
2012-11-29 20:46:59 +00:00
|
|
|
return Nothing
|
2012-06-21 00:05:40 +00:00
|
|
|
|
2013-04-24 17:04:46 +00:00
|
|
|
{- Shown an alert while performing an action to add a file or
|
2013-07-10 19:37:40 +00:00
|
|
|
- files. When only a few files are added, their names are shown
|
2013-04-24 17:04:46 +00:00
|
|
|
- in the alert. When it's a batch add, the number of files added
|
|
|
|
- is shown.
|
|
|
|
-
|
|
|
|
- Add errors tend to be transient and will be
|
|
|
|
- automatically dealt with, so the alert is always told
|
|
|
|
- the add succeeded.
|
|
|
|
-}
|
|
|
|
addaction [] a = a
|
2013-07-10 19:37:40 +00:00
|
|
|
addaction toadd a = alertWhile' (addFileAlert $ map changeFile toadd) $
|
2013-04-24 17:04:46 +00:00
|
|
|
(,)
|
|
|
|
<$> pure True
|
|
|
|
<*> a
|
|
|
|
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
{- Files can Either be Right to be added now,
|
2012-06-20 23:04:16 +00:00
|
|
|
- or are unsafe, and must be Left for later.
|
|
|
|
-
|
2013-02-15 17:08:22 +00:00
|
|
|
- Check by running lsof on the repository.
|
2012-06-16 02:35:29 +00:00
|
|
|
-}
|
2019-05-07 17:04:39 +00:00
|
|
|
safeToAdd :: FilePath -> LockDownConfig -> Bool -> Maybe Seconds -> [Change] -> [Change] -> Assistant [Either Change Change]
|
|
|
|
safeToAdd _ _ _ _ [] [] = return []
|
|
|
|
safeToAdd lockdowndir lockdownconfig havelsof delayadd pending inprocess = do
|
2012-10-29 15:40:22 +00:00
|
|
|
maybe noop (liftIO . threadDelaySeconds) delayadd
|
|
|
|
liftAnnex $ do
|
2016-01-07 21:39:59 +00:00
|
|
|
lockeddown <- forM pending $ lockDown lockdownconfig . changeFile
|
2015-12-22 19:23:27 +00:00
|
|
|
let inprocess' = inprocess ++ mapMaybe mkinprocess (zip pending lockeddown)
|
2013-12-04 21:39:44 +00:00
|
|
|
openfiles <- if havelsof
|
|
|
|
then S.fromList . map fst3 . filter openwrite <$>
|
2015-12-22 19:23:27 +00:00
|
|
|
findopenfiles (map (keySource . lockedDown) inprocess')
|
2013-12-04 21:39:44 +00:00
|
|
|
else pure S.empty
|
2013-02-15 17:08:22 +00:00
|
|
|
let checked = map (check openfiles) inprocess'
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
|
|
|
|
{- If new events are received when files are closed,
|
|
|
|
- there's no need to retry any changes that cannot
|
|
|
|
- be done now. -}
|
|
|
|
if DirWatcher.closingTracked
|
|
|
|
then do
|
|
|
|
mapM_ canceladd $ lefts checked
|
|
|
|
allRight $ rights checked
|
|
|
|
else return checked
|
2012-10-29 15:40:22 +00:00
|
|
|
where
|
2015-12-22 19:23:27 +00:00
|
|
|
check openfiles change@(InProcessAddChange { lockedDown = ld })
|
2020-02-21 13:34:59 +00:00
|
|
|
| S.member (fromRawFilePath (contentLocation (keySource ld))) openfiles = Left change
|
2012-10-29 15:40:22 +00:00
|
|
|
check _ change = Right change
|
2012-06-20 23:04:16 +00:00
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
mkinprocess (c, Just ld) = Just InProcessAddChange
|
2012-10-29 15:40:22 +00:00
|
|
|
{ changeTime = changeTime c
|
2015-12-22 19:23:27 +00:00
|
|
|
, lockedDown = ld
|
2012-10-29 15:40:22 +00:00
|
|
|
}
|
2013-01-14 19:02:13 +00:00
|
|
|
mkinprocess (_, Nothing) = Nothing
|
always check with ls-files before adding new files
Makes it safe to use git annex unlock with the watcher/assistant.
And also to mix use of the watcher/assistant with regular files stored in git.
Long ago, I had avoided doing this check, except during the startup scan,
because it would be slow to run ls-files repeatedly.
But then I added the lsof check, and to make that fast, got it to detect
batch file adds. So let's move the ls-files check to also occur when it'll
have a batch, and can check them all with one call.
This does slow down adding a single file by just a bit, but really only
a little bit. (The lsof check is probably more expensive.) It also
speeds up the startup scan, especially when there are lots of new files
found by the scan.
Also, fixed the sleep for annex.delayadd to not run while the threadstate
lock is held, so it doesn't unnecessarily freeze everything else.
Also, --force no longer makes it skip the lsof check, which was not
documented, and seems never a good idea.
2012-10-02 21:34:22 +00:00
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
canceladd (InProcessAddChange { lockedDown = ld }) = do
|
|
|
|
let ks = keySource ld
|
2020-02-21 13:34:59 +00:00
|
|
|
warning $ fromRawFilePath (keyFilename ks)
|
2012-10-29 15:40:22 +00:00
|
|
|
++ " still has writers, not adding"
|
|
|
|
-- remove the hard link
|
2013-02-14 18:10:36 +00:00
|
|
|
when (contentLocation ks /= keyFilename ks) $
|
2020-02-21 13:34:59 +00:00
|
|
|
void $ liftIO $ tryIO $ removeFile $ fromRawFilePath $ contentLocation ks
|
2012-10-29 15:40:22 +00:00
|
|
|
canceladd _ = noop
|
2012-06-16 02:35:29 +00:00
|
|
|
|
2013-02-11 21:24:12 +00:00
|
|
|
openwrite (_file, mode, _pid)
|
|
|
|
| mode == Lsof.OpenWriteOnly = True
|
|
|
|
| mode == Lsof.OpenReadWrite = True
|
|
|
|
| mode == Lsof.OpenUnknown = True
|
|
|
|
| otherwise = False
|
2012-06-20 23:04:16 +00:00
|
|
|
|
2012-10-29 15:40:22 +00:00
|
|
|
allRight = return . map Right
|
2013-02-15 17:08:22 +00:00
|
|
|
|
2019-05-07 17:04:39 +00:00
|
|
|
{- Normally the KeySources are locked down inside the lockdowndir,
|
2013-02-15 17:08:22 +00:00
|
|
|
- so can just lsof that, which is quite efficient.
|
|
|
|
-
|
|
|
|
- In crippled filesystem mode, there is no lock down, so must run lsof
|
|
|
|
- on each individual file.
|
|
|
|
-}
|
|
|
|
findopenfiles keysources = ifM crippledFileSystem
|
|
|
|
( liftIO $ do
|
2020-02-21 13:34:59 +00:00
|
|
|
let segments = segmentXargsUnordered $
|
|
|
|
map (fromRawFilePath . keyFilename) keysources
|
2013-02-15 17:08:22 +00:00
|
|
|
concat <$> forM segments (\fs -> Lsof.query $ "--" : fs)
|
2019-05-07 17:04:39 +00:00
|
|
|
, liftIO $ Lsof.queryDir lockdowndir
|
2013-02-15 17:08:22 +00:00
|
|
|
)
|
2013-03-10 22:16:03 +00:00
|
|
|
|
|
|
|
{- After a Change is committed, queue any necessary transfers or drops
|
|
|
|
- of the content of the key.
|
|
|
|
-
|
|
|
|
- This is not done during the startup scan, because the expensive
|
|
|
|
- transfer scan does the same thing then.
|
|
|
|
-}
|
|
|
|
checkChangeContent :: Change -> Assistant ()
|
2013-03-11 17:52:06 +00:00
|
|
|
checkChangeContent change@(Change { changeInfo = i }) =
|
2013-03-10 22:16:03 +00:00
|
|
|
case changeInfoKey i of
|
|
|
|
Nothing -> noop
|
|
|
|
Just k -> whenM (scanComplete <$> getDaemonStatus) $ do
|
|
|
|
present <- liftAnnex $ inAnnex k
|
2014-01-23 20:51:16 +00:00
|
|
|
void $ if present
|
2017-03-10 17:12:24 +00:00
|
|
|
then queueTransfers "new file created" Next k af Upload
|
|
|
|
else queueTransfers "new or renamed file wanted" Next k af Download
|
|
|
|
handleDrops "file renamed" present k af []
|
2013-03-11 17:52:06 +00:00
|
|
|
where
|
|
|
|
f = changeFile change
|
2019-12-05 19:10:23 +00:00
|
|
|
af = AssociatedFile (Just (toRawFilePath f))
|
2013-03-10 22:16:03 +00:00
|
|
|
checkChangeContent _ = noop
|