File Calumnies

Now that I’m newly thinking about helping out with another project in Cocoa, it’s getting me thinking about some issues I’ve had with Cocoa.

Let’s start with files.

Here’s a demonstration for you. Open TextEdit and save a file to the desktop. Go to the desktop and move the file somewhere else. Then go back to TextEdit, modify the file, and save it again.

Presto! New file on the desktop.

Do the same thing in BBEdit. No new file appears on the desktop. Instead, the changes are made to the moved file.

Now, some of you are saying, “Ah ha, bug in TextEdit!” Others of you are saying, “Ah, ha, weird behavior in BBEdit!”

This schism is described in detail in the macosx-dev mailing list thread “Paths, FSRef, Alias, Resource Fork, and the Big Schism”.

As an old Mac user, I think the BBEdit behavior is correct – just because you’ve moved a file doesn’t mean it’s in any way different. The most effective argument to the contrary is that many computer users aren’t used to this behavior, because of experience with Windows and Unix-like OSes.

Another argument in the thread is that, in certain circumstances, this isn’t the behavior you want. For developer projects, for instance, you often want the IDE to refer to projects by paths relative to the project or a particular location. Moving a file doesn’t mean changing the path, it means removing that file from consideration in the project.

I had already gone down this route with my now-abandoned Toolbox-based MacTADS. Writing your own framework does give you the freedom to, say, come up with your own, appropriate file classes.

But I do think that, apart from those special cases, I as a user would rather have the BBEdit behavior. So it distresses me (a) that Cocoa does not have a real file class, and (b) that I so often see NSString substituting for a file reference.

2 comments

  1. Joachim Bengtsson

    I agree completely. It *was* the standard behaviour of Mac OS 9, that the file is not its path, and that you could move it and all applications consider that when saving.

    Now, what is Mac OS X? Is it a Windows/Unix replacement OS? Or is it the next version of *Mac OS*?

    I’d say Mac OS is Mac OS, and that the behaviour should in many respects be the same in old and new Mac OS.

    It is also logical for anyone but a programmer — a window represents the contents of a file, NOT the contents of a file that occupies a certain *path*. A normal user should not have to consider path changes in his workflow.

    Okay, I think I made my point…

  2. Uli Kusterer

    Actually, this works in NSDocument-based Cocoa apps (try it in Workbench?). They will notice the file was moved, and when you save it will tell you it was moved to a new location, and ask you whether you want to save in the new spot or specify another location to save to.

    Trouble is, TextEdit is a rather old app (either early Rhapsody days, or maybe it’s even the original from NeXT) and doesn’t use NSDocument.

    So, don’t worry, the schism is getting smaller. At least a little 🙂