downloading a file twice seems to fail

[thoth-seshat]

I have a setup like this:

    let file;

      
      await new Promise<void>((resolve, reject) => {
        CloudStore.download(filePath, {
          onProgress: async (progress) => {
            console.log("progress", progress);
            if (progress.progress === 100) {
              file = await CloudStore.readFile(filePath);
              resolve();
            }
          },
        });
      });

The first time I run this, it seems to work fine however, the second time I run this, it will fail. I'm not sure why.

My file path is created like this:

  function mkICloudFilePath(fileName?: string) {
   if (!defaultIPath) return new Error("No default iCloud folder found");

   const iCloudUrl = CloudStore.getICloudURL().then((url) => {
     console.log("iCloudUrl", url);
   });

   console.log("defaultIPath", defaultIPath);

   return CloudStore.PathUtils.join(defaultIPath, `Documents/${fileName}`);
 }

It seems like the file is downloaded but won't persist in the iCloud folder for some reason and then the second time I try to access it it says it doesn't exit. With a WARN Possible Unhandled Promise Rejection (id: 1):

I'm also seeing the progress indicator from the onICloudDocumentsUpdateGathering events showing progress 0 before it dies.

If the file is already downloaded does it die again? I'm confused on what download does vs startDownloadingUbiquitousItem and I'm not sure which should be used. I need to ensure the file exists so I can read it in and process it.

[XHMM]

Re-call download should be fine. Can you log the rejection to see what the error message was？

[cip123]

I think it's because of this line:

react-native-cloud-store/ios/CloudStore.swift

Line 749 in d713dfc

try FileManager.default.evictUbiquitousItem(at: iCloudURL)

Here's Apple note:

Don’t use a coordinated write to perform this operation. In macOS 10.7 or earlier, the framework takes a coordinated write in its implementation of this method, so taking one in your app causes a deadlock. In macOS 10.8 and later, the framework detects coordination done by your app on the same thread as the call to this method, to avoid deadlocking