Update state

diff --git a/docs/manuals/en/main/state.tex b/docs/manuals/en/main/state.tex
index 4d954b8718bdae31819413bbacabaefe8aa898ef..c9291aa56bc4f909965cbe6d266bdec48fdde833 100644 (file)
--- a/docs/manuals/en/main/state.tex
+++ b/docs/manuals/en/main/state.tex
@@ -203,33 +203,22 @@ In other words, what is and what is not currently implemented and functional.
 \index[general]{Restrictions!Current Implementation }
 
 \begin{itemize}
-\item Bacula's Differential and Incremental \textsl{normal} backups are based
-  on time stamps.  Consequently, if you move files into an existing directory
-  or move a whole directory into the backup fileset after a Full backup, those
-  files will probably not be backed up by an Incremental save because they will
-  have old dates.  You must run backups in Accurate mode or explicitly update
-  the date/time stamp on all moved files. % TODO: remove it ?
-\item File System Modules (configurable routines for
-   saving/restoring special files) are not yet implemented.  However,
-   this feature is easily implemented using RunScripts.
-\item Bacula cannot restore two different jobs in the same
-   restore if those jobs were run simultaneously, unless you had
+\item It is very unusual to attempt to restore two Jobs
+   that ran simultaneously in a single restore, but if
+   you do, please be aware that unless you had
    data spooling turned on and the spool file held the full
-   contents of both jobs. In other terms, Bacula cannot restore
-   two jobs in the same restore if the jobs' data blocks were
-   intermixed on the backup medium. This poses no restrictions
-   for normal backup jobs even if they are run simultaneously.
-\item Bacula can generally restore any backup made from a client
+   contents of both Jobs during the backup, the restore will not
+   work correctly. In other terms, Bacula cannot restore
+   two jobs in the same restore if the Jobs' data blocks were
+   intermixed on the backup medium. The problem is resolved by
+   simply doing two restores, one for each Job. 
+\item Bacula can generally restore any backup made from one client
    to any other client. However, if the architecture is significantly
    different (i.e. 32 bit architecture to 64 bit or Win32 to Unix),
    some restrictions may apply (e.g. Solaris door files do not exist
    on other Unix/Linux machines; there are reports that Zlib compression
    written with 64 bit machines does not always read correctly on a 32 bit
    machine).
-\item In older version of Bacula ($<=$ 3.x), if you have over 4 billion file
-  entries stored in your database, the database FileId is likely to overflow.
-\item In non \textsl{Accurate} mode, files deleted after a Full save will be
-  included in a restoration. This is typical for most similar backup programs.
 \end{itemize}
 
 \section{Design Limitations or Restrictions}
@@ -244,3 +233,18 @@ In other words, what is and what is not currently implemented and functional.
 \item Command line input to some of the stand alone tools -- e.g. btape,
    bconsole is restricted to several hundred characters maximum.
 \end{itemize}
+
+\section{Items to Note}
+\index[general]{Items to Note}
+\begin{itemize}
+\item Bacula's Differential and Incremental \textsl{normal} backups are based
+  on time stamps.  Consequently, if you move files into an existing directory
+  or move a whole directory into the backup fileset after a Full backup, those
+  files will probably not be backed up by an Incremental save because they will
+  have old dates.  This problem is corrected by using Accurate mode backups
+  or by explicitly updating the date/time stamp on all moved files.
+\item In older versions of Bacula ($<=$ 3.0.x), if you have over 4 billion file
+  entries stored in your database, the database FileId is likely to overflow.
+\item In non \textsl{Accurate} mode, files deleted after a Full save will be
+  included in a restoration. This is typical for most similar backup programs.
+\end{itemize}