Fixes some typos in the docs.

HISTORY

@@ -4,13 +4,13 @@ SnapRAID HISTORY
 6.2 2014/5
 ==========
  * Fixed the regression test when run as root.
- * Added a new euristic to detect file copies. Now a file is assumed
+ * Added a new heuristic to detect file copies. Now a file is assumed
    to be a copy if name, size and nanosecond timestamp are matching,
-   but if the nanosecond part of the timestamp is 0, we require
+   but if the nanosecond part of the timestamp is 0, it requires
    the full path matching and not only the name.
  * Added the -N, --force-nocopy option to disable completely
-   the copy detection. SnapRAID also suggest to use this option
-   in the error message of a data mismatch if caused by the
+   the copy detection. SnapRAID also suggests to use this option
+   in the error message of a data mismatch if likely caused by the
    copy detection.
 
 6.1 2014/4
@@ -99,7 +99,7 @@ SnapRAID HISTORY
    This improves the performance in sync for modified files.
  * Added a new "list" command to see the stored list of files.   
  * Removed the detailed list of errors from the screen output.
-   To get it you must explicitely use the -l, --log option.
+   To get it you must explicitly use the -l, --log option.
    It's now too detailed for the screen, because it contains a lot
    of info.
  * Changed the output format of some commands to make it similar
@@ -175,7 +175,7 @@ SnapRAID HISTORY
  * Fixed a directory creation problem in Windows when the "disk" option points to
    the root directory of a drive. Now SnapRAID won't complain about the
    inability to create such directory.
-   If you encouter this problem when trying to recover your data, just upgrade
+   If you encounter this problem when trying to recover your data, just upgrade
    to this version, and you'll be able to complete the recovering process.
    No need to upgrade for platforms different than Windows.
 
@@ -205,7 +205,7 @@ SnapRAID HISTORY
    symlink is saved and not the linked file.
    Note that Windows Symlinks to dirs and junctions are still not supported.
  * Files without read permission generate an error instead of a warning.
-   You now must explicitely exclude them in the configuration file with
+   You now must explicitly exclude them in the configuration file with
    exclusion rules.
  * In 'check' and 'fix', if verbose is enabled, prints the result for each
    processed file.
@@ -273,7 +273,7 @@ SnapRAID HISTORY
  * Fixed directory inclusion, in case the last rule is an "include" one.
  * Fixed very long paths in Windows. We now always use the special '\\?' prefix
    to remove the 260 chars limitation.
- * If a file is excluded, it prints explicitely which attribute caused the
+ * If a file is excluded, it prints explicitly which attribute caused the
    exclusion.   
  * Automatically excludes also the temporary copy of content file,
    the one with the ".tmp" extension.
@@ -397,7 +397,7 @@ SnapRAID HISTORY
 * Added support for multiple 'content' files. You can save extra copies to be
   able to verify the checksums also if you lose all the 'content' files in the
   parity disks.
-* Added a filtering include logic, where anything not explicitely included
+* Added a filtering include logic, where anything not explicitly included
   is excluded. For example, it allow to include only the files in a predefined
   set of directories.
 * The check command returns with an error code if any kind of error is present.

TEST

@@ -25,7 +25,7 @@ the error conditions that result in an immediate termination of the program.
 You can recognize this excluded code because it's enclosed between
 the LCOV_EXCL_START and LCOV_EXCL_STOP keywords.
 
-To test with the clang static anlayzer use:
+To test with the clang static analyzer use:
 
 	scan-build ./configure
 	scan-build make

TODO

@@ -26,12 +26,12 @@ to estimate the speed of the last minute, for each second.
 
 * Checks if splitting hash/parity computation in 4K pages
 can improve speed in sync. That should increase cache locality,
-becase we read the data two times for hash and and parity,
+because we read the data two times for hash and and parity,
 and if we manage to keep it in the cache, we should save time.
 
-* In the content file save the timestap of the parity files.
+* In the content file save the timestamp of the parity files.
 If they do not match, stop the processing.
-This can be done to avoid to use not syncronized parity and content files,
+This can be done to avoid to use not synchronized parity and content files,
 resulting in wrong data.
 But if the sync process is killed we need a way to resyncronize them.
 Or maybe we should allow parity never than content, but not viceversa.
@@ -80,8 +80,8 @@ rest of the block.
 The problem is that we don't have any hash to ensure that the block is partially recovered,
 or completely garbage. But it makes sense to anyway write the "most likely" correct one.
 
-* In the repair() function the euristic to detect if we recovered after the sync, can be extended
-to all the previous blocks, because we always proceeed in block order during a sync.
+* In the repair() function the heuristic to detect if we recovered after the sync, can be extended
+to all the previous blocks, because we always proceed in block order during a sync.
 So, if for a block we can detect that we recovered using updated parity data,
 also for all the previous blocks this is true.
 Anyway, the case where this information could be useful should be present
@@ -117,7 +117,7 @@ This feature can be enabled with a specific option, and available
 in Windows using Shadow Copy, and in Linux using Btrfs, and in a generic
 Unix using ZFS.
 See Jens's Windows script at: http://sourceforge.net/p/snapraid/discussion/1677233/thread/a1707211/
-Note that a different between Windows and Unix is that in Windows old shapshots
+Note that a different between Windows and Unix is that in Windows old snapshots
 are automatically deleted.
 
 * Use smaller hashes to reduce the memory occupation. We can truncate the 128 bits hash
@@ -142,7 +142,7 @@ existing filesystem.
 In the order of 0.01%. Not really worth to do it.
 - With NTFS the saving is also limited, because the "reserved" MFT of 12.5% is
 not really exclusively reserved, but can be used also for normal files,
-when all the remainig space is filled.
+when all the remaining space is filled.
 
 * Split the parity in multiple files and allow it to coexist with data
 in the same disk.
@@ -239,7 +239,7 @@ data doesn't overlap, do not recompute it.
 - It's going to work only in RAID5 mode and only in special cases.
 
 * Implements a multithread sync command.
-- At now it's questionable if it will result in a performance improvment.
+- At now it's questionable if it will result in a performance improvement.
 The murmur3 hash, and the RAID5/6 computations are so fast that even a single
 thread should be able to do them.
 Use the "snapraid -T" comment to see the speed.

snapraid.1

@@ -762,7 +762,7 @@ read for the first time,
 This happens when the system is under heavy pressure due all
 disks spinning and CPU busy, and in such extreme conditions,
 if your machine has a latent hardware problem, it\'s possible to
-encouter silent errors what cannot be detected because the data
+encounter silent errors what cannot be detected because the data
 is not yet hashed.
 To avoid this risk, you can enable the \[dq]pre\-hash\[dq] mode and have
 all the data hashed two times to ensure its integrity.
@@ -821,14 +821,14 @@ disk in the free space left in an already used disk. and this
 option allows you to continue anyway.
 .TP
 .B \-N, \-\-force\-nocopy
-In the \[dq]sync\[dq] command, disables the copy detection optimization.
-Withouth this option SnapRAID assumes that files with the
+In the \[dq]sync\[dq] command, disables the copy detection heuristic.
+Without this option SnapRAID assumes that files with the
 same name, size, and nanosecond timestamp are copies with the
 same data.
 This allows to identify copied files from one dir to another,
 and to reuse the already computed hash information to detect
 silent errors in the copy.
-This behaviour, in some rare cases, may result in false positives,
+This behavior, in some rare cases, may result in false positives,
 and this option allow to resolve them.
 .TP
 .B \-l, \-\-log FILE
@@ -1036,7 +1036,7 @@ any wasted space.
 Note also, that any file in data disks that is excluded from the parity
 computation, counts for its size as extra parity space for such data disk.
 .SS autosave SIZE_IN_GIBIBYTES 
-Automatically save the state when synching after the specified amount
+Automatically save the state when syncing after the specified amount
 of GiB processed.
 This option is useful to avoid to restart from scratch long \[dq]sync\[dq]
 commands interrupted by a machine crash, or any other event that
@@ -1353,7 +1353,7 @@ For example, if you have moved away some files from other disks after the last \
 you can retry to put them inplace, and retry the \[dq]fix\[dq].
 .PP
 If you are satisfied of the recovering, you can now proceed further,
-but take care that after synching you will no more able to retry the
+but take care that after syncing you will no more able to retry the
 \[dq]fix\[dq] command!
 .SS STEP 3 \-> Check 
 As paranoid check, you can now run a \[dq]check\[dq] command to ensure that everything

snapraid.d

@@ -525,7 +525,7 @@ Options
 		This happens when the system is under heavy pressure due all
 		disks spinning and CPU busy, and in such extreme conditions,
 		if your machine has a latent hardware problem, it's possible to
-		encouter silent errors what cannot be detected because the data
+		encounter silent errors what cannot be detected because the data
 		is not yet hashed.
 		To avoid this risk, you can enable the "pre-hash" mode and have
 		all the data hashed two times to ensure its integrity.
@@ -584,14 +584,14 @@ Options
 		option allows you to continue anyway.
 
 	-N, --force-nocopy
-		In the "sync" command, disables the copy detection optimization.
-		Withouth this option SnapRAID assumes that files with the
+		In the "sync" command, disables the copy detection heuristic.
+		Without this option SnapRAID assumes that files with the
 		same name, size, and nanosecond timestamp are copies with the
 		same data.
 		This allows to identify copied files from one dir to another,
 		and to reuse the already computed hash information to detect
 		silent errors in the copy.
-		This behaviour, in some rare cases, may result in false positives,
+		This behavior, in some rare cases, may result in false positives,
 		and this option allow to resolve them.
 
 	-l, --log FILE
@@ -795,7 +795,7 @@ Configuration
 	computation, counts for its size as extra parity space for such data disk.
 
     autosave SIZE_IN_GIBIBYTES
-	Automatically save the state when synching after the specified amount
+	Automatically save the state when syncing after the specified amount
 	of GiB processed.
 	This option is useful to avoid to restart from scratch long "sync"
 	commands interrupted by a machine crash, or any other event that
@@ -978,7 +978,7 @@ Recovering
 	you can retry to put them inplace, and retry the "fix".
 
 	If you are satisfied of the recovering, you can now proceed further,
-	but take care that after synching you will no more able to retry the
+	but take care that after syncing you will no more able to retry the
 	"fix" command!
 
   STEP 3 -> Check

snapraid.txt

@@ -570,7 +570,7 @@ SnapRAID provides the following options:
         This happens when the system is under heavy pressure due all
         disks spinning and CPU busy, and in such extreme conditions,
         if your machine has a latent hardware problem, it's possible to
-        encouter silent errors what cannot be detected because the data
+        encounter silent errors what cannot be detected because the data
         is not yet hashed.
         To avoid this risk, you can enable the "pre-hash" mode and have
         all the data hashed two times to ensure its integrity.
@@ -629,14 +629,14 @@ SnapRAID provides the following options:
         option allows you to continue anyway.
 
     -N, --force-nocopy
-        In the "sync" command, disables the copy detection optimization.
-        Withouth this option SnapRAID assumes that files with the
+        In the "sync" command, disables the copy detection heuristic.
+        Without this option SnapRAID assumes that files with the
         same name, size, and nanosecond timestamp are copies with the
         same data.
         This allows to identify copied files from one dir to another,
         and to reuse the already computed hash information to detect
         silent errors in the copy.
-        This behaviour, in some rare cases, may result in false positives,
+        This behavior, in some rare cases, may result in false positives,
         and this option allow to resolve them.
 
     -l, --log FILE
@@ -859,7 +859,7 @@ Note also, that any file in data disks that is excluded from the parity
 computation, counts for its size as extra parity space for such data disk.
 
 ---- 7.8.1 autosave SIZE_IN_GIBIBYTES ----
-Automatically save the state when synching after the specified amount
+Automatically save the state when syncing after the specified amount
 of GiB processed.
 This option is useful to avoid to restart from scratch long "sync"
 commands interrupted by a machine crash, or any other event that
@@ -1054,7 +1054,7 @@ For example, if you have moved away some files from other disks after the last "
 you can retry to put them inplace, and retry the "fix".
 
 If you are satisfied of the recovering, you can now proceed further,
-but take care that after synching you will no more able to retry the
+but take care that after syncing you will no more able to retry the
 "fix" command!
 
 9.3 STEP 3 -> Check