check preferred content when a file is moved or created

This can result in the file being dropped, or being downloaded, or even
being dropped from some other repo.

It's even possible to create a file in a directory where content is not
wanted, which will make the assistant immediately send it elsewhere, and
then drop it.

2 files changed, 15 insertions, 10 deletions

diff --git a/Assistant/Threads/Watcher.hs b/Assistant/Threads/Watcher.hs
index 1bf9e8581..310a6e984 100644
--- a/Assistant/Threads/Watcher.hs
+++ b/Assistant/Threads/Watcher.hs
@@ -20,6 +20,7 @@ import Assistant.DaemonStatus
 import Assistant.Changes
 import Assistant.TransferQueue
 import Assistant.Alert
+import Assistant.Drop
 import Logs.Transfer
 import Utility.DirWatcher
 import Utility.Types.DirWatcher
@@ -135,6 +136,7 @@ onAddSymlink threadname file filestatus dstatus transferqueue = go =<< Backend.l
 					liftIO $ debug threadname ["fix symlink", file]
 					liftIO $ removeFile file
 					liftIO $ createSymbolicLink link file
+					checkcontent key =<< liftIO (getDaemonStatus dstatus)
 					addlink link
 				)
 		go Nothing = do -- other symlink
@@ -146,7 +148,7 @@ onAddSymlink threadname file filestatus dstatus transferqueue = go =<< Backend.l
 		 - 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
+		 - As an optimisation, during the startup 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
@@ -174,12 +176,16 @@ onAddSymlink threadname file filestatus dstatus transferqueue = go =<< Backend.l
 					stageSymlink file sha
 			madeChange file LinkChange
 
-		{- When a new link appears, after the startup scan,
-		 - try to get the key's content. -}
+		{- When a new link appears, or a link is changed,
+		 - after the startup scan, handle getting or
+		 - dropping the key's content. -}
 		checkcontent key daemonstatus
-			| scanComplete daemonstatus = unlessM (inAnnex key) $
-				queueTransfers Next transferqueue dstatus
-					key (Just file) Download
+			| scanComplete daemonstatus = do
+				present <- inAnnex key
+				unless present $
+					queueTransfers Next transferqueue dstatus
+						key (Just file) Download
+				handleDrops dstatus present key (Just file)
 			| otherwise = noop
 
 onDel :: Handler
diff --git a/doc/design/assistant/transfer_control.mdwn b/doc/design/assistant/transfer_control.mdwn
index 1c31b85e7..a14b8410f 100644
--- a/doc/design/assistant/transfer_control.mdwn
+++ b/doc/design/assistant/transfer_control.mdwn
@@ -33,10 +33,9 @@ the same content, this gets tricky. Let's assume there are not.)
    groups change. Generally, some change to global annex state. Only way to deal
    with this is an expensive scan. (The rest of the items below come from
    analizing the terminals used in preferred content expressions.) **done**
-2. renaming of a file (ie, moved to `archive/`)
-   (note that renaming a file can also make it become preferred content
-   again, and should cause it to be transferred in that case, which doesn't
-   happen either..)
+2. renaming of a file (ie, moved to `archive/`) **done**
+   (note also that renaming a file can also make it become preferred content
+   again, and should cause it to be transferred in that case) **done**
 3. we get a file (`in`, `copies`) **done**
 4. we sent a file (`in`, `copies`) **done**
 5. some other repository drops the file (`in`, `copies` .. However, it's