operation can't be completed because an item of same name already exist

It doesn't appear to be consistent, but in some cases it's reproducible. Maybe one out of ten tries is successful without throwing the error. It also appears to possibly have something to do with specific files, though I haven't been able to determine what that is. I have a rather large directory (1500+) of mostly text and archive files that I tried to copy to two different drives, each a different brand and different capacity. The copy failed and the "filename exists" error appeared at exactly the same time in exactly the same place in the directory structure. I don't know what that means, but the error is definitely reproducible.

Don't you just love it when you post a specific problem and you get replies from people saying their machine is fine or they don't know how to fix it - if they don't know the answer then why are they even replying?

This is nothing to do with faulty drives or anything else - IT'S A BUG with the latest version of OSX. Many people are experiencing this when trying to copy any directory structure onto a Fat 32 volume.

Note to the people who are advising using NTFS - Some people need to use Fat 32, for example the PS3 only recognizes Fat 32 so this bug stops you backing up an external PS3 hard disk.

Apple have not properly responded to many complaints about this, they only say they can't recreate the issue, which is worrying when thousands of their own users can.

I, too, am having this issue. I had a Seagate external hard drive that I used to consolidate files from many hard drives. The default formatting for it pretty much only compatible with PCs and shows up as read only on my mac. Frustrated that I couldn't make any edits directly to the hard drive, I tried to copy all the contents to a new hard drive. I frequently get all 3 of the error messages you guys have been listing.

1. something about an error code 36
2. The operation can’t be completed because an item with the name “somefilename” already exists.
3. The operation can’t be completed because you don’t have permission to access some of the items.

The third one is the one I get the most. It seems to only be an issue with the folders themselves, not the contents. Considering there's usually a lot of sub folders that I'm dealing with, this has become a truly painful experience. I've got over 250GB of old files in a various degrees of disarray.

I have been forced to copy things over, one directory at a time (including every subdirectory). I will get the error message about 40% of the time. When I do, the folder gets created anyway, but none of the contents copy over. So then I go in and manually copy all the contents into that new empty folder that was created. If there's a subdirectory, there's a chance I have to do the same for that...and repeat.

I'm almost done copying every blasted folder. Sometimes just creating a new folder and typing in the new folder names so I don't have to worry about that dreaded error. It's a shame that Apple is pretending this doesn't exist.

It's been 2 days so far with constant focus and manual effort. Should have been as easy as dragging all the contents and letting it copy for about an hour or two. Oh well. Hope they fix this soon.

I also started receiving this error message after upgrading to Snow Leopard (10.6). I was able to work around it using Terminal to copy the files, and also using a Finder alternative (in this case, "Path Finder" http://www.cocoatech.com/).

Clearly a bug in Finder itself.

I have seen this problem with PC files due to the file naming convention, whether this is your problem or not I do not know, but this is what happens.

On Windows a file has the long file name you see in explorer. In the background that file name is converted to a 7x3 name using an algorithm that makes the 7x3 name map exclusively to the long name you have created. It's some form of "hashing" technique that attempts to assure a unique mapping between the long file name and the 7x3 name (that is 7 character name . 3 character extension).

When copying files between directories it sometimes happens that when creating the 7x3 name for a file that is to be copied, it finds that a 7x3 file of the same name already exists, even though the long file name shown in explorer is different. In other words, when it hashes a file name it checks to see if that hashed name exists, if it does it modifies the hash to get a unique name. When copying existing files it wants to keep the source and destination directories the same, which means the same LONG name and the same 7x3 name. If the 7x3 name happens to exist in the destination directory you get this daft error saying a file by that name exists.

Not sure if this is the problem but FAT tables use this type of file naming on PCs and I suspect it might carry over. Probably a clean wipe of the file system will fix it.

Maybe.

Lawrence

Unless the 7x3 name exists twice in the source directory and then you get the message when the second one is copied over as it finds the first 7x3 name and declares a duplicate. That of course implies a damaged source directory - so dunno.

Good luck with the exams, my daughter is going through the same thing right now.

Sure glad I am well past that - although of course one always needs to impress someone!

Cheers - Lawrence

I have just experienced the same problem, but only when I try to copy directories or large files from a network drive to another network drive.

The only way I have found to copy or move these folders is to copy to desktop and then move them to the network drive required, which is a real problem when you are talking about 200Gb folders.

I can't believe that Apple have not discovered the problem and corrected it. I never had this fault until I installed Snow Leopard.

FYI and for Apple, if you read this; the problem is definitely caused by OSX 10.6.2.

I connected my old Mac Mini to my network and I was immediately able to copy or move large folders between my network drives without any problems, just as I was previously able to do.

So Apple please hurry up with a solution to a problem which is driving us all mad.

I can confirm it only started happening when I upgraded to 10.6.2 as well.

The work around is to use pacifist to reinstall the /System/Library/Coreservices/Finder.app
from the 10.6.0 install DVD (10.6.1 update did not include a Finder update).

You will have to use terminal.
1. insert 10.6 install DVD
2. using Pacifist 2.6.3, select Open Apple Install Discs
3. Navigate to Contents of Essentials.pkg
4. Find /Systems/Library/CoreServices/Finder.app
5. Extract it to your Desktop
6. If sane, you should see Finder.app with the Mac Icon on your desktop

Now open Terminal.app
7. at the terminal prompt:
sudo mv /System/Library/CoreServices/Finder.app /System/Library/CoreServices/Finder10.6.2.app
(press return, enter admin password, press enter again)
8. next:
sudo cp -R ~/Desktop/Finder.app /System/Library/CoreServices
(press return, enter admin password if prompted, press enter again)
9. Relaunch Finder (control - option -click - relaunch on finder icon on the Dock)
10. If finder relaunches successfully, you are in business.

If finder won't relaunch:
at the terminal prompt:
sudo ditto /System/Library/CoreServices/Finder10.6.2.app /System/Library/CoreServices/Finder.app
(press return, enter admin password if prompted, press enter again)
Relaunch Finder
carefully repeat procedure again, as it will work if done properly

Kj ♘

I discovered a simpler work around:

1. Control click on selected file(s)/folder(s). (right click if mouse secondary button is set)
2. Select Copy "items"
3. Paste items into Fat32 volume at the appropriate place.


Kj ♘

Kj, are you saying that you have seen the problem too? And that while drag 'n drop doesn't work, copy does? I ask because I've been following several related threads where drag 'n drop of folders does not work, but alternates such as using Terminal works fine (as does copying individual files), when moving things from one hard drive to another, if the destination is formatted as FAT32. It appears to be a Finder bug, evidently introduced in 10.6.2--I gather from your report that the bug only involves drag 'n drop of folders?
Francine


Francine
Schwieder

Hi Francine:
Yes, I have seen the problem. I was first working around it by using the terminal (ditto, cp and rsync)
to move data around. I then tried an earlier finder version (10.6.0), That worked okay for a while,
but then I started experiencing mouse control problems, so I put the 10.6.2 finder back in place.
Today I needed to transfer some files to an external drive, so I began copying them and the bug
was back, so out of curiosity, I wondered if "copy and paste" would work any better. Lo and Behold,
it worked like a charm! That's not a bad work around compared to using terminal or the 10.6.0 finder.

Funny thing though, the bug only shows up on when copying to Fat32 volumes. Copying to NTFS
(using paragon ntfs 7 for write access) seems to be unaffected by the bug. Fortunately, most of my
drives are NTFS. I was copying files to a family member's fat32 drive when I discovered the "copy
and paste" function still worked properly.

I have only experienced this bug when drag and dropping folders.

Kj ♘