[SOLVED] Receive Only folders always get marked as "Local Additions" in Android

tomasz86 · November 12, 2020, 12:27am

I have this problem with Receive Only folders always getting marked as “Local Additions” in Android. This happens despite no changes having been made to the files, and reverting local changes also does not help, as the problem comes back right away after a rescan.

The files are located on a FAT partition, which makes me suspect that the issue may be related to FAT timestamps. However, as far as I understand, Syncthing has a workaround specifically for Android to deal with this.

github.com

syncthing/syncthing/blob/48da6f0f22729bc66cc43ffbcec6122b8ed8fbe9/lib/config/folderconfiguration.go#L68-L82


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") {
			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
}

I have also compared the actual modified timestamp of one of the files.

Android: 2017-10-04 12:05:46
Windows: 2017‎-10-04 ‏‎12:05:47

There is a 1 second difference, likely due to the FAT file system. However, even if I manually set the Mod Time Window in the Advanced Configuration for the folder to 2, the file is still listed in the “Local Additions”. I have also actually pulled the file from Android and compared it with the counterpart in Windows, and the two are binary identical.

Right now, it seems that the Mod Time Window setting is simply not working in my system.

Do you have any idea what the culprit may be? The only thing that I can think of that is somewhat “non-standard” is that I am running Syncthing as root.

Syncthing is v1.10.0 and Android is 4.1 (old, I know).

tomasz86 · October 29, 2020, 3:43pm

After more testing, there are two problems here.

Syncthing does not seem to detect my OS as Android (or perhaps the file system as FAT?), and thus the automatic 2s modtime window setting is not applied. Is there any way to see what OS has actually been detected as the runtime.GOOS?
Setting the mtime window after the files have already been scanned and added to the database does not clear the “Local Additions” flag. On the other hand, doing the reverse, i.e. removing a previously set mtime window does mark them as “Local Additions”. I believe that this is a bug (see https://github.com/syncthing/syncthing/issues/7067).

For now, I have managed to work around the problem by explicitly setting modTimeWindowS to 2 manually, and then using the “Revert Local Additions” button. After the operation, Syncthing correctly marks the the folder as “Up to Date”, even after further rescans.

AudriusButkevicius · October 30, 2020, 8:37am

GOOS is decided at compile time. If you are using Linux arm binaries, then goos is linux. We don’t specifically build standalone android binaries. We only build them when building the android app.

The fact that changing the window does not retroactively “unmodify” stuff is expected.

tomasz86 · October 30, 2020, 9:14am

Yes, I build the Android binaries myself. This would mean the the GOOS is not the problem, but rather something in between

github.com

syncthing/syncthing/blob/48da6f0f22729bc66cc43ffbcec6122b8ed8fbe9/lib/config/folderconfiguration.go#L71-L79


		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") {
			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)
		}

not detecting the file system as FAT, and thus not setting the Mod Time Window automatically. Is there any simple way to debug this?

Android itself reports the file system used on the partition as vfat.

AudriusButkevicius · October 30, 2020, 9:30am

I don’t think you can build with GOOS android unless you setup android ndk, pointed go at the ARM C compiler and all the other faf. Building an android binary is not as straight forward as any other platform.

You can enable debugging logging and see what those log lines print.

tomasz86 · October 30, 2020, 2:22pm

Wow.

First of all, yes, I have been building the binary despite “the other faf” under Windows for at least a few months. It is actually very simple, once you have downloaded the Android SDK.

set CC=<path-to-armv7a-linux-androideabi16-clang.cmd>
set CGO_ENABLED=1
go run build.go -goos android -no-upgrade -goarch arm tar

Secondly, apparently the file system is “msdos” . Now, this is Samsung’s Android, so I am not sure whether it is something specific to this particular manufacturer or a general naming convention.

DEBUG: Detecting FS at /sdcard/test on android: Leaving mtime window at 0: usage.Fstype == "msdos"

No wonder why Syncthing has been unable to detect the FAT partition.

Edit: Actually, judging by a quick search in the Internet, the name msdos seems to be in fact the standard name of FAT partitions in Android. I cannot find any official documentation mentioning this though.

bege · November 10, 2020, 7:08pm

I have the same issue as mentioned in the subject with Syncthing-Fork (Syncthing 1.10.) on Samsung Galaxy S5 Plus (SM-G901F), LineageOS for microG 16 (Android 9) and on Samsung Galaxy S3 (GT-I9300), /e/OS 0.7 (Android 7.1.2)

Catfriend1 · November 10, 2020, 7:56pm

Yeah, I think we need to wait till the fix lands in a release. It doesn’t play a role which app you use atm.

According to https://github.com/syncthing/syncthing/pull/7072 it may be in 1.12.0