From 265e440d225f565dd7fcf714f80877acc728ca34 Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@kitenet.net>
Date: Thu, 7 Mar 2013 12:35:42 -0400
Subject: [PATCH] avoid queuing transfers that are already queued

I saw this happen in real life, when syncing to a newly added usb drive.
I think it got scanned twice, and files were doubled in the queue.

This could be optimised a little bit more, to only read from the mvar
once, rather than twice.
---
 Assistant/TransferQueue.hs | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/Assistant/TransferQueue.hs b/Assistant/TransferQueue.hs
index 7c41f0399d..3f38b37a33 100644
--- a/Assistant/TransferQueue.hs
+++ b/Assistant/TransferQueue.hs
@@ -122,13 +122,19 @@ enqueue reason schedule t info
 	| otherwise = go (\l -> l++[new])
   where
 	new = (t, info)
-	go modlist = do
-		q <- getAssistant transferQueue
-		liftIO $ atomically $ do
-			void $ modifyTVar' (queuesize q) succ
-			void $ modifyTVar' (queuelist q) modlist
+	go modlist = whenM (add modlist) $ do
 		debug [ "queued", describeTransfer t info, ": " ++ reason ]
 		notifyTransfer
+	add modlist = do
+		q <- getAssistant transferQueue
+		liftIO $ atomically $ do
+			l <- readTVar (queuelist q)
+			if (new `elem` l)
+				then do	
+					void $ modifyTVar' (queuesize q) succ
+					void $ modifyTVar' (queuelist q) modlist
+					return True
+				else return False
 
 {- Adds a transfer to the queue. -}
 queueTransfer :: Reason -> Schedule -> AssociatedFile -> Transfer -> Remote -> Assistant ()