for existed file 'content://' exists returns false

[code-by]

I have image file (obtained by using device camera) with following uri content://media/external/images/media/331 using RNFS.exists.then returns false while file is exists. how to fix this?

[baskan]

same here.

[itinance]

The "content://"-scheme is currently not supported. I suppose it is android related right? We definitely should add support for it.

[baskan]

@itinance yes, in my case it was returning from react-native-image-picker (https://github.com/react-community/react-native-image-picker) on android.

[antsmo]

Also ran into this issue on Android when using react-native-document-picker (https://github.com/Elyx0/react-native-document-picker)

[jonathangreco]

Hi did you found any workaround waiting this feature ?

[llaine]

Any workaround on that one?

[jonathangreco]

@llaine Use RNFS.stat should do the trick.

[llaine]

@jonathangreco thank's for your answer. I'm actually trying to use copyFileAssets which throw me an error Error: Asset 'content://media/external/images/media/xx' could not be opened

[jonathangreco]

@itinance Hi, is this issue worth to be a top priority ? Because for as long as I recall, neither React-native-fs nor RNFetchBlob have a functionnal exist method for content:// or asset-library://

[jonathangreco]

@llaine In fact if you try to RNFS.stata medias in your content:// and it not exist, you'll be able to do your stuff in the catch

[llaine]

@jonathangreco The RNFS.stat is throwing the exception. Is there any way to use copyFileAssets on android ?

[jonathangreco]

@llaine of course it throws an exception. It's the whole point of this workaround. Catch it and do what you need to do :)

[scarlac]

Here's a workaround until we get native support:

await Promise.all(arrayOfFilesWithContentUris.map(async (file) => {
  const file = await RNFS.stat(file.uri);
  console.log(file.originalFilepath);
  // will now output a regular file url, compatible with other functions, e.g.:
  // RNFS.unlink(file.originalFilepath);
}));

[StevenMasini]

@scarlac thank you, the workaround made it for me 👍

[gsunsnackv]

@scarlac It's not working for me

07-07 16:14:53.413  5404  7076 I ReactNativeJS: fs stat failed on: content://com.google.android.apps.photos.contentprovider/0/2/mediakey%3A%2Flocal%253A87ecd038-4f96-4c8e-aaf7-4520ad3a6b2c/ORIGINAL/NONE/508284454
07-07 16:14:53.414  5404  7076 I ReactNativeJS: { [Error: Error not specified.]
07-07 16:14:53.414  5404  7076 I ReactNativeJS:   framesToPop: 1,
07-07 16:14:53.414  5404  7076 I ReactNativeJS:   nativeStackAndroid: [],
07-07 16:14:53.414  5404  7076 I ReactNativeJS:   userInfo: null,
07-07 16:14:53.414  5404  7076 I ReactNativeJS:   code: 'EUNSPECIFIED' }

[DaveLomber]

 RNFS.stat(fileUri).then(fileStat => {
         
});

It just crashes if I try to share image from Photos app, e.g. this one: 'content://com.google.android.apps.photos.contentprovider/1/1/mediakey%3A%2Flocal%253Af752e9f9-7259-4b0a-8ed7-0c8e30f46730/REQUIRE_ORIGINAL/NONE/88846342'

2019-10-18 14:11:30.989 13134-13231/? W/System.err: java.lang.NullPointerException
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at java.io.File.<init>(File.java:283)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at com.rnfs.RNFSManager.stat(RNFSManager.java:626)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at java.lang.reflect.Method.invoke(Native Method)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:371)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:150)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at android.os.Handler.handleCallback(Handler.java:873)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at android.os.Handler.dispatchMessage(Handler.java:99)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:26)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at android.os.Looper.loop(Looper.java:193)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:225)
2019-10-18 14:11:30.989 13134-13231/? W/System.err:     at java.lang.Thread.run(Thread.java:764)

[scousino]

any chance this is going to be supported? Seems silly to not support content:// for android on a cross-platform architecture

[kodie]

I ran into this issue recently when trying to upload a file that was shared to my app (via the react-native-share-menu module). The file that it was trying to upload started with content:// and so while RNFS.stat as well as RNFS.uploadFiles threw an exception when trying to handle that file, RNFS.copyFile could work with it just fine. So here's my workaround:

let fileName = sharedItem.data.split('\\').pop().split('/').pop()
let filePath = sharedItem.data
        
if (Platform.OS === 'android') {
  try {
    let ext = null

    switch(sharedItem.mimeType) {
      case 'image/jpeg':
        ext = 'jpg'
        break
      case 'image/png':
        ext = 'png'
        break
      default:
        Alert.alert('Unsupported file type.')
        this.setState({ loading: false })
        return
    }

    fileName = fileName + '.' + ext
    filePath = RNFS.DocumentDirectoryPath + '/' + fileName

    await RNFS.copyFile(sharedItem.data, filePath)
  } catch (err) {
    log('File Read Error:', err)
    Alert.alert('An unknown error occured while reading your file.')
    this.setState({ loading: false })
    return
  }
}

const files = [
  {
    name: 'image',
    filename: fileName,
    filepath: filePath,
    filetype: sharedItem.mimeType
  }
]

// and then RNFS.uploadFiles as usual

Basically, I'm just copying the file over to my app's own directory for handling. But with the web server I was uploading the images to, the file extension is required and in this case the file extension wasn't in the file path, luckily the share module gives me the MIME type and my application only supports a limited number of types so I was able to make do.

[scousino]

Can we get any sort of traction on this??? This seems like a easily fixed oversight to not account for content://

[charlyBerthet]

@scarlac calling const file = await RNFS.stat("content://..."); still returns the following error {"nativeStackAndroid":[],"userInfo":null,"message":"File does not exist","code":"EUNSPECIFIED"} even tho it was picked right from the device gallery.

File exists because calling for the same file RNFS.moveFile("content://...", to) works fine.

To reproduce, I just pick a video media on Android using

import {launchImageLibrary} from 'react-native-image-picker'; //v^4.8.5
const result = await launchImageLibrary({
    mediaType: 'mixed',
    videoQuality: 'high',
    quality: 1,
    selectionLimit: 10,
});

[kassim]

Hi. Just commenting here because we found the issue on our app in a native Android context. I'm unsure if this will be helpful but there's only a handful of places on the web that seem to be highlighting the error

For apps using the photopicker, there is something about the implementation that causes DocumentFile.exists() (and possibly File.exists()) to return false when a "content://" URI is returned

Instead what we use to check validity is DocumentFile.name != null

Sorry it's not a ReactNative fix for you but perhaps a fix for your React Native library can be pulled from that knowledge