Why default modTimeWindowS to 2 for FAT only on Android?

tomasz86 · January 26, 2021, 7:31am

As far as I understand, the FAT file system uses imprecise timestamps regardless of the OS. What is the reason for applying the default value of 2 on Android only? Would it not be better to always apply it when finding a FAT partition and remove the OS check altogether?

The relevant part of the code:

github.com

syncthing/syncthing/blob/0db3b7a5304c679226687a53af994a0c650e056d/lib/config/folderconfiguration.go#L73-L87


func (f FolderConfiguration) ModTimeWindow() time.Duration {
	dur := time.Duration(f.RawModTimeWindowS) * time.Second
	if f.RawModTimeWindowS < 1 && runtime.GOOS == "android" {
		if usage, err := disk.Usage(f.Filesystem().URI()); err != nil {
			dur = 2 * time.Second
			l.Debugf(`Detecting FS at "%v" on android: Setting mtime window to 2s: err == "%v"`, f.Path, err)
		} else if usage.Fstype == "" || strings.Contains(strings.ToLower(usage.Fstype), "fat") || strings.Contains(strings.ToLower(usage.Fstype), "msdos") {
			dur = 2 * time.Second
			l.Debugf(`Detecting FS at "%v" on android: Setting mtime window to 2s: usage.Fstype == "%v"`, f.Path, usage.Fstype)
		} else {
			l.Debugf(`Detecting FS at %v on android: Leaving mtime window at 0: usage.Fstype == "%v"`, f.Path, usage.Fstype)
		}
	}
	return dur
}

For reference: https://forum.syncthing.net/t/raspberry-pi-some-receive-only-files-always-get-marked-as-local-additions/16246

imsodin · January 26, 2021, 8:50am

There is already a mechanism that deals with any filesystem that does not have nano-second precision: The mtimeFS. Meaning that covers the 2s precision of FAT. That mechanism requires though, that the filesystem is consistent: If it told Syncthing at some point that the mod. time of a file is 01:30:03, when asked again it should say 01:30:03 as well - not 01:30:02. And that’s what a “normal” FAT filesystem does. Android on the other hand puts some virtual filesystem shenanigans on top of FAT, and apparently that changes reported mod. times upon restart (well remount probably). And that’s the problem and that’s why the mod. time window workaround is necessary despite having the mtimeFS.

tomasz86 · January 26, 2021, 9:07am

Thank you for the explanation, but what is the deal with that Raspberry Pi then though?

imsodin · January 26, 2021, 9:08am

No idea. Looking at that thread I don’t think it has even been established whether modification time is the culprit or not.