From 3a0cffcfed4e6824b0771ce69f70095a4e3b9917 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 18 Sep 2012 14:10:33 -0400 Subject: when a Download finishes, queue Uploads This ensures file propigate takes place in situations such as: Usb drive A is connected to B. A's master branch is already in sync with B, but it is being used to sneakernet some files around, so B downloads those. There is no master branch change, so C does not request these files. B needs to upload the files it just downloaded on to C, etc. My first try at this, I saw loops happen. B uploaded to C, which then tried to upload back to B (because it had not received the updated git-annex branch from B yet). B already had the file, but it still created a transfer info file from the incoming transfer, and its watcher saw that be removed, and tried to upload back to C. These loops should have been fixed by my previous commit. (They never affected ssh remotes, only local ones, it seemed.) While C might still try to upload to B, or to some other remote that already has the file, the extra work dies out there. --- Assistant/Threads/Transferrer.hs | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Assistant/Threads/Transferrer.hs') diff --git a/Assistant/Threads/Transferrer.hs b/Assistant/Threads/Transferrer.hs index bd73d06d6..8e2b67243 100644 --- a/Assistant/Threads/Transferrer.hs +++ b/Assistant/Threads/Transferrer.hs @@ -63,6 +63,10 @@ startTransfer st dstatus program t info = case (transferRemote info, associatedF (_, _, _, pid) <- createProcess (proc program $ toCommand params) { create_group = True } + {- Alerts are only shown for successful transfers. + - Transfers can temporarily fail for many reasons, + - so there's no point in bothering the user about + - those. The assistant should recover. -} whenM ((==) ExitSuccess <$> waitForProcess pid) $ void $ addAlert dstatus $ makeAlertFiller True $ -- cgit v1.2.3