I’ve found ~/Library/Application Support/Sublime Text/Backup and is taking about 500MB in space.
Inside, among others, a bunch of subfolders each taking exactly 24MB of a Clang plugin which I’ve used once and has been disabled since then.
What is this folder used for?
This is created by Package Control. Maybe there should be a setting to prune backups older than, say, one month or so. But anyways, the stuff in there can be safely removed.
Obviously for if an upgrade fails, or overwrites your customizations, or something like that.
If the upgrade fails, we run the upgrade again, ou re-install the broken plugin, no need to collect outdated versions in the disk.
Why don’t we backup only customization files?
Sorry for resurrecting, but the answer is still unclear. What is the exact purpose and the use cases of the C:\Users\User\AppData\Roaming\Sublime Text\Backup folder? And how do we know when its the time to use something from it?
I need to understand this because I frequently back up my AppData\Roaming\Sublime Text subfolders to Dropbox. This way, in case of a disk-related emergency, I can restore all my settings and even my session (including recently opened files). So, I’m wondering whether I should also back up the Backup folder.
Or, let’s say, if someone asks me to share my Sublime setup along with all the packages and settings and so on, should I also share that folder or not?
When package control does an update of a package that is represented by a folder in the Packages directory (as opposed to a sublime-package file, which are installed in Installed Packages instead), it needs to remove the folder in order to place the new update.
When it does that, it moves the content into the backup folder in case you need to get it back.
You’d notice after a package upgrade that suddenly the package doesn’t do what it used to do previously. Most frequently that is likely because you hand modified files in the package in order to customize it and you notice that your customizations are now lost.
Hm… I was just delving into the OverrideAudit package docs* (found this package when I was reading this topic), and its instructions seem to suggest kind of opposite:
When an override is present, Sublime Text uses it unconditionally, ignoring the original package file completely. If the author of the package updates it, you’re not told. This could make you miss out on important new features or bug fixes.
Has there been a recent change in Sublime’s behavior in this regard?
* Omg, I’ve just realized that you are the author of that site (with the OverrideAudit package), and you also contribute to almost every question on this forum! It’s awesome to have such an active community member. Take my greatest gratitude!
It hasn’t changed, but there is a bit more nuance to it than is described above.
Imagine a hypothetical package named Bob ; the package could be installed in three different ways (including two or even all three simultaneously):
It could be inside of the Packages folder that exists inside of the Sublime Text installation folder, next to the binary as a file named Bob.sublime-package. In that case, this would be a package that ships with Sublime and is just always installed for everyone.
It could be inside of the Installed Packages folder as a file named Bob.sublime-package ; this could be put there manually by you or installed by Package Control.
It could be inside of the Packages folder as a folder named Bob, within which is the contents of the files; this also could be put there manually by you or by Package Control.
Each of the layers can be overridden by the layers that follow it; for example:
The Python package ships with Sublime Text, but if there is a Python.sublime-package file in Installed Packages, then Sublime will ignore the version of the file it ships with and use the other one instead
While loading the Python.sublime package file (from either location), if Sublime notices a Packages\Python folder. it will load those files too. If any of those files have the same name as a file inside of the sublime-package file, Sublime ignores the version inside of the sublime-package file and only loads the other one (i.e. it is an override).
In all cases, the presumption is that you might want to augment a package, either by replacing it wholesale, adding files to it, or modifying the contents of files to better suit them to yourself.
The rules for package updates go like this:
When Sublime Text is upgraded, this is done by deleting the entire installation and replacing it with a new one. Hence, you never modify Python.sublime-package directly, because if you did, on the next upgrade of Sublime your change will be thrown away.
When Package Control updates a package installed as a sublime-package file, it does so by deleting the file and replacing it with a brand new, updated version. Hence, you never modify a sublime-package file unless you’re the one that manually put it there, because if you did, on the next upgrade of the package your change will be thrown away.
When Package Control updates a package installed as loose files in the Packages folder, it does so by moving the old package into the Backups folder and then puts a new version of the package in place.
Package control never updates a package that it did not install itself.
Due to the way that package updates work, Package Control defaults to installing every package as a sublime-package file, so that you can create an override in the Packages folder to make a change without your change being thrown away. And of course, OverrideAudit exists to tell you if the package update happens because even though the sublime-package gets removed, the loose files will not (because you’re the one that put them there), so your change will remain even if you might not intend it.
Some packages have to be installed unpacked and not as a sublime-package file, such as if they contain files that will need to be accessible from outside of Sublime. In such a case the package author needs to specifically opt in.
It’s this last case that the Backup folder is for; if a package is installed that way, you might modify the files, and if you do your changes will get whacked when the package updates because there’s no safe way for Package Control to do the update other than by replacing everything. So, it backs up the content of such a package so that if you DID modify it, it doesn’t disrupt anything.
You can discard the Backup folder with impunity if you know you never modified anything. The folders inside of it represent the date of updates, so you could also delete any backups over a certain threshold age that you decide on, under the presumption that if you haven’t noticed in the last month (or whatever) that something is amiss, you probably don’t need the backup.
Thank you, now it’s a lot more clear.
To summarize:
The Backup folder keeps safe copies of packages found in the <user_app_data>/Sublime Text/Packages folder. These backups are helpful if you’ve made changes to these packages by hand, particularly when they are managed under Package Control.
Is that correct?
That’s correct.
If you don’t miss a thing after an upgrade it is safe to remove this folder.
Package Control 4.0 will prune old backups after 14 days automatically to limit its size.