SyncTrayzor v2.0.0 is now also officially released, to go alongside syncthing v2.
Betas will not auto-upgrade as they consider themselves to be already at 2.0.0. Everything since beta.2 should however auto-upgrade to 2.0.1 or newer (once released).
There is a small last-minute fix in 2.0.0: Prior betas did not restore the autostart settings when upgrading from v1. This cannot be retroactively fixed, though if you’re affected all you need to do is to re-check the “Automatically start on login” box.
@Nummer378 I’ve been looking at SyncTrayzor for a while because of the file watcher since Syncthing file watcher doesn’t like the root of a drive - but I never got around to trying the previous version because of it not being maintained. So thanks for reviving this!
So yesterday I started the upgrade of Syncthing to 2.0.0 and it worked perfectly on a win 11 machine but I had some issues with a windows 2019 server. After 3 tries, I got it to upgrade with your SyncTrayzor 2.0.1 - after it locking up the server and having to hard restart it. I think at this point it updated Syncthing to 2.0.1. Then it started doing a full resync of my 2.3TB of data and part way through the same lock up happened where I couldn’t even end task on SyncTrayzor.
I’m not sure if it’s Synctrayzor causing this lockup but it’s very suspicious that it could be. I don’t think it’s a memory issue as there was plenty of memory left. Would any logs or other information help you?
In addition, I keep getting these errors on both computers:
[Warn] SyncTrayzor.Services.Conflicts.ConflictFileManager: UnauthorizedAccessException when trying to enumerate files in folder:
System Volume Information
$RECYCLE.BIN
In Syncthing, I have these in my ignore pattern.
I’ve also had these a few times on different folders
[Error] SyncTrayzor.Services.Conflicts.ConflictFileManager: Failed to enumerate files in folder Path\To\Folder: OperationCanceledException The operation was canceled. System.OperationCanceledException The operation was canceled. Void ThrowOperationCanceledException() at System.Threading.CancellationToken.ThrowOperationCanceledException()
at SyncTrayzor.Services.Conflicts.ConflictFileManager.<>c__DisplayClass14_1.b__1()
at SyncTrayzor.Services.Conflicts.ConflictFileManager.TryFilesystemEnumeration(Action action, String path, String itemType) System.OperationCanceledException: The operation was canceled.
at System.Threading.CancellationToken.ThrowOperationCanceledException()
at SyncTrayzor.Services.Conflicts.ConflictFileManager.<>c__DisplayClass14_1.b__1()
at SyncTrayzor.Services.Conflicts.ConflictFileManager.TryFilesystemEnumeration(Action action, String path, String itemType)
SyncTrayzor doesn’t know about syncthing’s ignore patterns (nor would that be useful). It’s to be expected that it can’t access the above, as they’re protected system folders. Those warnings can be ignored.
The upgrade to syncthing 2.0+ will trigger a database migration, which is resource heavy. From your description, my first assumption would be the machine didn’t like the load.
If you can replicate the lockup, an exact timeline of actions performed within SyncTrayzor may be useful. Also, if this reproduces with plain syncthing without SyncTrayzor. Otherwise, I’ve no idea.
I just want to thank you.
Great work.
I updated all my syncthing installations to 2.0.2. This includes several LMDE and one W11 running SyncTrayzor. I used your exe to upgrade the old version. All worked like a charm.
Thank you so much for updating SyncTrayzor! Very happy to see it’s getting the love it deserves.
I hope someone will stand up and offer to help with modernizing the UI code so it can become cross-platform. I’ve tried other wrappers but it just didn’t feel right in the way that SyncTrayzor does.
Beside that, is there more code that needs a touch-up?
Thank you @Nummer378 and all the other contributors for your great work!
I did not find any indication about the possibility to upgrade my old SyncTrayzor portable to the new SyncTrayzor2 portable (or how to transfer my old config). Is this possbile…?
What does the Cefsharp.browsersubprocess.exe do, is it really necessary. I blocked it in the firewall and SyncTrayzor v2 still works no problem (so far).
Cefsharp is the embedded chrome browser, so this binary is probably the browser subprocess. The embedded browser is only used to display the Synchting web ui. Blocking internet access doesn’t change anything, as it only accesses localhost.
Recent CEF versions apparently want to talk to Google for whatever reason ( why does CEF need safebrowsing? No idea…). I haven’t found a switch to disable that unfortunately. Blocking should be fine as CEF only really needs to communicate with syncthing through localhost.
I’m not that of an expert in .NET, but using a bundled runtime, other than increasing the download size, also increases the memory usage and startup time, albeit not necessarily much in these days of multi-GB processes. Would you consider providing a framework-dependent and a self-contained download? I remember some .NET apps used to do that (my impression is that nowadays most apps do not bundle the runtime, as it’s omnipresent, and Windows can always show the ‘download .NET’ dialog)
I can’t measure a difference in startup time when using self-contained vs external runtimes. I haven’t looked at memory too much, but I use external runtimes all the time during development and there’s no significant difference on my machine either.
I did consider whether to use a self-contained build vs an external build. In the end I went with the self-contained for several reasons:
Runtime version: If the user provides the .NET Core runtime, we have not much control over the version in use. That increases the number of potential bugs, and it’s super difficult to test with all different patch levels that the Core runtime has.
Modern .NET Core doesn’t exactly have a super long lifetime. We will need to move to the next .NET LTS soon-ish, and unfortunately Microsoft doesn’t uninstall old runtimes due to backwards compatibility. I myself have all .NET Core runtimes all the way back to Core 5 on a recent machine, because programs install them and then never clean them up. You inevitably end up trashing the user’s system with old runtimes this way (and the user has no idea if they can safely remove them or not, nor do we)
Security updates managed by us: This is both a pro and a con. The core runtimes receive regular security updates, and by pushing builds with the latest runtime we ensure that the user has these patches. Of course that also means that we need to do regular releases, otherwise the runtime is frozen. If we use an external runtime, Windows Update can manage security updates as long as it’s on a supported major version (generally up to 3 years).
Installer difficulties: The installer would need to ensure that a correct version of the runtime is present on the user’s system. We cannot rely on the startup detection, as that won’t fly with distributions like chocolatey and also doesn’t work on an offline install. The .NET installer has lots of error dragons left and right, and avoiding it altogether is just the simpler way.
I originally hoped to provide an AOT build, which is vastly superior performance-wise. All AOT builds have the runtime included. Unfortunately, WPF (the UI framework used by SyncTrayzor) is incompatible with AOT, so we don’t have them at this time. But if there’s ever a chance to get an AOT build, it will be with the self-contained runtime.
I should note that the self-contained runtime for us “only” adds about 50MB. That’s far more than I would like, but it’s also much less than the 200MB CEF dragon that annoys me a lot more…
Very interesting indeed, and well thought through. And it makes me think back to the Good Old Days when one of the marketing taglines of Firefox 1.5 was “Setup’s a snap! - only 7 MB for the installer”. In sharp contrast to the alternatives back then, long before Chrome came about.
Reminds me of the guy who made a tool called spinrite. It was a disk recovery tool. He wrote a number of useful utiiities in assembler. Fully self contained executables that were a few kb. Maybe up to 10 or 20kb with GUI and everything. LOL. So much bloat in these huge libraries.
@Nummer378 I’m syncing 2 windows machines both ways. One is windows server 2019, one is windows 11. I have noticed that my scanning is really slow on the server. The win 11 speed is not ideal but can live with it. Once the scan is complete, the sync is quick. I am using the file watcher in synctrayzor because it is a full drive that I’m syncing via mkdir. I disabled the full rescans.
Global State 4,634,303 files 101,28 folders ~2.35 TiB
win 11 - 17mins
server - 60+mins
Any ideas what I could look into as to why the slow scan? I had hoped that when the file watcher picked up changes, it would sync them and then continue checking for changes - but it seems to wait to check the entire set of files before syncing.
Just to confirm: You are using the file watchers from SyncTrayzor and not syncthing, because the native file watchers do not support drive roots, correct?
The SyncTrayzor file watchers are really a legacy feature from the time where Syncthing did not have a native mechanism on Windows. Their performance isn’t guaranteed to be ideal. SyncTrayzor also cannot increase the scanning speed: all it does is tell syncthing “hey please go and scan this path”. SyncTrayzor passes the watcher events as received from the Windows API. If that includes a changed root folder, syncthing will scan the whole folder.
In general, syncthing will need to do at least one full scan to build the database for the folder. Subsequent scans are much faster.
That’s correct. That’s why I’m using the SyncTrayzor file watchers. I have a P drive that I’m syncing via mkdir (C:\Mount\P). It has many project folders and they have many sub folders.
When you say “one full scan”, do you mean the root P? Because that has been built for weeks now. I’m trying to speed up the sync and the “scanning” seems to be the bottleneck here so not sure what I can change to make it faster..
