use new name for new format fsck db

The old db is cleaned up when a new incremental fsck is started.

The incremental fsck won't pick up where the old one left off, but I
consider this a minor enough thing that it can just be documented and
won't be a problem.

Annex/Locations.hs

@@ -43,6 +43,7 @@ module Annex.Locations (
 	gitAnnexKeysDbIndexCache,
 	gitAnnexFsckState,
 	gitAnnexFsckDbDir,
+	gitAnnexFsckDbDirOld,
 	gitAnnexFsckDbLock,
 	gitAnnexFsckResultsLog,
 	gitAnnexSmudgeLog,

Database/Fsck.hs

@@ -44,6 +44,8 @@ Fscked
 |]
 
 {- The database is removed when starting a new incremental fsck pass.
+ -
+ - (The old fsck database used before v8 is also removed here.)
  -
  - This may fail, if other fsck processes are currently running using the
  - database. Removing the database in that situation would lead to crashes
@@ -52,8 +54,10 @@ Fscked
 newPass :: UUID -> Annex Bool
 newPass u = isJust <$> tryExclusiveLock (gitAnnexFsckDbLock u) go
   where
-	go = liftIO . void . tryIO . removeDirectoryRecursive
+	go = do
-		=<< fromRepo (gitAnnexFsckDbDir u)
+		removedb =<< fromRepo (gitAnnexFsckDbDir u)
+		removedb =<< fromRepo (gitAnnexFsckDbDirOld u)
+	removedb = liftIO . void . tryIO . removeDirectoryRecursive
 
 {- Opens the database, creating it if it doesn't exist yet. -}
 openDb :: UUID -> Annex FsckHandle

Upgrade/V7.hs

@@ -23,6 +23,10 @@ upgrade automatic = do
 		showAction "v7 to v8"
 	
 	populateKeysDb
+	-- The fsck databases are not transitioned here; any running
+	-- incremental fsck can continue to write to the old database.
+	-- The next time an incremental fsck is started, it will delete the
+	-- old database, and just re-fsck the files.
 
 	removeOldDb gitAnnexKeysDbOld
 	liftIO . nukeFile =<< fromRepo gitAnnexKeysDbIndexCacheOld

doc/todo/sqlite_database_improvements.mdwn

@@ -94,9 +94,13 @@ remaining todo:
 > 
 > * Fsck (SKey)
 >   can't rebuild? Just drop and let incremental fscks re-do work
+>
+>   (done)
+
 > * ContentIdentifier (IKey)  
 >   rebuild with updateFromLog, would need to diff from empty tree to
 >   current git-annex branch, may be expensive to do!
+> 
 > * Export (IKey, SFilePath)  
 >   difficult to rebuild, what if in the middle of an interrupted
 >   export?
@@ -110,7 +114,8 @@ remaining todo:
 >   situations, the next time an export is run, so should be ok.
 >   But it might result in already exported files being re-uploaded,
 >   or other unncessary work.
-> Keys (IKey, SFilePath, SInodeCache)
+> 
+> * Keys (IKey, SFilePath, SInodeCache)
 >   Use scanUnlockedFiles to repopulate the Associated table.
 > 
 >   But that does not repopulate the Content table. Doing so needs
@@ -133,6 +138,8 @@ remaining todo:
 >   However, it has never actually changed since it was introduced in 2010
 >   (git v1.8.3.1), except for a fix for an unsigned int overflow bug that
 >   was fixed in April 2019.
+>
+>   (done)
 > 
 > Alternatively, can keep the old database code and use it to read the old
 > databases during the migration. But then bad data that got in due to the