When started with /tray, syncs only after first full scan

[GoogleCodeExporter]

I noticed a serious problem when running CryptSync 1.1.4.241 with the /tray 
option (which happens when "Start with Windows" is selected).

Normally, CryptSync syncs automatically every 10 seconds and in addition to 
that, does a full scan every 30 minutes. However, when started with the /tray 
option, the folders are not synced and no synchronisation will happen until the 
first full scan, i.e. only after 30 minutes, or after you open the options 
dialog and select "run in background".

My uneducated guess is that the problem is a missing call of 
foldersyncer.SyncFolders() on WM_CREATE.

Original issue reported on code.google.com by ch.zwerschke@gmail.com on 1 Mar 2014 at 11:16

[GoogleCodeExporter]

Original comment by tortoisesvn on 2 Mar 2014 at 2:56

• Changed state: Started
• Added labels: Milestone-1.1.5

[GoogleCodeExporter]

Actually, this is by design.

CS monitors the folders for changes. If a change is detected, it syncs those 
changes after 10 seconds. That's active all the time, independent of the /tray 
option.

A full scan is done every 30 minutes in case the change monitoring missed a 
change.

If you start CS with the /tray option, a full scan is not done immediately: 
this gives the cloud drives time to do their syncing first. The changes those 
tools do are still monitored and synced after 10 seconds.

Original comment by tortoisesvn on 2 Mar 2014 at 3:07

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for the quick reply. Yes, I understand that a full sync is only done 
after 30 minutes but that's not the problem. I also understand that the 10 
second syncs *should* happen all the time, independent of the /tray option. 

The problem is that it really is not so. When started with /tray, the syncs 
that should happen every 10 seconds really do not happen until the first full 
sync. I can fully reproduce this here. The syncs every 10 seconds only start 
after the first full sync or after clicking the button "run in background". In 
both of these cases, foldersyncer.SyncFolders() is called, so my guess is that 
this call does something that is necessary for the 10 second syncs to work.

Original comment by ch.zwerschke@gmail.com on 2 Mar 2014 at 11:40

[GoogleCodeExporter]

foldersyncer.SyncFolders() is the call to do a full scan and sync.

I've tested this on three machines now and the immediate sync works fine there 
after start with /tray.

Could it be that when you start with /tray that the synced folders are not 
available yet/not yet ready/not yet mounted?

Original comment by tortoisesvn on 3 Mar 2014 at 8:58

[GoogleCodeExporter]

Maybe the call to SyncFolders() was a red herring then. I thought it may be 
relevant because it is one thing that is different when running from the 
commandline with /tray and when running with the button "run in background", so 
maybe it does something that is necessary for the synchronisation to work 
properly.

When I reported the issue I had seen it on two Win 7 PCs with 32bit and 64bit, 
synchronising against my dropbox folder with some config changes. I just 
checked with a third PC, using a fresh install of CryptSync64-1.1.4.msi 
downloaded from SourceForge without changing any of the configuration switches 
and using two ordinary folders I created on my Windows desktop. I set these two 
folders up as a folder pair, without checking any of the checkboxes in the 
configuration dialog. I put a plain text file in the unencrypted folder.

Then I ran CryptSync from the command line with the /tray option. I.e. no 
dialog was displayed, but the tray icon shows it's running. Again, I could see 
the same problem: The plain text file was not initially synced to the 
unencrypted folder, and it was not even synced when I changed the content of 
the file and waited several minutes.

The synchronisation only starts to work when I wait 30 minutes or click on 
CryptSync and exit the dialog with "run in background". After doing one of 
these things, the synchronisation works properly, every 10 seconds.

Original comment by ch.zwerschke@gmail.com on 4 Mar 2014 at 10:20

[GoogleCodeExporter]

I think I found the problem...

Original comment by tortoisesvn on 4 Mar 2014 at 6:25

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r256.

Original comment by tortoisesvn on 4 Mar 2014 at 6:41

• Changed state: Fixed

[GoogleCodeExporter]

So  it seems my guess that it was something done in SyncFolders that was 
missing was not so far off. Thanks a lot  for solving this so quickly. 

Original comment by ch.zwerschke@gmail.com on 4 Mar 2014 at 7:09

[GoogleCodeExporter]

I installed version 1.1.5 now and can confirm that it works as expected now 
resp. as you explained in comment #2.

Original comment by ch.zwerschke@gmail.com on 4 Mar 2014 at 10:44