The support forum

ReadFile() failed with 381 - as source, not sink

pmcjones :

Jul 24, 2020

Has Apple's iCloud Shared Albums recently changed to use some sort of "fetch on demand" feature of Windows? I haven't changed my Bvckup 2 configuration, but my nightly error count jumped from dozens to thousands. This is one of the errors:

2020.07.22 18:12:51.500 (UTC-8) 2 2         15383. Copying file Users\paul\Pictures\iCloud Photos\Photos\Robert_McJones-Contact_prints-2400dpi-121.jpg
2020.07.22 18:12:51.742 (UTC-8) 3 3             691.20 KB, created 1940.01.01 01:00:00.000, modified 2020.07.03 12:45:21.357, archive / recall-on-access
2020.07.22 18:12:51.742 (UTC-8) 3 4                 Raw: 707790 / 106977312000000000 / 132382791213579250 / 00400020
2020.07.22 18:12:51.765 (UTC-8) 0 3             ReadFile() failed with 381
2020.07.22 18:12:51.765 (UTC-8) 3 4                 Context: 0 720896

I opened a "git bash" window, navigated to that directory, did an "ls", and now a pop-up says "ls.exe is downloading from Photos".  Somehow Bvckup 2 avoids triggering these downloads, and treats this as an error.

Alex Pankratov :

Jul 27, 2020

You can tell the program to skip these files if they aren't present [1] or you can exclude them from the backup altogether [2].

I am not sure why 'ls' triggers the download, but bvckup's attempt to read them doesn't, because that should be a default behavior for files with the recall-on-access attribute.

Edit - Ah, hold on. 381 stands for ERROR_CLOUD_FILE_READ_ONLY_VOLUME, which in the context of ReadFile request doesn't make any sense. There was an older thread on this, but I don't think we identified the cause, only how to work around it [3].


New topic

Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms