Document new %D

[bacula/docs] / docs / manuals / en / main / dirdconf.tex

diff --git a/docs/manuals/en/main/dirdconf.tex b/docs/manuals/en/main/dirdconf.tex
index 6cfba98ff34a96598d8aa6ec660b870220ea80b5..32f4558b5e2f2151afb81781d663a80489ec0a39 100644 (file)
--- a/docs/manuals/en/main/dirdconf.tex
+++ b/docs/manuals/en/main/dirdconf.tex
@@ -678,9 +678,10 @@ For a {\bf Verify} Job, the Level may be one of the  following:
 \item [VolumeToCatalog]
 \index[dir]{VolumeToCatalog}
    This level causes Bacula to read the file attribute data written to the
-   Volume from the last Job.  The file attribute data are compared to the
+   Volume from the last backup Job for the job specified on the {\bf VerifyJob}
+   directive.  The file attribute data are compared to the
    values saved in the Catalog database and any differences are reported.
-   This is similar to the {\bf Catalog} level except that instead of
+   This is similar to the {\bf DiskToCatalog} level except that instead of
    comparing the disk file attributes to the catalog database, the
    attribute data written to the Volume is read and compared to the catalog
    database.  Although the attribute data including the signatures (MD5 or
@@ -697,7 +698,7 @@ For a {\bf Verify} Job, the Level may be one of the  following:
    This level causes Bacula to read the files as they currently are on
    disk, and to compare the current file attributes with the attributes
    saved in the catalog from the last backup for the job specified on the
-   {\bf VerifyJob} directive.  This level differs from the {\bf Catalog}
+   {\bf VerifyJob} directive.  This level differs from the {\bf VolumeToCatalog}
    level described above by the fact that it doesn't compare against a
    previous Verify job but against a previous backup.  When you run this
    level, you must supply the verify options on your Include statements.
@@ -723,7 +724,7 @@ For a {\bf Verify} Job, the Level may be one of the  following:
    and renamed directories are restored properly.
 
    In this mode, the File daemon must keep data concerning all files in
-   memory.  So you do not have sufficient memory, the restore may
+   memory.  So If you do not have sufficient memory, the backup may
    either be terribly slow or fail.
 
 %%   $$ memory = \sum_{i=1}^{n}(strlen(path_i + file_i) + sizeof(CurFile))$$
@@ -1141,17 +1142,24 @@ Console          &       &          & Console command\\
 \footnotesize
 \begin{verbatim}
     %% = %
+    %b = Job Bytes
     %c = Client's name
-    %d = Director's name
+    %d = Daemon's name (Such as host-dir or host-fd)
+    %D = Director's name (Also valid on file daemon)
     %e = Job Exit Status
+    %f = Job FileSet (Only on director side)
+    %F = Job Files
     %h = Client address
     %i = JobId
     %j = Unique Job id
     %l = Job Level
     %n = Job name
+    %p = Pool name (Only on director side)
     %s = Since time
     %t = Job type (Backup, ...)
     %v = Volume name (Only on director side)
+    %w = Storage name (Only on director side)
+    %x = Spooling enabled? ("yes" or "no")
  
 \end{verbatim}
 \normalsize