Path config options should get Android-specific defaults

[SigmaBonder]

Currently, path config options seem to get the typical Linux details. For example, both db_path and chunk_path get /data/local/tmp/rclone/cache-backend instead of something like /data/data/com.chiller3.rsaf/cache-backend. The app cannot access the former, which results in an error and the whole cache remote doesn't work.

Additionally, the description of chunk_path reads:

This config follows the "--cache-db-path". If you specify a custom location for "--cache-db-path" and don't specify one for "--cache-chunk-path" then "--cache-chunk-path" will use the same path as "--cache-db-path".

Currently, this is not true in RSAF. If I configure just the db_path and not the chunk_path (which I verified to be the case by exporting the config file), it still tries to access the default /data/local/tmp/rclone/cache-backend directory which it doesn't have access to. I had to specify an appropriate paths for both of these options to get this remote to work.

---

By the way, I just noticed this fragment on the rclone website:

The cache backend code is working but it currently doesn't have a maintainer so there are outstanding bugs which aren't getting fixed. The cache backend is due to be phased out in favour of the VFS caching layer eventually which is more tightly integrated into rclone.

This seems to explain buggy behavior that I noticed while testing out cache in RSAF — though I'm not sure if these are problems with the rclone itself or something specific to RSAF, because I don't have any experience with cache backend on other systems. This backend seems to have been deprecated in 1.39, which is very unfortunate, because I don't see any good option to use rclone mount on Android, which would be necessary to use the VFS caching layer. I think that some way of caching operations on Android is a must, because mobile devices are more likely to have unstable Internet connections. Do you plan to look into that, maybe?

[chenxiaolong]

Hmm, this is a bit annoying to fix due to golang's quirks. The first thing RSAF does when initializing rclone is setting the general cache directory. Both db_path and chunk_path are set to <cache dir>/cache-backend, but the code that does that executes before any of RSAF's code can run.

I might be able to work around this by setting the XDG_CACHE_HOME environment variable instead. I'll give that a try.

[chenxiaolong]

XDG_CACHE_HOME would normally work fine, but it can't work for RSAF. golang cannot read environment variables when it's built as a shared library. I'll keep looking to see if I can find a workaround for this.

[chenxiaolong]

Fixed by #12.

---

This backend seems to have been deprecated in 1.39, which is very unfortunate, because I don't see any good option to use rclone mount on Android, which would be necessary to use the VFS caching layer. I think that some way of caching operations on Android is a must, because mobile devices are more likely to have unstable Internet connections. Do you plan to look into that, maybe?

RSAF currently does enable the VFS cache. It's equivalent to running rclone mount --vfs-cache-mode writes. It should be sufficient when creating new files, but rclone currently does not support caching file copy/move operations.

I currently have no plans to add caching beyond what rclone's VFS cache provides.

[SigmaBonder]

RSAF currently does enable the VFS cache.

I'm not sure I follow — do you mean it's enabled by default?

[chenxiaolong]

I'm not sure I follow — do you mean it's enabled by default?

That's correct. It's enabled by default and cannot be disabled (because the feature is required for some of RSAF's functionality, like random writes).

[SigmaBonder]

Ah, OK — I tested it only by copying, which it isn't supposed to support. So it should work fine as an output directory for BCR, for example, when offline? (Whether the caching is reliable enough for that to be a good idea is a separate question.)

[chenxiaolong]

Ah, OK — I tested it only by copying, which it isn't supposed to support.

Ah, yep. rclone's copy/move functionality bypasses the VFS layer completely, in order to support server-side operations when copying/moving files on the same remote. They didn't make a separate implementation (with VFS cache) for other scenarios, like copies across remotes or copies from local to remote.

So it should work fine as an output directory for BCR, for example, when offline? (Whether the caching is reliable enough for that to be a good idea is a separate question.)

In theory, I would think so, though I haven't really taken a close look at how long rclone will keep retrying uploads.

In the worst case where rclone completely fails to upload, it's possible to manually grab the files out of the VFS cache. You can create an alias remote that points to /data/data/com.chiller3.rsaf/cache and access the files from a file manager.