is there a particular situation where atomic saves are better than the current implementation?

Atomic saves are preferable because you will never end up with a mangled file if anything untoward happens while saving.

got it thanks! (any drawbacks for atomic saving?)

You can loose meta data about the file, such as extended attributes and resource forks. OS X and Windows both provide APIs to preserve the metadata, which Sublime Text uses, but these won’t work in all scenarios (e.g., over some network drives), and there’s no equivalent on Linux. You can also get into trouble if editing a file in a directory with strange permissions, e.g., if it’s setup to allow modifying existing files, but not create new ones.

thanks, much appreciated!

It also looses symlinks and that is very annoying.

Just remember that atomic save is notoriously bugged in Sublime Text (at least versions 2 and 3), and should not be used until the bugs have been fixed

Considering Sublime Text 2 doesn’t even have the concept of atomic saves - you might want to take this statement with a grain of salt.

Typo from my point see these posts for a description of the problem:

Just for the record: disable this trick in preferences if you want file updates to be visible to concurrent processes by normal means.

i.e. with the default setting, another process that has open(2)'d a file you then open, edit and save with Sublime won’t see those changes because they’re made to a different underlying file.

If your having issues with saved files not being synced to a vagrant box, this setting is the culprit.
set it to false to fix.

I have to use atomic saving, because I have a remote drive hooked up as a mounted Windows SFTP drive. Without atomic_save being “false” it fails whenever I try to save a document.

Unfortunately, there’s no way to say “atomic save on drive Q” and “non-atomic-save on every other drive”.

I created a userecho request to do this: sublimetext.userecho.com/topic/516558-/

It should just be disabled. In theory, atomic saving is a good idea, but in practice it just doesn’t work. Also, most file watchers will not understand what’s happening with the file (deleted, then another file renamed) and do something unpredictable.

Atomic saving should be done at the OS level imo with a specific API for that which works around all these issues, not by an application.

I also recommend disabling this feature (which I believe should be its default state). I learned of its adverse effects the hard way. I was editing files in a versioned SharePoint document library. Atomic save’s process of deleting the original file and renaming the .tmp file to the original file name completely wiped out all previous versions of the documents I was editing. So much for our audit trail!