How do I control how Emacs makes backup files?

Question

Emacs puts backup files named foo~ everywhere and I don't like having to remember to delete them. Also, if I edit a file that has a hard link somewhere else in the file system, the hard link points to the backup when I'm done editing, and that's confusing and awful. How can I either eliminate these backup files, or have them go somewhere other than the same directory?

score 583 · Accepted Answer · edited Jan 12 '17 at 18:58

583

If you've ever been saved by an Emacs backup file, you probably want more of them, not less of them. It is annoying that they go in the same directory as the file you're editing, but that is easy to change. You can make all backup files go into a directory by putting something like the following in your .emacs.

(setq backup-directory-alist `(("." . "~/.saves")))

There are a number of arcane details associated with how Emacs might create your backup files. Should it rename the original and write out the edited buffer? What if the original is linked? In general, the safest but slowest bet is to always make backups by copying.

(setq backup-by-copying t)

If that's too slow for some reason you might also have a look at backup-by-copying-when-linked.

Since your backups are all in their own place now, you might want more of them, rather than less of them. Have a look at the Emacs documentation for these variables (with C-h v).

(setq delete-old-versions t
  kept-new-versions 6
  kept-old-versions 2
  version-control t)

Finally, if you absolutely must have no backup files:

(setq make-backup-files nil)

It makes me sick to think of it though.

edited Jan 12 '17 at 18:58

AST

211
6
18

answered Sep 30 '08 at 06:15

jfm3

36,964
10
32
35

6

hey but it is creating backups with a name like this one !home!svradmin!foo~ and I cannot open the file – Jaime Hablutzel Sep 28 '11 at 21:33
40

why use backups? why not use git/mercurial? good version control systems and programming methodologies should trump individual file backup by the editor – vol7ron Jul 16 '12 at 23:55
58

@vol7ron : The backups are for when you are editing something not under version control - like a config file or something quick and dirty that you haven't gotten around to putting into version control yet. Then, when you haven't been doing what you ought to, the editor saves your neck. – Eponymous Sep 05 '12 at 19:14
1

@jaime : have you tried `cat /path/to/backupdir/\!home\!svradmin\!foo~` ? That is, have you tried escaping the `!` (which is a special character in bash) with \ ? – Eponymous Sep 05 '12 at 19:18
2

I guess auto-save has it's benefits, but you could also probably set a script to auto-commit. Afterall `commit early and often` – vol7ron Sep 06 '12 at 02:52
75

@vol7ron - That's just wrong. You shouldn't be putting crap into revision control that you don't want to keep. It just makes finding the important stuff way harder. Instead, use your editor backups for what they are good for (backing up changes in case of emergency) and revision control for what its good for (keeping important versions of your software and facilitating team development). Use the right tool for the job. – T.E.D. Feb 26 '13 at 19:58
2

@T.E.D. It sounds like you may need to review your setup. I would suggest revisiting your branching model and possibly standardizing your commit messages. You should be able to easily find major and intermittent commits. Perhaps something like [gitflow](https://github.com/nvie/gitflow) may help – vol7ron Feb 27 '13 at 07:18
6

@vol7ron - So you actually have to go get third-party tools to help you sift through all the trash you're putting in your repository? Uhhh...thanks, but I'll muddle through my way. – T.E.D. Feb 27 '13 at 12:52
2

@T.E.D. No, that's to help you keep a consistent architecture, you can name branches however you choose, much like you can name a variable any way you please. If you keep a consistent naming convention, you'll be able to comprehend and find things much faster. The "3rd party tool" is almost nothing more than a set of scripts. Would you call your reliance on lisp or Emacs plugin to be a 3rd party tool? Additionally, an emacs backup file is nothing more than your last commit, which is easy to find in git; but if you do any real changes, you might want to re-implement something you've deleted – vol7ron Feb 27 '13 at 15:24
8

Downvoting b/c of the judgmentalism. Backup files add so much overhead and almost no value. You have to save to run your tests, anyway, so it's rare to go more than 5 minutes without saving. Even if I'm editing non version controlled config files, is emacs so unstable that it's constantly crashing? What workflow merits this kind of overhead? – Joshua Cheek Mar 25 '13 at 05:58
29

"Backup files add so much overhead and almost no value": isn't that judgmentalism? – Miserable Variable May 20 '13 at 16:19
1

Sorry to interject (2 months later), but is the option to backup this way: (setq backup-by-copying t) still funneling them to a single directory which is not the current directory? I'd like the most secure option and I'm having a hard time finding out what that actually does. Also, is that lisp? – astromax Jul 24 '13 at 00:17
Where do I put these scheme commands? Ie. when I have emacs in CLI mode, what keys do I have to press to get to a relevant prompt? – Zds Sep 24 '13 at 09:14
Why "." instead of ".*"? What's the difference? – lazywei Jun 15 '14 at 11:27
1

Also, how to put autosave files into `.saves` as well? It seems this setting only works for auto-backup files? – lazywei Jun 15 '14 at 11:48
3

@vol7ron clearly you've never used Emacs for drafting email, which I for one definitely don't want in a vcs. – Ben Aug 03 '14 at 22:04
@Ben No I haven't :) I guess this discussion is based on how emacs is being used. *And with that, there's a danger of having this discussion evolve into a debate about how emacs tries to be too much of everything (e.g., os, ide).* Anyhow, I can see that I was not thinking about a use case like which you described, but I'll add that while I understand the benefits of having a temp file, I'm biased because emacs doesn't do a great job of cleaning those *temp* files up after a save is performed and I've seen too many people rely on those *temp* files as their version control (***bad***). – vol7ron Aug 03 '14 at 22:16
2

I had to create the `.saves` before any backup would be created. – jcalfee314 Aug 13 '14 at 15:40
1

@Zds do C-x C-f ~/.emacs that is where all the custom emacs settings are stored. Type in the command there – u8y7541 Aug 06 '16 at 04:18
3

@vol7ron it's very very silly to compare emacs backups to version control. they are different tools for different purposes. before new changes are ready to be commited into a VCS, they go through a sequence of intermediate edits, character by character, line by line, statement by statement, these are not changes any sane person would ever comit into VCS (most would have syntax errors). yet, at any point during these changes, your laptop's battery may die, or your network connection broken. this is when emacs (or vi) backups are helpful – ealfonso Oct 02 '17 at 18:10
1

vol7ron This is the point @T.E.D. was trying to make. Additionally, not everything is in version control. I might be editing a local config file, or drafting an email as someone pointed out earlier, and I do appreciate emacs being able to save me in case of an emergency. I have never met anyone who relies on emacs backup files as version control. – ealfonso Oct 02 '17 at 18:17
@erjoalgo no. Just no. You can cherrypick commits, you don't have to retain all commits as part of the history when doing merges. Commits are save points and it's up to you to manage them how you see fit. All of them don't have to be part of the chain/history and certainly it's better to have more in your history then the most recent save, which is what emacs yields as a temporary file.— I'm not opposed to temporary files, but in my experience, Emacs has created more bloat then necessary all due to these temporary files. – vol7ron Oct 02 '17 at 20:04
1

`git` can be used for more then "version control" as versioning is a matter of philosophy with respect to technicality. Yes it does versioning and it does it great, but if you don't view it as versioning a software/system, then it is just creating many save points. Perhaps it's not for software release, but in terms of file system management / backups. Maybe its overkill, maybe RCS is better for particular use cases, but why not get in the habit of using `git` efficiently? – vol7ron Oct 02 '17 at 20:09
1

Perhaps you've drafted an email and it got derailed or overly complex. Do you ever start a paper/email and need to get back to a version that you originally started? An emacs backup won't get you there. What emacs backups are good for, much like MS Word temp files are for, is an automatic save point in the case of power/network failure, but in that case, you could develop your own system scripts to make automatic `git` save points almost the same way. Again, a matter of setting up the system to suit your needs and no, you don't have to retain all those commits/branches. – vol7ron Oct 02 '17 at 20:13
1

@vol7ron what happens when your laptop battery dies between save points? I agree it is a good practice to commit of often and to have small commits, this is still totally different from what emacs or vi backups provide, which is a last-resort fallback in case of emergency. "you could develop your own system scripts to make automatic git save points almost the same way" do you realize how silly and not practial this is? – ealfonso Oct 02 '17 at 21:46
1

@erjoalgo I admitted the necessity of temp files already. I have that as a simple solution. I’m not going to tell you how to set up and run your environment, the point being addressed was something to the effect that not all commits were desired as part of history, which I responded to. Regarding your point of ridiculous, many things seem ridiculous until you try them and see how beneficial they are once they’re applied. I don’t see any need to further defend this point as it benefits me nothing. Do what you want. – vol7ron Oct 02 '17 at 22:41
Thank you it kind of save my 1 day work. What if I am using `(setq undo-tree-auto-save-history t)` would it also have its own backup? @jfm3 – alper Jun 11 '20 at 23:51
@T.E.D. *You shouldn't be putting crap into revision control that you don't want to keep* — I agree emphatically with everything you said in that comment, and yet: evidently you and I are both simply wrong. I've just discovered that, on at least one of my systems, in its default configuration, emacs doesn't create ~ files in directories managed by git, because ["backup files are redundant when you store all the previous versions in a version control system"](https://stackoverflow.com/questions/56915816). Good grief. – Steve Summit Feb 28 '22 at 21:40
@SteveSummit - Well, I guess it couldn't as obvious an insight at it seems it should be if it generated (..counts ... ) 21 comment replies when pointed out. – T.E.D. Feb 28 '22 at 21:55
Is there not a security concern here, with having backup files that may be hard to keep track of hanging around after you've already deleted a file with sensitive data? Emacs is the only editor I use that creates backups of files when I save them and I've never once found it useful, but always annoying and possibly problematic. – mithunc Jul 12 '22 at 00:02

Andreas Spindler · Answer 2 · 2013-10-16T07:45:47.430

Emacs backup/auto-save files can be very helpful. But these features are confusing.

Backup files

Backup files have tildes (~ or ~9~) at the end and shall be written to the user home directory. When make-backup-files is non-nil Emacs automatically creates a backup of the original file the first time the file is saved from a buffer. If you're editing a new file Emacs will create a backup the second time you save the file.

No matter how many times you save the file the backup remains unchanged. If you kill the buffer and then visit the file again, or the next time you start a new Emacs session, a new backup file will be made. The new backup reflects the file's content after reopened, or at the start of editing sessions. But an existing backup is never touched again. Therefore I find it useful to created numbered backups (see the configuration below).

To create backups explicitly use save-buffer (C-x C-s) with prefix arguments.

diff-backup and dired-diff-backup compares a file with its backup or vice versa. But there is no function to restore backup files. For example, under Windows, to restore a backup file

C:\Users\USERNAME\.emacs.d\backups\!drive_c!Users!USERNAME!.emacs.el.~7~

it has to be manually copied as

C:\Users\USERNAME\.emacs.el

Auto-save files

Auto-save files use hashmarks (#) and shall be written locally within the project directory (along with the actual files). The reason is that auto-save files are just temporary files that Emacs creates until a file is saved again (like with hurrying obedience).

Before the user presses C-x C-s (save-buffer) to save a file Emacs auto-saves files - based on counting keystrokes (auto-save-interval) or when you stop typing (auto-save-timeout).
Emacs also auto-saves whenever it crashes, including killing the Emacs job with a shell command.

When the user saves the file, the auto-saved version is deleted. But when the user exits the file without saving it, Emacs or the X session crashes, the auto-saved files still exist.

Use revert-buffer or recover-file to restore auto-save files. Note that Emacs records interrupted sessions for later recovery in files named ~/.emacs.d/auto-save-list. The recover-session function will use this information.

The preferred method to recover from an auto-saved filed is M-x revert-buffer RET. Emacs will ask either "Buffer has been auto-saved recently. Revert from auto-save file?" or "Revert buffer from file FILENAME?". In case of the latter there is no auto-save file. For example, because you have saved before typing another auto-save-intervall keystrokes, in which case Emacs had deleted the auto-save file.

Auto-save is nowadays disabled by default because it can slow down editing when connected to a slow machine, and because many files contain sensitive data.

Configuration

Here is a configuration that IMHO works best:

(defvar --backup-directory (concat user-emacs-directory "backups"))
(if (not (file-exists-p --backup-directory))
        (make-directory --backup-directory t))
(setq backup-directory-alist `(("." . ,--backup-directory)))
(setq make-backup-files t               ; backup of a file the first time it is saved.
      backup-by-copying t               ; don't clobber symlinks
      version-control t                 ; version numbers for backup files
      delete-old-versions t             ; delete excess backup files silently
      delete-by-moving-to-trash t
      kept-old-versions 6               ; oldest versions to keep when a new numbered backup is made (default: 2)
      kept-new-versions 9               ; newest versions to keep when a new numbered backup is made (default: 2)
      auto-save-default t               ; auto-save every buffer that visits a file
      auto-save-timeout 20              ; number of seconds idle time before auto-save (default: 30)
      auto-save-interval 200            ; number of keystrokes between auto-saves (default: 300)
      )

Sensitive data

Another problem is that you don't want to have Emacs spread copies of files with sensitive data. Use this mode on a per-file basis. As this is a minor mode, for my purposes I renamed it sensitive-minor-mode.

To enable it for all .vcf and .gpg files, in your .emacs use something like:

(setq auto-mode-alist
      (append
       (list
        '("\\.\\(vcf\\|gpg\\)$" . sensitive-minor-mode)
        )
       auto-mode-alist))

Alternatively, to protect only some files, like some .txt files, use a line like

// -*-mode:asciidoc; mode:sensitive-minor; fill-column:132-*-

in the file.

So you do not use autosave? These settings allow you to avoid having to see those nasty #filename.tex# files in your folder? — PascalVKooten, Oct 02 '13 at 12:13
I always use autosave and backup files by default, except for files with sensitive data. Sensitive mode disables autosaving and backups. BTW, #file.ext# files are not really nasty, because Emacs creates and deletes them as needed. If they remain either Emacs is still running, or they're an artifact from a crashed Emacs. In both cases they can save the day ;-) — Andreas Spindler, Oct 16 '13 at 07:50
Ah, thanks for that extra information. I do indeed have mostly positive experience with them (they did save my day). Only when you're looking for ugliness, well you got it right there :) — PascalVKooten, Oct 16 '13 at 08:12
BTW it is one thing to make backups, and a different thing to restore backups. Hence play with auto-save. Kill the Emacs job or ssh session. If there is an auto-save file `diff` it with the actual file. Then fire Emacs and find out by yourself what `revert-buffer` does. This will pay off quickly in cases of emergency. — Andreas Spindler, Jul 04 '15 at 09:09
The sensitive-mode works great. Thanks. Please note that in your post you call it sensitive-minor-mode whereas in the definition (link) it is called sensitive-mode. Maybe you want to align that. — HeyMan, Feb 01 '18 at 13:29
Note that process watchers (like nodejs's [pm2](http://pm2.keymetrics.io/docs/usage/watch-and-restart/)) will **restart the server at each of those auto-save** so make sure you *ignore* them by adding (in the case of pm2) `"ignore_watch" : ["*#", "ignored-dir"]` — yPhil, Mar 24 '18 at 12:10
@AndreasSpindler I am not sure but this does not save some files that is already on the buffer list when emacs started, also can we ignore `recentf` file to be recorded? — alper, Jan 05 '21 at 15:06
@AndreasSpindler That is not true. If you open a file, change something, and then close Emacs without saving the file, the autosave file is still there, which is pretty annoying. — Philipp Ludwig, Aug 13 '22 at 12:53

score 74 · Answer 3 · edited May 23 '17 at 12:26

The accepted answer is good, but it can be greatly improved by additionally backing up on every save and backing up versioned files.

First, basic settings as described in the accepted answer:

(setq version-control t     ;; Use version numbers for backups.
      kept-new-versions 10  ;; Number of newest versions to keep.
      kept-old-versions 0   ;; Number of oldest versions to keep.
      delete-old-versions t ;; Don't ask to delete excess backup versions.
      backup-by-copying t)  ;; Copy all files, don't rename them.

Next, also backup versioned files, which Emacs does not do by default (you don't commit on every save, right?):

(setq vc-make-backup-files t)

Finally, make a backup on each save, not just the first. We make two kinds of backups:

per-session backups: once on the first save of the buffer in each Emacs session. These simulate Emac's default backup behavior.
per-save backups: once on every save. Emacs does not do this by default, but it's very useful if you leave Emacs running for a long time.

The backups go in different places and Emacs creates the backup dirs automatically if they don't exist:

;; Default and per-save backups go here:
(setq backup-directory-alist '(("" . "~/.emacs.d/backup/per-save")))

(defun force-backup-of-buffer ()
  ;; Make a special "per session" backup at the first save of each
  ;; emacs session.
  (when (not buffer-backed-up)
    ;; Override the default parameters for per-session backups.
    (let ((backup-directory-alist '(("" . "~/.emacs.d/backup/per-session")))
          (kept-new-versions 3))
      (backup-buffer)))
  ;; Make a "per save" backup on each save.  The first save results in
  ;; both a per-session and a per-save backup, to keep the numbering
  ;; of per-save backups consistent.
  (let ((buffer-backed-up nil))
    (backup-buffer)))

(add-hook 'before-save-hook  'force-backup-of-buffer)

I became very interested in this topic after I wrote $< instead of $@ in my Makefile, about three hours after my previous commit :P

The above is based on an Emacs Wiki page I heavily edited.

I pasted the above code inside my init.el file, yet I don't get any backup directory and emacs still creates the backup files all over. I might have misunderstood something, I'm new to emacs :P — Soeholm, Nov 27 '15 at 16:37
@Soeholm: did you paste *all* of the code in my answer, including the `setq`s at the top of my answer? The above works for me in Emacs 24.5.1. — ntc2, Nov 27 '15 at 22:15
It started working now. I had all the code pasted in, so I'm not sure why it was slow to accept my new configuration. But thanks a lot! — Soeholm, Nov 30 '15 at 08:38
As a followup, I know why it didn't work now. It worked on one machine, but not the other. It was because I had an empty .emacs file in my home directory, which took priority over my .emacs.d directory. Silly mistake.. — Soeholm, Dec 03 '15 at 17:18
I don't know why by it does not save the file I am workig on, but it only saves newly created files — alper, Jan 05 '21 at 15:14
If I understand right, the `per-save` directory gets a copy of every save -- i.e. including the first save of each session. Whereas by contrast the `per-session` directory only gets the first save of each session. If that's right, what do you see as the advantage of having the `per-session` directory at all, given that `per-save` has everything `per-session` has and more? — tkp, Nov 04 '21 at 21:05
@tkp: the motivation is to be able to completely revert the file to how it existed at the beginning of the session. Without the `per-session` backups, it might be hard to figure out which of the `per-save` backups was the one from the beginning of the session (but in many cases it would probably be the first save for the day I guess). — ntc2, Nov 05 '21 at 13:26

score 32 · Answer 4 · answered Sep 30 '08 at 08:14

Another way of configuring backup options is via the Customize interface. Enter:

M-x customize-group

And then at the Customize group: prompt enter backup.

If you scroll to the bottom of the buffer you'll see Backup Directory Alist. Click Show Value and set the first entry of the list as follows:

Regexp matching filename: .*
Backup directory name: /path/to/your/backup/dir

Alternatively, you can turn backups off my setting Make Backup Files to off.

If you don't want Emacs to automatically edit your .emacs file you'll want to set up a customisations file.

I wish I had known about `customize-group` 2 years ago. Thank you! — wprl, Jul 03 '12 at 03:31

score 32 · Answer 5 · answered Jan 21 '09 at 21:24

32

You can disable them altogether by

(setq make-backup-files nil)

answered Jan 21 '09 at 21:24

Paweł Hajdan

18,074
9
49
65

I like to set this from the shell prompt, when I'm hopping from host to host I don't like to have .emacs files: emacs --eval "(setq make-backup-files nil)" – Dave Morse Jul 05 '17 at 21:11

score 0 · Answer 6 · answered Apr 10 '22 at 20:19

(setq delete-auto-save-files t)

deletes buffer's auto save file when it is saved or when killed with no changes in it. thus you still get some of the safety of auto save files, since they are only left around when a buffer is killed with unsaved changes or if emacs exits unexpectedly. if you want to do this, but really need history on some of your files, consider putting them under source control.

How do I control how Emacs makes backup files?

6 Answers6

Linked

Related