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-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-06-25 20:10:10 +00:00
|
|
|
import Assistant.Threads.Watcher
|
2012-07-05 16:21:22 +00:00
|
|
|
import Assistant.TransferQueue
|
|
|
|
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
|
|
|
|
|
|
|
{- This thread makes git commits at appropriate times. -}
|
2012-10-29 15:40:22 +00:00
|
|
|
commitThread :: NamedThread
|
|
|
|
commitThread = NamedThread "Committer" $ do
|
|
|
|
delayadd <- liftAnnex $
|
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
|
|
|
maybe delayaddDefault (Just . Seconds) . readish
|
|
|
|
<$> getConfig (annexConfig "delayadd") ""
|
2012-10-29 15:40:22 +00:00
|
|
|
runEvery (Seconds 1) <~> 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
|
|
|
-- We already waited one second as a simple rate limiter.
|
|
|
|
-- Next, wait until at least one change is available for
|
|
|
|
-- processing.
|
2012-10-29 23:30:23 +00:00
|
|
|
changes <- getChanges
|
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 see if now's a good time to commit.
|
2012-10-29 15:40:22 +00:00
|
|
|
time <- liftIO getCurrentTime
|
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 shouldCommit time changes
|
|
|
|
then do
|
2012-10-29 15:40:22 +00:00
|
|
|
readychanges <- handleAdds delayadd changes
|
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 shouldCommit time readychanges
|
|
|
|
then do
|
2012-10-29 15:40:22 +00:00
|
|
|
debug
|
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"
|
|
|
|
]
|
2012-10-29 20:49:47 +00:00
|
|
|
void $ alertWhile commitAlert $
|
2012-10-29 15:40:22 +00:00
|
|
|
liftAnnex commitStaged
|
2012-10-29 23:35:18 +00:00
|
|
|
recordCommit
|
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-10-29 15:40:22 +00:00
|
|
|
where
|
|
|
|
refill [] = noop
|
|
|
|
refill cs = do
|
|
|
|
debug ["delaying commit of", show (length cs), "changes"]
|
2012-10-29 23:30:23 +00:00
|
|
|
refillChanges 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-10-29 15:40:22 +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
|
2012-10-29 15:40:22 +00:00
|
|
|
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
|
|
|
-}
|
2012-10-29 15:40:22 +00:00
|
|
|
handleAdds :: Maybe Seconds -> [Change] -> Assistant [Change]
|
|
|
|
handleAdds 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
|
|
|
|
pending' <- findnew pending
|
2012-10-29 15:40:22 +00:00
|
|
|
(postponed, toadd) <- partitionEithers <$> safeToAdd 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
|
|
|
|
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
|
2012-10-29 23:30:23 +00:00
|
|
|
r <- handleAdds delayadd =<< getChanges
|
2012-06-20 23:04:16 +00:00
|
|
|
return $ r ++ added ++ otherchanges
|
2012-10-29 15:40:22 +00:00
|
|
|
where
|
|
|
|
(incomplete, otherchanges) = partition (\c -> isPendingAddChange c || isInProcessAddChange c) cs
|
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-10-29 15:40:22 +00:00
|
|
|
findnew [] = return []
|
|
|
|
findnew pending@(exemplar:_) = do
|
|
|
|
(!newfiles, cleanup) <- liftAnnex $
|
|
|
|
inRepo (Git.LsFiles.notInRepo False $ map changeFile pending)
|
|
|
|
void $ liftIO cleanup
|
|
|
|
-- note: timestamp info is lost here
|
|
|
|
let ts = changeTime exemplar
|
|
|
|
return $ map (PendingAddChange ts) newfiles
|
|
|
|
|
|
|
|
returnWhen c a
|
|
|
|
| c = return otherchanges
|
|
|
|
| otherwise = a
|
2012-06-20 23:04:16 +00:00
|
|
|
|
2012-10-29 15:40:22 +00:00
|
|
|
add :: Change -> Assistant (Maybe Change)
|
|
|
|
add change@(InProcessAddChange { keySource = ks }) = do
|
2012-10-29 20:49:47 +00:00
|
|
|
alertWhile' (addFileAlert $ keyFilename ks) $
|
|
|
|
liftM ret $ catchMaybeIO <~> do
|
|
|
|
sanitycheck ks $ do
|
|
|
|
key <- liftAnnex $ do
|
|
|
|
showStart "add" $ keyFilename ks
|
|
|
|
Command.Add.ingest ks
|
|
|
|
done (finishedChange change) (keyFilename ks) key
|
2012-10-29 15:40:22 +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-10-29 20:49:47 +00:00
|
|
|
add _ = return Nothing
|
2012-06-16 00:44:34 +00:00
|
|
|
|
2012-10-29 15:40:22 +00:00
|
|
|
done _ _ Nothing = do
|
|
|
|
liftAnnex showEndFail
|
|
|
|
return Nothing
|
|
|
|
done change file (Just key) = do
|
|
|
|
link <- liftAnnex $ Command.Add.link file key True
|
|
|
|
when DirWatcher.eventsCoalesce $
|
|
|
|
liftAnnex $ do
|
2012-06-19 06:40:21 +00:00
|
|
|
sha <- inRepo $
|
|
|
|
Git.HashObject.hashObject BlobObject link
|
|
|
|
stageSymlink file sha
|
2012-10-29 15:40:22 +00:00
|
|
|
showEndOk
|
2012-10-30 21:14:26 +00:00
|
|
|
queueTransfers Next key (Just file) Upload
|
2012-10-29 15:40:22 +00:00
|
|
|
return $ Just change
|
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
|
|
|
|
fs <- liftIO $ getSymbolicLinkStatus $ keyFilename keysource
|
|
|
|
ks <- liftIO $ getSymbolicLinkStatus $ contentLocation keysource
|
|
|
|
if deviceID ks == deviceID fs && fileID ks == fileID fs
|
|
|
|
then a
|
|
|
|
else return Nothing
|
2012-06-21 00:05:40 +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
|
|
|
{- 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
|
|
|
-}
|
2012-10-29 15:40:22 +00:00
|
|
|
safeToAdd :: Maybe Seconds -> [Change] -> [Change] -> Assistant [Either Change Change]
|
|
|
|
safeToAdd _ [] [] = return []
|
|
|
|
safeToAdd delayadd pending inprocess = do
|
|
|
|
maybe noop (liftIO . threadDelaySeconds) delayadd
|
|
|
|
liftAnnex $ 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
|
|
|
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-10-29 15:40:22 +00:00
|
|
|
where
|
|
|
|
check openfiles change@(InProcessAddChange { keySource = ks })
|
|
|
|
| S.member (contentLocation ks) openfiles = Left change
|
|
|
|
check _ change = Right change
|
2012-06-20 23:04:16 +00:00
|
|
|
|
2012-10-29 15:40:22 +00:00
|
|
|
mkinprocess (c, ks) = InProcessAddChange
|
|
|
|
{ changeTime = changeTime c
|
|
|
|
, keySource = ks
|
|
|
|
}
|
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-10-29 15:40:22 +00:00
|
|
|
canceladd (InProcessAddChange { keySource = ks }) = do
|
|
|
|
warning $ keyFilename ks
|
|
|
|
++ " still has writers, not adding"
|
|
|
|
-- remove the hard link
|
|
|
|
void $ liftIO $ tryIO $ removeFile $ contentLocation ks
|
|
|
|
canceladd _ = noop
|
2012-06-16 02:35:29 +00:00
|
|
|
|
2012-10-29 15:40:22 +00:00
|
|
|
openwrite (_file, mode, _pid) =
|
|
|
|
mode == Lsof.OpenWriteOnly || mode == Lsof.OpenReadWrite
|
2012-06-20 23:04:16 +00:00
|
|
|
|
2012-10-29 15:40:22 +00:00
|
|
|
allRight = return . map Right
|