Picker returns different uri paths for same file

[Yandamuri]

Bug report

Summary

Picker returns different uri paths for same file when I picked it from "Recents" and it's actual file location

Below is the response when I try to upload file from Recents;

Below is the response when I try to upload file from it's actual location

As far as I know Recents is not a folder to have specific uri path(If I am wrong please correct me). It's just listing recently captured snaps or recently downloaded files from internet etc.

In that case, Why shouldn't the same file have same uri path when it is accessed from Recents and from it's actual location?

Reproducible sample code

Please find this repository for reproducible demo code

https://github.com/Yandamuri/Document-Picker-Testing

Steps to reproduce

1. As soon as app is opened(From above reproducible demo code) you will find a "Document Uploader" button.

2. Tap on "Document Uploader" and try to upload a file from Recents. As saunas you tapped on file you will be returned to app and file path uri will be rendered over the screen.

3. Tap on "Document Uploader" and try to upload same file from it's actual location(Say from Documents or Downloads acts);

Environment info

   "react": "17.0.2",
   "react-native": "0.66.4",
   "react-native-document-picker": "7.1.2"
    Platform: Android -> Tried with Honor

[vonovak]

hello and thanks for a detailed description of the problem. People often don't include enough details, making it hard to respond to their questions.

In this case, what you are reporting is not a bug but expected behavior.

As far as I know Recents is not a folder to have specific uri path

I think that sounds about right.

Why shouldn't the same file have same uri path when it is accessed from Recents and from its actual location?

that would be a question for the android developers, in particular of ContentResolver / Content Providers or people who implemented the "recents" functionality

The android OS provides an api that allows to obtain uri for files that are present locally on the phone, as well as in google drive, dropbox and etc. So the uri can have different forms and you should not make any strong assumptions about it.

If you need to get hold of the file, you can use the apis provided by the android OS, as we do here, when you pass the copyTo option

https://github.com/rnmods/react-native-document-picker/blob/ca61f269972df31b404162185f596f533b3f5f89/android/src/main/java/com/reactnativedocumentpicker/DocumentPickerModule.java#L319

hope this helps, thanks

[Yandamuri]

@vonovak Thank you so much for your detailed response which gave me a solution to long lasting issue(Of course a bit frustrating😜). CopyTo option is solution to my issue.

I have few doubts pertaining to copyTo option,

If copying the file fails (eg. due to lack of free space)

Are there any situations to anticipate for file copying failure except due to lack of free space?

by default, the picked documents are temporary files. They remain available only until your application terminates.

Does it mean that, temporary files are removed If app is closed normally or app is swipe closed(By using app switcher) ?. Actually I am thinking to delete temporary files once my work(Actually I am doing document uploading) is done.

by default, the picked documents are temporary files. They remain available only until your application terminates. This may impact performance for large files.

May I know in what way it impacts larger files?

so keep this in mind if you expect users to pick particularly large files and your app does not need immediate read access.

I have read this point number of times but still unable to get it. If possible, Can you please elaborate this point.?

Once again thank you so much for your detailed response🙂

[vonovak]

Are there any situations to anticipate for file copying failure?

in theory, there can be many errors that can happen, you can check them here: https://developer.apple.com/documentation/foundation/1448136-nserror_codes (only some of them are relevant)

Does it mean that, temporary files are removed If app is closed normally or app is swipe closed(By using app switcher) ?. Actually I am thinking to delete temporary files once my work(Actually I am doing document uploading) is done.

the docs link to the documentation provided by apple which is the source of that information. If by "close normally" you mean moving the app to background, then the app is not terminated in that case. There is a callback that you can use to be informed about termination. Personally, I'd not worry about the temporary files and leave that job to the iOS, but it's up to you :)

May I know in what way it impacts larger files?

well, larger files will take longer to get copied and so there can be larger delay between the user closing the document picker and the promise resolving with the information about the file.

I have read this point number of times but still unable to get it. If possible, Can you please elaborate this point.?

If you need to pick large files and do not need immediate read access, it'd make sense to not specify the copyTo option upon picking, but copy the files later when it's actually needed. But the module does not expose the copying functionality "independently" (ie. the module does not expose a function that takes a uri and copies its contents to local storage and resolves with the uri of the copy) yet.

In fact, it'd be better to change the module to split the picking functionality from copying, and it probably wouldn't be difficult.

hope this helps :)

[Yandamuri]

@vonovak Thank you so much for your time resolving this issue and closing this issue for now.