search

arvidn / libtorrent

an efficient feature complete C++ bittorrent implementation
http://libtorrent.org
Other
5.18k stars 995 forks source link

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

Closed proninyaroslav closed 2 years ago

proninyaroslav commented 2 years ago

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 commented 2 years ago

I think it is somehow related to this error https://github.com/arvidn/libtorrent/issues/6687. I don't know whether the error is related only with arm64 library, but it's quite possible.

arvidn commented 2 years ago

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 commented 2 years ago

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

arvidn commented 2 years ago

what do you mean? an implementation of what?

arvidn commented 2 years ago

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 commented 2 years ago

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

proninyaroslav commented 2 years ago

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