fileCopy() Error

[Jonathan.F]

I'm occasionally seeing the following error when duplicating a file.

FSCopyObjectSync: Bad file name

What exactly does this mean and does anyone have an idea why this is happening?

Using 4.7.3 on 10.7.2 on a macbook pro 2011.

Thanks!

Jonathan

[codegreen]

Hi Jonathan,

Basically it means FSCopyObject (the modern Carbon Toolbox API for copying file system objects) didn't like the target file name you passed it (or at least whatever was left of it by the time it got parsed). This error indicates it's choking on the actual file name (not the path, which would return a different error).

If you set up a wrapper around the call to report the source and destination file paths on failure, the reason for the problem may become clearer...

HTH,
-Mark

[Jonathan.F]

Thanks Mark.

What is making me crazy about this is that the file names have been consistent for literally years and this problem is new. The code hasn't changed in ages either, although it is using the new 4.7.3 version of file copy(). Furthermore it works on one machine and fails on another. I've tried replacing the application and it doesn't change anything.

I'll look more closely at the name values.

Thanks!

Jonathan

[Jonathan.F]

I think I figured out what is happening. Apparently there is some subtle inconsistency in how fileCopy deals with the short date in the file name. Sometimes it allows "(1/1/11)" in the file name and sometimes it chokes on it. I believe that this might have to do with whether "(1/1/11)" is evaluated as a number or treated as text and that this appears to depend on whether the name variable has been 'touched' after the text date value was added.

I'm not sure why the same code works on one machine and not another, but perhaps there is another factor such as path length that makes a difference. In any event, I have modified the format of the date used in my file names using the new international format and everything appears to be working again.

Thanks!

Jonathan

[Dan_Kelleher]

Thanks Jonathan.
-Dan

[codegreen]

I think I figured out what is happening. Apparently there is some subtle inconsistency in how fileCopy deals with the short date in the file name. Sometimes it allows "(1/1/11)" in the file name and sometimes it chokes on it. I believe that this might have to do with whether "(1/1/11)" is evaluated as a number or treated as text and that this appears to depend on whether the name variable has been 'touched' after the text date value was added.

I'm not sure why the same code works on one machine and not another, but perhaps there is another factor such as path length that makes a difference. In any event, I have modified the format of the date used in my file names using the new international format and everything appears to be working again.

Aha! I think you've hit the nail on the head there.

FileCopy uses an older API to copy files if the path doesn't contain any long components, isn't over 255 characters, and doesn't otherwise confuse those crusty old MacRoman FSSpec-based routines. It does so because the newer long filename aware Toolbox API that takes FSRefs (Carbon's opaque Unicode-based and IMHO idiotically designed mechanism for referring to files -- which everyone hates) was IIRC roughly 80 times slower at the exact same task.

That means you're running through a completely different set of gnarly code written decades later by people who probably never even met the authors of the older version when you force fileCopy to fall back to using FSRef-based routines, and it wouldn't surprise me a bit if things worked subtly differently in special cases like the one you describe...

-Mark

[Dave_Higgins]

Makes me kinda glad I waited until Cocoa / Obj-C was the norm before I decided to "step it up".