Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

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 http://hints.macworld.com/article.php?story=20120218074834885

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.]

Comments

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

1.

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.)

4b.

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.