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

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.

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.

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.

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

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.

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.

OK, inform us of your observations.

Lex

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.

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?

It has nothing to do with

a. Apple bug, it is not,

b. iHope's issue.