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

Home » Learning Curve » ACP Guru

Joel Bruner's '-41' Test with Xfile

But we have Cover Flow!!1! And permissions are simple!!1!

Get It

Try It

STANSTED (Rixstep) — Joel Bruner's '-41' test of both Finder and Path Finder is a doozy. It shows that both those 'file managers' once again fail.

The '-41' test is about access control lists and about how those two applications go nuts when copying or creating files, leaving an OS X system unstable and out of memory.

Joel claims Xfile passes the test like all the earlier tests with flying colours. He writes that Rixstep software is quite conscientious about doing the Right Thing™. What's the truth?

The truth of course is that Joel Bruner is right. And here you can see the proof in action.

The Test!

A test directory outside the home area was created for the experiment. The directory was christened '-41'.

$ mkdir -41

The 'ACLShackles' directory was created inside '-41'.

$cd -41; mkdir ACLShackles

Because default ACL behaviour is different on OS X Server and OS X Client, the directory 'ACLShackles' was first loaded with all the requisite ACL gunk. (Note you must remove the spaces after commas as chmod code is still weak on parsing.)

$ chmod +a "$(whoami) allow list, add_file, search, add_subdirectory, delete_child, readattr, writeattr, readextattr, writeextattr, readsecurity, file_inherit, directory_inherit" ACLShackles

Now you're ready: ACLShackles has both the directory_inherit and file_inherit flags, meaning anything created in ACLShackles will get the same ACL gunk. So now you go for it. Add a few levels to the original test if you wish.

$ mkdir -p 0/1/2/3/4/5/6/7/8/9/10/11/12/13/14/15

Now check your handiwork with a reliable file manager.

Things seem to be fine. Xfile shows the complete hierarchy on the left and ACL shows the ACEs on the right. Hunky-dory.

Now we duplicate the directory '0'. This is a simple operation in Xfile: ⌘2 (or 'Duplicate' off the menu or toolbar). And we can then verify our handiwork again.

What happens with Finder and Path Finder is the ACEs (access control entries) get duplicated all over the place; in such case you'd see a flood of entries in the lower pane in ACL on the right. Over 100 of them. What's supposed to happen is no ACEs get added at all. And that's what happens with Xfile. Xfile passes yet another test where others fail.

Herewith the two info sheets for '0...15' and '0 copy...15'.

Herewith the two ACE sheets for '0...15' and '0 copy...15'.

Everything is as it should be.

Food for Thought

This isn't the first time Finder and Path Finder fail. Their promiscuous use of the Cocoa code class NSOutlineView leads to crashes, hangs, and major lulz. None of those issues are fixed as they're endemic to the applications' fundamental design.

Why isn't Finder a Cocoa app if everyone at Apple insists it is?
Why does Path Finder insist on duplicating each and every design and coding flaw in Finder and making things not faster but slower, not more reliable but more buggy?

Of course if you really want Cover Flow™ to fulfill your file management wet dreams, then by all means go for it. Good luck.