WatcherSyncDelete logic

[ahmedtolba1984]

Hi @nicolas-raoul ; I want to understand why WatcherSyncDelete method doesn't delete directly from the server instead of waiting the next syn to run.

[nicolas-raoul]

Hello Ahmed,

That's because some software (for instance MS Word) delete the file and rewrite it, every time they save. So deleting immediately would lose versions.

Cheers! Nicolas

[lelmarir]

Eg: when you save an office file (test.doc for example) it will not write directly to the file, instead it will first write the new file to a temporary hidden file, then delete the original file and rename the temp file. This process would trigger a Delete event, but it is indeed a Change event, so it must wait for the process to complete and then handle it.

take a look at my implementation: https://github.com/lelmarir/CmisSync/blob/master/CmisSync.Lib/Watcher.cs

[ahmedtolba1984]

Thanks you for your help;I already understand the purpose of the WatcherSyncDelete ; I have two questions 1- Why the watcher is reworked in the fork https://github.com/lelmarir/CmisSync/blob/master/CmisSync.Lib/Watcher.cs 2- Why we have two timer one for remote changes and the the other for local changes; i think, we can have only one timer for both operations and also, why the first is 5 seconds and the second is 15 seconds

[lelmarir]

1- I've reworked the watcher in my fork as part of a global refactoring to start a new GUI (see my pull request https://github.com/aegif/CmisSync/pull/627) but, i know, I've ended with a drastic break with nicolas-raoul's code (i'm sorry). But i needed it. Eg: the original code will do this on a delete event

            int GRACE_TIME = 15000; // 15 seconds.
            Thread.Sleep(GRACE_TIME);
            return false; // Perform a sync.

(sleep for a wile and force a full sync) To me this is not the right behavior, and my code instead will handle the event directly without a full sync. Unfortunately I did not found a fix or a quick hack to implement this (and others) behavior in the existing code, so I've started my fork.

2- well, you still need two timer because the "remote_timer" will trigger a partial or full remote sync and it's main purpose is to sync new remote changes (remote-->local) and will also do the opposite in the while. But this is a slow process and will put some stress on the server (because it will ask for changes or do a recursive scan) so it should be done only once in a while (15 seconds is too short, 60sec is a better interval). The "local_timer" (not anymore in my implementation) will trigger instead a "local sync" (this is a partial sync and can be done more often). This will "apply" the detected changes from the Watcher. Mine implementation do this the same as nicolas-raoul one (more or less), but I've moved the timer inside the watcher itself. Also: the local_timer will not trigger every 5 seconds, but instead will trigger once 5 second after the last event from the watcher (if an event before the 5 seconds the timer will reset)

I hope I have been clear, if any question ask away

ps. the code in my fork is not the final one i'm using in production, is more a proof of concept, right now i can't release the GUI (because it is under a proprietary licence) but with some work i can release the library part (only the sync logic without the user interface). If you are interested in the final product (gui, sync-file icon (like dropbox), auto-update, automatic crash reports, etc) ready for deploy we can talk about. Or if you like the Lib implementation i can publish the last version here (it need some polishing work, so i'll only do if someone interested in it)

[ahmedtolba1984]

Thanks for your help

[nicolas-raoul]

@lelmarir I want to fix this part, and if possible I would like our two branches to use the same solutions, so that we can cooperate more in the future too. Would you mind pushing your latest code? (now 6 months old) Thanks! :-)