hash() function gives "no such file" error while readFile() succeeds with same uri.

[andra961]

Here's the code:

      const fileDetails = await DocumentPicker.pick({
        // Provide which type of file you want user to pick
        type: [DocumentPicker.types.allFiles],
      });
      setSelectedFile(fileDetails)
      let fileContentBlobUtil = await RNFetchBlob.fs.readFile(fileDetails[0].uri, 'base64')
      let fileHashBlobUtil = await RNFetchBlob.fs.hash(fileDetails[0].uri, 'sha256')

readFile() return the base64 encoding of the file correctly, while the hash() function using same identical uri (provided by document picker) gives following error:

[Error: No such file 'content://com.google.android.apps.docs.storage/document/acc%3D1%3Bdoc%3Dencoded%3DTGhH_d6AtnqwiD39DnZwrQ0kCTtqjiY6UYhHLISr6DLSSsqJONKGKvfjlSdVqkT2']

Any idea of why this happens?

[RonRadtke]

Might be that there is missing a normalizePath call which would resolve the URI.
You could try to add
``resolved = ReactNativeBlobUtilUtils.normalizePath(path);```
before that line:

react-native-blob-util/android/src/main/java/com/ReactNativeBlobUtil/ReactNativeBlobUtilFS.java

Line 780 in 1512092

Map<String, String> algorithms = new HashMap<>();

[onlyling]

Might be that there is missing a normalizePath call which would resolve the URI. You could try to add ``resolved = ReactNativeBlobUtilUtils.normalizePath(path);``` before that line:

react-native-blob-util/android/src/main/java/com/ReactNativeBlobUtil/ReactNativeBlobUtilFS.java

Line 780 in 1512092

Map<String, String> algorithms = new HashMap<>();

can fix the problem, release a new version?

#124

[RonRadtke]

@onlyling of course. Did you test if it resolves your issue?

[onlyling]

@onlyling of course. Did you test if it resolves your issue?

solved.

modified the local node_module file and repackaged the application for testing.

but, mv has a similar problem?

static void mv(String path, String dest, Callback callback) {}

path and dest miss ReactNativeBlobUtilUtils.normalizePath?

[RonRadtke]

technically yes.
Do you want to add it directly? Then I would merge the PR and both are fixed

[onlyling]

technically yes. Do you want to add it directly? Then I would merge the PR and both are fixed

The path starting with content:// is not adapted in the normalizePath function, and the path starting with file:// does not report an error. At the same time, I found that there are differences in usage between Android and iOS.

#124

Need you to fix it, or explain that the path cannot start with file://.

[RonRadtke]

A path starting with content:// often belongs to a media store and thus will make problems regardless since we would have to open these via a contentProvidor or copy the first into the internal storage.