Why not allow the user to rename an open file?

It's odd that virtually all document editors still prevent the user from changing the name of the file they're working on. This is a shame, because it's a common user task.

A user may start writing a new document, save it under one name, and then as the document evolves come to realize that another name would be more appropriate. There's usually no good way to do this inside the application, so they struggle through workarounds like saving the file under a new name and then digging around in the file system to delete the file with the old name. The operating system usually doesn't offer much help either:

The main reason most applications don't support this is because most platforms don't make it easy—and the main reason platforms don't make this easy is because most applications don't think they need to support the feature. Alan Cooper vented about this problem in About Face, and it's still a widespread problem today.

There are a few applications enlightened enough to let you rename an open file. Microsoft Visual Studio, for example, handles this without complaint. Interestingly, Microsoft Word used to support this—but only in the Macintosh version years ago, before its user interface was realigned for consistency with the Windows version.

It's almost impossible to get problems like this fixed in an application, let alone the operating system. Unless customers complain about this, no one wants to tackle the problem—and by now most people have grown too used to working around the problem.

Comments

[peterchen]

How would one implement that?

I think (1) open-read-close (i.e. don't hold a handle to the file, or map it), and (2) some monitoring to detect the change (FindFirstChangeNotification?)

[Factory]

Is the dialog from Vista? In previous versions of windows they wouldn't even tell you which program was locking the file.

[Brian]

UltraEdit-32 (a very nice text editor) has this feature to rename an open file. It's incredibly handy, and I wish more programs had this. Technically it's very simple to code into an app -- just a simple dequence of save-as and delete. Since the program itself is performing the action there is no file-in-use mess to worry about.

[Jeff]

I'm not making excuses for application developers, but the fact that Windows doesn't support this makes their job harder. Mac OS X allows you to not only rename, but to move open files, without invalidating any open file handle.

[Michael Zuschlag]

I hate to get off topic, but why was it important for the Mac UI to be "realigned for consistency with the Windows version"? I can't see how that form of consistency benefits the users. In the rare cases that Windows users use a Mac, some may not discover the rename feature, and are thus no better or worse off than not having the feature at all. In cases of Mac users using Windows, they'll see the rename feature isn't supported and utter a curse on Microsoft, but they do that by habit anyway. Why penalize all Mac users when they're using Macs because of edge conditions that have mild consequences?

[Adrian]

Doing a Save As/Delete behind the scenes may, in some cases, be too simplistic. Save As will create a new file. As a developer, you'd have to be careful to copy the file attributes, creation date, and ACLs of the original file.

Most of the document editors I use allow renaming the file. Then again, I stay pretty far away from Office.

[kbiel]

I believe this is one of the problems that will be solved by WinFS. The problem is that MS has treated the file name/path as an immutable part of the file itself rather than a nice UI attribute. The Mac was able to support renaming and moving of open files, because the file name/path is only a metadata attribute of the actual file which is identified by a unique key.

The reason that developers don't support file renaming usually is because it is a lot of work in Windows. You have to close the open file handle, rename/move the file, open a file handle on the new file/path.

[Dustin Long]

Adrian said, "Doing a Save As/Delete behind the scenes may, in some cases, be too simplistic. Save As will create a new file. As a developer, you'd have to be careful to copy the file attributes, creation date, and ACLs of the original file."

Actually, that's not true
http://blogs.msdn.com/oldnewthing/archive/2005/07/15/439261.aspx

With regards to the post, I find it amazing that we're still stuck with the archaic DOS hierarchical file system in this day and age. It's the root cause of so many usability problems it's not even funny.

[Jamie Anderson]

Actually, you can rename a file that's in use. It just depends on how that file's been opened.

If you pass FILE_SHARE_DELETE when you call CreateFile(...), users are allowed to rename the file while it's being used. However, they can also delete it, which isn't a good thing.

The boffins at Microsoft should implement a FILE_SHARE_RENAME flag, which allows the file to be renamed while in use. This would allows renames, but would prevent deletions.

[Moz]

The oldnewthing like applies to something different - if you delete the file then rename a new file to the old name, tunnelling will help you. Creating a file with a new name and the same content has no effect.

FWIW TextPad has had this for a long time (and I use it a lot).

[bryan]

Well, I would not like to see this changed now. it would confuse people used to the old way of working. so basically you would want to add the functionality via another save entry on the menu. That however becomes problematic, how to phrase the menu item so it does not in turn confuse the user.

[RogerC]

It works again on the mac. You can also move the file around the filesystem.

I wouldn't worry about any changes confusing the user. Menus change to personalize to the user, and filesystem functionality is all too variable. A change for the better might be shocking to some, but the user would get over it. If my filesystem suddenly let me do this, I'm not sure I'd even notice that one more annoyance had gotten out of my way.