Why doesn't Apple fix the ".DS_Store" bug?

If you search ".DS_Store" in the support archive you'll find the issue has been around for a long time, well over a year. The frustration expressed has been loud and emphatic. The problem? Some folks are finding their computer won't copy some folders from one drive to another. The copying process is interrupted with the following message: "The operation can't be completed because an item with the name ".DS_Store" already exists."


Folks have chosen an Apple computer and something as basic as copying a folder turns out to be a hassle. Apple haven't offered a fix. Apple are an embarrassment.


I've just moved up from Tiger to Mountain Lion. Suddenly some folders I've been copying over for years can't be done! The experts here have suggested it might be a permissions issue or a 3rd-party software issue. They're wrong. IT'S A BUG!


Identifying it took time I'd rather have spent doing something else… (The new 'Apple Experience'?)… As a non-techie who hadn't heard of ".DS_Store" before I read some of the discussions on the issue. The problem seemed to be erratic, some folders could be copied, others couldn't. Here are the steps I took to identify the bug.


1) Since ".DS_Store" files are invisible I used TinkerTool to make them visible, in order to see how they behave.

2) The ".DS_Store" files are nearly always the first item in any folder (viewed by Name or Date Modified etc). Such folders can be copied without a problem. However, where for any reason the ".DS_Store" file isn't at the top of the list (eg where there's an item whose name deliberately begins with a space) the copying of that folder will be interrupted.

3) If a folder can't be copied because the content viewed by Name means the ".DS_Store" file isn't at the top, changing it to view by Date Modified will bring the ".DS_Store" file to the top of the list and allow the folder to be copied.

4) Apple, is that arbitrary behaviour intended? Or is that A BUG?


We want to know!


iHope

Mac Pro, OS X Mountain Lion (10.8.4), 3.2 Ghz Quad-Core Intel Xeon

Posted on Dec 30, 2013 5:47 PM

Reply
95 replies

Jan 1, 2014 12:23 PM in response to iHope

I've only used TinkerTool in order to observe the behavior of the (usually invisible) .DS_Store files. How else are you supposed to do it?

Yes, sorry. Forgot about that.

What makes you think the issue should resolve itself?

My thought was that if you can't select it, then it won't copy. That doesn't help when you're copying an entire folder, though. The .DS_Store file will go with it. But it still shouldn't stop.

Jan 1, 2014 1:47 PM in response to Lexiepex

Do you get the same error when copying a folder fromn ML to the 'tiger' disk?, that was my question.

My answer was 'no'. Wasn't that clear?

If I am right, then you have only once get rid of all .DS_Store files in the folders to be copied; it probably does not matter if you do that on one side or the other or both.

Do you know how to do that?


iHope

Jan 1, 2014 3:26 PM in response to Kurt Lang

Kurt,

Create a new user account and log into it. Try a copy with a folder that has been showing the error. Does the same thing happen in the new account

Yes, more or less. The new account allowed me to copy a 'problem' folder from an external drive to the desktop (which I couldn't do before in my account). However, copying the folder from the desktop to an internal drive was interrupted with the usual message.


Removing the spaces in the file names at the top (as described previously) allowed the folder to be copied from the desktop to the internal drive. (This might offer a workaround, though who knows how reliably?).


I suppose next step is installing a fresh OS? Not sure exactly when I'll have the time...


iHope

Jan 2, 2014 12:54 AM in response to iHope

The oneway problem:

Read my explanation about that I think that the tiger structure too different with the new OS structure may be the cause.

Deletes:

You can delete all DS_Store files with a tool, like Onyx. These files do not take part in OS. You do not need them.


I would like to add, since you still do not follow my thinking (correct or not): the copying starts (sequentially) with the first file, goes on to the second... and stops on a file that it can not copy for some reason, the normal copy can not exclude a particular file unless you do that by hand and that is too cumbersome in this case, you might do that for one or two folders with files in it, but that is not feasable for you.

Jan 3, 2014 2:40 PM in response to Lexiepex

LexSchellings,

Read my explanation about that I think that the tiger structure too different with the new OS structure may be the cause.

I appreciate what you are saying. It is a possibility. Because of the erratic nature of the issue, it will need to be monitored over a prolonged period of time to see if you're right. I'll report back when / if I have an answer.


iHope

Jan 11, 2014 2:10 AM in response to iHope

This is clearly an Apple bug, but here's a quick and easy workaround that worked for me:


  • I was trying to copy a big (800 GB) folder from one external drive to the root of another. It consistently failed with the above error message.
  • My fix was simply to create a dummy folder in the root of the "To" drive and copy my big folder to that.
  • After it ran (3 hours, no problems), all the files were successfully copied to the dummy folder, so I just dragged that to the root and deleted the dummy folder.

Jan 11, 2014 6:06 AM in response to cyberchucker

cyberchucker,


Thanks for your posting. Could you please clarify?

• when you say 'root' do you mean the level where the System, Application and Users folders live?

My fix was simply to create a dummy folder

Does it matter what you call the dummy folder?


After it ran (3 hours, no problems), all the files were successfully copied to the dummy folder, so I just dragged that to the root and deleted the dummy folder.

Do you mean you dragged the contents of the dummy folder to the root? (The dummy folder itself was already at the root, no?)


I'll give your workaround a try. Since the problem is erratic it will take time to establish if it's a definite solution. Meanwhile Apple will no doubt continue to ignor our unreasonable demand to be able to copy folders without a hassle...


iHope

Jan 11, 2014 7:08 AM in response to iHope

OK, I'll try it again:


I'm a photographer. I have 2 external hard drives, Master and Backup. To make a backup (besides what I have on Time Machine), I want to copy my 800GB Pictures folder from Master to Backup.


This used to be easy, just drag from one EHD to the other. Recently, perhaps since Mavericks, it's been failing with the .DS_Store error. I read all the posts in these forums, tried about 12 things, and here's what works for me:


- Start with an empty Backup EHD

- Create a dummy folder at the top level of the Backup EHD. Call it Dummy, whatever, it doesn't matter.

- If I try to drag Pictures directly to Backup, it fails, but if I drag Pictures and drop it inside Dummy, it works.

- After the copy is complete, I just drag Pictures out of Dummy and put it on the root of Backup. None of this touches my MacBook's SSD drive.

- Delete Dummy, because it's empty and not needed anymore.


Dumb trick, shouldn't be needed, but it solves my problem.


Make sense?

Jan 11, 2014 9:16 AM in response to Lexiepex

LexSchellings,


Maybe you don't fully understand?


The problem cyberchucker has described is exactly the same problem I've reported, with the same error message.


How can you say it has nothing to do with my issue?


As I've explained previously, this issue is not restricted to folders produced by a Tiger OS. Folders produced by the Mountain Lion OS also cannot be copied to internal and external drives for the same reason. I hope that's clear.


iHope

Jan 11, 2014 2:24 PM in response to Lexiepex

Lex,


Regarding a, not an Apple bug:


You're saying that if I have an empty external hard drive, then use Disk Utility to completely erase it, and then try to copy a folder to that drive, when I get the message


"The operation can't be completed because an item with the name ".DS_Store" already exists."


then that's the expected behavior?


I'm no Apple guru, but to me, that's not a feature, it's a bug.


This used to work for me with no problems, but then started failing a while ago. It may have started with Mavericks, but I don't know, don't care, am not going to mess with it further because I have simple, 10-second workaround that gets around this "feature."


My only continuing interest is whether my workaround is helping others. If it worked for you or did not, either way I'd be interested in hearing about it. There are at least a dozen threads on various forums about this issue, with lots of people way smarter than me not being able to get past it, so I'm curious if my simple fix is a universal solution until Apple allows us to do a copy the natural way, copying to the actual desired destination.

Jan 11, 2014 8:15 PM in response to Lexiepex

Lex. IT IS A BUG. Get over it! I have a new WD NAS to which I have pushed tons of music. I have a new mini with no external apps (ones that didn't come with the system) except my music player. The music on the NAS is my gold standard. If I change any tags, I do it on the NAS, then copy back to my mini. I frequently get this problem when I try to copy back. BTW, the reason I have two copies, one on the NAS and one on the local machine is backup. I backup from the NAS to my local drive. Why I do it this way isnt' the issue either. The fact that copy is broken IS the issue.

Jan 12, 2014 12:31 AM in response to cyberchucker

@Cyberchucker
It is a bug when all or most installations have it. In your case it is you or a few more of the millions. That is called a glitch (unlluckily that is much more difficult to solve). It might even have to do with the Nas in your case (Nas is not one of the strongest points of OSX), I do not know. It comes back to the definitions.

In the iHope case I still think that it is between Tiger and Mavericks, that can be a different glitch (at least that is my opinion now still).

Lex

Mar 19, 2014 3:15 PM in response to cyberchucker

Hi CyberChucker, iHope and all.


Thanks for all your inputs, I've read it all and in a way I'm happy I'm not the only one experiencing this bug / glitch. Call it how you want, the fact is that a simple copy do not work with some folders.


I have the same error as you guys :

"Impossible d’effectuer l’opération car un élément intitulé « .DS_Store » existe déjà." (in French)


My configuration is : I bought a 4To to put into my 2008 MacPro, so that I have a backup disk with everything on it. The purpose of this disck is to store everything I have on my disc and put it some place else so that if my appartement burns I have a copy safe. I also have a 4To Time Machine drive in the MacPro, but that's for every day backup.


The thing is CyberChucker, your trick does not work for me. I've been on other forums and apple support pages and some guys did present this idea of copying to a dummy folder, but I've tried it many times and it does not work.


Strangely, It's only some folders that are a problem. Some copy well, some just don't, and it's always the same ones.


I'm sorry I don't come with an answer, I just wanted to state that I also have this problem AND that CyberChucker's trick unfortunately does not work for me.

If you guys have any other lead on how to solve this, I'd be happy to read it.


Cheers !

Mar 20, 2014 12:55 AM in response to iHope

Is the issue solved already?

.DS_Store is a file that appears in every folder, when you delete it it will reappear.

There are however possibilities to avoid creating them on "network" disks:

In your Tinkertool utility choose the Finder tab and check that setting.

You can also delete the .DS_Store files on a volume or in a folder with the help of a utility called Onyx (http://www.titanium.free.fr), they will be rebuild. This may solve the issue.

In Onyx you choose the "Maintenance" page, in there choose the "rebuild" tab, in there is a section called "Appearance of folder's content", in there choose the disks or folders that you want to clean.

Maybe after all .DS_Store files rebuilt you have no or less issues.

Do not use Onyx for anything else ! Uninstall it when you do not need it any more.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Why doesn't Apple fix the ".DS_Store" bug?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.