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

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.

Brilliant! THanks Cyberchucker. This works for me.

~Mary

Mary, you're welcome, glad I could help. What I think would actually be brilliant is if Apple fixed this so we didn't have to resort to silly workarounds! Cheers, Chuck

rcush65: Note - There's no need to create a dummy folder for each movie. Just create one dummy folder in the root of the target drive. Next, drag all the movies (in one fell swoop) into the new dummy folder. I'm betting that will work fine. When that's done, just drag the entire contents of the dummy folder onto the root of the same drive. I'm betting that will solve your problem. Please let us know!

I figured out a solution that is working for us! After finding out that a .ds_store file is a preference for how folders are sorted and organized, I realized that there is only one view in Finder that does not have any preference to how folders or files are viewed. The column view doesn't maintain anything other than alpha order. If we copied anything in list view or icon view we'd run into the issue. But in column view we've been copying terrabytes of data many folders deep without problem.

The reason I see is because as soon as a folder is accessed in another view that would maintain display preferences of the folders, like if they are expanded or not in list view, then Finder is creating a preference file for that folder. It's just my deductive reasoning but I'd love it if others could benefit from it. Please test it for yourself and report back. Thanks!

Well done DaChavez!

I have never had this problem before, but it suddenly reared its head this weekend (on Mavericks 10.9.3). Trying to copy nested folders to an external drive suddenly became an impossible task, although it's worked for me for as long as I can remember (before OS X was invented). I had thought it was an indexing issue, as re-indexing the drive appeared to cure it, but then it suddenly went wrong again. I also thought it was an indexing issue with the external drive, but erasing and re-formatting did not help. As someone has said, it's fickle - sometimes it's OK, sometimes it isn't, and it's always worked fine in the past.

However, copying from column view on the hard drive to column view on the external drive was an instant success, and the reasoning of DaChavez seems very logical to me. I can now copy faultlessly every time - until I change the external drive to list view, and then it goes wrong again! Keep it all in column view, and all is fine.

Thank you, DaChavez, you've saved hours of frustration, and I hope many others can benefit from this cure.

I have just experienced this problem while trying to copy almost 150GB of files in nested folders from an external ExFAT formatted HDD. I managed to solve it by launching Onyx and running Maintenance>Rebuild to delete and rebuild all .DS_Store files in the external volume. Now it works!