I often face issues with Syncthing reporting conflicts, I believe in my case it’s due to the following issue:
Background Issue: My Home-PC is generally always on but when loading my Notebook I believe a program might be loading/modifying a file slightly before Syncthing has loaded/synced so if I made a change to a file at Home-PC the Notebook then creates a conflict as the updated file coming from Home-PC is actually the newest ‘data’ file however the Notebook has just edited the same file but most likely just changed some minor open file mark inside the file making it have the latest date before Syncthing has loaded…etc…
I understand nothing can be done from Syncthing side for this issue… however, I do find the Conflict REsolver screen to be a little complicated and not very clear currently and would like to suggest the following:
Currently the Original File lists the last modified date however the Conflicting file name does not (it liss a conflict created date which the file name also includes… see screenshot below)
Going on the screenshot above you will notice it’s very hard to ‘see’ which file is newer and which is older as they are comparing different dates/metadata.
What I normally need to do each time to confirm which is the correct file to keep, is click on the ‘show in folder’ button and see the file dates via explorer as per the bottom half of the image above (forum limited me to a single image so merged them together, sorry for any confusion):
From the screen above I can now see the conflict file was actually modified on the 1st March which would be the correct file to keep were as the top file is actually today’s date and time and as I only just turned on my PC today a few min ago I know I have not used that file today so the changes inside that latest file must not contain the true updated file from 1st march…
Proposal:
Please, could you consider adding last modified dates to both "original File’ and “Conflicting File” so it’s easier to compare and choose the correct file to keep
Why is it hard? The non-conflicting file is newer. The decision on which file becomes the conflict is based on time, so the newer file is always the one that was not renamed to conflict.
The date of the conflict file in that case is when the conflict was detected, not the modification time of file that caused the conflict.
I agree with you 100%, it’s not hard at all to see the non-conflicting file is newer, however for me to do this currently I need to use Windows Explorer (show in folder button) as the GUI currently does not confirm or display the modified dates of both files currently meaning there is no clear and accurate way to confirm this without Explorer to ensure the correct decision is made…
Thanks for looking into this for me
Update: also looking into the screenshot again I see the newest file is also called "original’ file which could also imply ‘older’… perhaps the word ‘current’ or ‘latest’ might be a better word but for me personally just seeing the modified dates of both files will be enough to confirm which file i need to keep or not as in my case I need to ensure I keep the older file name
You don’t need to confirm it, that is always the case, as the date in the name of the conflict is the modification time of the file. The actual date shown in explorer is irrelevant.
The last modified date of the filename is very important to me with this database file name as if I choose the wrong file I can lose a bunch of data so I need to always double check before selecting which file to keep and which to discard.
Thanks for your reply and taking the time to check into this for me, I was going through it and double checking thing as the file modified time is critical to me to know which file is ‘older’ and also to confirm the current/latest file does have a last motified time of essentially right now as if this is the case it means the following to me:
the application using this database file (although not used) has changed something very slightly in the file (probably a time stamp or similar as they files to slightly differ if I do a byte by byte comparison).
The ‘older’ file modified in this case on the 1st March is correct for me as I know I did edit/use that database file on the 1st March so I know the date listed is correct and that the current version being todays date is not correct so I essentially discard the latest verison and choose the older version provided the above conditions are correct…
If I ever have a case were the modified dates don’t match up to what I expect I would then need to manually open each file up and try to compare what has been changed and visually ensure the file I choose is the correct one however so far to date the modified file dates have been perfect for my workflow and have been a reliable way to quickly ‘see’ which file I need to keep.
Hope the more details above help explain the workflow and reasonings why the last modified data can be important to some users however I can also understand now that you mention it above that on some cross platforms/OS’s it’s possible perhaps for the modified data to change if you change the fil,e unlike Windows is behaving for me which works out well.
Thanks again for taking the time out to consider this and looking into it for me, greatly it’s appreciated!
In your case the non-conflict file should always be newer. If it’s older, then the time of the conflict file was artificially bumped when it was renamed.
I believe you are 100% correct, thinking back I do think I do normally choose to keep the conflict file however as it happens not very often I always want to ensure 100% that I’m selecting the right file by checking the modified file stamps as it’s not something I do every day and I always question myself on which one to select and always believe if in doubt always double check which is what I do each time… hahaha
If it’s at all possible to show the modified time somewhere in the GUI that would be great, if not that ok I’ll just keep manually checking each time, it’s more of a time saver step and keeping the dates listed in the GUI ‘comparable’ with each other which is what would nice for my needs/workflow
I don’t show the “Last Modified” time for the conflict file as it has no meaning: the file was almost certainly last modified by Syncthing when it created the conflict file. Instead I show the date at which the conflict file was created, which should be the last thing that touched that particular file.
Thanks for the reply, however in my case the last modified date is critical and has allot of meaning for the following reasons:
The file that is synced is part of a programs database.
It can be modified by either Syncthing (syncing from another PC) OR it can be modified locally by the application that controls the database even if no changes are made.
Depending on the last modified time of the file I can tell if it was modified by myself (eg, if I see it’s been modified recently but I last ‘used’ the application yesterday) I know the file has been ‘touched’ by the local application that has not really been ‘modified’ from a database contents point of view but has been from a metadata point that will trigger the conflict.
In this case I need to manually confirm if I did update the file at another location the day before or not, it’s very important that I keep the ‘older’ file in most cases I’ve found and not the newer one.
In my situation the creation date of the conflict is nice to know but it’s of no use to me trying to work out which file truly has the latest data inside… The conflict creation date is also listed in the new file name and also listed in it’s own field currently (I understand with long filenames you could possible not see the date in the file name and it’s why it’s listed as well) but for my use having a modified date would be allot more usefully and it’s directly comparable to the ‘original’ file listed above it (which is actually the ‘newer’ file and not an original/older file which I find can also cause me to second guess myself at times as I need to be 100% sure the file version I keep is correct to avoid data loss)
Perhaps if both the conflict date and modified date were listed it might work for all parties?
? It’s actually fine as it’s a small application I use to sync password database that I don’t want to use a public cloud for and find Syncthing would be more secure being a private cloud network… I generally only use it in one location at a time but I think the issue comes in when the application might load up and open the database before Syncthing has finished syncing on load…if that is the case it can be very easily resolved by checking the modified timestamps…
I appreciate the general idea it’s not a good idea but like I’ve said if I can simply check the time stamps on a file it’s really a very reliable and much more secure way for me with my workflow… Also if I had all my systems on 24/7 it most likely would not be an issue but I sync it at my work PC as well and often thats were the conflict might occur as that PC is not on all the time.
The application I’m using is a password manager… I believe what can cause this issue is if I login Windows and then try to login to a website before Syncthing has updated/synced I run into this issue IF i’ve changed the database at home for example (changing passwords, adding new registrations…etc)…
I’m not a huge fan of the public cloud for sensitive data and prefer to use a more ‘closed’ network and found your application to sound really good for this and it’s been working fantastic other than the very minor issue in the GUI with not being able to compare the two files displayed for my use as I believe most people would generally keep the latest version of the file but with me I often want to keep the older version (depending on the time stamps) which is really easy for me to manage using the Windows Explorer view and though if it was easy and might benefit others to see both modified dates that would be great
Can you answer the question, and confirm that the program is modifying the conflict files?
I don’t think it is, and if it is not, then the modification timestamp is always the timestamp of when the conflict file was created which is totally irrelevant, arbitary and not related to any modifications your application made.
