Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

streams, resource forks, other unusual file contents #51

Closed
ThomasWaldmann opened this issue Jun 9, 2015 · 6 comments
Closed

streams, resource forks, other unusual file contents #51

ThomasWaldmann opened this issue Jun 9, 2015 · 6 comments
Assignees

Comments

@ThomasWaldmann
Copy link
Member

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
Copy link
Member Author

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

@level323
Copy link

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
Copy link

tk7r commented Jul 14, 2016

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
Copy link
Contributor

enkore commented Jul 14, 2016

That's great, thanks for testing :)

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

@ThomasWaldmann
Copy link
Member Author

@enkore it is already documented in the footnote of the features table (installation.rst):

.. [#xattr] extended attributes; key-value pairs attached to a file, mainly used by the OS.
    This includes resource forks on Mac OS X.

@ThomasWaldmann ThomasWaldmann removed this from the 1.0.8 (rc2?) milestone Oct 18, 2016
@enkore
Copy link
Contributor

enkore commented Oct 18, 2016

Looks like I forgot about this ticket when doing it.

Nothing more to do here; except keeping that table updated with any changes of course...

@enkore enkore closed this as completed Oct 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants