Someone at macosxhints.com reported something that I think is worth repeating here. The poster used the following code with terrible results. If you decide to run this code (don’t do it!), make sure that the targeted folder is something that you can afford to lose. To test the code (don’t do it!), open a window in TextEdit, type something and then run the script using the path to a disposable folder (don’t do it!).
Warning: Do not test this code. If you hose something of value, it’s your own fault.
set source_folder to alias "path:to:folder:"
tell application "TextEdit"
activate
set the path of document 1 to source_folder
save document 1
end tell
I’ve tested this in Jaguar and got the same result that was reported by the victim. I don’t know which version of OS X he uses but the result is that the folder is replaced with a document! He is currently exploring options for recovering the contents of his Documents folder.
I consider this a bug and I was shocked to learn that a file could overwrite a folder so easily (at least with TextEdit). Did I mention that you shouldn’t test the code? No? Don’t test the code!
:!: Beware of faulty paths in TextEdit scripts :!:
While this could result in unexpected (and damaging) consequences (and why would you run it?), I don’t think it is a bug. The reason I say this is because TextEdit allows you to create .rtfd documents which are actually document bundles (“RTF with attachments (RTFD) document”) that can contain images and other resources and are, like application bundles, actually folders even though the OS treats them like files. To test this, follow these steps:
1 Make a new document in TextEdit 2 Drag an image into the document 3 Save the document on your desktop (the default name is “Untitled.rtfd”, let it be) 4 Run this script:
set the_file to (((path to desktop) as string) & "Untitled.rtfd")
return get info for file the_file
-->{name:"Untitled.rtfd", creation date:date "Monday, March 8, 2004 3:28:57 AM", modification date:date "Monday, March 8, 2004 3:28:57 AM", icon position:{0, 0}, size:5.5793E+4, folder:true, alias:false, name extension:"rtfd", extension hidden:false, visible:true, package folder:true, file type:"file creator:"displayed name:"Untitled.rtfd", default application:alias "Macintosh HD:Applications:TextEdit.app:", kind:"RTF with attachments (RTFD) document", short version:missing value, long version:missing value, bundle identifier:missing value}
So, in some ways, telling the app to save the file as a folder makes sense.
Man: It hurts when I do this. What should I do?
Doctor: Don’t do that.
The behavior doesn’t seem normal to me, even if it isn’t a bug. It seems that in previous versions of Mac OS (pre-X), a file could not overwrite a folder, and I feel that TextEdit should deal with this in a more user-friendly way. When I drop into the shell, I expect the unexpected, but not when using a consumer level app supplied by Apple.
I know that a lot has changed since the OS 9 days but this seems like such a simple way to do a royal hose job that I felt it should be mentioned. I’d hate to see another inexperienced scripter inadvertently wipe out a crucial folder when it could have been avoided by reading a post on a BBS.
Oh I fully agree about getting the word out, Rob, and I appreciate the warning, I just wouldn’t call it a bug or even bad behavior, just something of which to be aware.
If there was a pre-existing file and you told TextEdit to set the path of document 1 to the pre-existing document and the saved document 1, and, lo and behold, your old file was over-written by the new one, this would be acceptable behavior, right? Well, you have to understand that bundles are folders and can do the same thing to a whole directory. Acceptable behavior in my book but something everyone should be alert to and, for the most part, something to be avoided.
There are plenty of things that we can do to really screw up our systems via AppleScript (or even on our own though permissions and the Finder try to save us from ourselves). Perhaps we should start a “Do Not Code” list of things to avoid–or to be on the lookout for in scripts from unknown sources which may have malicious intent.
Malicious intent was at the heart of my concern, along with sloppy, uninformed coding. If, prior to today, I had inspected a script that contained the code from my first post, I probably wouldn’t even have given a thought to the fact that it could wipe out an entire folder without asking and without any indication of the possibly severe consequences. I know that this is the result of my ignorance on the topic of TextEdit bundles (thanks for explaining) but I imagine that I’m not alone in being surprised. Some things raise red flags and some don’t. This simply wouldn’t have raised a red flag for me, a cautious person/scripter.
While a noble idea, I don’t know if a list of warnings is practical since there can be a legitimate use for every command that’s issued in a script. In the end, users would still need to be fairly knowledgeable to make a sound decision.
