Filesystem API `lstat` never resolves or rejects on Android 9.0 / RNFetchBlob 0.10.15 / RN 0.59.9

[rkdavidson]

Versions/Env:

• "rn-fetch-blob": "0.10.15"
• "react-native": "0.59.9"
• Device: emulated Google Pixel 3, Android 9.0 (API 28)

In short, RNFetchBlob.fs.lstat is not working in the above Android environment for me. It never resolves or rejects.

I've been using the RNFB filesytem API fairly heavily for our app's image encryption/decryption with caching etc. Filesystem methods like exists, mkdir, cp, mv, all have been working fine in this environment.

Here's a simplified version of the code that has the issue:

export function getDecryptedPath() {
  return `${RNFetchBlob.fs.dirs.DocumentDir}/chat/decrypted`;
}

export async function clearExpiredDecryptedCache() {
  const cacheFiles = await RNFetchBlob.fs.lstat(getDecryptedPath());
  console.log('cacheFiles: ', cacheFiles); // ❌ Never runs on Android!

  // ... Some logic checking the file's `lastModifiedDate`, etc
}

My real code works as intended on iOS. I'm able to lstat on a directory and see the stat objects with details for each file in a directory.

To debug/troubleshoot, I stuck a global reference to RNFetchBlob so I can run code in console. It appears both ls and stat are working fine, but lstat never resolves/rejects.

In this screenshot, I ls the contents of a directory, then run stat on one of the files within that directory, and finally try to lstat the directory:

Am I missing something? Anybody else able to reproduce this?

We'll be upgrading to the latest RN and RNFetchBlob versions soon, however, I need to ship this code in the meantime. Going to look into a redundant, temporary re-implementation of lstat in my app's JS code since ls and stat work.

[rkdavidson]

🤦‍♂️ Of course, as soon as I post I figured it out.

Something strange was going on with my emulator which was "out of storage"/room, so I had to Wipe Data from the device via Android Studio. After that, a fresh app install restored everything to working order.

Will close this issue but hopefully someone in the future will find it via Google and think to try wiping data from the emulated device first, unlike me...

[omatrot]

Hi, I have exactly the same problem and I think the behaviour is tied to the implantation in Java, which does not use a Promise. If you look at the code you can see that it uses an async task and a callback. From a javascript point of view the method is leaving immediately and never resolves. I've set some breakpoints in there to confirm that there is no exception. The code do what it should. stat is working because this is a simple operation that shouldn't take long. I'll see what I can do to rewrite the implementation and make a pull request.