Helper class for performing atomic operations on a file by creating a
backup file until a write has successfully completed. If you need this
on older versions of the platform you can use
AtomicFile in the v4 support library.
Atomic file guarantees file integrity by ensuring that a file has been completely written and sync'd to disk before removing its backup. As long as the backup file exists, the original file is considered to be invalid (left over from a previous attempt to write the file).
Atomic file does not confer any file locking semantics. Do not use this class when the file may be accessed or modified concurrently by multiple threads or processes. The caller is responsible for ensuring appropriate mutual exclusion invariants whenever it accesses the file.
Create a new AtomicFile for a file located at the given File path.
Delete the atomic file.
Call when you have failed for some reason at writing to the stream returned by
Call when you have successfully finished writing to the stream returned by
Return the path to the base file.
Open the atomic file for reading.
A convenience for
Start a new write operation on the file.
Create a new AtomicFile for a file located at the given File path. The secondary backup file will be the same file path with ".bak" appended.
Delete the atomic file. This deletes both the base and backup files.
Call when you have failed for some reason at writing to the stream
startWrite(). This will close the current
write stream, and roll back to the previous state of the file.
Call when you have successfully finished writing to the stream
startWrite(). This will close, sync, and
commit the new data. The next attempt to read the atomic file
will return the new file stream.
Return the path to the base file. You should not generally use this, as the data at that path may not be valid.
Open the atomic file for reading. If there previously was an incomplete write, this will roll back to the last good data before opening for read. You should call close() on the FileInputStream when you are done reading from it.
Note that if another thread is currently performing a write, this will incorrectly consider it to be in the state of a bad write and roll back, causing the new data currently being written to be dropped. You must do your own threading protection for access to AtomicFile.
Start a new write operation on the file. This returns a FileOutputStream
to which you can write the new file data. The existing file is replaced
with the new data. You must not directly close the given
FileOutputStream; instead call either
Note that if another thread is currently performing a write, this will simply replace whatever that thread is writing with the new file being written by this thread, and when the other thread finishes the write the new write operation will no longer be safe (or will be lost). You must do your own threading protection for access to AtomicFile.