Lost a script due to a bug!

OK, Here’s what happened to the best of my detective ability.

I had an applet that had been last opened in SD6.x and saved with debugging on.

When the app launched it opened in SD7. From there nothing happened. The script did not execute.

I turned off debugging and saved the script, and now the script file is empty. No text, not data. I tried running Recover Damaged Script but the applet is not active in the menu.

I’ll have to dig up the last version of the script, but it looks like the work I’d just done to it is lost.

So the steps to recreate would be:

Save an applet from SD6 with debugging on. Have SD7 be the default app for AppleScript. Launch the applet. When it opens in SD7, turn debugging off and save.

Ed,

What was the OS level you ran it with SD 6 and the OS level for SD 7. I makes me wonder if there could be some sandbox issue. Apple is trying very hard to force applications to run in their own little world and as the OS version moves up it seems like the OS is less tolerant to some outside process messing with it. If you can get another copy of the applet perhaps you can try it on the OS version you used with SD 6 and use that with SD7.

Bill

–>Mac OS 10.11.6 (15G1611)

If the OS was the same from you used it before and recently then that my idea doesn’t have anything to do with your problem. Unfortunately that was the only idea I had.

Bill

Twas the same. I’m holding off on SD7 debugging applets. Don’t want to lose work again! Took me about 45 minutes to redo what I had done.

I can appreciate the fenestration of loosing work. However, in order to resolve the problem you are experiencing I need to develop a reproducible test case. I’ve tried a few things here but so far I’m not able to reproduce this problem.

Regarding recovery, did Time Machine not help? SD5, 6,& 7 all save Versions compatible revisions to document files. If SD7 killed the file, previous versions of the document should still exist.

As with all beta software, I suggest making an explicit duplicate of any important document before letting Script Debugger 7 operate on it (though I’ve not had SD7 corrupt any document of mine throughout the development and testing process).

We don’t use time machine here at work, and what we do use never helps.

I did have previous versions. What I lost was basically the work I did on it for the two hours or so before the problem. (Took less time to do it over)

In this case I didn’t realize I’d saved it in debugging mode, and hadn’t planned to edit it in SD7.

FYI, the script was a droplet. It was activated by another script telling it to open a list of aliases. When this happens to a script saved in Debugging mode in SD6, the script opens and it stops on the first line of the script ready to start stepping. In SD7 the script opened and nothing happened.

I should have closed it, without saving. Instead I turned off debugging mode and saved.

The intent is for documents to be compatible across Script Debugger versions. And in fact, there have been no changes to the way scripts saved with debugging enabled are written and read for Script Debugger 7.

If this should happen again, you can try and use a new feature of Script Debugger 7: versions browsing. This does not depend on Time Machine, and uses the versioning provided by the macOS (presuming you are using a disk volume format that supports Versions). With the damaged document open, try the File > Revert To menu. This should let you move backward in time to a version of your document that has not been corrupted. Please see the Document Versions section of the Script Debugger 7 Release Notes for more information

Should this problem happen again, please immediately make a zip archive of the document and send it to us so we try and determine what happened to it.

One other rider: SD7 is designed for 10.12+. Although the beta runs under 10.11, it may well crash because of it.

I still had the bad copy of the applet, so I opened it in SD7 (which was not running), no text.

I tried File>Revert To menu. The only option was to browse versions. I selected that and SD immediately crashed. (Sending Crash Report, saved crash data if that would help)

Not sure if this makes a difference but I had moved the bad file to the desktop, before reopening it just now.

Will that versioning work on Scripts started on SD 6?

Here’s a link to the bad file: https://www.dropbox.com/s/vi6h9fpdjsgdda2/ProcessMarketRoundUpText.zip?dl=0

And another crash.

This time I opened a file I’d worked on this morning. I tried the File>Revert To menu.

Way cool, btw. Saw numerous versions of the script.

Click the close button on the script’s window in the version browser and crash.

Twice in a row.

That will happen if you’re not running 10.12 or later.

Dang. I’m stuck with 10.11 until our systems people bless anything newer. They get irked with all these new systems coming out so frequently.

Could take years.

Keep away from close buttons in the version browser.

I am running under 10.12 Sierra and tested “versions browsing” a lot. It is actually nicer than time machine. It is more responsive. Sometimes time machine can take an insanely long time before it becomes responsive. The worst I got out of “versions browsing” was siting around for 30 seconds before it responded.

I’m guess your work place won’t let you attach a drive to your Mac. You can use a small time machine backup disk by disabling the back up every where but one folder. But still time machine only backs up very so often.

When doing testing (Alpha or Beta) I name a program something like The “program #1” then I do a test, then save, go to finder and press command-d and rename the new file “program #2” and so on. Then I have a record of every attempt. Sometimes I get up to “program #78” or something but if I get an error I can go back and see what happened. Sometime a problem starts in say try 23 and then crashes in try 27. Once a person gets used to this it isn’t that big of a distraction. I put my previous versions in a separate folder and display the folder in list view sorted by last added. Then when the folder is expanded out you can see at what time each new version was used. This can sometime help identify when something unrelated to the testing happened and might be a cause for the problem I am currently having. When my testing is done I throw out all the old versions.

While I would not do important work with beta software this process would definitely add a significant level of protection to what you have now. If you use the method I described always make sure the oldest file goes in the folder and you are using the newest version. Always save the SD document before making a Finder copy. That’s the only 2 things you have to physically do. You can use a cell phone and have an alarm go off every 5 minutes. Then every 5 minutes you get a back up. Just turn down the sound enough on the phone so the continuous alarm sound does not bother other people. Then your back up system turns into a cell phone you already have and small amount of periodic Finder work which is free.

If I’m feeling really lazy I put the file in a folder by itself and just do a command-D on the most recently created file and let Finder sequentially rename the file. Finder names it the file name with “copy” appended to the name and after that it just keeps incrementing the number appended. It can get up to insanely big numbers it appends without having a problem.

But if you willing to put just the single script file you working with in a folder a simple Applet can can do a cheap (free) backup. The Applet checks a time interval set by the user for the file with the latest date in the folder and if there has been changes since the last backup was made it automatically make a copy of the file with the latest modification date. It also checks to make sure the file with the latest modification date is not an autosave file. The current script does not back up autosave files. The is specifically designed to automatically back up AppleScript files. It not a general case backup script.

This is a pretty simple script so if there is something you don’t like it can be modified. The Applet is called “The Applet”. I made a zip archive of the applet and uploaded it to this post.

The property TheBackupFolderPath is where you would enter the path for the folder where your folder with the single script file is located.

FiveMinutes is a property that holds the number of seconds in five minutes.

OldestDate is a very old date basically back when Apple first started. It is used to start a loop that finds the latest modified date for a file in the the folder.

TheBackupFolderPath is the path to the folder to back up.

Here is the script

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

-- property FiveMinutes : minutes * minutes
property FiveMinutes : 10
property OldestDate : date "Tuesday, January 1, 1980 at 12:00:00 AM"
property LatestDate : OldestDate
property TheBackupFolderPath : "Bills second iMac HD:Users:bill:Desktop:untitled folder 3"

on IsAutoSavedFile(ThePath)
	local ThePath
	local TheFile
	local EndOfFileName
	
	-- This handler returns true if ThePath points to an Autosaved file
	tell application "Finder"
		
		set TheFile to item ThePath
		set ThePath to TheFile as string
		tell application "System Events" to set NameExtension to name extension of file (TheFile as string)
		set EndOfFileName to "(Autosaved)." & NameExtension
		if (name of TheFile as string) ends with EndOfFileName then
			return true
		else
			return false
		end if
	end tell
end IsAutoSavedFile

on FindLatestModifiedFile(ThePath)
	tell application "Finder"
		set TheFolder to item ThePath
		set FileList to files of TheFolder
		
		set NewestFile to missing value
		set OldestDateString to "1/1/1980"
		set NewestDate to OldestDate
		repeat with TheFile in FileList
			-- set CDate to creation date of TheFile
			set ModDate to modification date of TheFile
			if (ModDate > NewestDate) and not my IsAutoSavedFile(TheFile as string) then
				set NewestFile to TheFile
				set NewestDate to modification date of TheFile
			end if
		end repeat
		NewestFile
	end tell
end FindLatestModifiedFile

on idle
	tell application "Finder"
		set TheFile to my FindLatestModifiedFile(TheBackupFolderPath)
		if (modification date of TheFile) > LatestDate then
			-- There are unsaved changes
			set TheLatestFile to TheFile
			set LatestDate to modification date of TheLatestFile
			duplicate TheFile to TheBackupFolderPath with exact copy without replacing
		end if
		return name of TheFile
	end tell
	return FiveMinutes
end idle

on run
	
	
	
end run

The applet.app.zip (58.8 KB)

Bill

None of that would have avoided this. One of the first things I test is setting the default script editor. After I did that, a script that runs automatically but had been saved in debugging mode opened in SD7. Turning off debugging and saving the script is what killed it.

I thought the problem was you didn’t have a back up to go back to. The solutions offered would allow you to back and get what was lost no mater what Script Debugger did. But ok if this was no help I won’t suggest any more about back up. Apparently I don’t understand what the actual problem is. Sorry.

Bill