2012-06-19 06:40:21 +00:00
|
|
|
{- git-annex assistant commit thread
|
2012-06-13 16:36:33 +00:00
|
|
|
-
|
|
|
|
- Copyright 2012 Joey Hess <joey@kitenet.net>
|
2012-06-23 05:20:40 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
2012-06-13 16:36:33 +00:00
|
|
|
-}
|
|
|
|
|
2012-10-04 23:56:32 +00:00
|
|
|
{-# LANGUAGE CPP, BangPatterns #-}
|
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-06-22 17:39:44 +00:00
|
|
|
import Assistant.Commits
|
2012-08-02 13:03:04 +00:00
|
|
|
import Assistant.Alert
|
2012-06-13 16:36:33 +00:00
|
|
|
import Assistant.ThreadedMonad
|
2012-06-25 20:10:10 +00:00
|
|
|
import Assistant.Threads.Watcher
|
2012-07-05 16:21:22 +00:00
|
|
|
import Assistant.TransferQueue
|
|
|
|
import Assistant.DaemonStatus
|
|
|
|
import Logs.Transfer
|
2012-06-13 16:36:33 +00:00
|
|
|
import qualified Annex.Queue
|
|
|
|
import qualified Git.Command
|
2012-06-19 06:40:21 +00:00
|
|
|
import qualified Git.HashObject
|
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 qualified Git.LsFiles
|
2012-09-19 16:58:53 +00:00
|
|
|
import qualified Git.Version
|
2012-06-19 06:40:21 +00:00
|
|
|
import Git.Types
|
preliminary deferring of file adds to commit time
Defer adding files to the annex until commit time, when during a batch
operation, a bundle of files will be available. This will allow for
checking a them all with a single lsof call.
The tricky part is that adding the file causes a symlink change inotify.
So I made it wait for an appropriate number of symlink changes to be
received before continuing with the commit. This avoids any delay
in the commit process. It is possible that some unrelated symlink change is
made; if that happens it'll commit it and delay committing the newly added
symlink for 1 second. This seems ok. I do rely on the expected symlink
change event always being received, but only when the add succeeds.
Another way to do it might be to directly stage the symlink, and then
ignore the redundant symlink change event. That would involve some
redundant work, and perhaps an empty commit, but if this code turns
out to have some bug, that'd be the best way to avoid it.
FWIW, this change seems to, as a bonus, have produced better grouping
of batch changes into single commits. Before, a large batch change would
result in a series of commits, with the first containing only one file,
and each of the rest bundling a number of files. Now, the added wait for
the symlink changes to arrive gives time for additional add changes to
be processed, all within the same commit.
2012-06-15 20:27:44 +00:00
|
|
|
import qualified Command.Add
|
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
|
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-10-02 22:04:06 +00:00
|
|
|
import Annex.Exception
|
2012-06-13 16:36:33 +00:00
|
|
|
|
|
|
|
import Data.Time.Clock
|
2012-06-16 02:35:29 +00:00
|
|
|
import Data.Tuple.Utils
|
|
|
|
import qualified Data.Set as S
|
2012-06-20 23:04:16 +00:00
|
|
|
import Data.Either
|
2012-06-13 16:36:33 +00:00
|
|
|
|
2012-07-20 23:29:59 +00:00
|
|
|
thisThread :: ThreadName
|
|
|
|
thisThread = "Committer"
|
|
|
|
|
2012-06-13 16:36:33 +00:00
|
|
|
{- This thread makes git commits at appropriate times. -}
|
2012-09-06 18:56:04 +00:00
|
|
|
commitThread :: ThreadState -> ChangeChan -> CommitChan -> TransferQueue -> DaemonStatusHandle -> NamedThread
|
2012-10-29 06:21:04 +00:00
|
|
|
commitThread st changechan commitchan transferqueue dstatus = thread $ liftIO $ 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
|
|
|
delayadd <- runThreadState st $
|
|
|
|
maybe delayaddDefault (Just . Seconds) . readish
|
|
|
|
<$> getConfig (annexConfig "delayadd") ""
|
|
|
|
runEvery (Seconds 1) $ do
|
|
|
|
-- We already waited one second as a simple rate limiter.
|
|
|
|
-- Next, wait until at least one change is available for
|
|
|
|
-- processing.
|
|
|
|
changes <- getChanges changechan
|
|
|
|
-- Now see if now's a good time to commit.
|
|
|
|
time <- getCurrentTime
|
|
|
|
if shouldCommit time changes
|
|
|
|
then do
|
|
|
|
readychanges <- handleAdds delayadd st changechan transferqueue dstatus changes
|
|
|
|
if shouldCommit time readychanges
|
|
|
|
then do
|
2012-10-29 06:21:04 +00:00
|
|
|
brokendebug thisThread
|
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
|
|
|
[ "committing"
|
|
|
|
, show (length readychanges)
|
|
|
|
, "changes"
|
|
|
|
]
|
|
|
|
void $ alertWhile dstatus commitAlert $
|
|
|
|
runThreadState st commitStaged
|
ensure that git-annex branch is pushed after a successful transfer
I now have this topology working:
assistant ---> {bare repo, special remote} <--- assistant
And, I think, also this one:
+----------- bare repo --------+
v v
assistant ---> special remote <--- assistant
While before with assistant <---> assistant connections, both sides got
location info updated after a transfer, in this topology, the bare repo
*might* get its location info updated, but the other assistant has no way to
know that it did. And a special remote doesn't record location info,
so transfers to it won't propigate out location log changes at all.
So, for these to work, after a transfer succeeds, the git-annex branch
needs to be pushed. This is done by recording a synthetic commit has
occurred, which lets the pusher handle pushing out the change (which will
include actually committing any still journalled changes to the git-annex
branch).
Of course, this means rather a lot more syncing action than happened
before. At least the pusher bundles together very close together pushes,
somewhat. Currently it just waits 2 seconds between each push.
2012-10-28 20:05:34 +00:00
|
|
|
recordCommit commitchan
|
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
|
|
|
else refill readychanges
|
|
|
|
else refill changes
|
2012-07-20 23:29:59 +00:00
|
|
|
where
|
2012-09-06 18:56:04 +00:00
|
|
|
thread = NamedThread thisThread
|
2012-07-29 17:55:07 +00:00
|
|
|
refill [] = noop
|
2012-07-20 23:29:59 +00:00
|
|
|
refill cs = do
|
2012-10-29 06:21:04 +00:00
|
|
|
brokendebug thisThread
|
2012-07-20 23:29:59 +00:00
|
|
|
[ "delaying commit of"
|
|
|
|
, show (length cs)
|
|
|
|
, "changes"
|
|
|
|
]
|
|
|
|
refillChanges changechan cs
|
|
|
|
|
2012-06-13 16:36:33 +00:00
|
|
|
|
run current branch merge in annex monad
I was seeing some interesting crashes after the previous commit,
when making file changes slightly faster than the assistant could keep up.
error: Ref refs/heads/master is at 7074f8e0a11110c532d06746e334f2fec6af6ab4 but expected 95ea86008d72a40d97a81cfc8fb47a0da92166bd
fatal: cannot lock HEAD ref
Committer crashed: git commit [Param "--allow-empty-message",Param "-m",Param "",Param "--allow-empty",Param "--quiet"] failed
Pusher crashed: thread blocked indefinitely in an STM transaction
Clearly the the merger ended up running at the same time as the committer,
and with both modifying HEAD the committer crashed. I fixed that by
making the Merger run its merge inside the annex monad, which avoids
it running concurrently with other git operations. Also by making
the committer not crash if git fails.
What I don't understand is why the pusher then crashed with a STM deadlock.
That must be in either the DaemonStatusHandle or the FailedPushMap,
and the latter is only used by the pusher. Did the committer's crash somehow
break STM?
The BlockedIndefinitelyOnSTM exception is described as:
-- |The thread is waiting to retry an STM transaction, but there are no
-- other references to any @TVar@s involved, so it can't ever continue.
If the Committer had a reference to a TVar and crashed, I can sort of see
this leading to that exception..
The crash was quite easy to reproduce after the previous commit, but
after making the above change, I have yet to see it again. Here's hoping.
2012-09-18 01:32:30 +00:00
|
|
|
commitStaged :: Annex Bool
|
2012-06-13 16:36:33 +00:00
|
|
|
commitStaged = do
|
2012-10-02 22:04:06 +00:00
|
|
|
{- This could fail if there's another commit being made by
|
|
|
|
- something else. -}
|
|
|
|
v <- tryAnnex Annex.Queue.flush
|
|
|
|
case v of
|
|
|
|
Left _ -> return False
|
|
|
|
Right _ -> do
|
|
|
|
void $ inRepo $ Git.Command.runBool "commit" $ nomessage
|
|
|
|
[ Param "--quiet"
|
|
|
|
{- Avoid running the usual git-annex pre-commit hook;
|
|
|
|
- watch does the same symlink fixing, and we don't want
|
|
|
|
- to deal with unlocked files in these commits. -}
|
|
|
|
, Param "--no-verify"
|
|
|
|
]
|
|
|
|
{- Empty commits may be made if tree changes cancel
|
|
|
|
- each other out, etc. Git returns nonzero on those,
|
|
|
|
- so don't propigate out commit failures. -}
|
|
|
|
return True
|
2012-09-19 16:58:53 +00:00
|
|
|
where
|
|
|
|
nomessage ps
|
|
|
|
| Git.Version.older "1.7.2" = Param "-m"
|
|
|
|
: Param "autocommit" : ps
|
|
|
|
| otherwise = Param "--allow-empty-message"
|
|
|
|
: Param "-m" : Param "" : ps
|
2012-06-13 16:36:33 +00:00
|
|
|
|
|
|
|
{- Decide if now is a good time to make a commit.
|
|
|
|
- Note that the list of change times has an undefined order.
|
|
|
|
-
|
preliminary deferring of file adds to commit time
Defer adding files to the annex until commit time, when during a batch
operation, a bundle of files will be available. This will allow for
checking a them all with a single lsof call.
The tricky part is that adding the file causes a symlink change inotify.
So I made it wait for an appropriate number of symlink changes to be
received before continuing with the commit. This avoids any delay
in the commit process. It is possible that some unrelated symlink change is
made; if that happens it'll commit it and delay committing the newly added
symlink for 1 second. This seems ok. I do rely on the expected symlink
change event always being received, but only when the add succeeds.
Another way to do it might be to directly stage the symlink, and then
ignore the redundant symlink change event. That would involve some
redundant work, and perhaps an empty commit, but if this code turns
out to have some bug, that'd be the best way to avoid it.
FWIW, this change seems to, as a bonus, have produced better grouping
of batch changes into single commits. Before, a large batch change would
result in a series of commits, with the first containing only one file,
and each of the rest bundling a number of files. Now, the added wait for
the symlink changes to arrive gives time for additional add changes to
be processed, all within the same commit.
2012-06-15 20:27:44 +00:00
|
|
|
- Current strategy: If there have been 10 changes within the past second,
|
2012-06-13 16:36:33 +00:00
|
|
|
- a batch activity is taking place, so wait for later.
|
|
|
|
-}
|
|
|
|
shouldCommit :: UTCTime -> [Change] -> Bool
|
|
|
|
shouldCommit now changes
|
|
|
|
| len == 0 = False
|
|
|
|
| len > 10000 = True -- avoid bloating queue too much
|
|
|
|
| length (filter thisSecond changes) < 10 = True
|
|
|
|
| otherwise = False -- batch activity
|
|
|
|
where
|
|
|
|
len = length changes
|
|
|
|
thisSecond c = now `diffUTCTime` changeTime c <= 1
|
2012-06-16 00:44:34 +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
|
|
|
{- OSX needs a short delay after a file is added before locking it down,
|
|
|
|
- as pasting a file seems to try to set file permissions or otherwise
|
|
|
|
- access the file after closing it. -}
|
|
|
|
delayaddDefault :: Maybe Seconds
|
|
|
|
#ifdef darwin_HOST_OS
|
|
|
|
delayaddDefault = Just $ Seconds 1
|
|
|
|
#else
|
|
|
|
delayaddDefault = Nothing
|
|
|
|
#endif
|
|
|
|
|
|
|
|
{- If there are PendingAddChanges, or InProcessAddChanges, the files
|
|
|
|
- have not yet actually been added to the annex, and that has to be done
|
|
|
|
- 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
|
|
|
-
|
|
|
|
- When a file is added, Inotify will notice the new symlink. So this waits
|
|
|
|
- for additional Changes to arrive, so that the symlink has hopefully been
|
2012-06-20 20:07:14 +00:00
|
|
|
- staged before returning, and will be committed immediately.
|
|
|
|
-
|
|
|
|
- OTOH, for kqueue, eventsCoalesce, so instead the symlink is directly
|
2012-06-20 23:04:16 +00:00
|
|
|
- created and staged.
|
|
|
|
-
|
|
|
|
- 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
|
|
|
-}
|
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
|
|
|
handleAdds :: Maybe Seconds -> ThreadState -> ChangeChan -> TransferQueue -> DaemonStatusHandle -> [Change] -> IO [Change]
|
|
|
|
handleAdds delayadd st changechan transferqueue dstatus cs = returnWhen (null incomplete) $ do
|
|
|
|
let (pending, inprocess) = partition isPendingAddChange incomplete
|
|
|
|
pending' <- findnew pending
|
|
|
|
(postponed, toadd) <- partitionEithers <$> safeToAdd delayadd st pending' inprocess
|
2012-06-20 23:04:16 +00:00
|
|
|
|
|
|
|
unless (null postponed) $
|
|
|
|
refillChanges changechan postponed
|
|
|
|
|
|
|
|
returnWhen (null toadd) $ do
|
|
|
|
added <- catMaybes <$> forM toadd add
|
2012-09-13 04:57:52 +00:00
|
|
|
if DirWatcher.eventsCoalesce || null added
|
2012-06-20 23:04:16 +00:00
|
|
|
then return $ added ++ otherchanges
|
|
|
|
else 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
|
|
|
r <- handleAdds delayadd st changechan transferqueue dstatus
|
2012-06-19 06:40:21 +00:00
|
|
|
=<< getChanges changechan
|
2012-06-20 23:04:16 +00:00
|
|
|
return $ r ++ added ++ otherchanges
|
2012-06-16 00:44:34 +00:00
|
|
|
where
|
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
|
|
|
(incomplete, otherchanges) = partition (\c -> isPendingAddChange c || isInProcessAddChange c) cs
|
|
|
|
|
|
|
|
findnew [] = return []
|
2012-10-21 04:34:48 +00:00
|
|
|
findnew pending@(exemplar:_) = do
|
2012-10-04 23:56:32 +00:00
|
|
|
(!newfiles, cleanup) <- runThreadState st $
|
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
|
|
|
inRepo (Git.LsFiles.notInRepo False $ map changeFile pending)
|
2012-10-04 23:56:32 +00:00
|
|
|
void cleanup
|
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
|
|
|
-- note: timestamp info is lost here
|
2012-10-21 04:34:48 +00:00
|
|
|
let ts = changeTime exemplar
|
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
|
|
|
return $ map (PendingAddChange ts) newfiles
|
2012-06-20 23:04:16 +00:00
|
|
|
|
|
|
|
returnWhen c a
|
|
|
|
| c = return otherchanges
|
|
|
|
| otherwise = a
|
2012-06-16 00:44:34 +00:00
|
|
|
|
2012-06-20 23:04:16 +00:00
|
|
|
add :: Change -> IO (Maybe Change)
|
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
|
|
|
add change@(InProcessAddChange { keySource = ks }) =
|
2012-08-02 13:03:04 +00:00
|
|
|
alertWhile' dstatus (addFileAlert $ keyFilename ks) $
|
2012-08-02 17:57:34 +00:00
|
|
|
liftM ret $ catchMaybeIO $
|
2012-08-02 13:03:04 +00:00
|
|
|
sanitycheck ks $ runThreadState st $ do
|
|
|
|
showStart "add" $ keyFilename ks
|
|
|
|
key <- Command.Add.ingest ks
|
2012-10-02 22:04:06 +00:00
|
|
|
done (finishedChange change) (keyFilename ks) key
|
2012-08-02 17:57:34 +00:00
|
|
|
where
|
|
|
|
{- Add errors tend to be transient and will
|
|
|
|
- be automatically dealt with, so don't
|
|
|
|
- pass to the alert code. -}
|
|
|
|
ret (Just j@(Just _)) = (True, j)
|
|
|
|
ret _ = (True, Nothing)
|
2012-06-20 23:04:16 +00:00
|
|
|
add _ = return Nothing
|
2012-06-16 00:44:34 +00:00
|
|
|
|
2012-10-02 22:04:06 +00:00
|
|
|
done _ _ Nothing = do
|
2012-06-16 00:44:34 +00:00
|
|
|
showEndFail
|
2012-06-20 23:04:16 +00:00
|
|
|
return Nothing
|
2012-10-02 22:04:06 +00:00
|
|
|
done change file (Just key) = do
|
2012-06-19 06:40:21 +00:00
|
|
|
link <- Command.Add.link file key True
|
|
|
|
when DirWatcher.eventsCoalesce $ do
|
|
|
|
sha <- inRepo $
|
|
|
|
Git.HashObject.hashObject BlobObject link
|
|
|
|
stageSymlink file sha
|
2012-10-09 17:49:27 +00:00
|
|
|
queueTransfers Next transferqueue dstatus key (Just file) Upload
|
2012-06-16 00:44:34 +00:00
|
|
|
showEndOk
|
2012-06-20 23:04:16 +00:00
|
|
|
return $ Just change
|
2012-06-16 02:35:29 +00:00
|
|
|
|
2012-06-21 00:05:40 +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
|
|
|
|
fs <- getSymbolicLinkStatus $ keyFilename keysource
|
|
|
|
ks <- getSymbolicLinkStatus $ contentLocation keysource
|
|
|
|
if deviceID ks == deviceID fs && fileID ks == fileID fs
|
|
|
|
then a
|
|
|
|
else return 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
|
|
|
{- 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.
|
|
|
|
-
|
|
|
|
- Check by running lsof on the temp directory, which
|
|
|
|
- the KeySources are locked down in.
|
2012-06-16 02:35:29 +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
|
|
|
safeToAdd :: Maybe Seconds -> ThreadState -> [Change] -> [Change] -> IO [Either Change Change]
|
|
|
|
safeToAdd _ _ [] [] = return []
|
|
|
|
safeToAdd delayadd st pending inprocess = do
|
|
|
|
maybe noop threadDelaySeconds delayadd
|
|
|
|
runThreadState st $ do
|
|
|
|
keysources <- mapM Command.Add.lockDown (map changeFile pending)
|
|
|
|
let inprocess' = map mkinprocess (zip pending keysources)
|
|
|
|
tmpdir <- fromRepo gitAnnexTmpDir
|
|
|
|
openfiles <- S.fromList . map fst3 . filter openwrite <$>
|
|
|
|
liftIO (Lsof.queryDir tmpdir)
|
|
|
|
let checked = map (check openfiles) $ inprocess ++ inprocess'
|
|
|
|
|
|
|
|
{- 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-06-16 02:35:29 +00:00
|
|
|
where
|
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
|
|
|
check openfiles change@(InProcessAddChange { keySource = ks })
|
2012-06-20 23:04:16 +00:00
|
|
|
| S.member (contentLocation ks) openfiles = Left change
|
|
|
|
check _ change = Right change
|
|
|
|
|
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
|
|
|
mkinprocess (c, ks) = InProcessAddChange
|
|
|
|
{ changeTime = changeTime c
|
|
|
|
, keySource = ks
|
|
|
|
}
|
|
|
|
|
|
|
|
canceladd (InProcessAddChange { keySource = ks }) = do
|
2012-06-20 23:04:16 +00:00
|
|
|
warning $ keyFilename ks
|
|
|
|
++ " still has writers, not adding"
|
2012-06-20 20:07:14 +00:00
|
|
|
-- remove the hard link
|
2012-06-20 23:04:16 +00:00
|
|
|
void $ liftIO $ tryIO $
|
|
|
|
removeFile $ contentLocation ks
|
|
|
|
canceladd _ = noop
|
2012-06-16 02:35:29 +00:00
|
|
|
|
|
|
|
openwrite (_file, mode, _pid) =
|
|
|
|
mode == Lsof.OpenWriteOnly || mode == Lsof.OpenReadWrite
|
2012-06-20 23:04:16 +00:00
|
|
|
|
|
|
|
allRight = return . map Right
|