4893378 FAQ

Serious user concerns dismissed by Apple 'user experience engineers' with 'works as designed'.

Get It Try It

Following a number of alarming reports at MacInTouch and Mac OS X Hints Rixstep published a study of - and comments on - the issues on 20 December 2006. Rixstep and a number of other ISVs also submitted bug reports to Apple.

Apple have responded.

This is a follow-up to Bug ID# 4893378. We have received the following update regarding your report:

Engineering has determined that this issue behaves as intended based on the following information:

When the Save panel asks if you want to replace a file or folder of the same name, and the Replace button is clicked, expected behavior is received.

Thank you for taking the time to submit this report.

Best Regards,

The Bug Reporting Team
Apple Developer Connection

Q: What exactly is the issue?
A: As per references cited above, entire directory hives can be removed and replaced by a single file. And contrary to what Apple want you to believe, this does not always require user interaction. Several documented cases show software products from Apple themselves are doing this to you without your being able to control or prevent it.

Q: But if the user opts to replace?
A: Not good enough. Unix itself comes equipped with safeguards to prevent this and Unix was built by and above all for accomplished system engineers. Even they realised the danger in the scenario. And besides: you're not always asked first.

Q: Why won't Apple recognise the issue and fix it?
A: It's partly denial and partly the difficulty in addressing the issue. As explained at the references above, this is a deeply rooted issue in OS X file management with further issues sure to manifest themselves over time.

Q: So what's wrong with Apple file management?
A: As with many aspects of OS X (and evidently earlier systems) Apple have taken the easy way out. File operations are not complementary. You have to remove your destination directories and files first. All Apple APIs require this.

Q: What are complementary file operations?
A: They're file operations that complement the destination rather than replace it. If a destination file already exists, a copy operation overwrites it with the source. If a destination directory already exists, it is ignored - it does not need to be removed only to be replaced. Apple file operations have to remove everything first in order to copy or move things in. In complementary file operations changes are propagated throughout the destination hive without destroying the target.

Q: Have there been cases of users hosing their computers?
A: Yes. See the references cited above.

Q: Can I protect myself against this scary thing?
A: To some extent but not completely. Rixstep's Xfile now prevents operations between incompatible file types but this is an issue at system level and Apple should fix it - for until they do, any wayward snippet of code in any program you have on disk can hose your computer without you being able to foresee it or prevent it.

See Also
Industry Watch: Sanity Checks at Apple
Learning Curve: A Sanity Check for Apple