2012-06-13 12:36:33 -04:00
|
|
|
{- git-annex assistant tree watcher
|
|
|
|
-
|
|
|
|
- Copyright 2012 Joey Hess <joey@kitenet.net>
|
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
|
|
|
{-# LANGUAGE CPP #-}
|
|
|
|
|
|
|
|
module Assistant.Watcher where
|
|
|
|
|
|
|
|
import Common.Annex
|
|
|
|
import Assistant.ThreadedMonad
|
|
|
|
import Assistant.DaemonStatus
|
|
|
|
import Assistant.Committer
|
|
|
|
import Utility.ThreadLock
|
|
|
|
import qualified Annex.Queue
|
|
|
|
import qualified Git.Command
|
|
|
|
import qualified Git.UpdateIndex
|
|
|
|
import qualified Git.HashObject
|
|
|
|
import qualified Git.LsFiles
|
|
|
|
import qualified Backend
|
|
|
|
import Annex.Content
|
|
|
|
import Annex.CatFile
|
|
|
|
import Git.Types
|
|
|
|
|
|
|
|
import Control.Concurrent.STM
|
|
|
|
import Data.Bits.Utils
|
|
|
|
import qualified Data.ByteString.Lazy as L
|
|
|
|
|
|
|
|
#if defined linux_HOST_OS
|
|
|
|
import Utility.Inotify
|
|
|
|
import System.INotify
|
|
|
|
#endif
|
|
|
|
|
|
|
|
type Handler = FilePath -> Maybe FileStatus -> DaemonStatusHandle -> Annex (Maybe Change)
|
|
|
|
|
|
|
|
watchThread :: ThreadState -> DaemonStatusHandle -> ChangeChan -> IO ()
|
|
|
|
#if defined linux_HOST_OS
|
|
|
|
watchThread st dstatus changechan = withINotify $ \i -> do
|
|
|
|
runThreadState st $
|
|
|
|
showAction "scanning"
|
|
|
|
-- This does not return until the startup scan is done.
|
|
|
|
-- That can take some time for large trees.
|
|
|
|
watchDir i "." (ignored . takeFileName) hooks
|
|
|
|
runThreadState st $
|
|
|
|
modifyDaemonStatus dstatus $ \s -> s { scanComplete = True }
|
|
|
|
-- Notice any files that were deleted before inotify
|
|
|
|
-- was started.
|
|
|
|
runThreadState st $ do
|
|
|
|
inRepo $ Git.Command.run "add" [Param "--update"]
|
|
|
|
showAction "started"
|
|
|
|
waitForTermination
|
|
|
|
where
|
|
|
|
hook a = Just $ runHandler st dstatus changechan a
|
|
|
|
hooks = WatchHooks
|
|
|
|
{ addHook = hook onAdd
|
|
|
|
, delHook = hook onDel
|
|
|
|
, addSymlinkHook = hook onAddSymlink
|
|
|
|
, delDirHook = hook onDelDir
|
|
|
|
, errHook = hook onErr
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
watchThread = error "so far only available on Linux"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ignored :: FilePath -> Bool
|
|
|
|
ignored ".git" = True
|
|
|
|
ignored ".gitignore" = True
|
|
|
|
ignored ".gitattributes" = True
|
|
|
|
ignored _ = False
|
|
|
|
|
|
|
|
{- Runs an action handler, inside the Annex monad, and if there was a
|
|
|
|
- change, adds it to the ChangeChan.
|
|
|
|
-
|
|
|
|
- Exceptions are ignored, otherwise a whole watcher thread could be crashed.
|
|
|
|
-}
|
|
|
|
runHandler :: ThreadState -> DaemonStatusHandle -> ChangeChan -> Handler -> FilePath -> Maybe FileStatus -> IO ()
|
|
|
|
runHandler st dstatus changechan handler file filestatus = void $ do
|
|
|
|
r <- tryIO go
|
|
|
|
case r of
|
|
|
|
Left e -> print e
|
|
|
|
Right Nothing -> noop
|
|
|
|
Right (Just change) -> void $
|
|
|
|
runChangeChan $ writeTChan changechan change
|
|
|
|
where
|
|
|
|
go = runThreadState st $ handler file filestatus dstatus
|
|
|
|
|
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 16:27:44 -04:00
|
|
|
{- During initial directory scan, this will be run for any regular files
|
|
|
|
- that are already checked into git. We don't want to turn those into
|
|
|
|
- symlinks, so do a check. This is rather expensive, but only happens
|
|
|
|
- during startup.
|
2012-06-13 12:36:33 -04:00
|
|
|
-
|
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 16:27:44 -04:00
|
|
|
- It's possible for the file to still be open for write by some process.
|
|
|
|
- This can happen in a few ways; one is if two processes had the file open
|
|
|
|
- and only one has just closed it. We want to avoid adding a file to the
|
|
|
|
- annex that is open for write, to avoid anything being able to change it.
|
2012-06-13 12:36:33 -04:00
|
|
|
-
|
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 16:27:44 -04:00
|
|
|
- We could run lsof on the file here to check for other writer.
|
|
|
|
- But, that's slow. Instead, a Change is returned that indicates this file
|
|
|
|
- still needs to be added. The committer will handle bundles of these
|
|
|
|
- Changes at once.
|
2012-06-13 12:36:33 -04:00
|
|
|
-}
|
|
|
|
onAdd :: Handler
|
|
|
|
onAdd file _filestatus dstatus = do
|
|
|
|
ifM (scanComplete <$> getDaemonStatus dstatus)
|
|
|
|
( go
|
|
|
|
, ifM (null <$> inRepo (Git.LsFiles.notInRepo False [file]))
|
|
|
|
( noChange
|
|
|
|
, go
|
|
|
|
)
|
|
|
|
)
|
|
|
|
where
|
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 16:27:44 -04:00
|
|
|
go = madeChange file PendingAddChange
|
2012-06-13 12:36:33 -04:00
|
|
|
|
|
|
|
{- A symlink might be an arbitrary symlink, which is just added.
|
|
|
|
- Or, if it is a git-annex symlink, ensure it points to the content
|
|
|
|
- before adding it.
|
|
|
|
-}
|
|
|
|
onAddSymlink :: Handler
|
|
|
|
onAddSymlink file filestatus dstatus = go =<< Backend.lookupFile file
|
|
|
|
where
|
|
|
|
go (Just (key, _)) = do
|
|
|
|
link <- calcGitLink file key
|
|
|
|
ifM ((==) link <$> liftIO (readSymbolicLink file))
|
|
|
|
( ensurestaged link =<< getDaemonStatus dstatus
|
|
|
|
, do
|
|
|
|
liftIO $ removeFile file
|
|
|
|
liftIO $ createSymbolicLink link file
|
|
|
|
addlink link
|
|
|
|
)
|
|
|
|
go Nothing = do -- other symlink
|
|
|
|
link <- liftIO (readSymbolicLink file)
|
|
|
|
ensurestaged link =<< getDaemonStatus dstatus
|
|
|
|
|
|
|
|
{- This is often called on symlinks that are already
|
|
|
|
- staged correctly. A symlink may have been deleted
|
|
|
|
- and being re-added, or added when the watcher was
|
|
|
|
- not running. So they're normally restaged to make sure.
|
|
|
|
-
|
|
|
|
- As an optimisation, during the status scan, avoid
|
|
|
|
- restaging everything. Only links that were created since
|
|
|
|
- the last time the daemon was running are staged.
|
|
|
|
- (If the daemon has never ran before, avoid staging
|
|
|
|
- links too.)
|
|
|
|
-}
|
|
|
|
ensurestaged link daemonstatus
|
|
|
|
| scanComplete daemonstatus = addlink link
|
|
|
|
| otherwise = case filestatus of
|
|
|
|
Just s
|
2012-06-13 13:35:15 -04:00
|
|
|
| not (afterLastDaemonRun (statusChangeTime s) daemonstatus) -> noChange
|
2012-06-13 12:36:33 -04:00
|
|
|
_ -> addlink link
|
|
|
|
|
|
|
|
{- For speed, tries to reuse the existing blob for
|
|
|
|
- the symlink target. -}
|
|
|
|
addlink link = do
|
|
|
|
v <- catObjectDetails $ Ref $ ':':file
|
|
|
|
case v of
|
|
|
|
Just (currlink, sha)
|
|
|
|
| s2w8 link == L.unpack currlink ->
|
|
|
|
stageSymlink file sha
|
|
|
|
_ -> do
|
|
|
|
sha <- inRepo $
|
|
|
|
Git.HashObject.hashObject BlobObject link
|
|
|
|
stageSymlink file sha
|
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 16:27:44 -04:00
|
|
|
madeChange file LinkChange
|
2012-06-13 12:36:33 -04:00
|
|
|
|
|
|
|
onDel :: Handler
|
|
|
|
onDel file _ _dstatus = do
|
|
|
|
Annex.Queue.addUpdateIndex =<<
|
|
|
|
inRepo (Git.UpdateIndex.unstageFile file)
|
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 16:27:44 -04:00
|
|
|
madeChange file RmChange
|
2012-06-13 12:36:33 -04:00
|
|
|
|
|
|
|
{- A directory has been deleted, or moved, so tell git to remove anything
|
|
|
|
- that was inside it from its cache. Since it could reappear at any time,
|
|
|
|
- use --cached to only delete it from the index.
|
|
|
|
-
|
|
|
|
- Note: This could use unstageFile, but would need to run another git
|
|
|
|
- command to get the recursive list of files in the directory, so rm is
|
|
|
|
- just as good. -}
|
|
|
|
onDelDir :: Handler
|
|
|
|
onDelDir dir _ _dstatus = do
|
|
|
|
Annex.Queue.addCommand "rm"
|
|
|
|
[Params "--quiet -r --cached --ignore-unmatch --"] [dir]
|
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 16:27:44 -04:00
|
|
|
madeChange dir RmDirChange
|
2012-06-13 12:36:33 -04:00
|
|
|
|
|
|
|
{- Called when there's an error with inotify. -}
|
|
|
|
onErr :: Handler
|
|
|
|
onErr msg _ _dstatus = do
|
|
|
|
warning msg
|
|
|
|
return Nothing
|
|
|
|
|
|
|
|
{- Adds a symlink to the index, without ever accessing the actual symlink
|
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 16:27:44 -04:00
|
|
|
- on disk. This avoids a race if git add is used, where the symlink is
|
|
|
|
- changed to something else immediately after creation.
|
|
|
|
-}
|
2012-06-13 12:36:33 -04:00
|
|
|
stageSymlink :: FilePath -> Sha -> Annex ()
|
|
|
|
stageSymlink file sha =
|
|
|
|
Annex.Queue.addUpdateIndex =<<
|
|
|
|
inRepo (Git.UpdateIndex.stageSymlink file sha)
|