0 Replies
      Latest reply on Oct 22, 2019 6:25 PM by mgmhunt
      mgmhunt Level 1 Level 1 (0 points)

        I posted this in the user forums but got no response as I suspect it's too low-level for the discussions there.  I think this is a relevant developer issue, even though I am only interested in this from a user perpsective.  Perhaps someone can confirm my reasoning (and the resulting potential for errors/bugs when syncing between Mac and Windows iCloud Drive)...

         

        ----

         

        After some investigation of log files for iCloud for Windows (Drive specifically) (latest version - 10.7.0.7 / 2.0.74.23) , I think I've discovered a major reason why there are so many syncing issues with iCloud for Windows.

         

        My theory is:

         

        1) iCloud for Windows is built on top of the OneDrive technology. https://www.howtogeek.com/fyi/daily-news-roundup-icloud-for-windows-powered-by-onedrive-tech/

         

        2) OneDrive technology limits the file path length to 216 characters (or thereabouts). You can verify this yourself by trying to create a folder path depth over 216 characters in length using OneDrive. See this article for some more information: http://www.purgeie.com/shareprep/maxlength.htm

         

        3) Mac OSX filing system and iCloud (for Mac), don't have the same folder path restriction (well as far as I can see it's somewhere around 1024 characters - https://stackoverflow.com/questions/7140575/mac-os-x-lion-what-is-the-max-path-length).

         

        4) So files that are successfully uploaded to iCloud from a Mac, will fail to download on to Windows 10 if they exceed the OneDrive folder path length of ~250.

         

        Checking the log files of iCloud for Windows I get errors such as

         

        ERROR BRC::LocalContainer::CreateNewFilePlaceholder Error creating unique file path for itemID

        ERROR BRC::LocalContainer::ApplyChangesForLiveFile Failed to create placeholder for

        WARN BRC::LocalContainer::UpdateUnappliedRankRetryWithEtag com.apple.CloudDocs:__defaultOwner__: Will retry applying item

        ERROR BRC::LocalContainer::ApplyChangesSchedule Apply failed for item

        The filename, directory name, or volume label syntax is incorrect.

         

         

        5) This then causes iCloud for Windows to constantly retry creating placeholders and downloading, and constantly failing....

         

        WARN BRC::LocalContainer::UpdateUnappliedRankRetryWithEtag com.apple.CloudDocs:__defaultOwner__: Will retry applying item in 30 seconds (retryCount = 0)

        ERROR CKD::MMCS::GetErrorWithMMCSError Error Domain=com.apple.mmcs Code=16 "Last 4 requests failed with a network error. Retry after 16 seconds" UserInfo= {NSLocalizedDescription=Last 4 requests failed with a network error. Retry after 16 seconds,

         

        ----------------------

         

        I don't see anyway easy way around this issue as the two OS are fundamentally incompatible in terms of filing system limits (note Windows 10 can have a larger limit using registry, but it appears OneDrive has the lower limit, which is the bottleneck).

         

        So the only way I can see is to reorganise all folders/files that are synced to iCloud to be under the ~250 character limit. And there is no easy way to check this while working normally in iCloud (on Mac side) - so you could unintentionally create a folder path depth that exceeds the OneDrive limit. It will work on the Mac side, but when using Windows it will fail.

         

        I haven't thoroughly tested this theory, but after waiting days for my iCloud for Windows to sync, I decided to dig a little deeper and found the above information (and log files).

         

        I have quite a deep structure to my filing, but I doubt I'm a complete edge case (!). Perhaps someone out there can verify these limits and symptoms.

         

        The log files for iCloud for Windows can be found at

        C:\Users\USERNAME\AppData\Local\Packages\AppleInc.iCloud_HASHCODE\LocalCache\Local\Logs