Ref. v0.14.37, Windows (64 bit) “Dysprosium Dragonfly”.
Hello, apologises in advanced if this is already requested.
If my understanding is correct, in the situation where a file conflict has occurred, the system handles this in the background by creating the necessary conflict files.
The problem I have is that the conflict occurrence is not displayed in the GUI, except for in the Global Changes window. Thus I have to remember to look.
The feature request is to have a notification permanently displayed in the GUI in some form of list perhaps. This would prompt me to click on a link that would open the relevant folder and I could investigate the conflict. A suitable button next to the notification could then be clicked to inform the system I have dealt with the conflict and the notification is then removed from the conflict list displayed in the GUI.
As a side note conflicts seem to create a ~.tmp file that is not removed. Could ST. remove this file automatically?
If you mean it would not be possible to create such a ‘link’ to open the relevant local folder, no problem, but it would sure be handy.
I assumed this was part of the conflict. I’ll wait to see if the file is cleared. I will have to lookup what the Advanced Options mean, but I assume it is keepTemorariesH 24.
There could be a ton of conflicts, it’s not obvious how/where to display them, and how to maintain the list persistently without having to re-walk the filesystem every time.
Sure, I have no idea how such a thing could be implemented as I am coming from an end users perspective. However, if there were to be a ton of conflicts the end user is going to have to sort these out manually, so I think it would be a good idea if the GUI has an improved method of notifying the end user that conflicts have occurred (maybe an optional email notification too). This would help the end-user fix a problem before it got out-of-hand. At present the end user has to search the Global Changes Window or folders manually.
If I understand correctly there is a MaxConflicts setting, however I think this is a per folder setting and I am not sure how it works in practice, but I assume it can help keep conflicts to a minimum. Perhaps there is a global setting too, but I am not aware of one.
Now if the system had a option to prevent the same file being opened on different devices at the same time, this would greatly reduce problems this scenario can cause (obviously this would not work if a device was offline). I have noticed that ~lock files are propagated quickly (I assume at the Rescan Interval), so perhaps Syncthing could enhance that in some way?
Well you can set MaxConflicts to 0 at which point I think they won’t be created all together, but the point is that they are created to avoid data loss, not because we are doing a sloppy job of syncing something.
There is no way to lock anything across devices, as locking as a concept doesn’t even exist on some platforms. You can avoid syncthing ~lock files by using ignores. As I said, I am still not sure what the ask here is, it seems you are in a situation where the tool is not doing what you want, but it’s because you did not configure it the way you want it.
The feature request is to Update the GUI so that File Conflict occurrences are displayed more prominently and help assist an administrator/enduser in dealing with them.
I have misunderstood MaxConflicts. I assume that after x conflict files are created then ST just stops creating anymore. If that is correct, when MaxConflicts is triggered it would be a good idea if this was displayed prominently in the GUI. I know this scenario is unlikely, but some end users seem to turn their brains off when sitting in front of a PC.
If the GUI displayed conflict events more prominently and/or sent an email, an administrator could investigate and nip any problems in the bud. The problem is not that conflict file are created, but what the consequences could be if two end users do not realise that a conflict has occurred.
Ok, I went around in circles but I have finally found the documentation for SyncTrayzor. One thing that is not clear to me is, is it best practice to close SyncThing before installing SyncTrayzor?
Great, I installed SyncTrayzor without any problems and it immediately picked up the conflicts I created, gave me delete buttons and the option to open the local folder.
This is exactly what I needed!
Excuse my ignorance, but is it the developers intention to merge these two programs?
No it isn’t. SyncTrayzor does only really work on Windows. But Syncthing is multi platform with a huge amount of installs on headless servers.
Synctrayzor is listed as the goto install for Native GUI in Windows on the download page though and is recommended for new users on windows. There were discussions for optimizing the download page so Windows users would get a much more prominent download link for Synctrayzor, but this isn’t implemented yet.
My experience: Syncthing beginner, 20 years IT support.
I already had Syncthing installed and tended to follow the documentation and support links from the main GUI to find information. It never occurred to me to access the home page.
From the support forum, a user would have to have pre-knowledge of SyncTrazor. From the documentation website SyncTrazor appears twice as far as I can tell:
FAQ – SyncTrayzor is referred to as a “notification plug-in”.
Community contributions – SyncTrayzor is referred to as a “Windows host for Syncthing”.
From the homepage https://syncthing.net/ there is a Native GUIs & Integrations section (top -left) with a link to SyncTrayzor. If this is the go to install for native GUI in Windows and is recommended for new users on Windows, this is only inferred. I had a good look through all the areas as mentioned above, and I could not find any such recommendation.
So yes if it is the developers wish that SyncTrayzor is the go to program for Windows users, I would also suggest that the documentation website is amended to show this. I must admit my impression was that SyncTrayzor was an add-on and I overlooked the significance of it (apologies if I am just bringing up old discussions).