Big warning to all AppleScript users

I have never seen this before and it surpise me deeply, lucky me I didn’t have any imported files.
I was able to run AppleScript to use the comand save to remove every files in the desktop folder. Without any warning…

How is that possible that save command could become delete… as I said before there is a serious bug in… So I do not recommend anyone to use it for AppleScript.

Do you have a sample script so we can see what you did?

I do not have any copy of that script but…

  1. Make a reference to mailbox for your account
  2. Get the messages of whoose message that contain mail attachment
  3. Get reference to mail attachment
  4. save

The last step I used (path to desktop), I thought the reference (mail attachment) already had a filename so I thought it was enought to use (path to desktop). The reference was list so I also
tried item 1. I got the script running for almost 10 second. I thought for a second that is strange
and later realized that every file I had in desktop folder was gone.

More probably an error in your script, not in the save method.

It was the save command inside the tell block of that did it. The code before it was a variable to get name of mail attachment (string).
No matter what a user do in any tell block of AppleScript shouldn’t have privileges to remove files and subfolder inside a folder. Why do we have checks if a folder or file do excists if there are way to ignore it. Nothing of my code in AppleScript make it possible to delete every file and subfolder of some folder.

Sure, my code was wrong, but 99.9999% of whose times I get a error… but in this case it didn’t and for me that is a bug.

And if you did a delete in tell block of Finder it will end-up in the bin. It means that removes files of desktop folder include all subfolder and I was not able to recover anything. How is that possible if that is not a bug but instead a user who find a way with some AppleScript code to do it. do not have any privileges what so ever to do something like that. have privileges to do something like that.

It would be nice to post the actual script you ran so others can debug to determine if it is indeed a bug in AppleScript or your script.

If a AppleScript is executed without error. And do things that it shouldn’t do. It’s enough for me to consider it a bug. If the code should return a error but do not is enough for me to consider it a bug. And other people who use Monterey had problem with save command.

This topic was to give user an alert what happen to me. I do not have more to say on this.

And I will not ‘try’ to reproduce a bug to prove my point.

Hi @Fredrik71.

Thanks for your intention to warn others of a potentially destructive bug. But robertfern and chrillek, who’ve taken an interest in your post, are right. If you can’t or won’t show in detail what the script was doing, and no-one else has so far encountered the same problem, your warning’s of little help.

It sounds as if you were trying to save the attachment to your desktop. The save command’s in parameter requires the complete path for the saved file, not just the path to the folder where you want it to go. If you just used (path to desktop), the save will have saved the file with your desktop folder path, thus overwriting the folder. This isn’t a bug, but a misunderstanding of the probably poorly explained dictionary entry. The paradigm is that you save data in (or to) a file, not a file in (or to) a folder.

I hope this solves both the mystery and the problem. :slight_smile:

1 Like

You may be right, Thanks
So the reality is (for me) there is no protection if a AppleScript user (me) do something wrong or missunderstood the dictionary. And who knows what will happen if that was ‘home folder’ instead. Bug or bad implementation… sometimes they go hand in hand.

And if a save command need a reference to an file and got folder instead wouldn’t it be error. Folders and Files is different things and when we think they are the same its something wrong with the implementation. If the argument is ‘user missunderstood’ and thats why it happen doesn’t make it more safe for anyone.

The Desktop folder is protected for delete, but rewrite the entire folder is possible with not warning at all.

ls -ale show the group that Desktop folder belong to.
drwx------@ 9 f.gustafsson.user staff 288 Mar 12 17:18 Desktop
0: group:everyone deny delete

Lets me say this, I’m not angry but I’m very disappointment that this is possible.

After reading the latest posts I think I finally understand the issue you encountered.

So yes, IF you by mistake specified an existing folder path instead of a file path as a result of which the entire folder got overwritten, then I would also consider it a severe bug. If you can reproduce it then I think you should report it to Apple.

I made a feedback to Apple… and describe the situation.

Though I can understand that you’re disappointed, I doubt that Apple will do anything about it. This is clearly a user error. Like when you type rm -rf * in Terminal while your current folder is ~/Desktop. The fact that save overwrites folders is well known:

Make sure you specify a file, not a folder! If you put a path to a folder after the in option, AppleScript overwrites that folder completely. And if that folder were your desktop, the script would instantly trash your Desktop folder and every file inside it, leaving your desktop files as mere memories.

The scripting dictionary for the Standard Suite clearly says, “[in: file] : The file in which to save the document.” Not “the file or folder”.

I understand what you mean, but I do not agree. If the save command expect a file and get a folder it should return a error. That is exactly what NSFileManager class does. Why would it be different in AppleScript. if Apple’s framework do not allow it. It doesn’t matter if its a user error when implemintation allow it to happen. And when did Apple overse the specification that is more 20 years old. When nobody care about security.

Would you also consider the command make new folder to overwrite a excisted one to be possible.

Save command is different from remove command. And that is not what happen. Desktop folder is protected folder from delete. Meaning you couldn’t remove it from AppleScript or FileManager class. And when you are talking about unix command mkdir could not make a folder with name Desktop in the home folder. I wonder why if your claim it is a ‘user error’ but maybe you think mkdir should allow it then.

The dictionary also say it could only save document and window. When did we define documents to be folder. A document is a reference to a application that contants content. This content could be saved to specifict format. Thats why it never could be a folder becouse a document is a file. And when a software do not know the different between a folder and file its a implemination bug.

Because AppleScript was there long before NSFileManager. And because it’s a loosely typed language based on messages (not on methods as the ObjC/Swift frameworks). And because there might be apps which do The Right Thing when save is passed a folder.

It can’t if the folder is already there. If it isn’t, it can (which makes sense, I guess). And my example was actually rm, not mkdir. There are a lot of possibilites to shoot yourself into the foot, and a scripting language will only protect you against some of them. You can easily run a shell command from AppleScript than does very bad things to your files …

Because you passed a folder instead of a file, and because the behavior is well documented since ages. Which is not to say that it is a nice behavior. But the save command might be related to the NSDocument’s similarly named method. Which allows saving to a package, and a package is just a glorified folder.

I can assure you that Apple is not going to change anything about this. Never. They’re simply not interested in scripting anymore.

If Apple do change they will not tell anyone… and that could be the same to think ‘they will not do anything about it’. The problem many times is not to report a bug its when the user do not get any feedback in return. Any software developer properly know they need users to find bugs… and when people start to thing ‘they will not do anything’ it also means the bug is still there.

And it would be impossible for Apple’s engineers to do anything without knowing.

Maybe it takes 100 times of same complain before a manager do anything. That is the life when people do not share the same experience. And still some do not give up when others do. The problem is when companies start to ask why custommer no longer care its to late. To care about something also means we like to have something back.

that’s very true

And it become more clear when Finder define Folder and File as 2 different thing.
Specially if you do something like this

tell application "Finder"
	set thePath to (path to desktop)
	set thePath to (thePath as text)
	set thePath to file thePath
end tell

The reason the below script works is becouse ‘file’ is a document file that do exists.

tell application "Finder"
	set thePath to (path to desktop)
	set thePath to (thePath as text) & "SomeFileThatDoExists.txt"
	set thePath to file thePath
end tell

So iif the argument still are its a ‘user error’ when I guess the standard ot implemintation is all over the place with different ideas how it should work.

I believe that I am on the receiving end of this script behavior, although I hesitate to call it a bug; most saves are functionally equal to delete, unless otherwise specified. I was attempting to download attachments from Mail to the desktop, when I noticed folders disappearing; at first, I thought the script was resource intensive and producing a graphics glitch. As the full horror dawned on me, I mashed the power button to force quit the machine, but several GBs of data was lost forever, and it was entirely my fault for not specifying a file name.

1 Like

saves are functionally equal to delete

If a method couldn’t write data of a class of document file to other class that is a folder. If that was possible . Then I guess it wouldn’t be different to say. We allow to add variable of type string in a array. The array will remove or replace everything that was there before with only 1 item. Why is that not allowed. Because add method do not do same things as remove or delete a object in array. When a program allow this to happen the implementation is weak. If a method is allowed to write or over write a excited object. We also have to check if the class is the same.

Document file and Folder is 2 different classes in AppleScript.

It would be a good to use a check. So I made this…

use framework "Foundation"
use scripting additions

set thePath to POSIX path of (path to desktop)

if isFile(thePath) then
	log "do something with my file"
end if

on isFile(thePath)
	set theURL to current application's |NSURL|'s fileURLWithPath:thePath
	if theURL's hasDirectoryPath then error "The URL is a directory."
	return true
end isFile