Editing File system (section)

===Transactional file systems===
Some programs need to either make multiple file system changes, or, if one or more of the changes fail for any reason, make none of the changes. For example, a program which is installing or updating software may write executables, libraries, and/or configuration files. If some of the writing fails and the software is left partially installed or updated, the software may be broken or unusable. An incomplete update of a key system utility, such as the command [[shell (computing)|shell]], may leave the entire system in an unusable state.

[[Transaction processing]] introduces the [[Atomicity (programming)|atomicity]] guarantee, ensuring that operations inside of a transaction are either all committed or the transaction can be aborted and the system discards all of its partial results. This means that if there is a crash or power failure, after recovery, the stored state will be consistent. Either the software will be completely installed or the failed installation will be completely rolled back, but an unusable partial install will not be left on the system. Transactions also provide the [[isolation (database systems)|isolation]] guarantee{{Clarify|reason=Complicated terms|date=June 2017}}, meaning that operations within a transaction are hidden from other threads on the system until the transaction commits, and that interfering operations on the system will be properly [[Serialization|serialized]] with the transaction.

Windows, beginning with Vista, added transaction support to [[NTFS]], in a feature called [[Transactional NTFS]], but its use is now discouraged.<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/windows/desktop/hh802690(v=vs.85).aspx |title=Alternatives to using Transactional NTFS (Windows) |publisher=Msdn.microsoft.com |date=2013-12-05 |access-date=2014-02-07}}</ref> There are a number of research prototypes of transactional file systems for UNIX systems, including the Valor file system,<ref>{{cite conference|last1=Spillane|first1=Richard|last2=Gaikwad|first2=Sachin|last3=Chinni|first3=Manjunath|last4=Zadok|first4=Erez|last5=Wright|first5=Charles P.|date=2009|url=http://www.fsl.cs.sunysb.edu/docs/valor/valor_fast2009.pdf|title=Enabling transactional file access via lightweight kernel extensions|conference=Seventh USENIX Conference on File and Storage Technologies (FAST 2009)}}</ref> Amino,<ref>{{cite journal|last1=Wright|first1=Charles P.|last2=Spillane|first2=Richard|last3=Sivathanu|first3=Gopalan|last4=Zadok|first4=Erez|date=2007|url=http://www.fsl.cs.sunysb.edu/docs/amino-tos06/amino.pdf|title=Extending ACID Semantics to the File System|journal=ACM Transactions on Storage|volume=3 |issue=2 |page=4 |doi=10.1145/1242520.1242521 |s2cid=8939577 }}</ref> LFS,<ref>{{cite conference|last=Seltzer|first=Margo I.|author-link=Margo Seltzer|date=1993|url=http://www.eecs.harvard.edu/~margo/papers/icde93/paper.pdf|title=Transaction Support in a Log-Structured File System|book-title=Proceedings of the Ninth International Conference on Data Engineering}}</ref> and a transactional [[ext3]] file system on the TxOS kernel,<ref>{{cite conference|last1=Porter|first1=Donald E.|last2=Hofmann|first2=Owen S.|last3=Rossbach|first3=Christopher J.|last4=Benn|first4=Alexander|last5=Witchel|first5=Emmett|url=http://www.sigops.org/sosp/sosp09/papers/porter-sosp09.pdf|title=Operating System Transactions|book-title=Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP '09)|location=Big Sky, MT|date=October 2009}}</ref> as well as transactional file systems targeting embedded systems, such as TFFS.<ref>{{cite conference|last1=Gal|first1=Eran|last2=Toledo|first2=Sivan|url=http://www.usenix.org/event/usenix05/tech/general/full_papers/gal/gal.pdf|title=A Transactional Flash File System for Microcontrollers|conference=USENIX 2005}}</ref>

Ensuring consistency across multiple file system operations is difficult, if not impossible, without file system transactions. [[File locking]] can be used as a [[concurrency control]] mechanism for individual files, but it typically does not protect the directory structure or file metadata. For instance, file locking cannot prevent [[TOCTTOU]] race conditions on symbolic links.
File locking also cannot automatically roll back a failed operation, such as a software upgrade; this requires atomicity.

[[Journaling file system]]s is one technique used to introduce transaction-level consistency to file system structures. Journal transactions are not exposed to programs as part of the OS API; they are only used internally to ensure consistency at the granularity of a single system call.

Data backup systems typically do not provide support for direct backup of data stored in a transactional manner, which makes the recovery of reliable and consistent data sets difficult. Most backup software simply notes what files have changed since a certain time, regardless of the transactional state shared across multiple files in the overall dataset. As a workaround, some database systems simply produce an archived state file containing all data up to that point, and the backup software only backs that up and does not interact directly with the active transactional databases at all. Recovery requires separate recreation of the database from the state file after the file has been restored by the backup software.