About | ACP | Get Stuff | Industry Watch | Learning Curve | Newsletter | Search | Test Drive
Home » Learning Curve

'TFF' Still Not 'Effed'

And it's still not Cocoa either.

Get It

Try It

ONE INFINITE LOOP (Rixstep) — Apple system and software design: slick. No one can touch them when it comes to pure beauty and usability. Why then do they continue to plague people with their own file manager?

Joel Bruner wrote a while back.

So did you happen to see the latest Finder brain fart?

10.7: A warning about Finder's 'Replace' feature

The 'hint' comes from 22 February.

If you have a folder that contains a file with the same name, and drag the file into the same location as the folder, the Finder may try to delete both items.

To reproduce this:

1. Create a folder on your desktop named 'test'.
2. Create a file in that folder also named 'test'.
3. Move the file from the folder onto your desktop.
4. Click 'Replace'.

Result: both the folder and the file are deleted.

Do the same sequence, except choose 'Keep Both Files'. Same result.

[crarko adds: Okay, this one half worked when I tried it in 10.7.3. With 'Replace', both file and folder were indeed deleted. I also tried it with other items remaining inside the folder, and in that case everything inside the folder was also deleted. A potential disaster.]


The hint received a goodly number of comments. Some of the best are reproduced below.


Yep, a child (folder/file/etc) replacing its parent (ancestor folder) is a dangerous thing. Though they could have made it 'work' with using some temporary renaming to prevent collisions/deletions, I'm not particularly surprised in retrospect.

'Temporary' solutions might be what Apple are made of but they're not what serious file management apps are made of.


10.6.8 does not contain this bug, instead it displays a warning The folder 'test' can't be replaced by an item it contains., which in my opinion is perfectly acceptable behaviour in such a situation and certainly preferrable over data loss. [sic]

No that is not acceptable. Because it doesn't tell the user what's wrong. What's going on is a so-called 'cyclical operation'. And there are many types, of which this is but one.


I tested this in 10.7.3 and got the same result as crarko: 'replace' deleted both, while 'keep both files' renamed the file. I believe that the 'replace' behaviour is not just dangerous but a clear bug to be reported to Apple.

No it is not a bug. Not according to Apple. See the links below.


It's a dangerous behaviour but I don't understand why it works - after all, a folder and a file are different kind of 'files' and that's why you can create a pdf, jpg etc. in the same location with the same names.

This is so confused it can bring real software engineers to tears. The 'files' get different extensions, so they do not have the same names. And it works because Apple continue to let it work. And as for disallowing overwrites by different file types: Xfile remains alone in that regard. (And it's not resident system code helping out.)


Maybe the file has to have no ending to replace the folder (made in command line with e.g. 'touch')? (my file was 'test.txt', with file ending hidden in Finder). Any comments on how to reproduce the issue? [sic]

Perhaps it's best to let #4 stew on that one for a while - keep him out of trouble.


Good news is it will not happen that way by end of summer :)

Facepalm. The reference of course is to OS X 10.8 which will supersede 10.7 Vista Lion a wee bit prematurely. The classic 'don't like the bugs then pay for the upgrade' is worn out. All but the most robotic fanatics refuse to accept such terms today. And 15 years down the road Apple's 'engineers' still can't get a file manager out the door at One Infinite Bloop.


An important thing to note is that the file has to be called 'test' with no extension (when I deleted the extension on a png OS X simply hid the extension). I don't think most people spend much time with files that don't have extensions...

Vies with #4 for an award.


Was just coming in to say the same thing.....9 times out of 10 I would assume the file has an extension on it. And the chances of a file and folder being named the same thing are somewhat slim. Should be a rare occurrence. [sic]

#7 sells fanboy baseball caps online. Find the link and get yours today.


Yep. In general, the only files in OS X that don't have extensions, are folders. So in one weird way, you could look at this as expected behaviour.

It just gets worse. Admit it. Resign yourself to it. The End of the World™.


Also of note: 1) Command-Z does not undo this action. 2) The file is not moved to the trash, but instantly deleted.

Yes, so good to know. And the explanation is the following.

As per this link, with all Apple file management APIs, whether of Cocoa legacy from 1997 or of Carbon legacy from even earlier, the destination for a file operation must not exist. This is contrary to all laws of common sense in file management. This is something the engineers at Rixstep noted ten years ago.

The matter was discussed at length with code owners at GNUstep who were aghast to hear of the situation Apple created.

Nor will the Windows file management interface created by David Cutler do anything of the sort. Cutler's file management module is rugged - it completely takes over all requested file ops immediately and ensures rigorous processing - amongst other things, preventing cyclical operations from completing.

Because Apple's approach to file management is the 'lazy' route, file management at application level must of needs remove the destination if it exists. But what if the destination is the source? Or if the source is a subdirectory of the destination?

File management tools need protective coding. It's previously been demonstrated that older versions of Apple's Finder 'lucked out' by creating subprocesses for these tasks, and users were told the operations could not complete because other processes were at work in the destination directory. But this is no way to write file management code.

It seems as if Apple completely lack the wherewithal (along with the human resources) to write a complete file manager that does one thing and does it well. That they even dare offer such a tool as Finder is in itself effrontery. What with all the issues over the years - massive data loss, .DS_Store which turned out to be a known bug never fixed, et al - serious users have to start wondering what they're dealing with.

But unfortunately the story doesn't end there. Joel Bruner again.

Carbon 2012

'Carbon' is of course a legacy 'procedural' API, incomparably buggy and overly complex, that Apple slated for the pastures in 1997 with the merger with NeXT. Carbon was a bridge for legacy 'Mac' code. Rather irrelevant as the 'learning curve' for NeXT's 'Cocoa' is one of the kindest in the industry. But never count out human laziness.

But Carbon was supposed to be phased out because no one at Apple wanted to bother porting it to 64-bit. So Apple's latest Finder was finally to be completely Cocoa, right? Wrong.

'fs_usage shows that Finder in 10.7.3 is still using Carbon', writes Bruner. And indeed it is.

$ sudo fs_usage -f filesys | grep Finder

17:20:37.517627  getattrlist                            /Users/admin/test       0.000011   Finder.151575
17:20:37.517643  open              F=28       (R_____)  /Users/admin/test       0.000012   Finder.151575
17:20:37.517678  fcntl             F=28  <SETFD>                                0.000035 W Finder.151575
17:20:37.517709  getdirentriesattr F=28                                         0.000029   Finder.151575
17:20:37.517718  close             F=28                                         0.000006   Finder.151575
17:20:37.517879  delete-Carbon                          /Users/admin/test/test  0.000088   Finder.151575
17:20:37.518000  rmdir                                  /Users/admin/test       0.000091 W Finder.151575
17:20:37.518960  close             F=27                                         0.000004   Finder.151544

Bottom line? Any wayward snippet of code in any Apple/Finder software you have on disk can hose your Mac without you being able to foresee it or prevent it. These Finder 'brain farts' aren't new. So be careful. Use an iPad. Or the command line. Or Xfile.

Further Reading
Test Drive Xfile

About: Press
About: Testimonials
Industry Watch: Xfile Unleashed!
Industry Watch: Xfile: 'Every Other Day'
Learning Curve: Xfile 3D: Drag Drop Display

The Very Ugly: Finder 10.6.1
The Very Ugly: Finder 10.5.6

Industry Watch: .DS_Store
Learning Curve: .DS_Store Redux
Learning Curve: Bride of .DS_Store


ACP Gurus: Highway -41 Revisited
ACP Gurus: Joel Bruner's '-41' Test with Xfile
Industry Watch: Finder's Nasty Inherited ACL Bug (aka Error -41)

ACP Gurus: Managing File Attributes
Developers Workshop: Finder Leading the Lame
Developers Workshop: It Wasn't Good Then, It's No Better Now
Learning Curve: Finder's 'Open With' Touches Modification Times?

Learning Curve: On File Management (1)
Learning Curve: On File Management (2)
Learning Curve: On File Management (3)
Learning Curve: On File Management (4)
Learning Curve: On File Management (5)
Learning Curve: On File Management (6)
Learning Curve: On File Management (7)
Learning Curve: On File Management (8)
Learning Curve: On File Management (9)

Learning Curve: 4893378 FAQ
Industry Watch: Sanity Checks at Apple
Learning Curve: A Sanity Check for Apple
Learning Curve: 4893378: 'Expected Behaviour'
Developers Workshop: HFS: The Good & The Bad
Developers Workshop: The Alfred E Neuman of File Managers
Learning Curve: Rebel Scum: More Attacks on 'Expected Behaviour'
Learning Curve: Hosing OS X with Apple's Idea of 'Expected Behaviour'

Hotspots: Just An Ordinary Innocent Little Old Text File
Hotspots: (A Document Being Saved By Rixedit)/Untitled
Hotspots: (A Document Being Saved By Rixedit)/CocoaDocument-Based.rtx

Rixstep/7: '(A Document Being Saved By Rixedit)/Untitled' (Membership Required)
Rixstep/7: '(A Document Being Saved By Rixedit)/CocoaDocument-Based.rtx' (Membership Required)

Red Hat Diaries: Back Burner
Learning Curve: Tim Ferriss Facepalms
Industry Watch: Xfile Test Drive
Developers Workshop: 'ACL bug, root cause'

Learning Curve: File Management Macintosh Style

Hotspots: 10.5.2
The Technological: File Merge
Red Hat Diaries: Suicide Fanboys
Macworld: Apple closes down OS X
The Technological: Desktop Services Store
Industry Watch: OpenDarwin Shutting Down
Hotspots: Apple's Open Source Bait & Switch
Hotspots: Apple's Cross-Platform Bait & Switch
The Technological: Of Assholes Gadflies Graybeards & Trolls

Developers Workshop: Three Reasons 1/3
Developers Workshop: Three Reasons 2/3
Developers Workshop: Three Reasons 3/3

Industry Watch: The QuickBooks Disaster
Apple Support Communities: Desktop GONE

Hotspots: A Road to Daytona
Industry Watch: 10.6 A Maintenance Update?
Ars Technica: 10.6 Snow Leopard May Be Pure Cocoa
Cult of Mac: Dear Steve Jobs, What Happened To Quality?
Apple Support Communities: WHERE are my PHOTOS?????

Industry Watch: Latest OS X Update Causing Wireless Problems?

Apple: NSWorkspace Reference
Apple: NSFileManager Reference

Slashdot: Data Loss Bug In OS X 10.5 Leopard
Tom Karpik: Massive Data Loss Bug in Leopard
MacInTouch: Mac OS X 10.5 Leopard: Finder Data-Loss Bug
The Technological: Dog of Bride of Son of Massive Data Loss

About | ACP | Get Stuff | Industry Watch | Learning Curve | Newsletter | Search | Test Drive
Copyright © Rixstep. All rights reserved.