jkl1337/duplicacy
1
0
Fork 0
mirror of https://github.com/jkl1337/duplicacy.git synced 2026-01-02 11:44:45 -06:00
Code Issues Packages Projects Releases Wiki Activity

Update DESIGN.md

Browse Source
This commit is contained in:
gilbertchen
2016-02-23 15:38:02 -05:00
parent ef9f1b7cb7
commit 9336fc97ae
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
DESIGN.md
View File

@@ -21,7 +21,7 @@ set of basic file operations, into powerful backup backends capable of both bloc
locking mechanism on top of the file storage.
There is one problem, though.
Delection of snapshots without an indexing database, when concurrent access is permitted, turns out to be a hard problem.
Deletion of snapshots without an indexing database, when concurrent access is permitted, turns out to be a hard problem.
If exclusive access to a file storage by a single client can be guaranteed, the deletion procedure can simply search for
chunks not referenced by any backup and delete them. However, if concurrent access is required, an unreferenced chunk
can't be trivially removed, because of the possibility that a backup procedure in progress may reference the same chunk.
@@ -32,7 +32,7 @@ Fortunately, there is a solution to address the deletion problem and make lock-f
## Two-Step Fossil Collection
When the deletion procedure identifies a chunk not referenced by any known snaphots, instead of deleting the chunk file
When the deletion procedure identifies a chunk not referenced by any known snapshots, instead of deleting the chunk file
immediately, it changes the name of the chunk file (and possibly moves it to a different directory).
A chunk that has been renamed is called a *fossil*.
@@ -157,7 +157,7 @@ contains sequences of chunk hashes and other fixed size fields:
}
```
If the respository has not been touched since last backup, a new backup procedure will not create any new chunks,
If the repository has not been touched since last backup, a new backup procedure will not create any new chunks,
as shown by the following output from a real use case:
```