On Mon, 2009-10-26 at 09:13 +0100, Eric Bollengier wrote: > Le lundi 26 octobre 2009 04:24:42, James Harper a écrit : > > > I think that run-windows-in-a-vm is a better idea than using BartPE, > > > now if Bacula can restore acl stream from BackupWrite/Read, i would be > > > very happy too! > > > > The patch tacked onto the end of this email accomplishes this, with the > > following (serious) restrictions/bugs: > > > > . Doesn't seem to work on directories. I assume that this is because > > when directories get restored, processWin32BackupAPIBlock is never > > called at any point... does that sound right? Any suggestions as to how > > to work around it? > > This call is present on many places (bextrat, filed/restore.c, etc...), > perhaps > it is missing at some places, but it's hard to say. > > > . Some other type of file is failing to apply ACL's... can I get the > > filename from the jcr? Or any other way? > > Marco is responsible for all ACL stuffs, he is doing a great job to cleanup > all > this part, i think that once you will have the good approach, he will have > some comments on how integrate your changes. > I'm not sure how this will fit in the current new setup as we now have native only acl and xattr streams. This is kind of different as here we restore NT stream (or even parts of streams) on a Linux platform right ? This kind of non-native streams is something I'm still thinking on how we will implement those.
> > . I'm restoring the Extended Attributes too, but haven't yet tested if > > they actually do anything > > . Needs the current 'Advanced' version of ntfs-3g > > If it's done from a LiveCD, this is just a documentation problem. > > > . The patch as it stands assumes that you are restoring to a filesystem > > mounted with the 'Advanced' version of ntfs-3g. If you were to try and > > restore to any other filesystem you would fill your logs with errors > > about failing to set attributes. > > This is where Marco will help us, the current architecture doesn't have this > problem. > Uh it had this problem but with Kern I worked out a way where we only report a number of errors and from that moment on we only count the errors. > > . Alternate Data Streams are not restored. Easy enough to add I think, > > but ntfs-3g has a few different ways of allowing access to them and I > > don't know which is best at this point. > > What can we expect from this Stream ? > > > . If a win32 backup stream (other than the normal data) crossed a bacula > > buffer boundary then it won't work. The alternative is to read the > > stream into a memory buffer and only set the xattr when it is completely > > read into memory. I haven't seen that happen yet but I'm pretty sure > > that it could. > > We can wait 2 days to get Kern advises on this particular subject, i think > that we call the BackupRead without any buffer boundary, so it shouldn't > cause > problem. > I would say we wait on Kern, as this is kind of dirty where a backup stream is dissected into multiple streams. > > . Reparse points aren't restored, but I think that's just another 3 > > lines of code. > > Great! > > > . Needs the attr libraries > > For sure, this is already needed for all other extended attributes. > > > . Assumes that you are restoring onto the same endianness as you backed > > up on. Windows is and has always been little-endian only so I don't > > think this is a problem. To make it endian independent would be a > > nightmare. > All current xattr are not endian neutral anyhow, we support only restoring xattr and acls on the same platform as they were saved on. > We can assume it at this time, in any cases, it needs careful testing. > > Great idea, great job, thanks you! > We probably need to redesign some of the code and send this to the generic functions using a separate ACL and XATTR stream number and then stuff the data into the jcr acl and xattr buffer. But this is probably only for backwards compatibility. I would say for the future we reserve 2 new stream numbers and stuff the data into that. Marco ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
