SyncTool: first Click on [Close] after [Abort] doesn't work

[ghisler(Author)]

But in general, I also agree that the situation is very ambiguous and poorly repeatable on other machines.

On which Windows version(s) does it occur?

[JOUBE]

Sorry, I cannot reproduce these problems at all. I need more info, otherwise I will never be able to reproduce your problems.
1. Some of you write that it got worse, but no one writes with which update. 11.02rc? 11.01? 11.0? Earlier?

I cannot say that, because I changed my handling to more than one sync at same time in the middle of (I do not know at all...) the Betas of 11.00.

2. In which phase does it take longer? When the footer shows "Reading directories:" or "Comparison:"?

The routine is: Comparison -> manual check whether everything is okay (deselect if necessary/individual deletion, etc... normal work before a sync) -> start the sync by clicking sync button -> waiting for finished -> the automatic new comparison starts. Soon after this automatic restart (1-10 seconds later, or even 1-2 minutes later) clicking on [Abort] and immediately afterwards there clicking on close ([close] is on the button !), which is not accepted.

3. What exactly are you comparing? Two local directories, a local directory and a remote directory, or something else?

Local directory with a remote directory (150-4000 readed folder with 400 - 45.000 files), but volumes always mapped as SMB drives with locally assigned drive letters.

4. When you click "Abort" just once, what happens then? Do you get an empty result list, or a partial result? If partial result, how long does it take to appear?

Sync stopped und button changed to [close]. The next click immediately afterwards
on that [close] does not work. The next click immediately afterwards (second time) on that [close] takes effect (it's seems an internal timing problem, Tc doesn't seem ready to react to a click yet or ignores the first click or doesn't notice it at all), even though [close] is on the button.

[ghisler(Author)]

2JOUBE
It sounds like this is a problem with your SMB server: The sync tool performs the read operations in a foreground thread, so when the server takes a while until it responds to the FindFirstFile command (e.g. because it's still busy writing data), then TC will hang for that time. While it hangs, clicking on the abort button will not do anything at all. I would have to rewrite the entire tool to do all operations in a background thread, but this may break using file system and packer plugins which aren't guaranteed to be thread safe.

To confirm this, can you try aborting the initial comparison instead of the one after copying? Please note that there are two phases, as described above: In the first phase, the footer will show "Reading directories:", and in the second (only when comparing by content) "Comparison:".

[JOUBE]

2JOUBE
It sounds like this is a problem with your SMB server:

I do not think so, most are simple local Windows Pc or local Samba machines. Please reread my answer above, because I change many things in it (specially to your #4.), sorry.

It is a Tc problem.

[JOUBE]

2JOUBE
To confirm this, can you try aborting the initial comparison instead of the one after copying? Please note that there are two phases, as described above: In the first phase, the footer will show "Reading directories:", and in the second (only when comparing by content) "Comparison:".

That's exactly what I do and that's what it's all about: Everything is written. The automatic recomparison starts again and THEN I stop (i.e. when Tc is rereading in). Sorry again for my first wrong answer an your #4. (I first replied on to click on [close], but the question was about click on [abort]. With [About] everything is always okay. The problem is the subsequent click on [close])

Do you really think you need to explain something to me about the sync tool?

[ghisler(Author)]

That's exactly what I do and that's what it's all about: Everything is written. The automatic recomparison starts again and THEN I stop

I understand this, but in reality the files are probably still in the write cache, either in Windows or your server, so you may get a reply with a delay.
Have you tried what I asked you?

can you try aborting the initial comparison instead of the one after copying

[ghisler(Author)]

Sorry, I still need more information from you to fix this.

I suggest that you add the line
SyncRecompareAfterCopy=0
to your wincmd.ini under [Configuration] to disable the re-compare step after copying.

[JOUBE]

Sorry, I still need more information from you to fix this.

I suggest that you add the line
SyncRecompareAfterCopy=0
to your wincmd.ini under [Configuration] to disable the re-compare step after copying.

Okay, just for a limited time test: SyncRecompareAfterCopy=0 , because it doesn't correspond to how I work. I will then start the recompare manually and then cancel it straight away.

[ghisler(Author)]

Moderator message

Moved to will not be changed

[JOUBE]

Moved to will not be changed

Unfortunately, setting SyncRecompareAfterCopy=0 doesn't change anything. (Except the handing takes longer) I'll come back to it if it bothers me too much. Unfortunately it is not solved.

Joube

[ghisler(Author)]

What do you mean? Can you please describe what doesn't work then?

[JOUBE]

What do you mean? Can you please describe what doesn't work then?

First: It's a minor bug. A minor problem and I can definitely live with it if it doesn't can be fixed.

Preliminary remark: The simultaneous syncs partially overlap, so that after the first comparison and the first copy, a second run must immediately follow with further copying and further comparison. Since a lot of things are happening at the same time, the comparisons always have to start automatically after copying so that everything doesn't stand still... In this respect, SyncRecompareAfterCopy=0 is not useful for me because it slows everything down significantly because the only difference is that you start the comparisons manually .

Main thing: The point is that sometimes (usually) you have to click [close] twice after aborting a comparison with [abort]. This happens both when the comparison started automatically and when you started it manually (SyncRecompareAfterCopy=0). The behavior is the same: If you click on [close] immediately after canceling, it doesn't work. The workaround is simple: just wait a moment, even though [close] is already visible.

That's it. No big deal. A bit annoying but like I said I can live with it.

However, I don't understand why the click of Tc is ignored instead of that:
- [close] only appears on the button when clicking is possible
- or at least the click works delayed, but it works.

Joube

[ghisler(Author)]

The point is that sometimes (usually) you have to click [close] twice after aborting a comparison with [abort]

Interesting, this doesn't happen here. Does the button change its text with a delay too? Or does the text change immediately to [Close] but then doesn't react immediately?

[JOUBE]

Does the button change its text with a delay too?

No.

Or does the text change immediately to [Close] but then doesn't react immediately?

Yes.

It seems as if you have now understood it. Sorry that I may have described it unexactly before.

1. It's not a big problem/bug.
2. It's just a bit annoying that you click on a visible [close] but nothing happens.
3. Remedy on my side: wait half a second and then tap [close]. Just a matter of getting used to it.
4b. Remedy 1 on your site: Don't show [close] until one can click on it. Or...
4a. Remedy 2 on your side: Investigate why the click on [close] is not responding.
5. Note: It is difficult to reproduce it, because it becomes more noticeable when several autonomous syncs are running and the data volumes are rather higher.

Joube