I guess so, I don’t think syncthing should add EINTR loops around our Lstat calls , Go developers have refused to fix it:
OK. Thanks for the help anyway. (And, as I said, this seems not to be a fatal issue, as things get added again, so nothing is lost).
This is probably the cause yes, and seems to be Android being Android as usual (i.e. different and annoying). That said, I’m not sure why the Go teams stance is what it is, and perhaps it could be revisited. The root cause of the confusion is probably that lstat() calls are not supposed to be returning EINTR on Linux. For example, the man page for lstat on Linux doesn’t list EINTR as a possible error, hence it’s not handled by Go or by us.
However, it is listed as a possible error return on for example Solaris, where Go also runs.
I guess you should reopen the issue and point them to the Solaris MAN page.
Alternatively, we could provide osutil.Stat osutil.Lstat … but I’d rather not.
I dunno. Apparently (reading that issue closer) Go registers signal handlers with SA_RESTART set, which means system calls should be automatically restarted when interrupted. However man sigaction doesn’t mention lstat being among the restarted system calls, which for example stat is. So this is probably an Android bug, having syscalls return errors they normally shouldn’t because it does weird magic underneath those syscalls.
The “solution” is probably for us to retry the call a few times if the returned error code is EINTR. 
It ought to only be needed for os.Lstat so it’s not really a heavy burden, even if it’s annoying.
(This was less of an issue before, because we required Lstat() to return an error that return true for IsNotExist(), so we didn’t interpret the “interrupted system call” return as a delete. We changed this because other error returns can also indicate a delete, i.e. “not a directory” can be returned for the previous children of a directory that has been replaced with a file.)
Because I love working around broken platforms:
In case it matters, I am no longer seeing any of this, after three days of running the new version of ST in my linux machines and the Android “silk client” (mentioned here: https://github.com/syncthing/syncthing-android/issues/362#issuecomment-96182479), with v. 11.0. Thanks a lot!!
An additional detail: with the silk client I think ST is always running in the Androids. This is in contrast to what seemed to happen with the standard android ST client, where it often was beeing seen as disconnected from the computers, and I had to manually re-wake the Android from sleep, and sometimes even restart ST. So if the weird events could have been triggered by sleeps/re-wakes this might have something to do with it too. (That the ST client is always running in the Androids is great for me so far.)
1 Like
Would this apply to arm builds as well?
You mean the Linux for arm? I have no idea. I was using the ‘silk client’ (I am now trying the official android app).
I see this thread does not get any attention any longer.
BUT: I do have this effect with standard android client v0.14.22-rc1+12.
On a synched laptop the files are removed BUT the still are present on the Android.
I am using BoxCryptor additionally.
I doesn’t get any attention because it’s several years old and the problem was solved a long time ago. You may well be seeing something similar or even the same, but the cause will be different. There was something about the media manager on Android resurrecting photos that were deleted on the other side, or your crypt thing may be doing something strange. I’m closing this topic, feel free to search for something more recent to resurrect or open a new topic if it seems none of the others fit. 