Level 1

18 points

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

95 replies

iHope Author

Level 1

18 points

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

does it make a difference if the .DS_Store file is "older" or "younger" when this file does not want to be overwritten?

Yes it makes a big difference!

A folder viewed by Name, in which the .DS_Store file is not at the top (ie, the latest) will only copy over the items 'above' the .DS_Store file and then stop. A message comes up: "The operation can't be completed because an item with the name ".DS_Store" already exists." In such a case the .DS_Store file on the destination drive is more recent - it seems to be created at the time of copying.

Today I observed the following behaviour of a such a problem folder. Three files were 'above' the .DS_Store file because their file names began with a blank space. The date of the .DS_Store file was 28 December. When I removed the blank space in the three files the .DS_Store file appeared at the top of the list with today's date and time (ie, the compter changed the date at that instant). I was able to copy the folder to another drive, whereas only a few minutes before it wasn't possible.

Any ideas?

iHope

Kurt Lang

Level 9

68,502 points

Jan 1, 2014 11:21 AM in response to iHope

Do you mean make a bootable drive of the computer's hard drive?

Yes. I would make a clone of your current startup drive to an external partition. You can use a Disk Utility, or the third party apps SuperDuper!, or Carbon Copy Cloner. If something happens while changing the partitions on the main drive (it shouldn't), then you just boot to the clone and clone it back. Takes far, FAR less time than reinstalling the OS and merging a Time Machine backup on the fly.

Make sure the external drive's partition map is GUID, or it will not be bootable. Make sure to also backup any other partitions on the main drive to a second source.

Kurt Lang

Level 9

68,502 points

Jan 1, 2014 11:26 AM in response to iHope

You must have hidden items set to show. This isn't a good practice since it in part causes the problem you're seeing. The .DS_Store files belong to the system, which is why it keeps stopping when it gets to that item.

Put hidden items back to where they should be and the issue should resolve itself.

iHope Author

Level 1

18 points

Jan 1, 2014 11:46 AM in response to Kurt Lang

Kurt,

As explained in my original posting, I've only used TinkerTool in order to observe the behaviour of the (usually invisible) .DS_Store files. How else are you supposed to do it?

Ordinarily I don't have hidden items set to show. I have no interest in seeing them. This problem arose before I used TinkerTool.

Put hidden items back to where they should be and the issue should resolve itself.

I've not touched any hidden items, only observed them. When made invisible again with TinkerTool the problem persists. What makes you think the issue should resolve itself?

iHope

Lexiepex

Level 6

14,108 points

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

You do not quite grasp what I asked.

Say you have a disk with Tiger origin, and a computer with ML: I understand that you have a problem when copying a folder from "tiger" to ML. Do you get the same error when copying a folder fromn ML to the 'tiger' disk?, that was my question.

Now about the date of the .DS_Store file : of course you immediately get a new date on that file: as I said it is created as soon as there is no/compromised/changed .DS_Store file. It has nothing to do with contents, it is created (and contains info) on how the folder has to be displayed according to the acting OS.

What I am trying to confirm is that the format of the .DS_Store file is too different between the two OS (tiger and ML) to not create problems.

Try the same actions between Leopard, SL, L,ML,Mavericks and you almost certainly will see that there will not occur such strange behaviour.

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.

Lexiepex

Level 6

14,108 points

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

iHope, do not worry about Tinker Tool: it is one of the very few that are coded good and do not interfere with the OS, you can trust the Bresink apps.

Lex

Kurt Lang

Level 9

68,502 points

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.

iHope Author

Level 1

18 points

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

iHope Author

Level 1

18 points

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

Lexiepex

Level 6

14,108 points

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.

iHope Author

Level 1

18 points

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

Lexiepex

Level 6

14,108 points

Jan 4, 2014 12:04 AM in response to iHope

OK, inform us of your observations.

Lex

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.

iHope Author

Level 1

18 points

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?

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?