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.

Posted

August 30, 2016

Uncategorized

alanysiu

Tags:

finder, icloud, mac, troubleshooting

Comments

9 responses to “iCloud sync creating duplicate files when saving”

Angela

October 24, 2016

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.

Reply
1. Alan Siu
  
  October 24, 2016
  
  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).
  
  Reply
Ken Spreitzer

March 2, 2019

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!

Reply
bzerk86

May 21, 2019

Can confirm this is occurring for myself as well.

Reply
Elizabeth Barone

September 7, 2019

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.

Reply
drfuchs

September 24, 2019

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

Reply
Henrik N

February 1, 2020

Seeing the same thing :/

Reply
Dave

February 18, 2020

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 🙁

Reply
Elisabetta

June 22, 2020

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!

Reply