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

Hi Lex,

Unfortunately I have not read anything that solved this issue, neither in this thread nor in others.

Thanks for suggesting again this deletion of all .DS_store files but :

1/ I don't want to do this because it would mean that I loose all my tags (which I use a lot) and other finder window prefs

2/ It's not a viable solution.

By trying to copy files one at a time, I discovered that the ones that posed a problem were the ones with a name starting woth a "#" character. I changed every folders name so there was no "#" left and then the copy went all along with the rest of the files and folders.

I checked if the two drives (the source HD and the backup HD) had the same formating, and yes, they were both formated HFS+ journalised, but not case sensitive.

Could this problem be avoid with a different HD file / bit format ?

cheers

1. you don't loose anything, but the .DS_Store file is renewed, so that any corruption is gone.

2. what is not a "viable solution" ?

Your remark about the special characters may have value: this is seen often in Macs when copying files that were made/named in Windows.

My post was based on the continuous mentioning of "stopping on the .DS_Store" files.

Since I can not simulate your issue, I can not be sure that my proposal will really solve the issue. It may solve the stopping issue and also the special characters issue.

Just wanted to state I have the same issue as others with ML 10.8.5. Quite annoying! I guess I might just try deleting all the .ds_store files and see how that does....

also I will try making a dummy folder and copy to that....

Hi,

I'm usually a reader rather than a "post'er", but this problem has been anoying me for months.

I have been trying to back-up 8TB of various stuff from a QNAP storage to brnad new WD 4TB newly formatted external drives using:

- iMac with Mavericks 10.9.1

- Brand new MacPRo (yes that one...) with Mavericks 10.9.1

- MacBookPRo with Mavericks 10.9.1

and the same .ds_store file problem occurs with all three.

I tried deleting the .DS_store file, changing the sort order, renaming the folder, reformatting the external drive as suggested in various post I read, but nothing worked.

This morning, I tried copying a folder from my NAS to my desktop and then copy that folder from my desktop to the WD drive and "Voila". It worked flawlessly, as it should...

I then took an older MacBookPro running Lion, connected the same external hard disk, reformatted it and tried to copy the same folder from the same NAS to the external drive and guess what: it worked.

So, there you go, there is something buggy in the way Maverick handles the copy process from an external drive to onther external drive.

My guess is that when it creates the new folder on the target drive, it also creates the .ds_store file and then when it comes to copying the original .ds_store to the same folder it cannot.

I also guess that the reson why it does not gives us the choice of overwriting the file is because there should not be any need for that since it is a newly created folder.

That's it for now.

I will be doing more testing and report them here.

Hi Guys,

here are some more news.

I reformatted my iMac hard disk and did a fresh install of Mountain Lion.

I then reformatted my WD HDD and I still can copy directly from my NAS to the external drive without any issue about the .ds_store file.

So, to make a long story short, it is most likely that the copy process in Mavericks is the culprit.

Let's hope that Apple solves this issue in a timely manner...

I had the .DS_Store problem as well running Mac OS 10.7. I was upgrading from a one external hard drive to another larger one. I got the dreaded "The operation can’t be completed because an item with the name “.DS_Store” already exists." message. I read a number of posts about it on the forum after running through a course of reformatting the new drive etc. etc., what I finally did was start copying one drive to the other until I got the dreaded message which occured after only a handful of files had been copied over. I then selected the new larger drive in the finder and used the file "find" to make the invisible DS Store files visible on the new drive. I then dragged all of them to the trash, when I did that they did not disappear from the window but changed to a white colour but they were trashed. I then selected the rest of the folders that needed to be copied over from the smaller harddrive, dragged and dropped them onto the new harddrive and everything transferred without any further problem. I had over 2 TB of photo files so it took sometime but it all worked. I think Cyberchuck's folder solution is better but I did not come it across until after I started my procedure. It appears to me after reading so many posts about this problem on various machines, OS systems, harddrives, flash drives that it is obviously an Apple software glitch

Here is a brief status of my NAS backup.

Somehow, I have been able to copy part of my NAS without any problems.

Unfortunately, for some folders, the .ds_store infamous message reappeared. It looks like folders containing several sub-folders are more prone to this behaviour.

The only way I found to copy those folders (without going through the "erase" process mentioned earlier and in several posts) is to copy the folder to my desktop and then recopy it from my desktop to the NAS.

This is getting really annoying...

Apple doesn’t routinely monitor the discussions.

Send Apple feedback. They won't answer, but at least will know there is a problem. If enough people send feedback, it may get the problem solved sooner.

Feedback

Solved the .DS_Store bug/problem!!!!!

Got the hint from this thread... it's the way things sort. .DS_Store needs to be the first file in a folder, starting with some recent system update (probably Mountain Lion; I know I noticed it before going to Mavericks). I got a utility called InVisible and used it to make invisible files visible. My photo workflow causes me to do a number of steps, some of which are nested. To keep track of how far along I am on each shoot, my master folder includes the following folders:

-1 Scratch Fuzzies

-2 Set Base Metadata

-3 Rate

-4 Set Classes

-5 Tag & Process

2 & -

3 & +

-6 Set Finder Color

1 Private

2 Problem

3 Polemical

4 Publishable

5 Particulars

6 Personal

7 Pattern

8 Put Away

The last eight steps are a sub-set of step 6 Set Finder Color. In order to get them to sort after the first 1-6 items, I added the dash before the first six items. Cutting on invisible files reveals that this puts the .DS_Store file after the items that begin with a dash, but before the items that begin with a number. I first tried to put the last eight steps within -6 Set Finder Color, but that didn't help, because .DS_Store was sorting to the end. Apparently, it needs to be at the beginning. So once the last eight were within -6 Set Finder Color, I just removed the dashes from the beginning of the first six items, and the problem went away! So happy it's this simple, and fixable!

If you're interested in a full explanation of the photo workflow for any reason, you can find it here: http://usefulstuffmouzon.tumblr.com/page/4

Hi Steve,

I did tried this route and it does work.

One of the problem I have is that I'm making a back-up of all the data in my NAS and within this data there are several iPhoto files.

As you may know, an iPhoto file is actaullay a package. If you right clic on the file and select "Show Package Content" you will notice that depending on the amount of separate rolls, days, etc.. of pictures there could be ten's of folders, each with a .DS_store files. So going through all these folders to make sure this .DS_store file is at the top is a nightmare.

For now, my solution of copying the files to my desktop and then copying it to my external drive is the safest and easiest way.

Regards,

Daniel

Hi all,

Thanks Steve for confirming what we though.

Thanks to everyone's inputs (like unhiding .ds_store file to see how they behave etc), I did manage to copy my files to a backup disk, as mentionned :

By trying to copy files one at a time, I discovered that the ones that posed a problem were the ones with a name starting with a "#" character. I changed every folders name so there was no "#" left and then the copy went all along with the rest of the files and folders.

But I'm with iHope when he says that it's not a solved problem, since you still have to go through your all disc and content to change your files' organisation and naming. I bet it did bother you a bit to change your folder naming system to fit the OS, am I right ? 🙂

I did send Apple a notice few weeks ago to report the problem, but I got no news from them.

Let's hope they fixe this in the next update.

cheers.

i am copyimg movie folders from disk to disk in Mavericks. Creating a dummy folder for each movie (it doesnt work with multiple folders of movies) or positioning DS_store in each folder would be a nightmare. I copy each movie one at a time and get the error message at the end of each copy but the movie plays fine. so that is my workaround. I have no problem with singular movie files without a folder unless of course they are grouped with erroneous folders then copy is aborted after the error is encountered. I never had this problem before Mavericks, before I reformated a disk (source disk) to FAT32 (im a NTSC guy) , or before I began copying all movies to a refurbished 2BIG 6TB Lacie i acquired yesterday from FAT32 to MAC extended journaled (2big). I never had this problem before between my 3tb and 2tb mac journaled or from them TO the FAT32 days ago. I never copied from a FAT32 to mac journaled before yesterday. Wierd: if i delete the movie from the destination after i have had this problem with the error before and copied the movie (from FAT32) to any disk including the destination I originally got the error, i dont get any error anymore. No wonder this problem is difficult to replicate, it is fickle.