Renaming a file you are currently working in, why is this still not done?

Question

We've all experienced this: You open a new document inside an application such as Word, Excel, Textmate, or others. You work on it for a while and save it. Then you wish you could rename it. What do you do? You either click "Save As..." or exit the application, rename the file, then reopen it.

Why isn't there an established "Rename" option under the File menu in applications? The operation of creating a copy of the file and deleting the old version is not so complex, but we always task the user to do this instead of simplifying it as a menu item.

Answer 1

I think that the two main reasons are K.I.S.S. and Featuritis. It is harmful to have two actions that do virtually the same thing (Rename and Save As). And of the two I prefer to leave Save As because it's less dangerous and more useful. Without it, I effectively leave the user no way to create a copy from within my app - he must do it in the file system.

Answer 2

OK, here's the story on Mac OS X

As written in my other reply on Windows vs. OSX, I explained that OSX has the capability to detect renames or moves on disk based on a file's (and folder's) unique File ID.

And programs written in Cocoa, using the document based classes to manage opening and saving files represented in their own windows, this should all work unless the programmer screwed it up. And even Carbon apps get this right if they're written properly (i.e. following Apple's guidelines):

Apple actively wants every app to support that the user can, while a file is opened in an app, rename or move that file (on the same disk, i.e. volume), and the app should learn of the change and keep referencing that same file. A good example of this is that, on OSX, you can also rename a folder containing your file, and it should not cause problems (on Windows, it usually does!).

So, to answer your question: You can usually rename a file you're working on, only that this isn't working the way you like it to: Apple has never suggested to add a Rename command, and instead suggests to either (or both) offer a "Save As..." and/or a "Save A Copy As..." in place of your preferred "Rename", resulting in more freedom: Not only can you rename but also move the file to save this way. Adding another "Rename" would only lead to confusion, if you think more about it.

Plus, you can rename and move the file on disk in Finder, if the app is written properly.

Answer 3

This action is generally deferred to the filesystem's tools: from experience this is because files rarely need renaming.

It's preferable to reduce the complexity of menus, so it's probable that this feature isn't ubiquitous simply because there's not sufficient demand (that demand is inferred from data collected about users' behaviour through techniques such as in-application analytics, observation and questioning).

This feature is available in some feature-laden specialist tools, such as Notepad++.

Answer 4

Actually depends on the quality of the software. Good software supports it - like for example Coda. When I have a document open and I rename it from Finder or elsewhere - Coda gets a notification and automatically knows the new name of the file. Coda actually knows if I move the file I'm editing and so just keeps in open from the new location. It's all about software design...

Answer 5

Uh - major fail, this post. I found this question when browsing StackExchange questions and somehow assumed this was a Windows question. Turns out that TextMate is a Mac app :) Oh well, I'll leave it here anyways, so much information. Will write another on the actual question to clarify the points.

Look at Mac OS X - there, it's actually often possible to rename an open file, and the application will notice the change by updating the file name in the window's title bar.

The reason for not allowing the user to do this generally is that a program must be aware of the change so that it knows where to save the new version to. And there are two major reasons why this is not happening:

1. Most programs do NOT leave the document file open, locking it thereby to prevent modification by other tools in the meantime. But they usually should. They just don't because that's harder to maintain (to program). Most programs just load the file into memory, and create a new file in the old place when you Save.

   If the program would leave the file open (writable) and just write back to the open file in the end when it wants to save the changes, renaming, and even moving of the file on the same volume, would not cause any confusion - it would keep saving to the same file. However, that might not even be what the user wants: He might think: Oh, I want to move the existing file somewhere else or rename it so that when I save, I keep this older version as a backup. Therefore, people thinking of files as things getting recreated at Save, may not even like the method you propose in your question - it would irritate them because then they can't keep a backup any more by renaming the old file manually.

2. Now, to keep the user better informed what will happen if the user renames (or moves) the on-disk name, the program would have to learn of this change. On Mac OS X this is easily possible because it has capabilities that DOS-based Windows doesn't: The File ID: Each file, when created, gets a unique code. So, there's two ways to remember a file on OSX: By its path (folders) and name, or by its ID. And many apps on OSX, either because they're using "proper" frameworks (pre-written code that performs many standard operations for common apps) or because they follow Apple's well-written guidelines covering these topics, will use this feature to detect changes to the loaded file, and then adopt to it.

This means, that a Mac user is much more likely to know (eg. by experience) that he can move an opened file around or rename it and still get it updated when saving.

On Windows, where there are (or for very long haven't been) such ways for applications to detect a change in the loaded file's name, this mechanism is therefore not employable.

In summary, there's several things why this works on OSX but not on Windows (and Linux):

• While OSX has a long history of supporting this "feature", based on Apple's early experiements and resulting guidelines since the 1990s, Mac programd and their users are more used to this feature and can deal with it accordingly.
• OTOH, Windows (built upon DOS, a very very simply and inefficient file system compared to the Mac's HFS) has never taught programmers nor users to deal with this feature and so no one expect it, and might get confused if randomly some apps would start following this paradigm now.