Is there a way in UEStudio (ver13) to encrypt the automated backup files? So, all of my automatically backed up files will be encrypted, but not the original.
Thanks
Dan
Thanks
Dan
No, it does not have this functionality.
You would need to submit a feature request to IDM by email.
As a workaround for now, I would suggest using a TrueCrypt volume or perhaps use Window's built in folder encryption, and point UEStudio to that folder to save all the backups. There is really no reason to keep a backup file in the same path as the original file. It just clutters the path.
I use a version backup on save (Advanced->Configuration->File Handling->Backup: Version Backup). Format: $b$p$n($c)$e
That format of the version backup will save F:\Documents\test.txt
as X:\uebackuppath\F\Documents\test(#).txt
where X:\uebackuppath\ is the Default Backup Directory for UE, and # is the incremental save number for multiple versioned backups. You may prefer to save other information there, but this works pretty well for me.
I use a bit of an odd method to open UEStudio, personally, which allows me to handle such issues.
I have written a small utility that is launched in place of UEStudio, anytime UEStudio is called to be opened by the system. What it does is the following:
As the TrueCrypt and volume is not automatically dismounted when I exit UES, if I want things to remain secure, I must manually dismount. Not difficult to do, but I generally keep it open for as long as I am working at my desk. If I step away for lunch or whatever, I dismount the TrueCrypt volume after closing UEStudio, if open.
Since it only has to mount the volume the first time it is run (until I manually dismount), then after the first run, starting UES is actually much faster than starting UES normally, if UES is already running, because this much smaller program is loaded and passes command line parameters to the running copy of UES instead of having to launch a new instance of UES, pass parameters to original copy of UES, then close the new instance.
All my backup files are configured to be saved on the TrueCrypt volume, so that they are always encrypted. The file originals that I am working with may or may not be encrypted, depending on the sensitivity of the file, but backups are always encrypted as a safety net.
Temp files, which can also be a security concern, can be routed to the TrueCrypt volume, but this is trickier. You need to change the environment variables TEMP and TMP, but ONLY for UEStudio. This is why UEStudio needs to have a launcher when you do these things.
You would need to submit a feature request to IDM by email.
As a workaround for now, I would suggest using a TrueCrypt volume or perhaps use Window's built in folder encryption, and point UEStudio to that folder to save all the backups. There is really no reason to keep a backup file in the same path as the original file. It just clutters the path.
I use a version backup on save (Advanced->Configuration->File Handling->Backup: Version Backup). Format: $b$p$n($c)$e
That format of the version backup will save F:\Documents\test.txt
as X:\uebackuppath\F\Documents\test(#).txt
where X:\uebackuppath\ is the Default Backup Directory for UE, and # is the incremental save number for multiple versioned backups. You may prefer to save other information there, but this works pretty well for me.
I use a bit of an odd method to open UEStudio, personally, which allows me to handle such issues.
I have written a small utility that is launched in place of UEStudio, anytime UEStudio is called to be opened by the system. What it does is the following:
- Check to see if an instance of this utility is already running in background. If so, pass filenames to UEStudio and exit. If not, continue...
- Check to see if a certain TrueCrypt volume is mounted. If not mounted, it asks for the password, then mounts the volume.
- Set Environment Variables TEMP and TMP to point to a temp path on the TrueCrypt volume. Since this utility will be launching UEStudio, then these values will only be used by UEStudio, and will be removed once this program exists. That means this launcher program has to remain resident in memory, hiding until UEStudio is closed.
- Check to see if UEStudio is already running. Any command-line flags are interpreted, and depending on whether configuration is for "open in new instance" or "existing instance", it will either pass a file to the already open UES or open a new instance of UES with that file.
As the TrueCrypt and volume is not automatically dismounted when I exit UES, if I want things to remain secure, I must manually dismount. Not difficult to do, but I generally keep it open for as long as I am working at my desk. If I step away for lunch or whatever, I dismount the TrueCrypt volume after closing UEStudio, if open.
Since it only has to mount the volume the first time it is run (until I manually dismount), then after the first run, starting UES is actually much faster than starting UES normally, if UES is already running, because this much smaller program is loaded and passes command line parameters to the running copy of UES instead of having to launch a new instance of UES, pass parameters to original copy of UES, then close the new instance.
All my backup files are configured to be saved on the TrueCrypt volume, so that they are always encrypted. The file originals that I am working with may or may not be encrypted, depending on the sensitivity of the file, but backups are always encrypted as a safety net.
Temp files, which can also be a security concern, can be routed to the TrueCrypt volume, but this is trickier. You need to change the environment variables TEMP and TMP, but ONLY for UEStudio. This is why UEStudio needs to have a launcher when you do these things.
Hi rhapdog!
You wrote a very interesting post.
I'm just wondering about the reason to keep the launcher application resistent in memory as long as UEStudio is running.
Windows creates a copy of the current environment table for every Windows GUI application started. Therefore Windows creates a copy of the environment table also for UEStudio. What is changed in the environment table of the process starting UEStudio does not result in updating the environment variables in the environment table for UEStudio. Also closing the process starting UEStudio does not result in making any changes on the environment table for UEStudio. This behavior in environment table management by Windows can be verified very easily.
You wrote a very interesting post.
I'm just wondering about the reason to keep the launcher application resistent in memory as long as UEStudio is running.
Windows creates a copy of the current environment table for every Windows GUI application started. Therefore Windows creates a copy of the environment table also for UEStudio. What is changed in the environment table of the process starting UEStudio does not result in updating the environment variables in the environment table for UEStudio. Also closing the process starting UEStudio does not result in making any changes on the environment table for UEStudio. This behavior in environment table management by Windows can be verified very easily.
- Open a command prompt window.
- Execute the commands
set TEMP=Directory of your choice
set TMP=Directory of your choice - Start UEStudio by entering full program name.
- In UEStudio use Advanced - DOS Command and execute the command set.
- By default the output of a DOS command is captured to a new document window and you will see there TEMP and TMP with the path you entered before.
- Back in the command prompt window, use the two set commands once again, but with a different directory as before.
- Switch back to UEStudio and execute once again the DOS command set with output captured. You will see again the same output as before as for UEStudio the values of the environment variables TEMP and TMP have not changed.
- Start a second instance of UEStudio with using /fni parameter.
- Run in this second instance of UES also the DOS command set and look on captured output. You see TEMP and TMP with the directory path set just before in the command prompt window.
- Close the command prompt window.
- Run a last time in both instances of UES the DOS command set and you see on the captured outputs that TEMP and TMP have still there values as set immediately before starting the instance of UEStudio.
Mofi,
Thanks for the info. I probably initially did it that way because I reused code I wrote as a launcher for portable applications, where cleanup is needed afterward, such as removing registry entries and storing them in a .reg file for the next time the program is used, or clearing out the AppData and moving it to a local portable folder after the program closes, etc. It's been so long since I really worked with the environment variables outside of portable app launching I have forgotten more than I learned.
One of the things my launcher does that I didn't specify above (as I feel it was unnecessary and very few users could make use of it) is that the launcher also copies the AppData directory to a RAM Drive, and uses a RAM Drive for the TEMP. At the close of UES, AppData has to be copied back from RAM to the HD. This also lessens disk read/writes which can, during a long session, increase performance when using a slower drive, or, if using a SSD, can increase the life of the drive. However, you need a lot of extra RAM that the system won't be using to do this. Since I bought my new system, I've never used enough RAM to prevent me from having a minimum of 12GB free at all times (except when using AutoCAD 2013), so a 12GB RAM Drive isn't any big deal for me.
Thanks for the info. I probably initially did it that way because I reused code I wrote as a launcher for portable applications, where cleanup is needed afterward, such as removing registry entries and storing them in a .reg file for the next time the program is used, or clearing out the AppData and moving it to a local portable folder after the program closes, etc. It's been so long since I really worked with the environment variables outside of portable app launching I have forgotten more than I learned.
One of the things my launcher does that I didn't specify above (as I feel it was unnecessary and very few users could make use of it) is that the launcher also copies the AppData directory to a RAM Drive, and uses a RAM Drive for the TEMP. At the close of UES, AppData has to be copied back from RAM to the HD. This also lessens disk read/writes which can, during a long session, increase performance when using a slower drive, or, if using a SSD, can increase the life of the drive. However, you need a lot of extra RAM that the system won't be using to do this. Since I bought my new system, I've never used enough RAM to prevent me from having a minimum of 12GB free at all times (except when using AutoCAD 2013), so a 12GB RAM Drive isn't any big deal for me.
