can't copy files to external hard drive

Hi! Try creating a folder on the external drive and then copy all the items you are trying to copy to that folder. Tom

same problem here, trying to get my 35GB itunes library on a lacie 250GB HD, get this error, even when i use your suggestion to make a folder and then put the files in that folder, it goes for about 4 minutes then this error pops up, again... very annoying, any other solutions?

What is the format of the external drive? I am wondering if you're up against a character count limit or perhaps a character incompatibility between Mac format and, say, something like FAT32. If your files have similar names and a file name is getting truncated or a character is getting changed a different character might it be resulting in duplication?

Hi! Yes, be sure the external is Mac formatted. Also you may have to do a "get info" on the external and check the box in the pane that says "ignore ownership on this drive". Tom

I have the same problem when trying to back up files from our xsan to firewire drives. We ran into this error upon transferring files when we were upgrading our existing san's storage pool to include two new promise arrays... we used terminal to copy the files, to get out of that rut but now as we are trying to archive our pre-2008 stuff we're getting the error messages again, all over the place. it's a little rediculous.. furthermore the error message is meaningless, except for a few characters.

The external drive is indeed Mac formatted, and ownership is ignored on the drive. Any other solutions? How about providing the CAUSE of the message? How could a similiarly named file (except for a few characters) prevent a copy??? Why don't i get the error when trying to copy a file "filename1.gif" into a folder that contains a file named "filename2.gif"?? These are file names that actually are the same, except for a few characters.

needless to say... Whoever at apple worded this error message "The file name already exists but kinda not really" should be hung upside down from their toes.

we never saw this message on tiger running xsan 1.4, but since the update we run into it constantly when trying to move or copy files.

Hi Rob, and a warm welcome to the forums! 🙂

"cannot copy xxxxxxx to the destination because its name is the same as the name of an item on the destination, except for the case of some characters"

Could you have misinterpreted the message?

The above one means you're trying to copy something like "Filename.gif" to a drive or folder that has "filename.GIF on it.


Was one of these Sans formatted Case Sensitive, and not the other one?

I can get around this if I copy a few files at a time. The problem is, I don't have time to sit at my computer and do that. When I'm doing a mass copy, like moving a whole folder over, it starts the copy but then hits the error and stops. When I check it has copied NONE OF THE FILES AT ALL! Not even the ones I could copy over one at a time.

Is there a way to tell it to copy while ignoring errors? Like just tell it "Hey, copy what you can and forget about the files that don't copy."?

Hello mldart, and a warm welcome to the forums! 🙂

It's quite acceptable to start a new topic & will usually get you more help...

http://discussions.apple.com/post!default.jspa?forumID=758

One thing I know that''l do that, and also show you a list of what and wasn't copied & why, is Tri-Backup...

http://www.tri-edre.com/english/tribackup.html

"Could you have misinterpreted the message?

No, my language settings are correct.

"The above one means you're trying to copy something like "Filename.gif" to a drive or folder that has "filename.GIF on it."

Exactly. The message shouldn't come up when you try to copy something like "Filename.gif" to a drive or folder that is completely EMPTY... I thought I had described quite clearly what I was doing in my original post but I guess I never specifically mentioned the drive/folder i am copying to is EMPTY.

I think you got confused by my hypothetical... READ the error message... What's with the qualifier "except for a few characters" why would an OS have trouble copying a file if its file name was similar to a pre-existing filename anyway??!! that would insinuate that if the target drive/folder contained a "Filename1.gif" it can not also contain a "Filename2.gif", because here, the file name is the same, except for a few characters. . . Toss that around for a little, i think you'll follow but it's not my core issue..

I need to know why i am getting this error when trying to copy files from one mac volume to another mac volume into an EMPTY folder. I am getting this error message when trying to copy to a completely empty freshly mac formatted 2TB drive (happening on any one of SIX brand new GRaids) and we really need to archive our files. I work in the design department of a television news station and we generate QUITE a load of graphics daily that take up lots of space, so we need to get this stuff off our Media drives pronto.

A possible explanation is that the drive you are copying from is case-sensitive, but the one you are copying to is not.

So if on the source drive, you have a file called 'Fred' and a file called 'fred', they can happily co-exist. But when you try to copy them to the destination drive, you have copied (or prepared to copy) 'Fred', and then when 'fred' comes up it is regarded as the same name and throws up the error.

It's not going to be easy to deal with this if there are a lot of files. You could try: attempt to copy half the files. If they copy OK, attempt to copy half the remaining file and so on. If you get an error on the first try, try to copy half of the failed files.

Any time you get a success, try copying half the remaining files. Any time you get a failure, try to copy half the failed files. Eventually you will narrow it down to a manageable amount to inspect manually. It's time consuming, but not nearly as much as ploughing through the lot manually.

(What's really needed is for some programming expert to come up with a way of listing all the files and finding the duplicate).

Ah, yes "EMPTY" makes a big difference, and Roger's explanation seems the most plausible.

Tri-Backup should copy the ones it can & give you a log of the ones that failed, to help you figure out a curse of action.

Again, the drive i am copying into is empty - case sensitivity has nothing to do with my situation as there are no files on the target disk to begin with. Neither the Xsan or the GRaids are formatted for Case-Sensitivity... they are normal Mac OS Extended (Journaled) partitions.

So I should just buy a third party bandaid because the developers of the os won't acknowledge the fact that an issue exists?? Who am I dealing with here... Microsoft??!!??

So I should just buy a third party bandaid because the developers of the os won't acknowledge the fact that an issue exists??

Sorry I mentioned anything at all.

Who am I dealing with here... Microsoft??!!??

Ahem, right here your just dealing with other users trying to either help you with your problem, or find a workaround... we are not Apple here.

Good luck.

From the OP

neoweapon wrote:
I'm trying to backup a directory with 50 GB of files and every time I do, I would get this error about 15 mins into copying...

"cannot copy xxxxxxx to the destination because its name is the same as the name of an item on the destination, except for the " case of some characters"

Then from:

rob@asg wrote:
I have the same problem when trying to back up files from our xsan to firewire drives. We ran into this error upon transferring files when we were upgrading our existing san's storage pool to include two new promise arrays... we used terminal to copy the files, to get out of that rut but now as we are trying to archive our pre-2008 stuff we're getting the error messages again, all over the place. it's a little rediculous.. furthermore the error message is meaningless, except for a few characters.

I have been following this thread with due attention as I had been encountering similar problems when copying files to an external firewire disk ... although I was not getting the exact same error message, so I can certainly empathize with the frustration; and agree that Apples error messages are often blatantly stupid to the point of being nearly incomprehensible.

How could a similarly named file (except for a few characters) prevent a copy??? Why don't i get the error when trying to copy a file "filename1.gif" into a folder that contains a file named "filename2.gif"?? These are file names that actually are the same, except for a few characters.

Ah ... no ..."filename1.gif" and "filename2.gif" are NOT the same when considering the numbering convention. So this must be 'something" different ... and that difference (or similarity, as it were) could only be accounted to differences in "Case".

"cannot copy xxxxxxx to the destination *_because its name is the same_* as the name of an item on the destination, *_except for the case_* of some characters"

So the answer is clear ... who ever named the files on your source drive has inadvertently named certain files similarly within the same directory, easily done with files of that size. Now, how that was done originally without encountering an error message is a bit perplexing.

rob@asg wrote:
Again, the drive i am copying into is empty - case sensitivity has nothing to do with my situation as there are no files on the target disk to begin with. Neither the Xsan or the GRaids are formatted for Case-Sensitivity... they are normal Mac OS Extended (Journaled) partitions.

Please take no offense Rob ... but are you indeed certain of THAT ???

I only ask as I have no method to verify how a drive is identified when it has been formatted to include a Case-Sensitive file system. Could it be that it does not display in "Get Info' from the Finder, but would reveal that within Disk Utility's "Get Info" pane ?

So I should just buy a third party bandaid because the developers of the os won't acknowledge the fact that an issue exists?? Who am I dealing with here... Microsoft??!!??>

Sorry about the problems you've encountered, but at this point waiting for Apple (to do anything or not) will not resolve the current problem.

The way I see it is that you have a series of bad or better choices.

1. You can go through the entire 50 Gigs of files manually to try to isolate the problem files, and then rename them.

2. You can re-format the destination drive to indeed be Case-Sensitive ... and avoid the error message and preserve the similarly named files.

3. Use a third party utility to do the copying that might identify and or sandbox the specific problematic files.

Going through the entire drive manually seems insane, and if you want to Boot the backup or Restore system files from it ... changing the file structure on the target destination volume might create more problems later on; but if THAT is NOT a concern (and the backup is to simply get the stuff off of the server into an archive as data), well then format the target volume as Case-Sensitive to allow the transfer.

If neither of the above are acceptable, and you decide on the third option, I have 2 recommendations.

Lacie's Silverkeeper v2 is free and has been recently updated to be compatible with Mac OS 10.5.5.

http://www.lacie.com/silverkeeper/

I haven't used this version myself so I can't attest to its feature set.

Then there is a fully featured commercial utility from Prosoft Engineering, the folks that developed Drive Genius and Data Rescue, offer Data Backup 3; this one I have used and do highly recommend it for its ease of use and it has a really stellar feature set.

I got it free with a drive I purchased through OWC ... an offer that is still available btw, so if you anticipate a need for other drives in the near future ... ???

Data Backup 3
http://www.prosofteng.com/products/data_backup.php

Hope your problem gets resolved expeditiously, if it hasn't already.

Ohm51

I've just had the same issue copying to an external Maxtor HD - I don't believe it has anything to do with case-sensitive formatting or otherwise, FWIW.

The following work-around did the job: I compressed the files to one folder then transferred the compressed folder to the external HD with no problems. Then I un-compressed the folder, to open on the external hard drive. In one final highly-skilled maneuver, I deleted the compressed folder, leaving my original set of files happily sitting on my external HD.

Happy days.