While better than Lion's behavior, the lack of a true "Save As..." in Mountain Lion frustrates me. I never really saw anything wrong with the old style Autosave feature, where a temporary file gets saved periodically until you close the original file. I liked being able to edit a document and then retroactively apply all changes since the last save to a new file with a different name and location from the old file.
This is what's wrong with the "Duplicate" command, which, when it duplicates the file, includes all the changes since the last save. This forces the user to be prescient about what sorts of changes they may want to make to the file at some point in the future, whereas the old "Save As..." helpfully allows you to move all your recent changes to a different file. Unfortunately for most Apple applications, you are stuck with the new behavior. However, for TextEdit, there appears to be a way to revert to the software's Autosave and "Save As... " to that used by computers since the dawn of time.
In this hint I described how to turn off the auto-save feature for an application, which at least in TextEdit causes the true "Save As..." menu item to re-appear in the File menu and enables the Command-Shift-S shortcut to act as the real "Save As...," not "Duplicate."
When doing this however, there was one problem: the new sandboxing "feature" of OS X does not allow the old auto-save feature of TextEdit to make changes to the document's working directory, so you get annoying pop-up error messages every time TextEdit tries to make the Autosave file. Here how you can fix that.
WARNING: We will be replacing the developer's code signature for TextEdit in this hint. If you have qualms about disabling security features on your computer, stop reading here.
First, open a Terminal window and make a back-up of the application, in case we break something:
cd /Applications
ditto TextEdit.app TextEdit.backup.app
Now, we're going to use codesign to force (-f) the application to use a alternate signing identity (-s). The one we'll use is the dash (-) sign identity. This means the code will use an ad-hoc signing identity, which supposedly means that significant restrictions apply (see the man page for codesign ), but it does seem to allow TextEdit to write to a user's directory so it seems like in this case it's significantly unrestricting the app's permissions. Note that when you do this next step, it will reset the preferences for TextEdit. Also note the second dash after the dash-s, "-s-":
sudo codesign -f -s- TextEdit.app
The normal way to disable the new auto-save is the following:
defaults write com.apple.TextEdit ApplePersistence -bool no
But I couldn't get that to work. The only thing I could think of to do was get rid of the lockfile (not sure this part is needed?) and then copy TextEdit's .plist file to a directory where I could write to it, and then copy it back. Note that in this next part, I am putting a copy of the .plist lockfile and the .plist itself into root's home directory (/var/root) before doing things to them:
sudo mv /Library/Preferences/com.apple.TextEdit.plist.lockfile /var/root
sudo cp /Library/Preferences/com.apple.TextEdit.plist /var/root
sudo cp /Library/Preferences/com.apple.TextEdit.plist ~
cd ~
sudo open com.apple.TextEdit.plist
Change ApplePersistence from YES to NO. Save, and go back to the Terminal Window.
sudo mv com.apple.TextEdit.plist /Library/Preferences/
That's it! Now go enjoy your favorite text editor behaving the way it should be. This trick won't work for any other applications (e.g., Keynote); the "Save As..." menu item doesn't reappear when you disable the ApplePersistence.
[kirkmc adds: I haven't tested this. The warning at the beginning should be sufficient for anyone squeamish about trying something like this.]
Mac OS X Hints
http://hints.macworld.com/article.php?story=20121210183341971