Sharing a Folder Between Debian and Android using Sparkleshare and SGit

Sharing a Folder Between Debian and Android using Sparkleshare and SGit

Fri, 05 Aug 2016 03:29:53 -0400

Tags: floss, debian


I have been looking for a self-hosted alternative to commercial "cloud" products for a while. Initially started using rsync but it had the problem that you need to remember the directionality of the updates: when a file is deleted in a copy, there is not enough information left to know whether the file is a new file in one of the copies or if the deletion was a purposeful act on behalf of the user. Therefore it is necessary to indicate the directionality of the deletions which is error prone. And some updates might be at both sides of the copies.

Looking for alternatives I peered into OwnCloud, even though a PHP implementation was not really my cup of tea. I found the project has rejected being packed by Debian (a major red flag for me, as I trust the Debian security team to keep old versions securely patched on my personal servers) and that the project has been forked. So no OwnCloud for me.

Given my wishlist of a tight Debian GNU/Linux and Android integration, I looked into a few other alternatives (Syncthing and dvcs-autosync come to mind) but decided to settle on sparkleshare as I thought it had a version on the F-Droid FOSS Android Apps Repository. I have heard from some friends using it that it has its glitches but that overall it was just git underneath so you can use it/repair it as you see fit outside of sparkleshare. This is the case so far and it ended up being a key feature for its interoperability with Android.

I thus setup a remote account for the share, with git installed in the remote server and nothing else (there is no need to install sparkleshare on the server, even though the instructions for using the sparkleshare App seems to indicate so). Now, the existing App only allows you to download files on demand and you cannot modify files. It is thus non-operational as a shared folder. As sparkleshare simply maintains a git repo automatically, I am then accessing through SGit, an incredibly resourceful git client for Android.

My workflow is then as follows: in my desktop and in my laptop, I use sparkleshare (one in Debian testing, the other in Debian stable, both interoperate just fine so far). These copies receive plenty of changes and are kept up-to-date just fine. Then in my phone and tablet I use SGit to pull the updates. In the few situations when I need to modify a file (usually a text file with notes on a paper I'm reading or writing), I use a text editor and then I have to go through the slightly clumsy steps of: adding the file to stage, commiting the changes (making sure the checkbox "Auto stage modified files" which is checked by default is unchecked, that takes forever on a mobile device) and then pushing the changes (which requires clicking on "origin", the interface is slightly confusing there). This workflow makes sense for a regular user of git, which is my case.

Now for the bad news: the maximum file size that can be unpacked on the Android version I have seems to be capped at 64Mb (or slightly less). This is really a let down, but seems to be a limitation that exceeds SGit internals and it might be related to the zlib version shipped with a particular Android version. That is not a show stopper but requires a little too much vigilance for my taste (if I drop a file on the sparkleshare folder, it will immediately polute the git repo with a large blob if the file is over 64Mb and the repo will need to be recovered or restarted afresh). On the good news front, if that happens and the repo gets borked, setting a new one is very simple. And as the repo gets bigger and bigger (it stores all files and their history), resetting it by changing to a fresh one from time to time is necessary anyway.

I have been using this solution for a few months and I am quite happy, but would consider switching for something handling bigger files, limited history and the same binary on the Debian and Android sides. I would expect that will take some time to come around, though.


Your name:

URL (optional):

Your e-mail (optional, won't be displayed):

Something funny using the word 'elephant' (spam filter):

Your comment: