Probably disable comparing inode change times if there is a modtime window, I think this could be done in the fileinfo comparison function, it already knows about the modtime window.
To be honest, my confidence when editing the Go code is very low, but I’ve tried doing something like this, i.e.
change
to
// If we are recording inode change times and it changed, they are not
// equal.
if comp.ModTimeWindow == 0 && ((f.InodeChangeNs != 0 && other.InodeChangeNs != 0) && f.InodeChangeNs != other.InodeChangeNs) {
return false
}
Is this change correct and what you meant above?
I still need to take a closer look and think this through, so just some quick though: Shouldn’t a time (whether modification or inode) change only not cause a conflict, resp. the conflict should be resolved silently without a copy? And if time shenanigans happen as with mtime, inode time should probably get the same treatment (DB backed time, a window, …).
The problem is that these conflicts happen when actually updating the file (i.e. changing its contents) on another device 
, so I’m not really sure what is going on under the hood specifically, but the modification proposed by @calmh in https://forum.syncthing.net/t/keep-getting-conflicts-generated-on-android-device-for-files-modified-only-on-a-desktop-pc/19060/17 seems to have fixed the issue nevertheless, as there have been no conflicts for the last 24 hours.
I think I may be experiencing this problem too. I first noticed it a few days ago.
After running fine for many months I started seeing sync conflict files for simple text files I edited on Linux. Those files get synced to one other Linux system and two Android phones.
If I edit the file on Android I don’t get the sync conflict files, but they almost instantly appear after any minor edit on Linux.
After reading this thread I’m guessing they started after and are related to the latest Syncthing update. I’ll do some digging and would appreciate any pointers.
Also ran into the same Issue. Windows, Linux Raspberry Pi work just fine on 1.22.1 . But as soon as I enable the Android client I get conflicts on every change. My Android is a Pixel 4a 5g on Android 13
I can help debug if needed
The thing I am still curious about (though not necessary for broad fixes): When does android report a new inode/c-time? The times in the logs look reasonable, but clearly they get updated too often.
To fix the problem generally, I propose the following two changes (will PR):
Ignore inode time for comparisons if neither xattrs nor ownership is enabled. To contain any issues with those features on all the systems they make no sense to use on (or simply aren’t used). It also just creates index/version vector churn.
Don’t bump the version in the scanner if only inode time changed, but everything else stayed the same.
I think that’s an overly broad disablement, we already had bugs related to some changes being considered not important enough to actually pass to the database etc.
We have the mtime window for systems without reasonable mtime semantics, I think using that to disable the inode time check as well makes enough sense.
What about systems misbehaving with respect to inode time that aren’t FAT and don’t have a window? I don’t see any value in considering inode time when it has no effect, while on the other hand it clearly can cause pretty significant issues. The previous bugs about “information that isn’t important enough” only mattered when any of the opt-in flags were enabled. Ignoring inode time for comparison addresses the default use case and won’t change the behaviour with flags enabled.
Also inode time really is a local thing (given it changes on pull as we don’t set it). So bumping the version just because inode time changed, but nothing else did, is at best useless, at worst misleading - it would have prevented the conflicts (inode change will still be persisted to db).
And what’s the connection of the mod time window to the inode time? Seems like android is misbehaving on inode time and also has a mod time window, and I guess it’s somewhat likely that a system with “not ideal mtime” also has issues with ctime, but is there any actual link? For android I’d actually guess on some virtualisation layer or management process causing inode time bumps than something FAT-like misbehaving (if FAT is even a thing still on android, don’t think so).
I also PRed the two changes, in case we do want to follow any of them (or not).
I’m not sure there are any such systems? I mean, there could be of course, but this seems like something that’s either tracked or it isn’t, and if it isn’t we’ll probably get back either zero time or the mtime, either of which should be fine. It’s just that FAT doesn’t manage to keep mtime either and Android maybe just makes up all the change times based on pure fantasy…
Anyway, I agree we don’t need to create and send a version if the only thing that changed was the inode time, obviously. I’m undecided on whether it’s a good idea to track it anyway or not… will sleep on it and look at your patches.
1 Like
FAT is still alive and well 
, at least when it comes to the internal /sdcard partition (and, of course, external SD cards).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.