@ifexist doesn't work anymore for scripts in latest beta

Help & Support
1

I just noticed that several of our backup scripts run in trouble now since the @ifexist modifier doesn't work anymore for scripts (as announced in the change notes of the latest beta version).

We have a lot of different script commands that stores some files to a target backup directory (specified by an alias /backup). Thus all scripts have an @ifexists:/backup in the header, which isn't interpreted in the newest beta.

Since this modifier was so nice and easy to use we really miss it and I simply want to let you know about that.

2

Please post an example script that is broken so we can see what you mean.

Also note that if you're combining @ifexists with @script, that will no longer work, as per the release notes. (It was never intended to work with scripts, and only sort-of-worked before due to a bug. There are better ways to do the same check within scripts, so if it's due to that it's easy to fix.)

3

[quote="leo"]Please post an example script that is broken so we can see what you mean.

Also note that if you're combining @ifexists with @script, that will no longer work, as per the release notes. (It only sort-of-worked before due to a bug. There are better ways to do the same check within scripts, so if it's due to that it's easy to fix.)[/quote]

I already fix that by manually checking the existence of the target directory within the JScript code itself. But anyway the modifier in the header is more simple and more obvious, thus I am worry that it is gone now.

Here is the old script (without doing the check in the JScript part):

@runonce 
@ifpath:*\*
@ifexists:/backup
@script jscript

function OnClick(clickData) {

	var command = clickData.func.command;
	var srcPath = clickData.func.sourcetab.path;
	var driveNumber = srcPath.drive;

	if (driveNumber > 0) {

		// retrieves drive label and serial
 	
		var driveLetter = String.fromCharCode(64 + driveNumber);
		var drive = new ActiveXObject("Scripting.FileSystemObject").GetDrive(driveLetter);
		var driveLabel = drive.VolumeName;
		var driveSerial = drive.SerialNumber;
		driveSerial = (driveSerial >>> 16 & 0xFFFF).toString(16) + "-" + (driveSerial & 0xFFFF).toString(16);
		driveSerial = driveSerial.toUpperCase()

		// builds destination path

		var bakPath = new String(DOpus.aliases("backup").path);
		var subPath = new String(srcPath).substring(3).replace(/\\/g, " # ");
		var dstPath = bakPath + "\\" + driveLabel + " {" + driveSerial + "}" + (subPath.length > 0 ? " # " + subPath : "") + "\\";
		
		command.RunCommand("xxcopysu.exe {sourcepath$} \"" + dstPath + "\" /CLONE /EC /WS /WE");
	
	} else {
		command.RunCommand("Play \"/dopusdata\\Sounds\\warning.wav\" QUIET");
		var dialog = clickData.func.Dlg;    
		dialog.message = "Drive meta data can not be retrieved for this path!";
		dialog.buttons = "OK";
		dialog.icon = "warning";
		dialog.title = "Warning";
		dialog.Show()
	}

}
4

So, this is exactly what Leo said they disabled in the beta on purpose.

But if you still really find it helpful to have those things taken care of at the top of the button with @ directives rather than buried further down in the main script code, you might consider a couple of alternate approaches:

1.) Move all of the script function code into a standard Opus User Command... do all your @ directive stuff like you were doing before, and then replace the script code with a call to the User Command where you move the script stuff to:

@runonce @ifpath:*\* @ifexists:/backup My_UserScriptCommand

2.) Same sort of thing, just a slightly different way - would be to implement the script stuff as a Script Command Add-In (as opposed to a User Command), which you could call the same way after the @ directive stuff.