iCloud sync creating duplicate files when saving

This is kind of a bizarre scenario, but I thought I'd document it, in case anyone else runs into a similar issue, since I wasn't able to find it through a Google search.

One of our users ran into an issue with saving a file and then suddenly (or shortly afterward) having the same file (with a 2 or 3 appended to its name) appear. In other words, if the file was originally called When Harry Met Sally, saving would then produce another file called When Harry Met Sally 2.

It appeared that iCloud was syncing it up to iCloud Drive, thinking that a local copy didn't exist, and then bringing back down the saved copy. Finder would then see that the file with that name already existed and then append a number to the name to distinguish from the original.

The solution was to move the file out of iCloud Drive (e.g., the Desktop folder), confirm to iCloud that the file was "deleted," and then move the file back. It would do a fresh sync with iCloud Drive and then behave properly.

Update 31 August, 2016: Unfortunately, it seems that fix was only temporary, and the behavior reverted. I'll see what else I can find. Seems I was able to find one more instance of someone else experiencing this—unfortunately, the solution was the same as what I described above.


  1. I’m experiencing the same thing! So much so that I’ve stopped saving files to iCloud because of all the strange added duplications (I’m in grad school and can’t handle all the extra copies!). Would love for a fix to tbis if you find one.

    1. Yeah, unfortunately, the user who was experiencing this problem… is still experiencing it. I haven’t found any known working solutions for this apart from using other forms of backup/sync (e.g., CrashPlan, Google Drive, Dropbox).

  2. I found the same thing, and wrote a test app to investigate.

    tl;dr — this happens when an existing “file.ext” exists in the iCloud account but hasn’t been loaded to a new/second device, and then the new device creates (another) “file.ext”, thinking it’ll overwrite the one in the cloud. It won’t; the new will get named “file 2.ext”. And “file.ext” won’t exist locally!

    Details — my test app defines a file named date.txt in the ubiquity container (dateFileURL). There is a button titled “Create date.txt”. Creating the file involves saving the current date/time into the file, overwriting anything that may exist. If the NSMetadataQuery finds a file which hasn’t been downloaded, it doesn’t start the download automatically (which leads to the problem!). I also output all of the details about each NSMetadataItem in each query result, and at the end of each update I output the entire contents of the local ubiquity container, as well as useful attributes for the target date.txt file (ie, dateFileURL). (File creation is done with a file coordinator, which is absolutely essential for iCloud to see any of these actions.)

    Testing procedure:
    1. On device A, tap “Create date.txt”. The file gets created as expected, and is uploaded to iCloud.

    2. Now start the test app on device B. The initial gathering will find date.txt in the iCloud container, but indicates that it is not downloaded. The local container has a file named “.date.txt.icloud” which appears to be how the iCloud subsystem knows there’s such a file in the container even though it hasn’t been downloaded yet. Also, FileManager.default.fileExists(atPath: dateFileURL.path) == false (which is accurate).

    3. Now tap “Create date.txt” on device B. This creates a new (local) date.txt file, but it doesn’t overwrite the earlier version created on device A (obviously, since that version hasn’t been downloaded). Now the query update shows 2 results: (1) date.txt in the cloud, not downloaded; and (2) date.txt in the local container, which is 100% downloaded (DownloadStatusCurrent) and 0% uploaded, and isUploading. The local directory contains “.date.txt.icloud” (which is the original “stub” from the device A version) and “date.txt” (which was just created by the button). FileManager shows that the file date.txt does exist.

    4. I see 2 updates as the new date.txt file gets uploaded to the cloud. On my setup I get one notification at 95% and another at 100%. The 95% notification is very similar to the original status (just a higher percentage). When the file has finished uploading, then the 100% notification comes in, with surprises! The file name has been changed to “date 2.txt”! This change is reflected everywhere in the NSMetadataItem (eg, NSMetadataItemURLKey, NSMetadataItemPathKey, NSMetadataUbiquitousItemURLInLocalContainerKey, NSMetadataItemDisplayNameKey). The local container now contains “.date.txt.icloud” and “date 2.txt”. FileManager.default.fileExists(atPath: dateFileURL.path) == false (which is accurate, of course).

    So the end result is that it created a new date.txt, as specified by dateFileURL, and everything worked correctly, but the resulting file got renamed (to avoid a name collision with the version created on device A but which was never downloaded) and therefore doesn’t exist where dateFileURL says it should be!

    (Note: the original “date.txt” version from device A is discovered in the initial gathering phase, and it remains in the query results throughout, and never changes at all.)

    It seems this would be avoided by always downloading any discovered file rather than ignoring it and creating a newer version. It depends on your app’s workflow and design, of course.

    I hope this helps!

  3. This started happening to me, too, recently. I backup my works in progress on iCloud and have a local file that I work from. I have yet to figure out how to stop this, but it’s kind of annoying, considering I now have 38 iterations of the same document on iCloud. I’ve always used iCloud exactly the same, so I have no idea why it’s just now happening.

  4. This happens to me, too, on a daily basis, for random files in the directory tree I’m working in. For instance, the C compiler will generate the file “foo.o” and occasionally the file “foo.o 2” will appear. I’m on Mac OS 10.14.6 and don’t use the machine for anything but compiling (and web browsing with Safari). No non-Apple software is installed. This seems to have been going on for years, and happens whether I’m working from my iMac or my MacBookPro.

    I can’t think of anything I’m doing that might cause me to see this problem every day, and yet it seems that it’s only happening to a small number of iCloud users (based on the fact that this is one of only two web pages on the topic that I’ve managed to find, the other being https://discussions.apple.com/thread/6637807

  5. Yup, me too! I have folders of duplicate files that are original-file.txt, original-file 2.txt and original-file 3.txt in some cases.

    Very frustrating ๐Ÿ™

  6. I’m having the same issue since last week, not doing anything different but it seems like it can’t find the copy where I’m working on because it’s in the cloud and then it creates a duplicate copy of the same file. It’s super annoying, I don’t know what to do!

  7. I’m finding the same issue too, always making problems to me and my work in progress. I hope someone finds a solution because it’s very frustrating.

  8. Same problem here on mac osx 10.15.7; I have a bunch of local files I sync to icloud drive using chronosync. Every time I sync files appear in the icloud drive named ‘somefile 2.txt’, ‘somefile 3.txt’, etc.
    First I thought it was chronosync messing up, but apparently that is not it, since I assume you are not all using that tool… I removed all the excessive files on icloud drive from the command line. If anyone knows a solution, please share ๐Ÿ˜‰

  9. This still happens in 2021. I have a lot of files with (1) appended. Most of them are images I didn’t even touch to edit.

  10. I just spoke with Apple support, and she will get back to me in about six days. She is elevating this issue(case) for the “engineers.”

    I share this webpage with her along with several others with the same complaint.

Leave a Reply to Robert B Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.