.mrt and .sas backup files

I've noticed that there are .mrt and .sas backup files in the folder containing the settings for SA:

	Quote:
	SqlEditor.2019-07-15-09-18.mrt SqlEditor.2019-08-05-22-39.mrt SqlEditor.2019-08-12-10-18.mrt SqlAssist.2019-07-15-09-18.sas SqlAssist.2019-08-05-22-39.sas SqlAssist.2019-08-12-10-18.sas

When/why are they created and how do I disable/prevent creating them?

These files are store historical changes, in other words they are historical snapshots of the settings. After upgrades and generally if you want to undo some changes, you can use Import/Export feature to copy settings from the historical versions. The files are are fairly small. Are you concerned with them taking much space?

I'm not really worried about the space they take, though the .sas files do indeed take ~7MB each. But I have that folder versioned in a git repository and those files tend to get in the way. I could ignore them by extension but every once in a while I export a named backup of my .sas/.mrt settings and then I want .sas/.mrt files to be noticed by git.

Besides those files create a clutter there.

That folder isn't designed for a version control. I'm afraid the backup copies cannot be disabled and saved in a different folder. Their location is likely not customizable.
Maybe it would be better to use a separate folder with clean copies of version controlled files instead of using this one?

Most folders aren't. But this folder contains settings, tons of them. It's mostly the snippets I've developed over the years, but they are numerous, they are important, and I want to keep an eye on them.

The backup files could be helpful if they only contained the original version of what has been changed. But as far as I can tell they contain the whole backup of the original files and their names (date of change?) are meaningless to me. Having another folder with a clean copy of the relevant files could work, but you see, those backups are just a nuisance. Having to maintain that other folder would be an overhead (copy files there, copy them back upon a repo revert/pull, etc.). I'll skip. Dropping the backup files is much less of a hassle.[/list]

I'm thinking that you can have clean copies of the files you want in the source control be stored physically in a different folder and symbolically linked to matching names in %APPDATA%\SQL Assistant\11.0. In other words, replace them with symbolic links. Then you can version control that new folder and don't worry about other files created or updated in %APPDATA%\SQL Assistant\11.0, which wouldn't be "visible" in the other folder.

Please take a look at https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink

I'm familiar with the concept. I've been using that for quite a while for similar purposes until I've run into a couple of "irregular" apps with the better-safe-than-sorry behavior: save it to a temporary file and if that succeeded, rename it to the original name. At first, that might sound good, because you either retain the original file (in case the saving failed), have the changes in the temporary one (if the rename failed), or the save/rename succeeds, and everything is good. And it is until you find out that renaming a non-symlinked file to a symlinked one this way is going to break the link, and that without throwing an error, so it takes a while to figure out where your changes have gone and why the link gets broken.

So to prevent that from ever again happening, I started linking the folders the files were in instead. Actually, that's exactly how my SA settings are kept in the repo:

But if you say that SA is not one of those wicked ones, I'll make SA folder use the "old" method.

I think it's not. But...
That doesn't apply to the installation process. Every installation will result in the old file getting renamed with a date time suffix. New default file created and custom changes merged. In the end the old file with the symbolic link will be going to git, but that's not the file you need. So I doubt this idea would work well for you.

Doesn't matter. I'll ignore the files *.sas and *.mrt. I'll have to remember I've made and then forcefully add my named backups of those files. If there were an option to disable the backups, I'd go that way, but as there isn't, this is the next, least painful solution. I can live with it and I'm pretty sure you have more important things to do than introducing an option only one user wants.