Priority:
+- Look at moving the Storage directive from the Job to the
+ Pool in the default conf files.
+- 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.
- Migration Volume span bug
- Rescue release
So one could compare against 'ctime' and/or 'mtime', but ONLY 'before'
or 'since'.
+
+Item: 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.
Jmsg1(jcr, M_FATAL, 0, _("Record header scan error: %s\n"), sd->msg);
goto bail_out;
}
- Dmsg2(30, "Got hdr: FilInx=%d Stream=%d.\n", file_index, stream);
+ Dmsg4(30, "Got hdr: Files=%d FilInx=%d Stream=%d, %s.\n",
+ jcr->JobFiles, file_index, stream, stream_to_ascii(stream));
/* * Now we expect the Stream Data */
if (bget_msg(sd) < 0) {
Jmsg2(jcr, M_FATAL, 0, _("Actual data size %d not same as header %d\n"), sd->msglen, size);
goto bail_out;
}
- Dmsg1(30, "Got stream data, len=%d\n", sd->msglen);
+ Dmsg3(30, "Got stream: %s len=%d extract=%d\n", stream_to_ascii(stream),
+ sd->msglen, extract);
/* If we change streams, close and reset alternate data streams */
if (prev_stream != stream) {
switch (stream) {
case STREAM_UNIX_ATTRIBUTES:
case STREAM_UNIX_ATTRIBUTES_EX:
- Dmsg1(30, "Stream=Unix Attributes. extract=%d\n", extract);
/*
* If extracting, it was from previous stream, so
* close the output file and validate the signature.
case STREAM_ENCRYPTED_SESSION_DATA:
crypto_error_t cryptoerr;
- Dmsg1(30, "Stream=Encrypted Session Data, size: %d\n", sd->msglen);
-
/* Do we have any keys at all? */
if (!jcr->pki_recipients) {
Jmsg(jcr, M_ERROR, 0, _("No private decryption keys have been defined to decrypt encrypted backup data."));
Jmsg(jcr, M_FATAL, 0, _("Error parsing bootstrap file.\n"));
goto bail_out;
}
- if (debug_level > 20) {
+ if (debug_level >= 10) {
dump_bsr(jcr->bsr, true);
}
ok = true;
Technical notes on version 1.39
General:
+25Nov06
+kes Add Landon's refactor of restore Feature request to the
+ projects file.
+kes Tweak debug levels and messages for examining the disk
+ seek problem.
22Nov06
kes Cleanup some of the error termination code in migration.
kes Separate read/write source strings to keep track of where