No such file or directory
 

My backup is failing with this error:

|12:10:04 AM|Info| WARNING: Caught I/O exception(2): No such file or directory
|12:10:04 AM|Info| WARNING: Source: /Applications/BBEdit 7.0/BBEdit Support/Scripts/02)Open Folder/"BBEdit Prefs" Folder, lstat(): 0
|12:10:04 AM|Info| WARNING: Target: /tmp/SVUmount/Applications/BBEdit 7.0/BBEdit Support/Scripts/02)Open Folder/"BBEdit Prefs" Folder, lstat(): -1
|12:10:04 AM|Info| WARNING: Could not copy file with Cocoa frameworks. Attempting to copy with ditto.
|12:10:04 AM|Error| ditto: /Applications/BBEdit 7.0/BBEdit Support/Scripts/02)Open Folder/BBEdit: No such file or directory

"BBEdit Prefs" Folder is actually an AppleScript file, not a folder, despite its name. Is SuperDuper choking on the quotation marks in the name? If not, what's going on here?

Hm. It certainly shouldn't be choking on the name, but there are a lot of special characters in there, including -- quite unusually -- some quotes around the name of the file itself. But we pass the filename directly to internal routines that shouldn't care what the name is.

Can the file be copied with the Finder?

The file copies fine in the Finder.

To be clear, the name of the file is:
"BBEdit Prefs" Folder

There are other files with quotation marks in the filename that SuperDuper copied without incident, but this is the first file it encountered with a quotation mark as the first character.

Yeah, that should be fine regardless -- we don't really care about the characters in the name.

A few things to try:

- Duplicate "BBEdit Prefs" Folder in the finder, trash the original, and rename the duplicate. That might resolve the issue.

- If not, could you send me the whole SuperDuper!.log via mail?

Thanks.

Well, I renamed all the files that had a quotation mark as the first character in the name, and this time it worked.

Really! Very interesting. Of course, it's possible there's some kind of bug in the functions we're calling (as I said, we're not parsing the file there), but it's not something we've ever seen before. But there's always a first time.

We'll take a look and see if we can repro. Thanks for the follow-up!

The log for the session that worked also doesn't contain the non-fatal errors seen in the log I sent you. So maybe that's a clue -- something else was broken that cascaded down to the quotation mark killing the process.

Egad, I'm dealing with so many cases right now I've misplaced the # of yours... could you provide it?