SD and Script Editor make second copy of folder

Before I begin, I should say that Script Editor shows the same behavior that I’m about to describe here, but I think I’m far more likely to see a fix (or some idea of how to fix it) by asking here.

I have an AppleScript application that runs a Wineskin wrapper of a Windows-based DOS emulator called vDos. That means that a program emulating DOS is running inside a program emulating Windows under OS X/macOS. I know that DOSBox can emulate DOS under OS X, but I have good reasons for using this alternative.

Anyway the AppleScript application is called vDosWP, the Wineskin wrapper is called vDos, and the “drive_c” folder in the Wineskin wrapper includes the directory /Program Files/vDosWP.

When I open the AppleScript wrapper in either SD or the Script Editor and make a change and then save, what sometimes (not always, but most of the time) happens is this:

A copy of the …/Program Fles/vDosWP folder gets created in the Contents folder of the AppleScript wrapper. This seems harmless, except that it adds 60+MB to the size of the application bundle, and I sometimes forget to remove the copy.

Is there anything I can do to prevent this from happening? The download is here:

https://www.dropbox.com/s/k40e323hagfg4l3/vDosWP%20Installer.dmg?dl=1

You don’t need to run the program (and it won’t start anyway unless you have some WordPerfect for DOS files installed elsewhere on your disk). You can see the effect simply by opening it, adding a comment or two, and saving it.

Not an urgent question, but I hope it excites someone’s curiosity who knows a lot more about this than I do

I’m not sure what’s happening. When you save a script in SD (or SE), a safe-save approach is taken where the contents of the original script bundle are copied into a new bundle. Only when the save operation is successful is the original bundle removed and the new bundle moved/renamed to take the original bundle’s place.

SD uses Unix hard links to create copies of all the files in your original bundle within the new bundle without having to actually duplicate them. I can only imagine that there is some problem with the vDosProgramFolder link. But when I try saving the script here, I see that the vDosProgramFolder link is removed (probably not a good thing). I’m not seeing the Program Files behaviour you describe.

Is the path that you’re saving to within your Dropbox folder?

If so, as a test, try the whole thing again saving to a path that is not within Dropbox and see if the problem still recurs.

Mark, Thank you for that - and you pointed toward an explanation. I first wrote this script in 2014, and I had forgotten some of the things it does.

First, about deleting the link to “vDosProgramFolder” - that’s something that the script does every time it runs, for this reason:

For my own convenience, and the convenience of users I wanted an easy-to-find link to the “vDos” folder on the emulated hard disk deep down in the resources. I couldn’t figure out how to create a relative symbolic link to this folder inside the application bundle –

…/Contents/Resources/vDos.app/Contents/Resources/drive_c/Program\ Files/vDos

– that would work as a link even when the application bundle was moved to another folder. So, instead, I made the script delete and recreate the link every time the program was run (lines 152+). That wasn’t a perfect solution (the link would be wrong if someone used the link before running the application after moving it), but it seemed to be better than nothing.

Anyway, I’ve now figured out the syntax that creates a relative link - but what still happens is this, though not always: Script Editor (and SD) (1) create the link to the folder and (2) make a copy of the folder. Both the link and the copy are created in the Contents folder of the bundle.

Is there some logic here that’s designed to guarantee that the contents of the link remain accessible? And is it somewhere deep in the OS, because the Script Editor and SD do the same thing? I’m asking only out of interest, because I don’t think there’s any urgent to need to fix what is basically a harmless error.