streams, resource forks, other unusual file contents

[ThomasWaldmann]

NTFS supports "streams" - multipe content streams associated with one file(name).

Mac OS X supports "resource forks", a similar mechanism.

If some windows / OS X users could comment on the importance of these mechanisms and of their support in a backup software, it would be very useful.

[ThomasWaldmann]

this is slightly related to #14 (as in "just storing 1 binary stream is not enough").

[level323]

IMO, these are worthwhile feature additions. At the risk of sounding like a broken record (see #1 (comment)), the prospect of expanding borg to handle these FS-specific capabilities really screams (at me, at least) for a modularised approach. At the core, borg is a deduplicated repo of binary blobs. Wrapping around this core is:

• data structures for separating data pushed to the repo into archives
• a mechanism for decontstructing and reconstructing those blobs to/from 'files'
• a mechanism for storing metadata about those 'files', for the various purposes of deconstructing and reconstructing that metadata, to speed up the detection of changed file data between backup runs and to speedily traverse the 'files' stored in that archive

The first point is filesystem agnostic. The latter two points require knowledge about the FS. I submit that these latter two points are excellent candidates for modularisation. Doing so should also lead to a more stable binary format for the repo, as it is agnostic concerning FS-specific data. Modularisation will also allow for a systematic approach to creation of FS-specific modules to handle FS's that borg currently does not support and new FS's that will come along in future.

[tk7r]

I am currently testing borg 1.0.6 with Mac OS X and data files with resource forks. Backup and restore of these files is working without a problem.

At least since Mac OS X 10.6 the resource fork can be accessed by using xattr (and by using posix api by appending /..namedfork/rsrc). borg uses the xattr api. Everything is working as expected, so you can maybe close this issue...

[enkore]

That's great, thanks for testing :)

Q: Document that this works? -> here would probably be the correct place