From: Kern Sibbald <kern@sibbald.com>
Date: Fri, 26 Jan 2007 21:26:50 +0000 (+0000)
Subject: ebl  Implements the include JobID in spool file name project.
X-Git-Tag: Release-7.0.0~7004
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=8a5ad4fc5f6d39bbae14b14061b9f15682f4d52c;p=bacula%2Fbacula

ebl  Implements the include JobID in spool file name project.
kes  Reorder projects file in order determined by Jan 2007 vote.
kes  Implement item #12 on project list -- quick release of FD by
     the SD.


git-svn-id: https://bacula.svn.sourceforge.net/svnroot/bacula/trunk@4049 91ce42f0-d328-0410-95d8-f526ca767f89
---

diff --git a/bacula/projects b/bacula/projects
index 87b5af4f88..05eea2aec9 100644
--- a/bacula/projects
+++ b/bacula/projects
@@ -1,51 +1,55 @@
                 
 Projects:
                      Bacula Projects Roadmap 
-                    Status updated 12 January 2007
+                    Status updated 26 January 2007
+                   After re-ordering in vote priority
+
+Items Completed:
+Item:  18   Quick release of FD-SD connection after backup.
+Item:  40   Include JobID in spool file name
 
 Summary:
-Item  1:  Accurate restoration of renamed/deleted files
-Item  2:  Implement a Bacula GUI/management tool.
-Item  3:  Implement Base jobs.
-Item  4:  Implement from-client and to-client on restore command line.
-Item  5:  Implement creation and maintenance of copy pools
-Item  6:  Merge multiple backups (Synthetic Backup or Consolidation).
-Item  7:  Deletion of Disk-Based Bacula Volumes
-Item  8:  Implement a Python interface to the Bacula catalog.
-Item  9:  Archival (removal) of User Files to Tape
-Item 10:  Add Plug-ins to the FileSet Include statements.
-Item 11:  Implement more Python events in Bacula.
-Item 12:  Quick release of FD-SD connection after backup.
-Item 13:  Implement huge exclude list support using hashing.
-Item 14:  Allow skipping execution of Jobs
-Item 15:  Tray monitor window cleanups
-Item 16:  Split documentation
-Item 17:  Automatic promotion of backup levels
-Item 18:  Add an override in Schedule for Pools based on backup types.
-Item 10:  An option to operate on all pools with update vol parameters
-Item 20:  Include JobID in spool file name
-Item 21:  Include timestamp of job launch in "stat clients" output
-Item 22:  Message mailing based on backup types
-Item 23:  Allow inclusion/exclusion of files in a fileset by creation/mod times
-Item 24:  Add a scheduling syntax that permits weekly rotations
-Item 25:  Improve Bacula's tape and drive usage and cleaning management.
-Item 26:  Implement support for stacking arbitrary stream filters, sinks.
-Item 27:  Allow FD to initiate a backup
-Item 28:  Directive/mode to backup only file changes, not entire file
-Item 29:  Automatic disabling of devices
-Item 30:  Incorporation of XACML2/SAML2 parsing
-Item 31:  Clustered file-daemons
-Item 32:  Commercial database support
-Item 33:  Archive data
-Item 34:  Filesystem watch triggered backup.
-Item 35:  Implement multiple numeric backup levels as supported by dump
-Item 36:  Implement a server-side compression feature
-Item 37:  Cause daemons to use a specific IP address to source communications
-Item 38:  Multiple threads in file daemon for the same job
-Item 39:  Restore only file attributes (permissions, ACL, owner, group...)
-Item 40:  Add an item to the restore option where you can select a pool
-
-Below, you will find more information on future projects:
+Item:   1   Accurate restoration of renamed/deleted files
+Item:   2   Implement a Bacula GUI/management tool.
+Item:   3   Allow FD to initiate a backup
+Item:   4   Merge multiple backups (Synthetic Backup or Consolidation).
+Item:   5   Deletion of Disk-Based Bacula Volumes
+Item:   6   Implement Base jobs.
+Item:   7   Implement creation and maintenance of copy pools
+Item:   8   Directive/mode to backup only file changes, not entire file
+Item:   9   Implement a server-side compression feature
+Item:  10   Improve Bacula's tape and drive usage and cleaning management.
+Item:  11   Allow skipping execution of Jobs
+Item:  12   Add a scheduling syntax that permits weekly rotations
+Item:  13   Archival (removal) of User Files to Tape
+Item:  14   Cause daemons to use a specific IP address to source communications
+Item:  15   Multiple threads in file daemon for the same job
+Item:  16   Add Plug-ins to the FileSet Include statements.
+Item:  17   Restore only file attributes (permissions, ACL, owner, group...)
+Item:  18*  Quick release of FD-SD connection after backup.
+Item:  19   Implement a Python interface to the Bacula catalog.
+Item:  20   Archive data
+Item:  21   Split documentation
+Item:  22   Implement support for stacking arbitrary stream filters, sinks.
+Item:  23   Implement from-client and to-client on restore command line.
+Item:  24   Add an override in Schedule for Pools based on backup types.
+Item:  25   Implement huge exclude list support using hashing.
+Item:  26   Implement more Python events in Bacula.
+Item:  27   Incorporation of XACML2/SAML2 parsing
+Item:  28   Filesystem watch triggered backup.
+Item:  29   Allow inclusion/exclusion of files in a fileset by creation/mod times
+Item:  30   Tray monitor window cleanups
+Item:  31   Implement multiple numeric backup levels as supported by dump
+Item:  32   Automatic promotion of backup levels
+Item:  33   Clustered file-daemons
+Item:  34   Commercial database support
+Item:  35   Automatic disabling of devices
+Item:  36   An option to operate on all pools with update vol parameters
+Item:  37   Add an item to the restore option where you can select a pool
+Item:  38   Include timestamp of job launch in "stat clients" output
+Item:  39   Message mailing based on backup types
+Item:  40*  Include JobID in spool file name
+
 
 Item  1:  Accurate restoration of renamed/deleted files
   Date:   28 November 2005
@@ -102,8 +106,77 @@ Item  2:  Implement a Bacula GUI/management tool.
           Lucas Di Pentima <lucas at lunix dot com dot ar> but
           it is no longer being developed.
 
+Item  3:  Allow FD to initiate a backup
+  Origin: Frank Volf (frank at deze dot org)
+  Date:   17 November 2005
+  Status:
+
+   What:  Provide some means, possibly by a restricted console that
+          allows a FD to initiate a backup, and that uses the connection
+          established by the FD to the Director for the backup so that
+          a Director that is firewalled can do the backup.
+
+   Why:   Makes backup of laptops much easier.
+
+
+Item  4:  Merge multiple backups (Synthetic Backup or Consolidation).
+  Origin: Marc Cousin and Eric Bollengier 
+  Date:   15 November 2005
+  Status: Waiting implementation. Depends on first implementing 
+          project Item 2 (Migration) which is now done.
+
+  What:   A merged backup is a backup made without connecting to the Client.
+          It would be a Merge of existing backups into a single backup.
+          In effect, it is like a restore but to the backup medium.
+
+          For instance, say that last Sunday we made a full backup.  Then
+          all week long, we created incremental backups, in order to do
+          them fast.  Now comes Sunday again, and we need another full.
+          The merged backup makes it possible to do instead an incremental
+          backup (during the night for instance), and then create a merged
+          backup during the day, by using the full and incrementals from
+          the week.  The merged backup will be exactly like a full made
+          Sunday night on the tape, but the production interruption on the
+          Client will be minimal, as the Client will only have to send
+          incrementals.
+
+          In fact, if it's done correctly, you could merge all the
+          Incrementals into single Incremental, or all the Incrementals
+          and the last Differential into a new Differential, or the Full,
+          last differential and all the Incrementals into a new Full
+          backup.  And there is no need to involve the Client.
+
+  Why:    The benefit is that :
+          - the Client just does an incremental ;
+          - the merged backup on tape is just as a single full backup,
+            and can be restored very fast.
+
+          This is also a way of reducing the backup data since the old
+          data can then be pruned (or not) from the catalog, possibly
+          allowing older volumes to be recycled
+
+Item  5:  Deletion of Disk-Based Bacula Volumes
+  Date:   Nov 25, 2005
+  Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
+          by Kern)
+  Status:         
+
+   What:  Provide a way for Bacula to automatically remove Volumes
+          from the filesystem, or optionally to truncate them.
+          Obviously, the Volume must be pruned prior removal.
+
+  Why:    This would allow users more control over their Volumes and
+          prevent disk based volumes from consuming too much space.
+
+  Notes:  The following two directives might do the trick:
+
+          Volume Data Retention = <time period>
+          Remove Volume After = <time period>
+
+          The migration project should also remove a Volume that is
+          migrated. This might also work for tape Volumes.
 
-Item  3:  Implement Base jobs.
+Item  6:  Implement Base jobs.
   Date:   28 October 2005
   Origin: Kern
   Status: 
@@ -137,28 +210,7 @@ Item  3:  Implement Base jobs.
           FD a list of files/attribs, and the FD must search the
           list and compare it for each file to be saved.
 
-Item  4:  Implement from-client and to-client on restore command line.
-   Date:  11 December 2006
-  Origin: Discussion on Bacula-users entitled 'Scripted restores to
-          different clients', December 2006 
-  Status: New feature request
- 
-  What:   While using bconsole interactively, you can specify the client
-          that a backup job is to be restored for, and then you can
-          specify later a different client to send the restored files
-          back to. However, using the 'restore' command with all options
-          on the command line, this cannot be done, due to the ambiguous
-          'client' parameter. Additionally, this parameter means different
-          things depending on if it's specified on the command line or
-          afterwards, in the Modify Job screens.
- 
-     Why: This feature would enable restore jobs to be more completely
-          automated, for example by a web or GUI front-end.
- 
-   Notes: client can also be implied by specifying the jobid on the command
-          line
-
-Item  5:  Implement creation and maintenance of copy pools
+Item  7:  Implement creation and maintenance of copy pools
   Date:   27 November 2005
   Origin: David Boyes (dboyes at sinenomine dot net)
   Status:
@@ -200,85 +252,224 @@ Item  5:  Implement creation and maintenance of copy pools
   Notes:  I would commit some of my developers' time if we can agree
           on the design and behavior. 
 
-Item  6:  Merge multiple backups (Synthetic Backup or Consolidation).
-  Origin: Marc Cousin and Eric Bollengier 
-  Date:   15 November 2005
-  Status: Waiting implementation. Depends on first implementing 
-          project Item 2 (Migration) which is now done.
+Item  8:  Directive/mode to backup only file changes, not entire file
+  Date:   11 November 2005
+  Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
+          Marek Bajon <mbajon at bimsplus dot com dot pl>
+  Status: 
 
-  What:   A merged backup is a backup made without connecting to the Client.
-          It would be a Merge of existing backups into a single backup.
-          In effect, it is like a restore but to the backup medium.
+  What:   Currently when a file changes, the entire file will be backed up in
+          the next incremental or full backup.  To save space on the tapes
+          it would be nice to have a mode whereby only the changes to the
+          file would be backed up when it is changed.
 
-          For instance, say that last Sunday we made a full backup.  Then
-          all week long, we created incremental backups, in order to do
-          them fast.  Now comes Sunday again, and we need another full.
-          The merged backup makes it possible to do instead an incremental
-          backup (during the night for instance), and then create a merged
-          backup during the day, by using the full and incrementals from
-          the week.  The merged backup will be exactly like a full made
-          Sunday night on the tape, but the production interruption on the
-          Client will be minimal, as the Client will only have to send
-          incrementals.
+  Why:    This would save lots of space when backing up large files such as 
+          logs, mbox files, Outlook PST files and the like.
 
-          In fact, if it's done correctly, you could merge all the
-          Incrementals into single Incremental, or all the Incrementals
-          and the last Differential into a new Differential, or the Full,
-          last differential and all the Incrementals into a new Full
-          backup.  And there is no need to involve the Client.
+  Notes:  This would require the usage of disk-based volumes as comparing 
+          files would not be feasible using a tape drive.
 
-  Why:    The benefit is that :
-          - the Client just does an incremental ;
-          - the merged backup on tape is just as a single full backup,
-            and can be restored very fast.
+Item  9:  Implement a server-side compression feature
+  Date:   18 December 2006
+  Origin: Vadim A. Umanski , e-mail umanski@ext.ru
+  Status:
+  What:   The ability to compress backup data on server receiving data
+          instead of doing that on client sending data.
+  Why:    The need is practical. I've got some machines that can send
+          data to the network 4 or 5 times faster than compressing
+          them (I've measured that). They're using fast enough SCSI/FC
+          disk subsystems but rather slow CPUs (ex. UltraSPARC II).
+          And the backup server has got a quite fast CPUs (ex. Dual P4
+          Xeons) and quite a low load. When you have 20, 50 or 100 GB
+          of raw data - running a job 4 to 5 times faster - that
+          really matters. On the other hand, the data can be
+          compressed 50% or better - so losing twice more space for
+          disk backup is not good at all. And the network is all mine
+          (I have a dedicated management/provisioning network) and I
+          can get as high bandwidth as I need - 100Mbps, 1000Mbps...
+          That's why the server-side compression feature is needed!
+  Notes:
 
-          This is also a way of reducing the backup data since the old
-          data can then be pruned (or not) from the catalog, possibly
-          allowing older volumes to be recycled
+Item 10:  Improve Bacula's tape and drive usage and cleaning management.
+  Date:   8 November 2005, November 11, 2005
+  Origin: Adam Thornton <athornton at sinenomine dot net>,
+          Arno Lehmann <al at its-lehmann dot de>
+  Status:
 
-Item  7:  Deletion of Disk-Based Bacula Volumes
-  Date:   Nov 25, 2005
-  Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
-          by Kern)
-  Status:         
+  What:   Make Bacula manage tape life cycle information, tape reuse
+          times and drive cleaning cycles.
 
-   What:  Provide a way for Bacula to automatically remove Volumes
-          from the filesystem, or optionally to truncate them.
-          Obviously, the Volume must be pruned prior removal.
+  Why:    All three parts of this project are important when operating
+          backups.
+          We need to know which tapes need replacement, and we need to
+          make sure the drives are cleaned when necessary.  While many
+          tape libraries and even autoloaders can handle all this
+          automatically, support by Bacula can be helpful for smaller
+          (older) libraries and single drives.  Limiting the number of
+          times a tape is used might prevent tape errors when using
+          tapes until the drives can't read it any more.  Also, checking
+          drive status during operation can prevent some failures (as I
+          [Arno] had to learn the hard way...)
 
-  Why:    This would allow users more control over their Volumes and
-          prevent disk based volumes from consuming too much space.
+  Notes:  First, Bacula could (and even does, to some limited extent)
+          record tape and drive usage.  For tapes, the number of mounts,
+          the amount of data, and the time the tape has actually been
+          running could be recorded.  Data fields for Read and Write
+          time and Number of mounts already exist in the catalog (I'm
+          not sure if VolBytes is the sum of all bytes ever written to
+          that volume by Bacula).  This information can be important
+          when determining which media to replace.  The ability to mark
+          Volumes as "used up" after a given number of write cycles
+          should also be implemented so that a tape is never actually
+          worn out.  For the tape drives known to Bacula, similar
+          information is interesting to determine the device status and
+          expected life time: Time it's been Reading and Writing, number
+          of tape Loads / Unloads / Errors.  This information is not yet
+          recorded as far as I [Arno] know.  A new volume status would
+          be necessary for the new state, like "Used up" or "Worn out".
+          Volumes with this state could be used for restores, but not
+          for writing. These volumes should be migrated first (assuming
+          migration is implemented) and, once they are no longer needed,
+          could be moved to a Trash pool.
 
-  Notes:  The following two directives might do the trick:
+          The next step would be to implement a drive cleaning setup.
+          Bacula already has knowledge about cleaning tapes.  Once it
+          has some information about cleaning cycles (measured in drive
+          run time, number of tapes used, or calender days, for example)
+          it can automatically execute tape cleaning (with an
+          autochanger, obviously) or ask for operator assistance loading
+          a cleaning tape.
 
-          Volume Data Retention = <time period>
-          Remove Volume After = <time period>
+          The final step would be to implement TAPEALERT checks not only
+          when changing tapes and only sending the information to the
+          administrator, but rather checking after each tape error,
+          checking on a regular basis (for example after each tape
+          file), and also before unloading and after loading a new tape.
+          Then, depending on the drives TAPEALERT state and the known
+          drive cleaning state Bacula could automatically schedule later
+          cleaning, clean immediately, or inform the operator.
 
-          The migration project should also remove a Volume that is
-          migrated. This might also work for tape Volumes.
+          Implementing this would perhaps require another catalog change
+          and perhaps major changes in SD code and the DIR-SD protocol,
+          so I'd only consider this worth implementing if it would
+          actually be used or even needed by many people.
 
-Item  8:  Implement a Python interface to the Bacula catalog.
-  Date:   28 October 2005
-  Origin: Kern
-  Status: 
+          Implementation of these projects could happen in three distinct
+          sub-projects: Measuring Tape and Drive usage, retiring
+          volumes, and handling drive cleaning and TAPEALERTs.
 
-  What:   Implement an interface for Python scripts to access
-          the catalog through Bacula.
+Item 11:  Allow skipping execution of Jobs
+  Date:   29 November 2005
+  Origin: Florian Schnabel <florian.schnabel at docufy dot de>
+  Status:
 
-  Why:    This will permit users to customize Bacula through
-          Python scripts.
+    What: An easy option to skip a certain job  on a certain date.
+     Why: You could then easily skip tape backups on holidays.  Especially
+          if you got no autochanger and can only fit one backup on a tape
+          that would be really handy, other jobs could proceed normally
+          and you won't get errors that way.
 
-Item  9:  Archival (removal) of User Files to Tape
+Item 12:  Add a scheduling syntax that permits weekly rotations
+   Date:  15 December 2006
+  Origin: Gregory Brauer (greg at wildbrain dot com)
+  Status:
 
-  Date:   Nov. 24/2005 
+   What:  Currently, Bacula only understands how to deal with weeks of the
+          month or weeks of the year in schedules.  This makes it impossible
+          to do a true weekly rotation of tapes.  There will always be a
+          discontinuity that will require disruptive manual intervention at
+          least monthly or yearly because week boundaries never align with
+          month or year boundaries.
 
-  Origin: Ray Pengelly [ray at biomed dot queensu dot ca
-  Status: 
+          A solution would be to add a new syntax that defines (at least)
+          a start timestamp, and repetition period.
 
-  What:   The ability to archive data to storage based on certain parameters
-          such as age, size, or location.  Once the data has been written to
-          storage and logged it is then pruned from the originating
-          filesystem. Note! We are talking about user's files and not
+   Why:   Rotated backups done at weekly intervals are useful, and Bacula
+          cannot currently do them without extensive hacking.
+
+   Notes: Here is an example syntax showing a 3-week rotation where full
+          Backups would be performed every week on Saturday, and an
+          incremental would be performed every week on Tuesday.  Each
+          set of tapes could be removed from the loader for the following
+          two cycles before coming back and being reused on the third
+          week.  Since the execution times are determined by intervals
+          from a given point in time, there will never be any issues with
+          having to adjust to any sort of arbitrary time boundary.  In
+          the example provided, I even define the starting schedule
+          as crossing both a year and a month boundary, but the run times
+          would be based on the "Repeat" value and would therefore happen
+          weekly as desired.
+
+
+          Schedule {
+              Name = "Week 1 Rotation"
+              #Saturday.  Would run Dec 30, Jan 20, Feb 10, etc.
+              Run {
+                  Options {
+                      Type   = Full
+                      Start  = 2006-12-30 01:00
+                      Repeat = 3w
+                  }
+              }
+              #Tuesday.  Would run Jan 2, Jan 23, Feb 13, etc.
+              Run {
+                  Options {
+                      Type   = Incremental
+                      Start  = 2007-01-02 01:00
+                      Repeat = 3w
+                  }
+              }
+          }
+
+          Schedule {
+              Name = "Week 2 Rotation"
+              #Saturday.  Would run Jan 6, Jan 27, Feb 17, etc.
+              Run {
+                  Options {
+                      Type   = Full
+                      Start  = 2007-01-06 01:00
+                      Repeat = 3w
+                  }
+              }
+              #Tuesday.  Would run Jan 9, Jan 30, Feb 20, etc.
+              Run {
+                  Options {
+                      Type   = Incremental
+                      Start  = 2007-01-09 01:00
+                      Repeat = 3w
+                  }
+              }
+          }
+
+          Schedule {
+              Name = "Week 3 Rotation"
+              #Saturday.  Would run Jan 13, Feb 3, Feb 24, etc.
+              Run {
+                  Options {
+                      Type   = Full
+                      Start  = 2007-01-13 01:00
+                      Repeat = 3w
+                  }
+              }
+              #Tuesday.  Would run Jan 16, Feb 6, Feb 27, etc.
+              Run {
+                  Options {
+                      Type   = Incremental
+                      Start  = 2007-01-16 01:00
+                      Repeat = 3w
+                  }
+              }
+          }
+
+Item 13:  Archival (removal) of User Files to Tape
+  Date:   Nov. 24/2005 
+  Origin: Ray Pengelly [ray at biomed dot queensu dot ca
+  Status: 
+
+  What:   The ability to archive data to storage based on certain parameters
+          such as age, size, or location.  Once the data has been written to
+          storage and logged it is then pruned from the originating
+          filesystem. Note! We are talking about user's files and not
           Bacula Volumes.
 
   Why:    This would allow fully automatic storage management which becomes
@@ -297,7 +488,58 @@ Item  9:  Archival (removal) of User Files to Tape
           access time.  Then after another 6 months (or possibly as one
           storage pool gets full) data is migrated to Tape.
 
-Item 10:  Add Plug-ins to the FileSet Include statements.
+Item 14:  Cause daemons to use a specific IP address to source communications
+ Origin:  Bill Moran <wmoran@collaborativefusion.com>
+ Date:    18 Dec 2006
+ Status:
+ What:    Cause Bacula daemons (dir, fd, sd) to always use the ip address
+          specified in the [DIR|DF|SD]Addr directive as the source IP
+          for initiating communication.
+ Why:     On complex networks, as well as extremely secure networks, it's
+          not unusual to have multiple possible routes through the network.
+          Often, each of these routes is secured by different policies
+          (effectively, firewalls allow or deny different traffic depending
+          on the source address)
+          Unfortunately, it can sometimes be difficult or impossible to
+          represent this in a system routing table, as the result is
+          excessive subnetting that quickly exhausts available IP space.
+          The best available workaround is to provide multiple IPs to
+          a single machine that are all on the same subnet.  In order
+          for this to work properly, applications must support the ability
+          to bind outgoing connections to a specified address, otherwise
+          the operating system will always choose the first IP that
+          matches the required route.
+ Notes:   Many other programs support this.  For example, the following
+          can be configured in BIND:
+          query-source address 10.0.0.1;
+          transfer-source 10.0.0.2;
+          Which means queries from this server will always come from
+          10.0.0.1 and zone transfers will always originate from
+          10.0.0.2.
+
+Item 15:  Multiple threads in file daemon for the same job
+  Date:   27 November 2005
+  Origin: Ove Risberg (Ove.Risberg at octocode dot com)
+  Status:
+
+  What:   I want the file daemon to start multiple threads for a backup
+          job so the fastest possible backup can be made.
+
+          The file daemon could parse the FileSet information and start
+          one thread for each File entry located on a separate
+          filesystem.
+
+          A confiuration option in the job section should be used to
+          enable or disable this feature. The confgutration option could
+          specify the maximum number of threads in the file daemon.
+
+          If the theads could spool the data to separate spool files
+          the restore process will not be much slower.
+
+  Why:    Multiple concurrent backups of a large fileserver with many
+          disks and controllers will be much faster.
+
+Item 16:  Add Plug-ins to the FileSet Include statements.
   Date:   28 October 2005
   Origin:
   Status: Partially coded in 1.37 -- much more to do.
@@ -313,31 +555,28 @@ Item 10:  Add Plug-ins to the FileSet Include statements.
           plug-in knows how to backup his Oracle database without
           stopping/starting it, for example.
 
-Item 11:  Implement more Python events in Bacula.
-  Date:   28 October 2005
-  Origin: Kern
-  Status: 
-
-  What:   Allow Python scripts to be called at more places 
-          within Bacula and provide additional access to Bacula
-          internal variables.
-
-  Why:    This will permit users to customize Bacula through
-          Python scripts.
+Item 17:  Restore only file attributes (permissions, ACL, owner, group...)
+  Origin: Eric Bollengier
+  Date:   30/12/2006
+  Status:
 
-  Notes:  Recycle event
-          Scratch pool event
-          NeedVolume event
-          MediaFull event
-           
-          Also add a way to get a listing of currently running
-          jobs (possibly also scheduled jobs).
+  What:   The goal of this project is to be able to restore only rights
+          and attributes of files without crushing them.
 
+  Why:    Who have never had to repair a chmod -R 777, or a wild update
+          of recursive right under Windows? At this time, you must have
+          enough space to restore data, dump attributes (easy with acl,
+          more complex with unix/windows rights) and apply them to your 
+          broken tree. With this options, it will be very easy to compare
+          right or ACL over the time.
 
-Item 12:  Quick release of FD-SD connection after backup.
+  Notes:  If the file is here, we skip restore and we change rights.
+          If the file isn't here, we can create an empty one and apply
+          rights or do nothing.
+Item 18:  Quick release of FD-SD connection after backup.
   Origin: Frank Volf (frank at deze dot org)
   Date:   17 November 2005
-  Status:
+  Status: Done -- implemented by Kern -- in CVS 26Jan07
 
    What:  In the Bacula implementation a backup is finished after all data
           and attributes are successfully written to storage.  When using a
@@ -371,49 +610,49 @@ Item 12:  Quick release of FD-SD connection after backup.
 
    Why:   Makes backup of laptops much faster.
 
-
-
-Item 13:  Implement huge exclude list support using hashing.
+Item 19:  Implement a Python interface to the Bacula catalog.
   Date:   28 October 2005
   Origin: Kern
   Status: 
 
-  What:   Allow users to specify very large exclude list (currently
-          more than about 1000 files is too many).
-
-  Why:    This would give the users the ability to exclude all
-          files that are loaded with the OS (e.g. using rpms
-          or debs). If the user can restore the base OS from
-          CDs, there is no need to backup all those files. A
-          complete restore would be to restore the base OS, then
-          do a Bacula restore. By excluding the base OS files, the
-          backup set will be *much* smaller.
+  What:   Implement an interface for Python scripts to access
+          the catalog through Bacula.
 
+  Why:    This will permit users to customize Bacula through
+          Python scripts.
 
-Item 14:  Allow skipping execution of Jobs
-  Date:   29 November 2005
-  Origin: Florian Schnabel <florian.schnabel at docufy dot de>
+Item 20:  Archive data
+  Date:   15/5/2006
+  Origin: calvin streeting calvin at absentdream dot com
   Status:
 
-    What: An easy option to skip a certain job  on a certain date.
-     Why: You could then easily skip tape backups on holidays.  Especially
-          if you got no autochanger and can only fit one backup on a tape
-          that would be really handy, other jobs could proceed normally
-          and you won't get errors that way.
-
+  What:   The abilty to archive to media (dvd/cd) in a uncompressed format
+          for dead filing (archiving not backing up)
 
-Item 15:  Tray monitor window cleanups
-  Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
-  Date:   24 July 2006
-  Status:
-  What:   Resizeable and scrollable windows in the tray monitor.
+    Why:  At my works when jobs are finished and moved off of the main file
+          servers (raid based systems) onto a simple linux file server (ide based
+          system) so users can find old information without contacting the IT
+          dept.
 
-  Why:    With multiple clients, or with many jobs running, the displayed
-          window often ends up larger than the available screen, making
-          the trailing items difficult to read.
+          So this data dosn't realy change it only gets added to,
+          But it also needs backing up.  At the moment it takes
+          about 8 hours to back up our servers (working data) so
+          rather than add more time to existing backups i am trying
+          to implement a system where we backup the acrhive data to
+          cd/dvd these disks would only need to be appended to
+          (burn only new/changed files to new disks for off site
+          storage).  basialy understand the differnce between
+          achive data and live data.
 
+  Notes:  Scan the data and email me when it needs burning divide
+          into predifind chunks keep a recored of what is on what
+          disk make me a label (simple php->mysql=>pdf stuff) i
+          could do this bit ability to save data uncompresed so
+          it can be read in any other system (future proof data)
+          save the catalog with the disk as some kind of menu
+          system 
 
-Item 16:  Split documentation
+Item 21:  Split documentation
   Origin: Maxx <maxxatworkat gmail dot com>
   Date:   27th July 2006
   Status:
@@ -435,27 +674,64 @@ Item 16:  Split documentation
              etc.
 
 
+Item 22:  Implement support for stacking arbitrary stream filters, sinks.
+Date:     23 November 2006
+Origin:   Landon Fuller <landonf@threerings.net>
+Status:   Planning. Assigned to landonf.
 
-Item 17:  Automatic promotion of backup levels
-   Date:  19 January 2006
-  Origin: Adam Thornton <athornton@sinenomine.net>
-  Status: 
-
-    What: Amanda has a feature whereby it estimates the space that a  
-          differential, incremental, and full backup would take.  If the  
-          difference in space required between the scheduled level and the next  
-          level up is beneath some user-defined critical threshold, the backup  
-          level is bumped to the next type.  Doing this minimizes the number of  
-          volumes necessary during a restore, with a fairly minimal cost in  
-          backup media space.
-
-    Why:  I know at least one (quite sophisticated and smart) user  
-          for whom the absence of this feature is a deal-breaker in terms of  
-          using Bacula; if we had it it would eliminate the one cool thing  
-          Amanda can do and we can't (at least, the one cool thing I know of).
+  What:   Implement support for the following:
+          - Stacking arbitrary stream filters (eg, encryption, compression,  
+            sparse data handling))
+          - Attaching file sinks to terminate stream filters (ie, write out  
+            the resultant data to a file)
+          - Refactor the restoration state machine accordingly
 
+   Why:   The existing stream implementation suffers from the following:
+           - All state (compression, encryption, stream restoration), is  
+             global across the entire restore process, for all streams. There are  
+             multiple entry and exit points in the restoration state machine, and  
+             thus multiple places where state must be allocated, deallocated,  
+             initialized, or reinitialized. This results in exceptional complexity  
+             for the author of a stream filter.
+           - The developer must enumerate all possible combinations of filters  
+             and stream types (ie, win32 data with encryption, without encryption,  
+             with encryption AND compression, etc).
 
-Item 18:  Add an override in Schedule for Pools based on backup types.
+  Notes:  This feature request only covers implementing the stream filters/ 
+          sinks, and refactoring the file daemon's restoration implementation  
+          accordingly. If I have extra time, I will also rewrite the backup  
+          implementation. My intent in implementing the restoration first is to  
+          solve pressing bugs in the restoration handling, and to ensure that  
+          the new restore implementation handles existing backups correctly.
+
+          I do not plan on changing the network or tape data structures to  
+          support defining arbitrary stream filters, but supporting that  
+          functionality is the ultimate goal.
+
+          Assistance with either code or testing would be fantastic.
+
+Item 23:  Implement from-client and to-client on restore command line.
+   Date:  11 December 2006
+  Origin: Discussion on Bacula-users entitled 'Scripted restores to
+          different clients', December 2006 
+  Status: New feature request
+ 
+  What:   While using bconsole interactively, you can specify the client
+          that a backup job is to be restored for, and then you can
+          specify later a different client to send the restored files
+          back to. However, using the 'restore' command with all options
+          on the command line, this cannot be done, due to the ambiguous
+          'client' parameter. Additionally, this parameter means different
+          things depending on if it's specified on the command line or
+          afterwards, in the Modify Job screens.
+ 
+     Why: This feature would enable restore jobs to be more completely
+          automated, for example by a web or GUI front-end.
+ 
+   Notes: client can also be implied by specifying the jobid on the command
+          line
+
+Item 24:  Add an override in Schedule for Pools based on backup types.
 Date:     19 Jan 2005
 Origin:   Chad Slater <chad.slater@clickfox.com>
 Status: 
@@ -474,86 +750,106 @@ Status:
           backups, then the Full job would use the proper Storage device, which
           has more capacity (i.e. a 8TB tape library.
 
-Item 19:  An option to operate on all pools with update vol parameters
-  Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
-   Date:  16 August 2006
-  Status:
-
-   What:  When I do update -> Volume parameters -> All Volumes
-          from Pool, then I have to select pools one by one.  I'd like
-          console to have an option like "0: All Pools" in the list of
-          defined pools.
-
-   Why:   I have many pools and therefore unhappy with manually
-          updating each of them using update -> Volume parameters -> All
-          Volumes from Pool -> pool #.
-
-
+Item 25:  Implement huge exclude list support using hashing.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: 
 
-Item 20:  Include JobID in spool file name ****DONE****
-  Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
-  Date:   Tue Aug 22 17:13:39 EDT 2006
-  Status: Done. (patches/testing/project-include-jobid-in-spool-name.patch)
-          No need to vote for this item.
+  What:   Allow users to specify very large exclude list (currently
+          more than about 1000 files is too many).
 
-  What:   Change the name of the spool file to include the JobID
+  Why:    This would give the users the ability to exclude all
+          files that are loaded with the OS (e.g. using rpms
+          or debs). If the user can restore the base OS from
+          CDs, there is no need to backup all those files. A
+          complete restore would be to restore the base OS, then
+          do a Bacula restore. By excluding the base OS files, the
+          backup set will be *much* smaller.
 
-  Why:    JobIDs are the common key used to refer to jobs, yet the 
-          spoolfile name doesn't include that information. The date/time
-          stamp is useful (and should be retained).
+Item 26:  Implement more Python events in Bacula.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: 
 
+  What:   Allow Python scripts to be called at more places 
+          within Bacula and provide additional access to Bacula
+          internal variables.
 
+  Why:    This will permit users to customize Bacula through
+          Python scripts.
 
-Item 21:  Include timestamp of job launch in "stat clients" output
-  Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
-  Date:   Tue Aug 22 17:13:39 EDT 2006
-  Status:
+  Notes:  Recycle event
+          Scratch pool event
+          NeedVolume event
+          MediaFull event
+           
+          Also add a way to get a listing of currently running
+          jobs (possibly also scheduled jobs).
 
-  What:   The "stat clients" command doesn't include any detail on when
-          the active backup jobs were launched.
 
-  Why:    Including the timestamp would make it much easier to decide whether
-          a job is running properly. 
+Item 27:  Incorporation of XACML2/SAML2 parsing
+   Date:   19 January 2006
+   Origin: Adam Thornton <athornton@sinenomine.net>
+   Status: Blue sky
 
-  Notes:  It may be helpful to have the output from "stat clients" formatted 
-          more like that from "stat dir" (and other commands), in a column
-          format. The per-client information that's currently shown (level,
-          client name, JobId, Volume, pool, device, Files, etc.) is good, but
-          somewhat hard to parse (both programmatically and visually), 
-          particularly when there are many active clients.
+   What:   XACML is "eXtensible Access Control Markup Language" and  
+          "SAML is the "Security Assertion Markup Language"--an XML standard  
+          for making statements about identity and authorization.  Having these  
+          would give us a framework to approach ACLs in a generic manner, and  
+          in a way flexible enough to support the four major sorts of ACLs I  
+          see as a concern to Bacula at this point, as well as (probably) to  
+          deal with new sorts of ACLs that may appear in the future.
 
+   Why:    Bacula is beginning to need to back up systems with ACLs  
+          that do not map cleanly onto traditional Unix permissions.  I see  
+          four sets of ACLs--in general, mutually incompatible with one  
+          another--that we're going to need to deal with.  These are: NTFS  
+          ACLs, POSIX ACLs, NFSv4 ACLS, and AFS ACLS.  (Some may question the  
+          relevance of AFS; AFS is one of Sine Nomine's core consulting  
+          businesses, and having a reputable file-level backup and restore  
+          technology for it (as Tivoli is probably going to drop AFS support  
+          soon since IBM no longer supports AFS) would be of huge benefit to  
+          our customers; we'd most likely create the AFS support at Sine Nomine  
+          for inclusion into the Bacula (and perhaps some changes to the  
+          OpenAFS volserver) core code.)
 
+          Now, obviously, Bacula already handles NTFS just fine.  However, I  
+          think there's a lot of value in implementing a generic ACL model, so  
+          that it's easy to support whatever particular instances of ACLs come  
+          down the pike: POSIX ACLS (think SELinux) and NFSv4 are the obvious  
+          things arriving in the Linux world in a big way in the near future.   
+          XACML, although overcomplicated for our needs, provides this  
+          framework, and we should be able to leverage other people's  
+          implementations to minimize the amount of work *we* have to do to get  
+          a generic ACL framework.  Basically, the costs of implementation are  
+          high, but they're largely both external to Bacula and already sunk.
 
-Item 22:  Message mailing based on backup types
- Origin:  Evan Kaufman <evan.kaufman@gmail.com>
-   Date:  January 6, 2006
- Status:
+Item 28:  Filesystem watch triggered backup.
+  Date:   31 August 2006
+  Origin: Jesper Krogh <jesper@krogh.cc>
+  Status: Unimplemented, depends probably on "client initiated backups"
 
-   What:  In the "Messages" resource definitions, allowing messages
-          to be mailed based on the type (backup, restore, etc.) and level
-          (full, differential, etc) of job that created the originating
-          message(s).
+  What:   With inotify and similar filesystem triggeret notification
+          systems is it possible to have the file-daemon to monitor
+          filesystem changes and initiate backup.
 
- Why:     It would, for example, allow someone's boss to be emailed
-          automatically only when a Full Backup job runs, so he can
-          retrieve the tapes for offsite storage, even if the IT dept.
-          doesn't (or can't) explicitly notify him.  At the same time, his
-          mailbox wouldnt be filled by notifications of Verifies, Restores,
-          or Incremental/Differential Backups (which would likely be kept
-          onsite).
+  Why:    There are 2 situations where this is nice to have.
+          1) It is possible to get a much finer-grained backup than
+             the fixed schedules used now.. A file created and deleted
+             a few hours later, can automatically be caught.
 
- Notes:   One way this could be done is through additional message types, for example:
+          2) The introduced load on the system will probably be
+             distributed more even on the system.
 
-   Messages {
-     # email the boss only on full system backups
-     Mail = boss@mycompany.com = full, !incremental, !differential, !restore, 
-            !verify, !admin
-     # email us only when something breaks
-     MailOnError = itdept@mycompany.com = all
-   }
+  Notes:  This can be combined with configration that specifies
+          something like: "at most every 15 minutes or when changes
+          consumed XX MB".
 
+Kern Notes: I would rather see this implemented by an external program
+          that monitors the Filesystem changes, then uses the console
+          to start the appropriate job.
 
-Item 23:  Allow inclusion/exclusion of files in a fileset by creation/mod times
+Item 29:  Allow inclusion/exclusion of files in a fileset by creation/mod times
   Origin: Evan Kaufman <evan.kaufman@gmail.com>
   Date:   January 11, 2006
   Status:
@@ -603,297 +899,57 @@ Item 23:  Allow inclusion/exclusion of files in a fileset by creation/mod times
            or 'since'.
 
 
-Item 24:  Add a scheduling syntax that permits weekly rotations
-   Date:  15 December 2006
-  Origin: Gregory Brauer (greg at wildbrain dot com)
+Item 30:  Tray monitor window cleanups
+  Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
+  Date:   24 July 2006
   Status:
+  What:   Resizeable and scrollable windows in the tray monitor.
 
-   What:  Currently, Bacula only understands how to deal with weeks of the
-          month or weeks of the year in schedules.  This makes it impossible
-          to do a true weekly rotation of tapes.  There will always be a
-          discontinuity that will require disruptive manual intervention at
-          least monthly or yearly because week boundaries never align with
-          month or year boundaries.
+  Why:    With multiple clients, or with many jobs running, the displayed
+          window often ends up larger than the available screen, making
+          the trailing items difficult to read.
 
-          A solution would be to add a new syntax that defines (at least)
-          a start timestamp, and repetition period.
 
-   Why:   Rotated backups done at weekly intervals are useful, and Bacula
-          cannot currently do them without extensive hacking.
+Item 31:  Implement multiple numeric backup levels as supported by dump
+Date:     3 April 2006
+Origin:   Daniel Rich <drich@employees.org>
+Status:
+What:     Dump allows specification of backup levels numerically instead of just
+          "full", "incr", and "diff".  In this system, at any given level, all
+          files are backed up that were were modified since the last backup of a
+          higher level (with 0 being the highest and 9 being the lowest).  A
+          level 0 is therefore equivalent to a full, level 9 an incremental, and
+          the levels 1 through 8 are varying levels of differentials.  For
+          bacula's sake, these could be represented as "full", "incr", and
+          "diff1", "diff2", etc.
 
-   Notes: Here is an example syntax showing a 3-week rotation where full
-          Backups would be performed every week on Saturday, and an
-          incremental would be performed every week on Tuesday.  Each
-          set of tapes could be removed from the loader for the following
-          two cycles before coming back and being reused on the third
-          week.  Since the execution times are determined by intervals
-          from a given point in time, there will never be any issues with
-          having to adjust to any sort of arbitrary time boundary.  In
-          the example provided, I even define the starting schedule
-          as crossing both a year and a month boundary, but the run times
-          would be based on the "Repeat" value and would therefore happen
-          weekly as desired.
+Why:      Support of multiple backup levels would provide for more advanced backup
+          rotation schemes such as "Towers of Hanoi".  This would allow better
+          flexibility in performing backups, and can lead to shorter recover
+          times.
 
+Notes:    Legato Networker supports a similar system with full, incr, and 1-9 as
+          levels.
+        
+Item 32:  Automatic promotion of backup levels
+   Date:  19 January 2006
+  Origin: Adam Thornton <athornton@sinenomine.net>
+  Status: 
 
-          Schedule {
-              Name = "Week 1 Rotation"
-              #Saturday.  Would run Dec 30, Jan 20, Feb 10, etc.
-              Run {
-                  Options {
-                      Type   = Full
-                      Start  = 2006-12-30 01:00
-                      Repeat = 3w
-                  }
-              }
-              #Tuesday.  Would run Jan 2, Jan 23, Feb 13, etc.
-              Run {
-                  Options {
-                      Type   = Incremental
-                      Start  = 2007-01-02 01:00
-                      Repeat = 3w
-                  }
-              }
-          }
-
-          Schedule {
-              Name = "Week 2 Rotation"
-              #Saturday.  Would run Jan 6, Jan 27, Feb 17, etc.
-              Run {
-                  Options {
-                      Type   = Full
-                      Start  = 2007-01-06 01:00
-                      Repeat = 3w
-                  }
-              }
-              #Tuesday.  Would run Jan 9, Jan 30, Feb 20, etc.
-              Run {
-                  Options {
-                      Type   = Incremental
-                      Start  = 2007-01-09 01:00
-                      Repeat = 3w
-                  }
-              }
-          }
-
-          Schedule {
-              Name = "Week 3 Rotation"
-              #Saturday.  Would run Jan 13, Feb 3, Feb 24, etc.
-              Run {
-                  Options {
-                      Type   = Full
-                      Start  = 2007-01-13 01:00
-                      Repeat = 3w
-                  }
-              }
-              #Tuesday.  Would run Jan 16, Feb 6, Feb 27, etc.
-              Run {
-                  Options {
-                      Type   = Incremental
-                      Start  = 2007-01-16 01:00
-                      Repeat = 3w
-                  }
-              }
-          }
-
-
-Item 25:  Improve Bacula's tape and drive usage and cleaning management.
-  Date:   8 November 2005, November 11, 2005
-  Origin: Adam Thornton <athornton at sinenomine dot net>,
-          Arno Lehmann <al at its-lehmann dot de>
-  Status:
-
-  What:   Make Bacula manage tape life cycle information, tape reuse
-          times and drive cleaning cycles.
-
-  Why:    All three parts of this project are important when operating
-          backups.
-          We need to know which tapes need replacement, and we need to
-          make sure the drives are cleaned when necessary.  While many
-          tape libraries and even autoloaders can handle all this
-          automatically, support by Bacula can be helpful for smaller
-          (older) libraries and single drives.  Limiting the number of
-          times a tape is used might prevent tape errors when using
-          tapes until the drives can't read it any more.  Also, checking
-          drive status during operation can prevent some failures (as I
-          [Arno] had to learn the hard way...)
-
-  Notes:  First, Bacula could (and even does, to some limited extent)
-          record tape and drive usage.  For tapes, the number of mounts,
-          the amount of data, and the time the tape has actually been
-          running could be recorded.  Data fields for Read and Write
-          time and Number of mounts already exist in the catalog (I'm
-          not sure if VolBytes is the sum of all bytes ever written to
-          that volume by Bacula).  This information can be important
-          when determining which media to replace.  The ability to mark
-          Volumes as "used up" after a given number of write cycles
-          should also be implemented so that a tape is never actually
-          worn out.  For the tape drives known to Bacula, similar
-          information is interesting to determine the device status and
-          expected life time: Time it's been Reading and Writing, number
-          of tape Loads / Unloads / Errors.  This information is not yet
-          recorded as far as I [Arno] know.  A new volume status would
-          be necessary for the new state, like "Used up" or "Worn out".
-          Volumes with this state could be used for restores, but not
-          for writing. These volumes should be migrated first (assuming
-          migration is implemented) and, once they are no longer needed,
-          could be moved to a Trash pool.
-
-          The next step would be to implement a drive cleaning setup.
-          Bacula already has knowledge about cleaning tapes.  Once it
-          has some information about cleaning cycles (measured in drive
-          run time, number of tapes used, or calender days, for example)
-          it can automatically execute tape cleaning (with an
-          autochanger, obviously) or ask for operator assistance loading
-          a cleaning tape.
-
-          The final step would be to implement TAPEALERT checks not only
-          when changing tapes and only sending the information to the
-          administrator, but rather checking after each tape error,
-          checking on a regular basis (for example after each tape
-          file), and also before unloading and after loading a new tape.
-          Then, depending on the drives TAPEALERT state and the known
-          drive cleaning state Bacula could automatically schedule later
-          cleaning, clean immediately, or inform the operator.
-
-          Implementing this would perhaps require another catalog change
-          and perhaps major changes in SD code and the DIR-SD protocol,
-          so I'd only consider this worth implementing if it would
-          actually be used or even needed by many people.
-
-          Implementation of these projects could happen in three distinct
-          sub-projects: Measuring Tape and Drive usage, retiring
-          volumes, and handling drive cleaning and TAPEALERTs.
-
-Item 26:  Implement support for stacking arbitrary stream filters, sinks.
-Date:     23 November 2006
-Origin:   Landon Fuller <landonf@threerings.net>
-Status:   Planning. Assigned to landonf.
-
-  What:   Implement support for the following:
-          - Stacking arbitrary stream filters (eg, encryption, compression,  
-            sparse data handling))
-          - Attaching file sinks to terminate stream filters (ie, write out  
-            the resultant data to a file)
-          - Refactor the restoration state machine accordingly
-
-   Why:   The existing stream implementation suffers from the following:
-           - All state (compression, encryption, stream restoration), is  
-             global across the entire restore process, for all streams. There are  
-             multiple entry and exit points in the restoration state machine, and  
-             thus multiple places where state must be allocated, deallocated,  
-             initialized, or reinitialized. This results in exceptional complexity  
-             for the author of a stream filter.
-           - The developer must enumerate all possible combinations of filters  
-             and stream types (ie, win32 data with encryption, without encryption,  
-             with encryption AND compression, etc).
-
-  Notes:  This feature request only covers implementing the stream filters/ 
-          sinks, and refactoring the file daemon's restoration implementation  
-          accordingly. If I have extra time, I will also rewrite the backup  
-          implementation. My intent in implementing the restoration first is to  
-          solve pressing bugs in the restoration handling, and to ensure that  
-          the new restore implementation handles existing backups correctly.
-
-          I do not plan on changing the network or tape data structures to  
-          support defining arbitrary stream filters, but supporting that  
-          functionality is the ultimate goal.
-
-          Assistance with either code or testing would be fantastic.
-
-Item 27:  Allow FD to initiate a backup
-  Origin: Frank Volf (frank at deze dot org)
-  Date:   17 November 2005
-  Status:
-
-   What:  Provide some means, possibly by a restricted console that
-          allows a FD to initiate a backup, and that uses the connection
-          established by the FD to the Director for the backup so that
-          a Director that is firewalled can do the backup.
-
-   Why:   Makes backup of laptops much easier.
-
-Item 28:  Directive/mode to backup only file changes, not entire file
-  Date:   11 November 2005
-  Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
-          Marek Bajon <mbajon at bimsplus dot com dot pl>
-  Status: 
-
-  What:   Currently when a file changes, the entire file will be backed up in
-          the next incremental or full backup.  To save space on the tapes
-          it would be nice to have a mode whereby only the changes to the
-          file would be backed up when it is changed.
-
-  Why:    This would save lots of space when backing up large files such as 
-          logs, mbox files, Outlook PST files and the like.
-
-  Notes:  This would require the usage of disk-based volumes as comparing 
-          files would not be feasible using a tape drive.
-
-Item 29:  Automatic disabling of devices
-   Date:  2005-11-11
-  Origin: Peter Eriksson <peter at ifm.liu dot se>
-  Status:
-
-   What:  After a configurable amount of fatal errors with a tape drive
-          Bacula should automatically disable further use of a certain
-          tape drive. There should also be "disable"/"enable" commands in
-          the "bconsole" tool.
-
-   Why:   On a multi-drive jukebox there is a possibility of tape drives
-          going bad during large backups (needing a cleaning tape run,
-          tapes getting stuck). It would be advantageous if Bacula would
-          automatically disable further use of a problematic tape drive
-          after a configurable amount of errors has occurred.
-
-          An example: I have a multi-drive jukebox (6 drives, 380+ slots)
-          where tapes occasionally get stuck inside the drive. Bacula will
-          notice that the "mtx-changer" command will fail and then fail
-          any backup jobs trying to use that drive. However, it will still
-          keep on trying to run new jobs using that drive and fail -
-          forever, and thus failing lots and lots of jobs... Since we have
-          many drives Bacula could have just automatically disabled
-          further use of that drive and used one of the other ones
-          instead.
-
-Item 30:  Incorporation of XACML2/SAML2 parsing
-   Date:   19 January 2006
-   Origin: Adam Thornton <athornton@sinenomine.net>
-   Status: Blue sky
-
-   What:   XACML is "eXtensible Access Control Markup Language" and  
-          "SAML is the "Security Assertion Markup Language"--an XML standard  
-          for making statements about identity and authorization.  Having these  
-          would give us a framework to approach ACLs in a generic manner, and  
-          in a way flexible enough to support the four major sorts of ACLs I  
-          see as a concern to Bacula at this point, as well as (probably) to  
-          deal with new sorts of ACLs that may appear in the future.
-
-   Why:    Bacula is beginning to need to back up systems with ACLs  
-          that do not map cleanly onto traditional Unix permissions.  I see  
-          four sets of ACLs--in general, mutually incompatible with one  
-          another--that we're going to need to deal with.  These are: NTFS  
-          ACLs, POSIX ACLs, NFSv4 ACLS, and AFS ACLS.  (Some may question the  
-          relevance of AFS; AFS is one of Sine Nomine's core consulting  
-          businesses, and having a reputable file-level backup and restore  
-          technology for it (as Tivoli is probably going to drop AFS support  
-          soon since IBM no longer supports AFS) would be of huge benefit to  
-          our customers; we'd most likely create the AFS support at Sine Nomine  
-          for inclusion into the Bacula (and perhaps some changes to the  
-          OpenAFS volserver) core code.)
-
-          Now, obviously, Bacula already handles NTFS just fine.  However, I  
-          think there's a lot of value in implementing a generic ACL model, so  
-          that it's easy to support whatever particular instances of ACLs come  
-          down the pike: POSIX ACLS (think SELinux) and NFSv4 are the obvious  
-          things arriving in the Linux world in a big way in the near future.   
-          XACML, although overcomplicated for our needs, provides this  
-          framework, and we should be able to leverage other people's  
-          implementations to minimize the amount of work *we* have to do to get  
-          a generic ACL framework.  Basically, the costs of implementation are  
-          high, but they're largely both external to Bacula and already sunk.
+    What: Amanda has a feature whereby it estimates the space that a  
+          differential, incremental, and full backup would take.  If the  
+          difference in space required between the scheduled level and the next  
+          level up is beneath some user-defined critical threshold, the backup  
+          level is bumped to the next type.  Doing this minimizes the number of  
+          volumes necessary during a restore, with a fairly minimal cost in  
+          backup media space.
 
+    Why:  I know at least one (quite sophisticated and smart) user  
+          for whom the absence of this feature is a deal-breaker in terms of  
+          using Bacula; if we had it it would eliminate the one cool thing  
+          Amanda can do and we can't (at least, the one cool thing I know of).
 
-Item 31:  Clustered file-daemons
+Item 33:  Clustered file-daemons
   Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
   Date:   24 July 2006
   Status:
@@ -925,7 +981,7 @@ Item 31:  Clustered file-daemons
 
    Notes:
 
-Item 32:  Commercial database support
+Item 34:  Commercial database support
   Origin: Russell Howe <russell_howe dot wreckage dot org>
   Date:   26 July 2006
   Status:
@@ -946,176 +1002,47 @@ Item 32:  Commercial database support
           properly specced database server for storing Bacula's catalog, rather 
           than having to run a second DBMS.
 
-
-Item 33:  Archive data
-  Date:   15/5/2006
-  Origin: calvin streeting calvin at absentdream dot com
-  Status:
-
-  What:   The abilty to archive to media (dvd/cd) in a uncompressed format
-          for dead filing (archiving not backing up)
-
-    Why:  At my works when jobs are finished and moved off of the main file
-          servers (raid based systems) onto a simple linux file server (ide based
-          system) so users can find old information without contacting the IT
-          dept.
-
-          So this data dosn't realy change it only gets added to,
-          But it also needs backing up.  At the moment it takes
-          about 8 hours to back up our servers (working data) so
-          rather than add more time to existing backups i am trying
-          to implement a system where we backup the acrhive data to
-          cd/dvd these disks would only need to be appended to
-          (burn only new/changed files to new disks for off site
-          storage).  basialy understand the differnce between
-          achive data and live data.
-
-  Notes:  Scan the data and email me when it needs burning divide
-          into predifind chunks keep a recored of what is on what
-          disk make me a label (simple php->mysql=>pdf stuff) i
-          could do this bit ability to save data uncompresed so
-          it can be read in any other system (future proof data)
-          save the catalog with the disk as some kind of menu
-          system 
-
-Item 34:  Filesystem watch triggered backup.
-  Date:   31 August 2006
-  Origin: Jesper Krogh <jesper@krogh.cc>
-  Status: Unimplemented, depends probably on "client initiated backups"
-
-  What:   With inotify and similar filesystem triggeret notification
-          systems is it possible to have the file-daemon to monitor
-          filesystem changes and initiate backup.
-
-  Why:    There are 2 situations where this is nice to have.
-          1) It is possible to get a much finer-grained backup than
-             the fixed schedules used now.. A file created and deleted
-             a few hours later, can automatically be caught.
-
-          2) The introduced load on the system will probably be
-             distributed more even on the system.
-
-  Notes:  This can be combined with configration that specifies
-          something like: "at most every 15 minutes or when changes
-          consumed XX MB".
-
-Kern Notes: I would rather see this implemented by an external program
-          that monitors the Filesystem changes, then uses the console
-          to start the appropriate job.
-
-Item 35:  Implement multiple numeric backup levels as supported by dump
-Date:     3 April 2006
-Origin:   Daniel Rich <drich@employees.org>
-Status:
-What:     Dump allows specification of backup levels numerically instead of just
-          "full", "incr", and "diff".  In this system, at any given level, all
-          files are backed up that were were modified since the last backup of a
-          higher level (with 0 being the highest and 9 being the lowest).  A
-          level 0 is therefore equivalent to a full, level 9 an incremental, and
-          the levels 1 through 8 are varying levels of differentials.  For
-          bacula's sake, these could be represented as "full", "incr", and
-          "diff1", "diff2", etc.
-
-Why:      Support of multiple backup levels would provide for more advanced backup
-          rotation schemes such as "Towers of Hanoi".  This would allow better
-          flexibility in performing backups, and can lead to shorter recover
-          times.
-
-Notes:    Legato Networker supports a similar system with full, incr, and 1-9 as
-          levels.
-
-Item 36:  Implement a server-side compression feature
-  Date:   18 December 2006
-  Origin: Vadim A. Umanski , e-mail umanski@ext.ru
-  Status:
-  What:   The ability to compress backup data on server receiving data
-          instead of doing that on client sending data.
-  Why:    The need is practical. I've got some machines that can send
-          data to the network 4 or 5 times faster than compressing
-          them (I've measured that). They're using fast enough SCSI/FC
-          disk subsystems but rather slow CPUs (ex. UltraSPARC II).
-          And the backup server has got a quite fast CPUs (ex. Dual P4
-          Xeons) and quite a low load. When you have 20, 50 or 100 GB
-          of raw data - running a job 4 to 5 times faster - that
-          really matters. On the other hand, the data can be
-          compressed 50% or better - so losing twice more space for
-          disk backup is not good at all. And the network is all mine
-          (I have a dedicated management/provisioning network) and I
-          can get as high bandwidth as I need - 100Mbps, 1000Mbps...
-          That's why the server-side compression feature is needed!
-  Notes:
-
-Item 37:  Cause daemons to use a specific IP address to source communications
- Origin:  Bill Moran <wmoran@collaborativefusion.com>
- Date:    18 Dec 2006
- Status:
- What:    Cause Bacula daemons (dir, fd, sd) to always use the ip address
-          specified in the [DIR|DF|SD]Addr directive as the source IP
-          for initiating communication.
- Why:     On complex networks, as well as extremely secure networks, it's
-          not unusual to have multiple possible routes through the network.
-          Often, each of these routes is secured by different policies
-          (effectively, firewalls allow or deny different traffic depending
-          on the source address)
-          Unfortunately, it can sometimes be difficult or impossible to
-          represent this in a system routing table, as the result is
-          excessive subnetting that quickly exhausts available IP space.
-          The best available workaround is to provide multiple IPs to
-          a single machine that are all on the same subnet.  In order
-          for this to work properly, applications must support the ability
-          to bind outgoing connections to a specified address, otherwise
-          the operating system will always choose the first IP that
-          matches the required route.
- Notes:   Many other programs support this.  For example, the following
-          can be configured in BIND:
-          query-source address 10.0.0.1;
-          transfer-source 10.0.0.2;
-          Which means queries from this server will always come from
-          10.0.0.1 and zone transfers will always originate from
-          10.0.0.2.
-
-Item 38:  Multiple threads in file daemon for the same job
-  Date:   27 November 2005
-  Origin: Ove Risberg (Ove.Risberg at octocode dot com)
+Item 35:  Automatic disabling of devices
+   Date:  2005-11-11
+  Origin: Peter Eriksson <peter at ifm.liu dot se>
   Status:
 
-  What:   I want the file daemon to start multiple threads for a backup
-          job so the fastest possible backup can be made.
-
-          The file daemon could parse the FileSet information and start
-          one thread for each File entry located on a separate
-          filesystem.
-
-          A confiuration option in the job section should be used to
-          enable or disable this feature. The confgutration option could
-          specify the maximum number of threads in the file daemon.
+   What:  After a configurable amount of fatal errors with a tape drive
+          Bacula should automatically disable further use of a certain
+          tape drive. There should also be "disable"/"enable" commands in
+          the "bconsole" tool.
 
-          If the theads could spool the data to separate spool files
-          the restore process will not be much slower.
+   Why:   On a multi-drive jukebox there is a possibility of tape drives
+          going bad during large backups (needing a cleaning tape run,
+          tapes getting stuck). It would be advantageous if Bacula would
+          automatically disable further use of a problematic tape drive
+          after a configurable amount of errors has occurred.
 
-  Why:    Multiple concurrent backups of a large fileserver with many
-          disks and controllers will be much faster.
+          An example: I have a multi-drive jukebox (6 drives, 380+ slots)
+          where tapes occasionally get stuck inside the drive. Bacula will
+          notice that the "mtx-changer" command will fail and then fail
+          any backup jobs trying to use that drive. However, it will still
+          keep on trying to run new jobs using that drive and fail -
+          forever, and thus failing lots and lots of jobs... Since we have
+          many drives Bacula could have just automatically disabled
+          further use of that drive and used one of the other ones
+          instead.
 
-Item 39:  Restore only file attributes (permissions, ACL, owner, group...)
-  Origin: Eric Bollengier
-  Date:   30/12/2006
+Item 36:  An option to operate on all pools with update vol parameters
+  Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
+   Date:  16 August 2006
   Status:
 
-  What:   The goal of this project is to be able to restore only rights
-          and attributes of files without crushing them.
-
-  Why:    Who have never had to repair a chmod -R 777, or a wild update
-          of recursive right under Windows? At this time, you must have
-          enough space to restore data, dump attributes (easy with acl,
-          more complex with unix/windows rights) and apply them to your 
-          broken tree. With this options, it will be very easy to compare
-          right or ACL over the time.
+   What:  When I do update -> Volume parameters -> All Volumes
+          from Pool, then I have to select pools one by one.  I'd like
+          console to have an option like "0: All Pools" in the list of
+          defined pools.
 
-  Notes:  If the file is here, we skip restore and we change rights.
-          If the file isn't here, we can create an empty one and apply
-          rights or do nothing.
+   Why:   I have many pools and therefore unhappy with manually
+          updating each of them using update -> Volume parameters -> All
+          Volumes from Pool -> pool #.
 
-Item 40:  Add an item to the restore option where you can select a pool
+Item 37:  Add an item to the restore option where you can select a pool
   Origin: kshatriyak at gmail dot com
     Date: 1/1/2006
   Status:
@@ -1138,6 +1065,66 @@ Item 40:  Add an item to the restore option where you can select a pool
           when you have 2 pools is to manually search for the right
           job-id's and enter them by hand, which is a bit fault tolerant.
 
+Item 38:  Include timestamp of job launch in "stat clients" output
+  Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
+  Date:   Tue Aug 22 17:13:39 EDT 2006
+  Status:
+
+  What:   The "stat clients" command doesn't include any detail on when
+          the active backup jobs were launched.
+
+  Why:    Including the timestamp would make it much easier to decide whether
+          a job is running properly. 
+
+  Notes:  It may be helpful to have the output from "stat clients" formatted 
+          more like that from "stat dir" (and other commands), in a column
+          format. The per-client information that's currently shown (level,
+          client name, JobId, Volume, pool, device, Files, etc.) is good, but
+          somewhat hard to parse (both programmatically and visually), 
+          particularly when there are many active clients.
+
+
+Item 39:  Message mailing based on backup types
+ Origin:  Evan Kaufman <evan.kaufman@gmail.com>
+   Date:  January 6, 2006
+ Status:
+
+   What:  In the "Messages" resource definitions, allowing messages
+          to be mailed based on the type (backup, restore, etc.) and level
+          (full, differential, etc) of job that created the originating
+          message(s).
+
+ Why:     It would, for example, allow someone's boss to be emailed
+          automatically only when a Full Backup job runs, so he can
+          retrieve the tapes for offsite storage, even if the IT dept.
+          doesn't (or can't) explicitly notify him.  At the same time, his
+          mailbox wouldnt be filled by notifications of Verifies, Restores,
+          or Incremental/Differential Backups (which would likely be kept
+          onsite).
+
+ Notes:   One way this could be done is through additional message types, for example:
+
+   Messages {
+     # email the boss only on full system backups
+     Mail = boss@mycompany.com = full, !incremental, !differential, !restore, 
+            !verify, !admin
+     # email us only when something breaks
+     MailOnError = itdept@mycompany.com = all
+   }
+
+
+Item 40:  Include JobID in spool file name ****DONE****
+  Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
+  Date:   Tue Aug 22 17:13:39 EDT 2006
+  Status: Done. (patches/testing/project-include-jobid-in-spool-name.patch)
+          No need to vote for this item.
+
+  What:   Change the name of the spool file to include the JobID
+
+  Why:    JobIDs are the common key used to refer to jobs, yet the 
+          spoolfile name doesn't include that information. The date/time
+          stamp is useful (and should be retained).
+
 ============= Empty Feature Request form ===========
 Item  n:  One line summary ...
   Date:   Date submitted 
diff --git a/bacula/src/c b/bacula/src/c
index 1e7eaf6c5e..86d1956942 100644
--- a/bacula/src/c
+++ b/bacula/src/c
@@ -1,7 +1,7 @@
 /*
    Bacula® - The Network Backup Solution
 
-   Copyright (C) 2000-2006 Free Software Foundation Europe e.V.
+   Copyright (C) 2000-2007 Free Software Foundation Europe e.V.
 
    The main author of Bacula is Kern Sibbald, with contributions from
    many others, a complete list can be found in the file AUTHORS.
diff --git a/bacula/src/cl b/bacula/src/cl
index eb9aac79dc..b7bca2315f 100644
--- a/bacula/src/cl
+++ b/bacula/src/cl
@@ -1,7 +1,7 @@
 /*
    Bacula® - The Network Backup Solution
 
-   Copyright (C) 2000-2006 Free Software Foundation Europe e.V.
+   Copyright (C) 2000-2007 Free Software Foundation Europe e.V.
 
    The main author of Bacula is Kern Sibbald, with contributions from
    many others, a complete list can be found in the file AUTHORS.
diff --git a/bacula/src/lib/smartall.h b/bacula/src/lib/smartall.h
index 3472566fda..a698593567 100644
--- a/bacula/src/lib/smartall.h
+++ b/bacula/src/lib/smartall.h
@@ -8,7 +8,7 @@
 /*
    Bacula® - The Network Backup Solution
 
-   Copyright (C) 2000-2006 Free Software Foundation Europe e.V.
+   Copyright (C) 2000-2007 Free Software Foundation Europe e.V.
 
    The main author of Bacula is Kern Sibbald, with contributions from
    many others, a complete list can be found in the file AUTHORS.
@@ -121,22 +121,25 @@ void  operator delete(void *ptr)
 }
 void  operator delete[](void *ptr, size_t i)
 {
+   (void)i;                           /* eliminate compiler complaints */
    free(ptr);
 }
 
 void  operator delete(void *ptr, const char *fname, int line)
 {
+   (void)fname; (void)line;          /* eliminate compiler complaints */
    free(ptr);
 }
 void  operator delete[](void *ptr, size_t i, const char *fname, int line)
 {
+   (void)i; (void)fname; (void)line; /* eliminate compiler complaints */
    free(ptr);
 }
 
 
 private:
-void *operator new(size_t s) throw() { return 0; }
-void *operator new[](size_t s) throw() { return 0; }
+void *operator new(size_t s) throw() { (void)s; return 0; }
+void *operator new[](size_t s) throw() { (void)s; return 0; }
 };
 
 
diff --git a/bacula/src/stored/append.c b/bacula/src/stored/append.c
index 6a57c14b47..402324fa4d 100644
--- a/bacula/src/stored/append.c
+++ b/bacula/src/stored/append.c
@@ -7,7 +7,7 @@
 /*
    Bacula® - The Network Backup Solution
 
-   Copyright (C) 2000-2006 Free Software Foundation Europe e.V.
+   Copyright (C) 2000-2007 Free Software Foundation Europe e.V.
 
    The main author of Bacula is Kern Sibbald, with contributions from
    many others, a complete list can be found in the file AUTHORS.
@@ -38,6 +38,7 @@
 
 /* Responses sent to the File daemon */
 static char OK_data[]    = "3000 OK data\n";
+static char OK_append[]  = "3000 OK append data\n";
 
 /* Forward referenced functions */
 
@@ -261,6 +262,14 @@ bool do_append_data(JCR *jcr)
       }
    }
 
+   /* Create Job status for end of session label */
+   set_jcr_job_status(jcr, ok?JS_Terminated:JS_ErrorTerminated);
+
+   /* Terminate connection with FD */
+   bnet_fsend(ds, OK_append);
+   do_fd_commands(jcr);               /* finish dialog with FD */
+
+
    time_t job_elapsed = time(NULL) - jcr->run_time;
 
    if (job_elapsed <= 0) {
@@ -271,8 +280,6 @@ bool do_append_data(JCR *jcr)
          job_elapsed / 3600, job_elapsed % 3600 / 60, job_elapsed % 60,
          edit_uint64_with_suffix(jcr->JobBytes / job_elapsed, ec));
 
-   /* Create Job status for end of session label */
-   set_jcr_job_status(jcr, ok?JS_Terminated:JS_ErrorTerminated);
 
    Dmsg1(200, "Write EOS label JobStatus=%c\n", jcr->JobStatus);
 
@@ -303,6 +310,8 @@ bool do_append_data(JCR *jcr)
       Pmsg0(000, _("NULL Volume name. This shouldn't happen!!!\n"));
    }
 
+
+
    if (!ok) {
       discard_data_spool(dcr);
    } else {
diff --git a/bacula/src/stored/fd_cmds.c b/bacula/src/stored/fd_cmds.c
index 47306f20b5..78a59331c9 100644
--- a/bacula/src/stored/fd_cmds.c
+++ b/bacula/src/stored/fd_cmds.c
@@ -15,7 +15,7 @@
 /*
    Bacula® - The Network Backup Solution
 
-   Copyright (C) 2000-2006 Free Software Foundation Europe e.V.
+   Copyright (C) 2000-2007 Free Software Foundation Europe e.V.
 
    The main author of Bacula is Kern Sibbald, with contributions from
    many others, a complete list can be found in the file AUTHORS.
@@ -95,7 +95,6 @@ static char NOT_opened[]      = "3902 Error session not opened\n";
 static char OK_end[]          = "3000 OK end\n";
 static char OK_close[]        = "3000 OK close Status = %d\n";
 static char OK_open[]         = "3000 OK open ticket = %d\n";
-static char OK_append[]       = "3000 OK append data\n";
 static char ERROR_append[]    = "3903 Error append data\n";
 static char OK_bootstrap[]    = "3000 OK bootstrap\n";
 static char ERROR_bootstrap[] = "3904 Error bootstrap\n";
@@ -107,6 +106,7 @@ char Job_end[]   =
 
 /*
  * Run a File daemon Job -- File daemon already authorized
+ *  Director sends us this command.
  *
  * Basic task here is:
  * - Read a command from the File daemon
@@ -115,14 +115,9 @@ char Job_end[]   =
  */
 void run_job(JCR *jcr)
 {
-   int i;
-   bool found, quit;
-   BSOCK *fd = jcr->file_bsock;
    BSOCK *dir = jcr->dir_bsock;
    char ec1[30];
 
-
-   fd->jcr = jcr;
    dir->jcr = jcr;
    Dmsg1(120, "Start run Job=%s\n", jcr->Job);
    bnet_fsend(dir, Job_start, jcr->Job);
@@ -130,6 +125,27 @@ void run_job(JCR *jcr)
    jcr->run_time = jcr->start_time;
    set_jcr_job_status(jcr, JS_Running);
    dir_send_job_status(jcr);          /* update director */
+   do_fd_commands(jcr);
+   jcr->end_time = time(NULL);
+   dequeue_messages(jcr);             /* send any queued messages */
+   set_jcr_job_status(jcr, JS_Terminated);
+   generate_daemon_event(jcr, "JobEnd");
+   bnet_fsend(dir, Job_end, jcr->Job, jcr->JobStatus, jcr->JobFiles,
+      edit_uint64(jcr->JobBytes, ec1));
+   bnet_sig(dir, BNET_EOD);           /* send EOD to Director daemon */
+   return;
+}
+
+/*
+ * Now talk to the FD and do what he says
+ */
+void do_fd_commands(JCR *jcr)
+{
+   int i;
+   bool found, quit;
+   BSOCK *fd = jcr->file_bsock;
+
+   fd->jcr = jcr;
    for (quit=false; !quit;) {
       int stat;
 
@@ -160,17 +176,8 @@ void run_job(JCR *jcr)
       }
    }
    bnet_sig(fd, BNET_TERMINATE);      /* signal to FD job is done */
-   jcr->end_time = time(NULL);
-   dequeue_messages(jcr);             /* send any queued messages */
-   set_jcr_job_status(jcr, JS_Terminated);
-   generate_daemon_event(jcr, "JobEnd");
-   bnet_fsend(dir, Job_end, jcr->Job, jcr->JobStatus, jcr->JobFiles,
-      edit_uint64(jcr->JobBytes, ec1));
-   bnet_sig(dir, BNET_EOD);           /* send EOD to Director daemon */
-   return;
 }
 
-
 /*
  *   Append Data command
  *     Open Data Channel and receive Data for archiving
@@ -185,7 +192,10 @@ static bool append_data_cmd(JCR *jcr)
       Dmsg1(110, "<bfiled: %s", fd->msg);
       jcr->JobType = JT_BACKUP;
       if (do_append_data(jcr)) {
+         return true;
+#ifdef xxx 
          return bnet_fsend(fd, OK_append);
+#endif
       } else {
          bnet_suppress_error_messages(fd, 1); /* ignore errors at this point */
          bnet_fsend(fd, ERROR_append);
diff --git a/bacula/src/stored/job.c b/bacula/src/stored/job.c
index 891c4477b6..2bd6be9d24 100644
--- a/bacula/src/stored/job.c
+++ b/bacula/src/stored/job.c
@@ -9,7 +9,7 @@
 /*
    Bacula® - The Network Backup Solution
 
-   Copyright (C) 2000-2006 Free Software Foundation Europe e.V.
+   Copyright (C) 2000-2007 Free Software Foundation Europe e.V.
 
    The main author of Bacula is Kern Sibbald, with contributions from
    many others, a complete list can be found in the file AUTHORS.
diff --git a/bacula/src/stored/protos.h b/bacula/src/stored/protos.h
index 2e3bbdf3a8..3b8388e7a5 100644
--- a/bacula/src/stored/protos.h
+++ b/bacula/src/stored/protos.h
@@ -6,7 +6,7 @@
 /*
    Bacula® - The Network Backup Solution
 
-   Copyright (C) 2000-2006 Free Software Foundation Europe e.V.
+   Copyright (C) 2000-2007 Free Software Foundation Europe e.V.
 
    The main author of Bacula is Kern Sibbald, with contributions from
    many others, a complete list can be found in the file AUTHORS.
@@ -144,7 +144,8 @@ void     *handle_connection_request(void *arg);
 
 /* From fd_cmds.c */
 void     run_job(JCR *jcr);
-bool get_bootstrap_file(JCR *jcr, BSOCK *bsock);
+bool     get_bootstrap_file(JCR *jcr, BSOCK *bsock);
+void     do_fd_commands(JCR *jcr);
 
 /* From job.c */
 void     stored_free_jcr(JCR *jcr);
diff --git a/bacula/src/stored/spool.c b/bacula/src/stored/spool.c
index 03d222196a..4cc076e312 100644
--- a/bacula/src/stored/spool.c
+++ b/bacula/src/stored/spool.c
@@ -154,8 +154,8 @@ static void make_unique_data_spool_filename(DCR *dcr, POOLMEM **name)
    } else {
       dir = working_directory;
    }
-   Mmsg(name, "%s/%s.data.%s.%s.spool", dir, my_name, dcr->jcr->Job, 
-        dcr->device->hdr.name);
+   Mmsg(name, "%s/%s.data.%u.%s.%s.spool", dir, my_name, dcr->jcr->JobId,
+        dcr->jcr->Job, dcr->device->hdr.name);
 }
 
 
diff --git a/bacula/technotes-2.1 b/bacula/technotes-2.1
index 62be12ed38..c261140f06 100644
--- a/bacula/technotes-2.1
+++ b/bacula/technotes-2.1
@@ -2,6 +2,10 @@
 
 General:
 26Jan07
+ebl  Implements the include JobID in spool file name project.
+kes  Reorder projects file in order determined by Jan 2007 vote.
+kes  Implement item #12 on project list -- quick release of FD by
+     the SD.
 kes  Fix open of SQLite3 db where user does not have write permission
      so that DIR does not crash. Fixes bug #761.
 25Jan07