Cannot attaching documents(not images) in v2.9.3 on Android

OS: Android 11
Joplin: V2.9.3

I can attach images to my note. But I cannot attach other types of files to my note. The log says:

"Could not attach file:", Error: You don't have read/write permission to access uri: content://com.android.providers.media.documents/documet/documentXXXX

After reading the code, I found that the processes of attaching images and attaching other types of files are different. The former uses react-native-fs directly, the latter might use react-native-saf-x.
I have some ideas to fix this but I don't know if I should blame it on Joplin or react-native-saf-x. Maybe it's just something wrong on my Android phone. I would appreciate it if someone could try to reproduce it on his/her Android device.

2 Likes

Can confirm with a custom-built version of Joplin.

1 Like

Maybe try to ping the developer who implemented this. There's a recent pull request about it

1 Like

I thought Android: Fixes #6791: Fixed handling of normal paths in saf-x module by jd1378 · Pull Request #6792 · laurent22/joplin · GitHub was supposed to fix that.

UPD
Actually it might be a different issue.

I think replacing shim.fsDriver().xx() with RNFS.xx() in packages/app-mobile/components/screens/Note.tsx can resolve this bug too.
RNFS.xx() is proved to work(it is used when attaching images), and removing shim.fsDriver().xx() will make the code in Note.tsx more consistent.
I'm gonna make a PR in Joplin for it. And I have made a issue to upstream.

3 Likes

It's not a sync problem, all my focus was on the sync process so I missed other places
soon I'll create a PR and replace all existing RNFS usages with fs driver calls so the changes are global
and apply changes required for scoped storage usages where I can find

hopefully that will address this issue as well

2 Likes

well it seems its not that simple, the document picker permissions only exist on the thread it used to select files, so my module cannot access the selected files some how ?
I have to think about it at a later time ...

For the native Java code, open the document picker with some flags, then call takePersistableUriPermission() will keep the permission.
I've checked your code. Maybe you need to add some flags after creating the intent in openDocumentTree() and openDocument().
I misunderstood the code there. Sorry.

no need to add some flag,
It's doing the right thing vs doing the easy thing
easy thing is to take permission forever for those files, which in my code, if needed, already works
the right thing is to only have enough permission to access those files and read them and be done with it

and the picker is not from my module, which is why it doesn't work, if it was it would work
the solution is probably to: 1. add multiple file picker to my own module 2. use my own module's file picker conditionally, like other places

1 Like

While adding multiple file picker to my module I understood there was a problem with my goToDocument in general which would not allow access to files that their permission are not persisted

I added the multiple file picker anyway but the problem should be gone without using my own picker I guess

I have to test

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.