🐛 Cannot access file created by takePhoto through FileSystem

[mortenmo]

What were you trying to do?

Expo 46, iOS,

The picture works fine and can use it, however I cannot access it in any other way.

But doing anything to this file file FileSystem operations (beyond getInfo) fails with a " isn't readable." error.

[Error: File '/private/var/mobile/Containers/Data/Application/D606F8F1-0B4C-41D7-81A8-46AF72BED567/tmp/ReactNative/8CED5BE1-61D5-43B7- ... FF9.jpeg' isn't readable.]

This comment mentions the same issue on an enhancement to be able to select the directory images are stored in.
#893 (comment)

Saving the image to image library does however work using await MediaLibrary.saveToLibraryAsync(path), but permissions there are probably different.

Reproduceable Code

const { path } = await camera.current.takePhoto({
     qualityPrioritization: 'balanced',
});

const file = FileSystem.documentDirectory +
   path.substring(path.lastIndexOf('/') + 1);

await FileSystem.copyAsync({
   from: path,
   to: file,
});

What happened instead?

Besides showing the image in an Image tag, there

Relevant log output

[Error: File '/private/var/mobile/Containers/Data/Application/D606F8F1-0B4C-41D7-81A8-46AF72BED567/tmp/ReactNative/8CED5BE1-61D5-43B7- ... FF9.jpeg' isn't readable.]

Device

iPhone 13

VisionCamera Version

2.14.1

Additional information

• I am using Expo
• I have read the Troubleshooting Guide
• I agree to follow this project's Code of Conduct
• I searched for similar issues in this repository and found none.

[mortenmo]

MlKit also failed to access the image:

import ImageLabeling from '@react-native-ml-kit/image-labeling';

    ImageLabeling.label(path);   // Fails with image is nil which probably means no access

[mrousavy]

Closing as this is a stale issue - this might have been fixed with the full rewrite in VisionCamera V3 (🥳) - if not, please create a new issue.

Try the file:// prefix

[joshua-revolutions]

I got the same issue when sending the photo into Google mlkit. Adding file:// prefix did fix it for me. I'm using v3

[mrousavy]

Adding file:// prefix did fix it for me

This is not a bug, this is how the filesystem works. It's even in the docs that you need to add this if you want to read the file.