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.
I have also compared the actual modified timestamp of one of the files.
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).
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.
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.
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.
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.
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)
. 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.