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.

anarcat · August 17, 2024, 2:42am

what is mtimeFS? it’s not config options… I’m asking because I got weird sync issues when running syncthing on a rather exotic platforms (a Kobo reader, which runs a custom Linux OS, with a folder backed by a FAT filesystem). I would get spurious sync conflicts, and difficulty propagating file deletions to the device, along with extremely long syncs (10m for a ~16GB folder).

All those issues seem to have gone away after flipping modTimeWindowS from 0 to 2, which wasn’t done automatically even if the backing folder was on a FAT filesystem…

It seems like not only Android has those problems, maybe it would be better to just do this on all FAT filesystems?

I somehow doubt that linux distro does something weird with FAT, but if you’re interested, i could look a little further. Maybe it’s some mount option we’re tripping over?

For what it’s worth, the mount looks like this:

/dev/mmcblk0p3 on /mnt/onboard type vfat (rw,noatime,nodiratime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)

any specific test i could do to confirm i’m seeing the same behavior Android is?

calmh · August 17, 2024, 5:07am

I think it’s more that it’s not detectable in the general case, at least not easily, and Android is a known environment. Setting the modtimeWindow when you know the fs is FAT is the correct thing.