Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Be aware of possible data loss with TextEdit's Save dialog Apps
This exercise is intended less as a hint, though there is one included, than as a demonstration of a potentially destructive OS X behavior that pre-OS X Mac veterans may find shocking.

Part I.

This applies to Cocoa Save dialogs in general, but the behavior of TextEdit's dialog is particularly suited for demonstration purposes. Read this entire section before proceeding. First, create a folder on your Desktop, name it MyImportantStuff, and put some copies of files or folders inside (but seriously -- do not put anything important in there!). Next, launch TextEdit, choose Format > Make Plain Text (assuming yours is set to Rich Text as default), and type a few words into the document. Then choose File > Save. In the dialog, give it the name MyImportantStuff, choose the Desktop as the destination, and make sure the If no extension is provided, use .txt checkbox is not selected. Finally -- and this is important -- hit Return twice quickly, simulating too much caffeine or low batteries in your mouse.

Congratulations, your entire MyImportantStuff folder has now been replaced with a single plain text file! Why did this happen? It happened because of the combined effects of Cocoa apps being allowed to overwrite a folder with a file (perhaps related to the need to create package type files like .rtfd), and the fact that Replace is the default option in the confirmation dialog.

Note that this behaviour is shamefully inconsistent with that of the Carbon Save dialog, which has the safer default of Cancel, and does not seem to allow a folder to be overwritten by a file under any circumstances. The pre-OS X Save dialog (eg. in apps running in Classic) is the most user friendly of all -- if a folder is selected, the Save button changes to Open, simplifying navigation.

You can, however, use this behavior to write executable shell scripts entirely within TextEdit...

Part II.

This is the token hint, with an application of a side-effect of Part I. Open a new plain text document in TextEdit, and enter the line of code below. If you are familiar with shell scripts, any suitable code will do:
osascript -e 'tell application Terminal to display dialog Hello World'
Choose File > Save, click the New Folder button, and create a folder named HelloWorld.command. Press Command-Up-Arrow, give the document the name HelloWorld.command, and hit Return twice. Double-click the resulting HelloWorld.command file in Finder, and it should open Terminal.app, which will display the friendly message.

What happened was that when TextEdit replaced the folder with a file, the file retained the executable bit from the folder. Not that you would want to, but you could create all of your shell scripts using TextEdit alone, never having to venture into the command line to chmod +x your scripts. Since TextEdit can create folders from the Save dialog, Info.plist files (which are plain text), and executable scripts, you could even create simple application packages (.app style wrappers for your shell scripts) using nothing more than TextEdit.
    •    
  • Currently 3.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[16,490 views]  

Be aware of possible data loss with TextEdit's Save dialog | 21 comments | Create New Account
Click here to return to the 'Be aware of possible data loss with TextEdit's Save dialog' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Correction in osascript
Authored by: googoo on Dec 15, '06 08:24:22AM
I think that you lost some quotes in your osascript commands. They should read as follows:

osascript -e 'tell application "Terminal" to display dialog "Hello World"'

Thanks for the hint

-Mark



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: boredzo on Dec 15, '06 08:40:25AM

Looks like part II is duplicated; there's a second copy of it above the "Part II" header.



[ Reply to This | # ]
Wierd Result
Authored by: garyp on Dec 15, '06 09:02:42AM

I tried the experiment, and noticed that the Save dialog popped up a clear warning that a file of the same name existed in the destination space, and would be overwritten. I went ahead and saved anyway, but the folder was replaced by a unix executable, not a plain text file! wtf?



[ Reply to This | # ]
Wierd Result
Authored by: SOX on Dec 15, '06 10:01:04AM

That's exactly what the hint is about! you get an executable.



[ Reply to This | # ]
Wierd Result
Authored by: DavidRavenMoon on Dec 15, '06 11:25:46AM

Just about any time you have a file with no type/creator codes, and no file extension, OS X will think it's a unix executable file.

I see this all the time with QuarkXPress files sent via email. Since the Mac version os XPress does not append the file extension, and the emailing stripped away the resource fork, you end up with a unix executable file.

By either adding the file extension, or type/creator codes, the file then changes back to a Quark document.

---
G4/Digital Audio/1GHz, 1 GB, Mac OS X 10.4.8 • www.david-schwab.com • www.myspace/davidschwab • www.imanicoppola.net



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: DavidRavenMoon on Dec 15, '06 10:07:25AM

The Cocoa file dialogs are dreadful in general. I think Apple really needs to redesign the Finder!!! It sucks.

---
G4/Digital Audio/1GHz, 1 GB, Mac OS X 10.4.8 • www.david-schwab.com • www.myspace/davidschwab • www.imanicoppola.net



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: talonwood on Dec 15, '06 03:10:45PM

If I'm not mistaken, I believe the Finder and Cocoa Save/Open dialogs are different things.



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: blgrace on Dec 15, '06 01:16:34PM

Now this was a really interesting Hint / warning .
Thanks - never noticed this behaviour.



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: hazkid on Dec 15, '06 02:51:31PM

Terminal says the .command file is not executable?

---
--|*~HazKid~*|--



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: mstolove on Dec 15, '06 05:52:37PM

This is nasty stuff. I think this should have been brought to OSX developers and/or security teams before being posted here.

I'm thinking an embedded "exec `rm -rf \*`" could cause some serious damage...



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: johnrchang on Dec 15, '06 09:06:43PM

This is only an issue with TextEdit, not with all Cocoa applications. See line 1632 of TextEdit/Document.m.

Anyway, this is not as horrible as you describe. TextEdit very clearly warns that a folder could be replaced: "A file or folder with the same name already exists in Desktop. Replacing it will overwrite its current contents."

One could argue that Replace shouldn't be the default button, but I've never had trouble with it. Actually, I hate how Finder, iTunes, etc. makes you click on non-default buttons and there's no keyboard shortcut whatsoever. If they did provide a keyboard shortcut, Return is not much worse, since most people don't think twice at familiar dialog boxes anyway.



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: Lou Kash on Dec 18, '06 09:25:04AM

command-R



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: starwxrwx on Jan 10, '07 11:54:37PM

When the dialogue box comes up there are acutally two defaults - one for the enter key (blue) and one for the space key (blue glow).

If you TAB around you can change which button you press (possibly only from space bar), without needing to resort to the mouse.



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: maczac on Dec 16, '06 05:22:09PM

While I agree that Cancel should be the default in the overwrite dialog box. Many of us use Default Folder and set the default to be replace, at least I know I do. Perhaps Apple did some research on this user interface and felt the risk was too low.

I find the creation of an executable in Part II to be scary though. Left me with that feeling, is it a feature or a bug?



---
zac



[ Reply to This | # ]
What does the Blue Glow mean?
Authored by: macgruder on Dec 17, '06 10:06:46AM

When I do this, I get to the dialogue box

Cancel [with a blue 'glow' around it]
Replace [highlighted blue]

Now if I hit the Tab, then

Cancel [plain button]
Replace [highlighted blue AND with a blue 'glow' around it]

So what does the blue glow actually mean?



[ Reply to This | # ]
What does the Blue Glow mean?
Authored by: type88 on Dec 18, '06 05:40:56AM

The blue glow indicates an option that can be selected by pressing the space bar. Saves a trip to the mouse.



[ Reply to This | # ]
What does the Blue Glow mean?
Authored by: starwxrwx on Jan 10, '07 11:57:21PM

And following up from that in some ways the default behaviour IS to cancel - because thats what the spacebar input defaults to (I know I always used to use the space as default button press)



[ Reply to This | # ]
What does the Blue Glow mean?
Authored by: nunulnul on Dec 29, '06 08:33:26AM

It means you have Full Access->All Controls turned on in
Systems Prefs->Keyboard & Mouse.



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: qrulf on Dec 18, '06 04:08:22AM

I must say that it is a bit horrifying that TextEdit allows a folder being overwritten by a file. Thanks for the explanation!

~ Jørgen



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: macnixer on Dec 18, '06 05:47:29AM

The steps explained here is like DUI. Don't do crime if you ain't have no time.



[ Reply to This | # ]
Be aware of possible data loss with TextEdit's Save dialog
Authored by: faquin on Dec 18, '06 12:22:11PM

This is exactly why they made Time Machine ;)



[ Reply to This | # ]