On Monday 15 August 2005 17:55, [EMAIL PROTECTED] wrote:
> Dear Kern,
>
> I'm inclined to agree with Phil & Thomas and your own comments.
>
> Since the FileSet we use includes the 'readfifo' option, why not:
> never overwrite an existing fifo if this option is set on a restore
> operation?
You might try applying the attached patch file to version 1.36.3 (possibly
1.36.2).
cd <bacula-source>
patch -p0 <raw.patch
make
...
>
> It then becomes the Run before client's job to create this fifo with the
> appropriate permissions such that bacula and the pipe reader software can
> utilise it.
>
> Best Regards,
>
> Brett Delle Grazie
>
> -----Original Message-----
> From: Kern Sibbald [mailto:[EMAIL PROTECTED]
> Sent: 13 August 2005 13:40
> To: [email protected]
> Cc: Phil Stracchino; Thomas E. Ruth; Brett Delle Grazie; bacula-devel
> Subject: Re: [Bacula-users] Backup / Restore of DB2 Databases using
> Fifo's
>
>
> Hello Phil,
>
> On Friday 12 August 2005 20:52, Phil Stracchino wrote:
> > Thomas E. Ruth wrote:
> > > I havn't been able to automate a restore completely within bacula for
> > > DB2 databases, but I've gotten close. The bacula restore process
> > > creates a FIFO with only root permissions but doesn't change the
> > > permissions of the actual fifo file until data starts restoring to it.
> > > At that time though, it's too late for the DB2 process (I think the
> > > file is actually deleted and re-created and the DB2 process loses it's
> > > handle on it).
> >
> > After thinking about what's going on here, I think this is a behavioral
> > error on Bacula's part. I suspect that *by default*, Bacula should
> > never overwrite a FIFO that already exists during a restore. If it's
> > not there, fine, restore it; if it's already there, LEAVE IT ALONE, we
> > don't want to break anything. Write any data to it that's supposed to
> > be written to it, sure, but if we delete and recreate the FIFO, we may
> > break things -- as in this example.
>
> I think you are on to something here.
>
> Originally, Bacula did not "touch" the directory entry for a file that
> existed, but I forget exactly why, but I was convinced to delete each file
> before restoring it. I had forgotten this until it came up with some work
> that Thorsten is doing. Deleting files before recreating them, has, in
> general, improved restoration. However, it appears that in this case, it
> breaks the ability to use a FIFO to restore a file as Tom wants to do.
>
> In general, I don't like things that are not symmetric or uniform -- i.e.
> why delete most files but not FIFOs before re-creating them? I need to
> think about this for a bit and look at the code ...
>
> > This probably applies to socket pseudo-nodes as well, assuming we even
> > restore those at all (which I still believe we shouldn't).
--
Best regards,
Kern
(">
/\
V_V
Index: src/findlib/create_file.c
===================================================================
RCS file: /cvsroot/bacula/bacula/src/findlib/create_file.c,v
retrieving revision 1.34.10.2
diff -u -u -b -r1.34.10.2 create_file.c
--- src/findlib/create_file.c 12 Apr 2005 21:31:20 -0000 1.34.10.2
+++ src/findlib/create_file.c 15 Aug 2005 16:53:39 -0000
@@ -116,7 +116,7 @@
case FT_SPEC:
case FT_REGE: /* empty file */
case FT_REG: /* regular file */
- if (exists) {
+ if (exists && attr->type != FT_RAW) {
/* Get rid of old copy */
if (unlink(attr->ofname) == -1) {
berrno be;
@@ -199,8 +199,9 @@
Dmsg1(200, "Restore node: %s\n", attr->ofname);
if (mknod(attr->ofname, attr->statp.st_mode, attr->statp.st_rdev) != 0 && errno != EEXIST) {
berrno be;
- Jmsg2(jcr, M_ERROR, 0, _("Cannot make node %s: ERR=%s\n"),
- attr->ofname, be.strerror());
+ Jmsg4(jcr, M_ERROR, 0, _("Cannot mknod(%s, 0x%s, 0x%x): ERR=%s\n"),
+ attr->ofname, attr->statp.st_mode, attr->statp.st_rdev,
+ be.strerror());
return CF_ERROR;
}
}
