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.
18 responses to “iCloud sync creating duplicate files when saving”
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.
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).
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.)
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!
Can confirm this is occurring for myself as well.
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.
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
Seeing the same thing :/
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 🙁
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!
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.
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 😉
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.
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.
Any leads on this?
This happened to me. I solved it by logging in to iCloud.com. I saw the original file and all of its duplicates (only the last of which was present in the view from Finder). I then deleted all the duplicates and the original and then recreated the original and, so far, it all works ok.
Of course, be careful to keep a copy (under a different name, probably outside of iCloud) as backup BEFORE you delete the files. The file that was causing problems for me, was a auxiliary file created by LaTeX, which the software automatically creates, so I was not worried about deleting it (or any of its duplicates)
I am also facing the same issue and not able to solve it. I recently moved to iOS after much hype from iPhone users in my life. And I completely detest it. All of my work is hampered. There are issues with everything that I used to do with a smartphone. Every app that I used to use doesn’t work the same as it used to.
In most of the cases, the only solution is conveniently to buy some more service or product of Apple. And that got me thinking, this is not some bug or issue with the OS. This is very cleverly created situation by Apple, so that people will jump ship to Apple Products completely and they can earn maximum money from a user.
iCloud sync duplicate files issue, weirdly, only happens for free iCloud users and iCloud for Windows users. And the solution is, you got it right, to buy a Mac and get a iCloud upgrade.
I was forced to migrate to Mac by the type of work I do. I use a MacPro and and a MacBook Pro. They are both connected to iCloud and now every single file that I have has now been duplicated. On one machine the duplicate has the file name amended to add the name of the other machine and vice versa. I so regret moving to Mac. There is nothing about it that is worth the high price paid for this junk.
this is really annoying. Below there’s a command line list
same problem. Files get created with “ 2”. Sometimes “ 3” or “ 4”.
I think that iCloud is backing up my Documents folder. I have to login to iCloud and change the settings so that iCloud does not back up my Documents folder. The solution I’m thinking about is to add a Documents folder to DropBox and then copy the sub-folders to DropBox/Documents as-needed.
peterb@iMac 2022 % ll Post2022Mar*.rtf
-rw-r–r–@ 1 peterb staff 1123 Mar 1 2022 Post2022Mar01_1 4.rtf
-rw-r–r–@ 1 peterb staff 1123 Mar 1 2022 Post2022Mar01_1.rtf
-rw-r–r–@ 1 peterb staff 981 Mar 3 2022 Post2022Mar03_1 2.rtf
-rw-r–r–@ 1 peterb staff 981 Mar 3 2022 Post2022Mar03_1.rtf
-rw-r–r–@ 1 peterb staff 1539 Mar 4 2022 Post2022Mar04_1 3.rtf
-rw-r–r–@ 1 peterb staff 1539 Mar 4 2022 Post2022Mar04_1.rtf
-rw-r–r–@ 1 peterb staff 491 Mar 4 2022 Post2022Mar04_2 2.rtf
-rw-r–r–@ 1 peterb staff 491 Mar 4 2022 Post2022Mar04_2.rtf
-rw-r–r–@ 1 peterb staff 586 Mar 7 2022 Post2022Mar06_1 4.rtf
-rw-r–r–@ 1 peterb staff 586 Mar 7 2022 Post2022Mar06_1.rtf
-rw-r–r–@ 1 peterb staff 1287 Mar 9 2022 Post2022Mar09_1 4.rtf
-rw-r–r–@ 1 peterb staff 1287 Mar 9 2022 Post2022Mar09_1.rtf
-rw-r–r–@ 1 peterb staff 648 Mar 15 2022 Post2022Mar14_1 4.rtf
-rw-r–r–@ 1 peterb staff 648 Mar 15 2022 Post2022Mar14_1.rtf
-rw-r–r–@ 1 peterb staff 456 Mar 23 2022 Post2022Mar23_1 4.rtf
-rw-r–r–@ 1 peterb staff 456 Mar 23 2022 Post2022Mar23_1.rtf
-rw-r–r–@ 1 peterb staff 715 Mar 27 2022 Post2022Mar27_1 4.rtf
-rw-r–r–@ 1 peterb staff 715 Mar 27 2022 Post2022Mar27_1.rtf
-rw-r–r–@ 1 peterb staff 602 Mar 27 2022 Post2022Mar27_2 2.rtf
-rw-r–r–@ 1 peterb staff 602 Mar 27 2022 Post2022Mar27_2.rtf
-rw-r–r–@ 1 peterb staff 1183 Mar 27 2022 Post2022Mar27_3 3.rtf
-rw-r–r–@ 1 peterb staff 1183 Mar 27 2022 Post2022Mar27_3.rtf
-rw-r–r–@ 1 peterb staff 585 Mar 27 2022 Post2022Mar27_4 2.rtf
-rw-r–r–@ 1 peterb staff 585 Mar 27 2022 Post2022Mar27_4.rtf
-rw-r–r–@ 1 peterb staff 1015 Mar 28 2022 Post2022Mar28_1 3.rtf
-rw-r–r–@ 1 peterb staff 1015 Mar 28 2022 Post2022Mar28_1.rtf
-rw-r–r–@ 1 peterb staff 2795 Mar 29 2022 Post2022Mar28_2 3.rtf
-rw-r–r–@ 1 peterb staff 2795 Mar 29 2022 Post2022Mar28_2.rtf
-rw-r–r–@ 1 peterb staff 1130 Mar 29 2022 Post2022Mar28_3 3.rtf
-rw-r–r–@ 1 peterb staff 1130 Mar 29 2022 Post2022Mar28_3.rtf
-rw-r–r–@ 1 peterb staff 1781 Mar 30 2022 Post2022Mar30_1 3.rtf
-rw-r–r–@ 1 peterb staff 1781 Mar 30 2022 Post2022Mar30_1.rtf
peterb@iMac 2022 %