Hi,
SETX will work, but only in future cmd.exe sessions. In this case, you would have to SETX the path variables, then start a new cmd.exe session so the variables can be read by SyncBack. To make a "clean" exit, you would need to do a "REG DELETE" to erase the variables. Also, if the cmd.exe session closed, the variables associated with the SETX command would still reside in registry. Not a "clean" way to end a program.
In v6, you could SET the path variables then start SyncBack within the same cmd.exe session. Once the cmd.exe session was terminated, the variables were deleted.
I understand what v7 now does, but I don't understand why you eliminated SyncBack's use of session variables. Allowing both would be a good compromise.
SETX will work, but only in future cmd.exe sessions. In this case, you would have to SETX the path variables, then start a new cmd.exe session so the variables can be read by SyncBack. To make a "clean" exit, you would need to do a "REG DELETE" to erase the variables. Also, if the cmd.exe session closed, the variables associated with the SETX command would still reside in registry. Not a "clean" way to end a program.
In v6, you could SET the path variables then start SyncBack within the same cmd.exe session. Once the cmd.exe session was terminated, the variables were deleted.
I understand what v7 now does, but I don't understand why you eliminated SyncBack's use of session variables. Allowing both would be a good compromise.