We're coming up on the end of the AppleScript.

			-- format file name to delete
			set l_file to v_destination_base Â
				& (extract string l_file from (v_source_base_length + 1))

Remember that l_file contains the file specification to delete next, which we get from l_filelist. But, l_filelist's file specifications point to the files that would be created in the destination if the backup were run. We need to delete the files in the source.

Here's where v_source_base_length and v_destination_base come in. We strip out the beginning of l_file, which will be the source portion, and substitute it with v_destination_base. Then the file specification will point to the correct file to delete.

			-- deleteFile command from Jon's Commands 2.1
			deleteFile l_file with unlocking without safety net
			
		end repeat
	end if
	
end deleteSyncFiles

The deleteFile command I got from Jon's Commands 2.1, a nice package of random AppleScript commands. The command will delete the file (or folder), unlocking it if necessary. The 'without safety net' clause means that it will delete folders that contain items. The backup command will list folders to be created, but not their folder contents, so there is no chance of this script deleting a folder and then trying to delete a deleted item, which would cause some sort of error.

You can also use Finder commands to delete the files. You do have to remember to unlock locked files and actually empty the Trash, and that may delete other items in the Trash that you don't want deleted yet. The deleteFile command is much cleaner: point it to a file and that file is gone, without changing anything else.

We close the loops and end the procedure. It is called like in the following example:

deleteSyncFiles("ATA_02:Ftp", 6, "Jennifer_Data:Ftp", "Jennifer_Data")

Note that position 6 of "ATA_02:Ftp" is '2', and we start replacing up to v_source_base_length + 1, which is ':'.

So how can the script be improved? Like any other piece of code, it doesn't have enough error handling. If a file to be deleted is missing, or some other command errors out, the script stops with an error message. Putting error handling code in a program is important, takes a long time, and is often not done sufficiently by programmers. Since this is a home use program I don't have any error handling code. If I find that certain errors do crop up, I'll modify the script then.

So that's it with this series of articles. Hopefully you got a good idea of why some things were done, and you got some examples that you can use in your own coding. Personally, I think AppleScript is too ambiguous and too scattered. There are several ways to format commands, all valid, and all too English like. That and every application has commands, there are lots of 3rd party command sets, and the basic AppleScript core is rather command poor. Just about every command is in an add-on library, with only a few standard Apple libraries included with the package. I just think it's hard to code when you keep having to remember the syntax and when the available commands are spread out over several packages.

That said, it's the easiest way to create scripts on the Mac OS. We're not talking about programs, but scripts that use programs to do their work. That's a pretty powerful idea that's been in Unix since its inception and that Windows has had for a while now. Although I may not like the format, I do like what I can do with the language.