For transactional file systems and transactional databases, the lower-level software deals with this for you. This whether a transactional SQL, or Mac OS X Core Data and its undo, or otherwise. ACID is goodness.
For non-transactional databases (and non-transactional file systems in general), look at the concept of "careful writes". At its simplest, you seek to allocate and work and read and write structures outside of the live application data structures and only add your structures into the static storage with a single-block or other canonical write as the last step of the update or change. To always avoid having inconsistent structures.
In the event of an application or system crash, you can (will?) need a clean-up daemon that finds and releases any dangling allocations.
And one that threw me: there are cases where multiblock writes might not see all blocks written. Some storage devices might either cache the data, or might (due to a power failure) not write all blocks.
You'll find various discussions and papers on "careful writes" around. And ACID. And related.
Once you get the hang of this sequencing, the next level of complexity upwards here can involve distributed access and coordinating and sequencing write operations. This can involve locking or queuing.