- General
-
Ideed
Atomic file saves to ensure file integrity
The way sublime editor works currently, is that first truncates the file, and then writes its content.
This has various unwanted consequences:
* Files are temporarirly left in an incomplete/inconsistent state while saving, and that might have various unexpected side effects. If there is interruption while saving to the network, the file will remain corrupted until the the user restarts the editor, and the file recovery mechanism kicks in.
* It breaks most file monitoring system, such as inotify; as the notification is triggered the moment it is truncated. It makes things like Guard and LiveReload not work properly, as they update the browser when they detect a change in the file. But when they do, the filesize is 0 bytes.
Screencast on Guard and LiveReload: http://railscasts.com/episodes/264-guard
Guard: https://github.com/guard/guard
LiveReload: https://github.com/mockko/livereload
Customer support service by UserEcho
"In general, I'm not a fan of atomic file saves. The problem the concept addresses, a crash or power outage during saves, is solved a different way in Sublime Text, via the auto save system. Atomic saves introduce a different set of issues: care has to be taken to preserve file attributes (creation date, permissions, etc), and other file meta data, like alternate data streams, are lost. It can interact in subtle ways with file system permissions.
Given that the method of simply overwriting files that Sublime Text uses is by far the most common, I'd suggest that any file system monitoring tool that doesn't support that is in error. The usual pattern for watching file system changes is to wait a short time after any modifications to a file before performing actions, to catch this and other scenarios. Sublime Text itself operates this way with its file system monitoring for the side bar."