[Android] "FILE_TRUNCATE Operation not permitted" on ARM64 only

[proninyaroslav]

Please provide the following information

libtorrent version (or branch): master

platform/architecture: Android arm64

One of my users collided with the following situation: it uses a tablet with SOC AllWinner A133 (arm64) and Android 11. My app uses access to all files (MANAGE_EXTERNAL_STORAGE permission is used in accordance with Android 11+ limitations).
When he tries to download any torrent on SD card, then he gets this error: [FILE_TRUNCATE] Operation not permitted, code 1, If he install the APK version for arm64 (I'm using libtorrent4j builds). If he install the armeabi-v7a version of the APK, then the downloading is successful.
The SD card file system is exFAT, because exFAT has become a standard solution for SD cards in recent versions of Android (in the form of the sdfat driver).
The problem is manifested exclusively with arm64 library, although it successfully uses armeabi-v7a version without any errors.

[proninyaroslav]

I think it is somehow related to this error #6687. I don't know whether the error is related only with arm64 library, but it's quite possible.

[arvidn]

one option would be to use the posix disk io, rather than mmap disk io. That will use a simpler and more portable posix file io functions.

[proninyaroslav]

Is this requires a future implementation on the libtorrent side, right? Or is it chosen during build configuration?

[arvidn]

what do you mean?
an implementation of what?

[arvidn]

you can select the disk back-end at session construction time, as part of the session_params object. See disk_io_constructor.

It's also possible to disable the mmap disk I/O back-end at compile time with mmap_disk_io=off

[proninyaroslav]

@arvidn
Ok, thank you. Apparently, I have to redirect this Issue towards libtorrent4j, because there is no API to switch disk back-end.

[proninyaroslav]

@arvidn
I tested the POSIX disk backend and noticed that it is very slow during pieces checking if the torrent is large aldenml/libtorrent4j#213. It's about 2 times slower than mmap. Is it possible to optimize this, or is it a POSIX overhead?