Conflicting file - Last modified date filed request on both files

Feature
21

Hi Audrius, I’m a little confused as I feel I’ve answered this a few times above already?

“The file can be modified by either Syncthing (syncing from another PC) OR it can be modified locally by the application that controls the database file even if no changes are made”

Perhaps we are talking about different things so please could you expand on what details you are looking for in a different way as I feel I’ve tried to provide a fair amount of detail already (perhaps a little too much that has confused things?)

Let me try expand on the file change side a little more and hopefully what you are after is included below:

  • File being synced is a local database file for a password and personal data management application.

  • The file can be edited on any system I have (currently around 3-4 in my Syncthing network.

  • Each destination system has the application installed and is set to not automatically open the file to avoid it being changed in multiple locations or being ‘locked’ and in turn unable to sync.

  • Say for example I make a change say on my home PC to the database at night then close the application down (to release the database file so Syncthing can access the file to update across other systems) - (so far all good and working well!)

  • In the morning I get into work, log in and see an e-mail I need to action I click on a link and check up some data in my password application, as soon as I unlock the application I believe the database file is slightly changed (modified), from what I can see no ‘data’ inside the database is changed but essentially metadata inside the database file but it’s enough to change the file and in turn the modified date…etc…

  • Then what I believe happens next is Syncthing eventually finds my other PC’s online and starts to sync however at this time it’s detected I modified the file at home yesterday night (which is correct) BUT it also detects the local file has been modified (although not really)… the file from home is actually the file I want to keep as I know I made changes/edits there but this morning at work I simply used the database in essentially a read-only mode (although the application did change the timestamps of the local file before it was updated via Syncthing)…

  • This does not happen too often as I try to give it time to sync and I also try to give the systems time after I close/lock the application (to release the database file) so Syncthing has time to sync those ‘metadata’ changes to other systems before shutting down the system for the day…

In my eyes to answer your question above “Is the program modifying the conflict files?” Yes my application controlling the database file is modifying the conflicted files…

Syncthing is correctly detecting the file has changed on both sides so no problems at all with Syncthing reporting a conflict as it’s 100% correct as I have done a byte for byte file comparison and the files are also different… so I have absolutely no issues with Syncthing reporting the conflict as it’s correct but the only feature request I would be grateful to see is having the modified date shown in the GUI for the following reasons:

  • When making important decisions such as deleting data from a system it’s always good to have a ‘check’ in place, the modified date is this as it relates to the file you are working with.

  • For me, the conflict date is nice to know and see as it relates to when Syncthing detected the conflict and stamped it as such however it has no relevance to my data nor the application so is not useful in a check situation for the source data.

  • Having a modified data on both the current and original/previous file listed allows a key piece of information that is directly comparable and relatable to the data files in question. (the conflict data is nice but irrelevant from the data file/comparison side of things when making an informed dessision about your data files)

  • I fully understand form a Syncthing point of view the conflict date stamp is great and important as it’s key data for Syncthing and working out when/why something happened however from the data file side of things it’s quite meaningless which is the side I’m working from as I know Synthing is working well and doing things correctly (and again the conflict data is great to know from a Syncthing side and troubleshooting any potential issues or trying to understand but just not to do with my data)

Hope some of the above details and information has helped try to explain and expand on some of the reasons and the thought process of this request and how it related to ensuring the conflict file I keep is 100% correct each time if the modified date is added to the GUI…

Just to summarise, I’ve had no issues with Syncthing and it’s working 100% well (thank you Syncthing team!), also each time a conflict is created it’s been correct and accurate, I’m also able to very easily resolve these conflicts when they occur (which is not too often really) but when they do I just need to ensure the file I’m keeping is 100% correct and the modified date on the file is the key bit of information to make an informed decision.

22

Hi Bt90,

No RDBMS in play, it’s essentially just a very basic flat database file that is only locked/in use when the application is in use. It will also automatically lock again after 15min of the application not being used, allowing Syncthing to access the file and update any sync jobs.

The application does not run as a service and does not hold the files open nor has any relationship database structure… it’s a very basic database file (essentially can be thought of as similar to an excel document really).

Hope that helps clear the ‘database’ part out as I should have expanded on that before to avoid any possible concerns as you have raised if I was using a RDBMS.

Apologies for all the long posts (especially above) as I’ve been trying to expand on the reasons and workflow/setup as I think I’m struggling to get my situation across well so hopefully the ‘detail’ above will help if you don’t fall asleep before getting to the end… hahaha

23

I don’t think your application is actually modifying the file.sync-conflict files based on what you described.

In any case the modification timestamp of the file does not represent what you expect and it usually represents the time syncthing renamed the file from file to file.sync-conflict, which is not at all related to when your application modified the file, so the mtime you are looking at is completely irrelevant for what I see.

Literally, as you noted yourself, what you are asking for is to see the time of when syncthing renamed the file, which is in no way related to the time any of the applications you run touched the file.

This is usually in close proximity (if not the same) to the date that is embedded in the file name, so I strugle to see any value of that timestamp being shown in the ui.

24

Thanks for the reply Audrius

In any case the modification timestamp of the file does not represent what you expect and it usually represents the time syncthing renamed the file from file to file.sync-conflict, which is not at all related to when your application modified the file, so the mtime you are looking at is completely irrelevant for what I see.

The last mtime on both files (old and new) files absolutely do represent the mtime the application modified the file in my cases. It does not represent the time Syncthing renamed the file as indicated above (the time synchthing renamed the file is recorded in the renamed ‘file name’ but this does not change the mtime of the file)

Literally, as you noted yourself, what you are asking for is to see the time of when syncthing renamed the file, which is in no way related to the time any of the applications you run touched the file.

Not correct, I’m asking that the mtime be considered to be added to the GUI for the “Conflicting file” as the GUI currently displays only for the “Original File” (screenshot to follow shortly for reference).

This is usually in close proximity (if not the same) to the date that is embedded in the file name, so I struggle to see any value of that timestamp being shown in the ui.

The time stamp I’m sugesting for the GUI is the mtime of the conflicting file, this makes it directly comparable to the “original file”, currently the GUI lists 2x dates which are completely not related to each other, one is a file last modified time the other is the time Syncthing detected the conflict (important information but nothing to do with the conflicting file)

Please refer to the below screenshot you will notice the following details available:

Original File - mtime: 4-3-2019 8:58:38am Conflicting File - Conflict created: 4-3-2019 8:48:37am

Now if you check Windows Explorer this is what you see the mtime of each file to be: Original File - mtime: 4-3-2019 8:58am Conflicting File - mtime: 1-3-2019 9:39am

Capture7-3
Capture7-3775×762 46.6 KB

You will notice the mtime for the conflict file is on the 1st March 2019 however the conflict was only detected on 4th March 2019 which is after the weekend once I got back into work… If the mtime of both files is displayed in the GUI you can see how easy it would be to identify which file is older from a users point of view…

Currently, the Conflict creation date is essentially just about the same as the original file shown (they are 1 second apart in the screenshot above) which does not currently provide any certainty on your data when trying to decide which version is required… Also the wording can create a little extra doubt as well in that the word “Original” could be interpreted as “previous/old…etc” but I’m not sure what word might work better other than perhaps ‘current’ file but it too is not very descriptive but I think it could offer a little more accuracy but this does not bother me if we are able to get mtime listed as thats the key data required for mey workflow :slight_smile:

25

Ok I just made a quick GUI suggestion change that you can see below that lists the “Last Modified” date on the conflicting file and I moved the conflict created date next to the file name side of the screen that should hopefully provide a better visual of what I’m requesting as I’ve also changed the dates to match up on what would be good for my workflow and I believe would make things more clear and easier to understand for most end users as well as with most users they would know right away to keep the “original File” as it has the newest mtime however in my case it allows me to know instantly depending when I worked on the database last I would more than often keep the older file :slight_smile:

Hope it’s of help to better explain (or show what I mean which might be easier) :slight_smile:

Capture7-3b
Capture7-3b775×762 72.3 KB

26

Not entirely sure why that is happening - I’m not sure it should be… Also if the conflict file is synchronised from another device, then the last modified time should definitely be the time at which it was synced (so even if you mockup is correct on one device for reasons I don’t understand, it won’t be on the others).

27

You could use Process Monitor to track which process is altering the files in which order. At least if you’re able to reproduce this behaviour.

28

Hi Antony,

Thanks for the reply, however I can confirm 100% after doing further testing the mtime is not modified after a sync job (as I don’t believe it should be).

For example I made a series of fils on my home PC with random dates between 2000 and 2019, I then remote connected to another PC and waited for Syncthing to propagate the data to my other systems and all all my other Windows systems the mdate was synced as well which I find very good as when Syncthing syncs a file it really should not change the last modified date as that file has not been modified but simply copied so the contents of the files has not been modified so the mdate should not change I would not think and this seems to be the case on 3 different Windows systems I’ve just tested it out on…

I then did another test by simply not editing the contents of the file on my home PC but simply changing the mtime file attribute to 1st Jan 2018 and this mtime was then synced and updated across all my Windows PC’s even withough the contents of the file changing so it seems Syncthing is managing the syncing of just metadata as well (mtime changes alone) which is really good!

29

Hi BT90,

Thansks for your reply, I have confirmed that the application I use is altering the file… what happens is the following:

  • If I start my PC up and login, all is find and no files are changed

  • If I load up my passwords/data manager application and unlock it with my password, at this point the application slightly alters the file and has it ‘locked’ so Syncthing can’t sync the file however once I lock the database (or it automatically locks it in 15min of no use) it then releases the file so Synthing can access/sync it with the ‘changed’ database file which essentially from a ‘data’ point of view has not really changed but physically the file has changed due to some database metadata stored inside the file being altered slightly…

  • I might reach out to the developer and ask them what they track/change and if it’s possible not to alter the file if no changes have been made as that would also make things easier.