> > Le dimanche 25 octobre 2009 10:24:30, James Harper a écrit : > > > 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 haven't done much investigating yet, but I believe that the magic code > > that currently retrieves the file data from the BackupRead (windows backup > > api) stream just searches until it finds the right stream. Ntfs-3g can get > > and set raw ACL data which I believe is in one of the BackupRead streams > > already. Ditto for the ADS's. Not sure about NTFS Attributes and DOS > > filename though. > > The problem is that it could change over the time and versions, but it's > interresting. >
At it stands right now, with an ntfs-3g mounted volume 'getfattr -h -e hex -n system.ntfs_acl <filename>' retrieves a hex string that is byte for byte identical with what comes out of the BACKUP_SECURITY_DATA in the BackupRead data stream. (the BackupRead decomposition code singles out the BACKUP_DATA stream and ignores everything else). Are you concerned about the xattr interface to ntfs-3g changing, or the format of the data produced by BackupRead and consumed by BackupWrite? I'm not yet convinced that either the above or the run-windows-in-a-vm solution is best, but there are still a lot of non-server devices that don't have hardware support for virtualisation, so doing it the virtualisation way leaves workstation rebuilds without a solution... (if that's a concern for you - maybe not?) James ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
