kes Implement code that should properly set that a job was migrated,

[bacula/bacula] / bacula / kernstodo

diff --git a/bacula/kernstodo b/bacula/kernstodo
index 61433f8bfb1b2c2b9ee1b0a1cf00f21e24ae36bc..8a541ed63c471f0847cf1963d7a62a7d60ec6135 100644 (file)
--- a/bacula/kernstodo
+++ b/bacula/kernstodo
@@ -1,5 +1,5 @@
                     Kern's ToDo List
-                     25 August 2006
+                     12 November 2006
 
 Major development:      
 Project                     Developer
@@ -41,24 +41,28 @@ Document:
  
 
 Priority:
-- Arno's reservation deadlock.
-- Doc items
+- Check if gnome-console works with TLS.
+- Ensure that the SD re-reads the Media record if the JobFiles
+  does not match -- it may have been updated by another job.
+- Look at moving the Storage directive from the Job to the
+  Pool in the default conf files.
+- Migration Volume span bug
+- Rescue release
 - Bug reports
-- Eric's SD patch
+- Test FIFO backup/restore -- make regression
+- Doc items
 - Add encryption regression tests
 - Test Volume compatibility between machine architectures
 - Encryption documentation
-- Migration Volume span bug
 - Wrong jobbytes with query 12 (todo)
 - bacula-1.38.2-ssl.patch
 - Bare-metal recovery Windows (todo)
-- Rescue release
-- Test FIFO backup/restore -- make regression
-- Document need for UTF-8 format
 
 
 
 For 1.39:
+- Fix hardlinked immutable files when linking a second file, the
+  immutable flag must be removed prior to trying to link it.
 - Implement Python event for backing up/restoring a file.
 - Change dbcheck to tell users to use native tools for fixing
   broken databases, and to ensure they have the proper indexes.
@@ -87,6 +91,20 @@ For 1.39:
   .move transfer device=xxx fromslot=yyy toslot=zzz
 
 Low priority:
+- It appears to me that you have run into some sort of race
+  condition where two threads want to use the same Volume and they
+  were both given access.  Normally that is no problem.  However,
+  one thread wanted the particular Volume in drive 0, but it was
+  loaded into drive 1 so it decided to unload it from drive 1 and
+  then loaded it into drive 0, while the second thread went on
+  thinking that the Volume could be used in drive 1 not realizing
+  that in between time, it was loaded in drive 0.
+  I'll look at the code to see if there is some way we can avoid
+  this kind of problem.  Probably the best solution is to make the
+  first thread simply start using the Volume in drive 1 rather than
+  transferring it to drive 0.
+- After pruning, check to see if the Volume retention period has
+  expired.
 - Check to see if jcr->stime is lost during rescheduling of
   jobs in jobq.c
 - Fix re-read of last block to check if job has actually written
@@ -1728,3 +1746,9 @@ Block Position: 0
 - Restore of a raw drive should not try to check the volume size.
 - Lock tape drive door when open()
 - Make release unload any autochanger.
+- Arno's reservation deadlock.
+- Eric's SD patch
+- Make sure the new level=Full syntax is used in all 
+  example conf files (especially in the manual).
+- Fix prog copyright (SD) all other files.
+- Document need for UTF-8 format