> > 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. >
Hmmm... I wonder if adding some sort of BackupWrite functionality to ntfs-3g is a better way to go... that would solve a lot of problems - bacula could just follow pretty much the same calls as it does for Windows. The Windows Backup Stream complexity would be in ntfs-3g (the filesystem), where it belongs. 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 Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
