assistant: Detect stale git lock files at startup time, and remove them.

Extends the index.lock handling to other git lock files. I surveyed
all lock files used by git, and found more than I expected. All are
handled the same in git; it leaves them open while doing the operation,
possibly writing the new file content to the lock file, and then closes
them when done.

The gc.pid file is excluded because it won't affect the normal operation
of the assistant, and waiting for a gc to finish on startup wouldn't be
good.

All threads except the webapp thread wait on the new startup sanity checker
thread to complete, so they won't try to do things with git that fail
due to stale lock files. The webapp thread mostly avoids doing that kind of
thing itself. A few configurators might fail on lock files, but only if the
user is explicitly trying to run them. The webapp needs to start
immediately when the user has opened it, even if there are stale lock
files.

Arranging for the threads to wait on the startup sanity checker was a bit
of a bear. Have to get all the NotificationHandles set up before the
startup sanity checker runs, or they won't see its signal. Perhaps
the NotificationBroadcaster is not the best interface to have used for
this. Oh well, it works.

This commit was sponsored by Michael Jakl

1 files changed, 0 insertions, 35 deletions

diff --git a/Assistant/Threads/Watcher.hs b/Assistant/Threads/Watcher.hs
index 9b9321014..c10d03eeb 100644
--- a/Assistant/Threads/Watcher.hs
+++ b/Assistant/Threads/Watcher.hs
@@ -122,7 +122,6 @@ waitFor sig next = do
 {- Initial scartup scan. The action should return once the scan is complete. -}
 startupScan :: IO a -> Assistant a
 startupScan scanner = do
-	checkStaleIndexLock
 	liftAnnex $ showAction "scanning"
 	alertWhile' startupScanAlert $ do
 		r <- liftIO scanner
@@ -143,40 +142,6 @@ startupScan scanner = do
 
 		return (True, r)
 
-{- Detect when .git/index.lock exists and has no git process currently
- - writing to it. This strongly suggests it is a stale lock file, because
- - git writes the new index to index.lock and renames it over top.
- -
- - However, this could be on a network filesystem. Which is not very safe
- - anyway (the assistant relies on being able to check when files have
- - no writers to know when to commit them). Just in case, when the file
- - appears stale, we delay for one minute, and check its size. If the size
- - changed, delay for another minute, and so on.
- -}
-checkStaleIndexLock :: Assistant ()
-checkStaleIndexLock = do
-	dir <- liftAnnex $ fromRepo Git.localGitDir
-	checkStale $ dir </> "index.lock"
-checkStale :: FilePath -> Assistant ()
-checkStale indexlock = go =<< getsize
-  where
-  	getsize = liftIO $ catchMaybeIO $ fileSize <$> getFileStatus indexlock
-	go Nothing = return ()
-	go oldsize = ifM (liftIO $ null <$> Lsof.query ["--", indexlock])
-		( do
-			waitforit "to check stale"
-			size <- getsize
-			if size == oldsize
-				then liftIO $ nukeFile indexlock
-				else go size
-		, do
-			waitforit "for writer on"
-			go =<< getsize
-		)
-	waitforit why = do
-		notice ["Waiting for 60 seconds", why, indexlock]
-		liftIO $ threadDelaySeconds $ Seconds 60
-
 {- Hardcoded ignores, passed to the DirWatcher so it can avoid looking
  - at the entire .git directory. Does not include .gitignores. -}
 ignored :: FilePath -> Bool