check InodeCache in inAnnex et al

This avoids querying the database when the content file doen't exist
(or otherwise fails the provided check). However, it does add overhead of
querying the database, and will certianly impact performance.

Annex/Content.hs

@@ -84,7 +84,10 @@ inAnnex key = inAnnexCheck key $ liftIO . doesFileExist
 inAnnexCheck :: Key -> (FilePath -> Annex Bool) -> Annex Bool
 inAnnexCheck key check = inAnnex' id False check key
 
-{- Generic inAnnex, handling both indirect and direct mode.
+{- inAnnex that performs an arbitrary check of the key's content.
+ -
+ - When the content is unlocked, it must also be unmodified, or the bad
+ - value will be returned.
  -
  - In direct mode, at least one of the associated files must pass the
  - check. Additionally, the file must be unmodified.
@@ -93,9 +96,17 @@ inAnnex' :: (a -> Bool) -> a -> (FilePath -> Annex a) -> Key -> Annex a
 inAnnex' isgood bad check key = withObjectLoc key checkindirect checkdirect
   where
 	checkindirect loc = do
-		whenM (fromRepo Git.repoIsUrl) $
-			error "inAnnex cannot check remote repo"
-		check loc
+		r <- check loc
+		if isgood r
+			then do
+				cache <- Database.Keys.getInodeCaches key
+				if null cache
+					then return r
+					else ifM (sameInodeCache loc cache)
+						( return r
+						, return bad
+						)
+			else return bad
 	checkdirect [] = return bad
 	checkdirect (loc:locs) = do
 		r <- check loc

doc/todo/smudge.mdwn

@@ -325,14 +325,11 @@ files to be unlocked, while the indirect upgrades don't touch the files.
 
 #### implementation todo list
 
-* inAnnex check should fail in the case where an annexed object is unlocked
-  and has had its content changed. Could use an InodeCache for
-  such objects. This parallels how inAnnex checks work for direct mode.
 * Reconcile staged changes into the associated files database, whenever
   the database is queried.
-* See if the cases where the associated files database is not used can be
-  optimised. Eg, if the associated files database doesn't exist at all,
-  we know smudge/clean are not used, so queries for associated files don't
+* See if the cases where the Keys database is not used can be
+  optimised. Eg, if the Keys database doesn't exist at all,
+  we know smudge/clean are not used, so queries don't
   need to open the database or do reconciliation, but can simply return none.
   Also, no need for Backend.lookupFile to catKeyFile in this case
   (when not in direct mode).