On Sunday 01 November 2009 10:56:13 James Harper wrote: > > > Le dimanche 25 octobre 2009 05:14:14, James Harper a écrit : > > > > A year or two ago I was pondering about the best way to restore a > > > > Windows system to 'bare metal'. BartPE is kind of nice for XP and > > > > 2003, but is fairly specific on what platforms it supports, is > > > > legally questionable if you are using OEM licenses, and in order to > > > > restore an XP system you need access to files from Windows 2003 etc. > > > > I then looked at what would be involved in booting Linux (via > > > > CD/USB/netboot/etc) and then restoring that way. At the time though, > > > > the ACL's, ownership, and a whole load of other stuff would be > > > > missing so there didn't seem to be much point pursuing it. > > > > > > > > The latest 'Advanced' release of ntfs-3g supports direct access to > > > > the ACL's, ADS's, NTFS Attributes, DOS filenames (eg the 8.3 filename > > > > equivalent of the Windows filename), datestamps, and possibly EFS > > > > too. So in theory, it would be possible to extend > > > > processWin32BackupAPIBlock to not only write out the regular file > > > > data, but also to write out the ACL's, ADS's, etc etc. I don't even > > > > think it would be that much work... although I've been famously wrong > > > > about such things before :) > > > > > > Would be nice, but it's a terribly difficult reverse engineering > > > process.... > > > > I'm suddenly a lot less enthusiastic about this approach. ntfs-3g is > > flatly refusing to let me apply some ACL's and it isn't obvious why. I > > think that ntfs-3g is being overly enthusiastic about checking what > > constitutes a valid ACL before applying it. I believe it's a bug, and am > > also concerned that maybe this is the tip of the iceberg of such bugs. On > > the other hand it may well be the only bug I ever encounter... > > According to one of the ntfs-3g developers, it is just an overzealous > check. > > I also implemented the setting of OBJECT_ID's into ntfs-3g. It doesn't > update the ntfs index so a chkdsk is required afterwards, but the developer > is looking at implementing properly. > > One thing the BackupRead stream has in it is details about sparse files, > specifically the sparse areas. A Windows system that was 5.92G when backed > up is suddenly 7.60G when restored, presumably the lack of Bacula's > understanding of BackupRead sparse streams is the cause of this.
Yes, currently, the only part of the BackupRead that Bacula looks at when restoring a BackupRead to a non-Windows system is the actual data stream all other streams are ignored. In general, I am not very keen on Bacula digging into OS structures, because they are very system dependent, and they can change from OS to OS -- meaning a bigger support load on developers. However, in the case of the data stream, it is a necessary "evil" so that Windows users can get back their data even if the Windows system is not available. Kern ------------------------------------------------------------------------------ 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
