Server: 5.1.3 on RasberryPi
Client: Android v. 2.1.5
WebServer: Apache, access via SSL
Client connects to encrypted library and downloads some files for reading.
Without any further action the Android client sometimes tries to upload files in that library without having been told to do so. These uploads all finally fail.
But they produce a lot of data traffic consuming the mobile data plan of that Android device when not being connected via WiFi.
seafile.log shows thousands of entries like “[07/05/2016 06:42:12 AM] repo-op.c(2912): Passwd for repo … is not set.”
I have no clue why the files above are tried to be uploaded.
Any help is appreciated!
These files have not been altered on the Android device - they only have been downloaded for viewing.
ES File Explorer still shows the timestamp when the file was downloaded to the Android device.
Last occurrence of this strange behavior was when the Android device returned from flight mode and went online in local WiFi.
Apache’s other_vhosts_access.log shows 3000+ pairs like this
"GET /api2/repos/.../update-link/ HTTP/1.1" 200 644 "-" "Dalvik/2.1.0 (Linux; U; Android 6.0.1; D5803 Build/23.5.A.1.291)"
"POST /seafhttp/update-api/... HTTP/1.1" 500 282 "-" "Dalvik/2.1.0 (Linux; U; Android 6.0.1; D5803 Build/23.5.A.1.291)"
As this is in the context of an encrypted library the cause for what I see in the logfiles is imho the no longer cached password on server side as it gets removed after one hour; so after coming back from flight mode after several hours there is no valid credential any more.
But I still wonder what makes the Android Seafile App calling the update-… API calls.
Is there a way to analyse the latter in more detail on the Android device?
I just see in the corresponding error.log (at the beginning of the GET/POST cycles from above):
[proxy_http:error] [pid 23950] (70008)Partial results are valid but processing is incomplete: [client ...:58201] AH02609: read request body failed to 127.0.0.1:8082 (127.0.0.1) from ... ()
[proxy_http:error] [pid 23950] [client ...:58201] AH01097: pass request body failed to 127.0.0.1:8082 (127.0.0.1) from ... ()
btw: the encrypted library showing this behavior only has 200 files in it. So even when each file in that library unnecessarily is tried to be updated - how does this compare to thousands of error entries in the logfiles?
Is there any news on this bug? It is more than annoying and renders the Android client not usable.
I have the same problem. I had to uninstall the mobile client because I reached my transfer volume at the first day of the month. I reinstalled it a day later and the next month same issue.
Same issue here!
Although I don’t use encrypted libraries, the Android Client caused over 30 GB of traffic on my Android phone in one month!
And I used the client only to look up a few pictures on my cloud over the entire month.
It seems that the client is re-uploading the entire image folders that I browsed although the images were not altered on the phone!
I uninstalled the Android Client now as well.
Please look into this, the Android client is useless like this.
Do you use the latest version 2.1.11? Can you check whether the photos are really be uploaded via the web interface (check the library history)?
Yes, I was using the latetst version.
And yes, the photos were changed (I guess this means uploaded) according to the history in the web interface, I also received a notification of files being changed in the desktop client on Windows 10.
But as I said, the files were not changed on Android but only viewed…
Thanks for looking into this!