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

[nfr] Add an --include option #18

Open
sourcejedi opened this issue Apr 24, 2015 · 1 comment
Open

[nfr] Add an --include option #18

sourcejedi opened this issue Apr 24, 2015 · 1 comment

Comments

@sourcejedi
Copy link

I'm using bup and want to switch to bup-cron for obvious reasons. I don't backup firefox because it seems like unecessary churn from history & state-saving (firefox crash recovery), plus we have Firefox Sync. But I do back up my 400Kb of bookmarks. I can't see how to do this in bup-cron, while I can with bup:

bup index "$HOME_DIR" --exclude "$HOME_DIR"/.mozilla
bup index "$HOME_DIR"/.mozilla/firefox/*/bookmarkbackups

I think bup-cron should have --include. Possibly bup-index could implement it, and bup-cron just pass it through :). I don't want to pass multiple paths with bup-cron -p, because then firefox is in a different backup to my other dotfiles.

(Am also slightly disturbed by the semantics illustrated in the example config file. Why are there multiple overlapping paths? Because implementing --snapshot effectively requires --xdev. But this means --snapshot affects what's being backed up. Strawman hack: implement --xdev if it's not already, and require it to be explicitly passed for --snapshot. Or snapshot recursively. Hmm, I wonder if other Windows backup programs handle mountpoints correctly with VSS :)).

@anarcat
Copy link
Owner

anarcat commented Apr 27, 2015

i would rather avoid a clunky --include and allow specifying multiple paths correctly.

if you look in the source code in bup_cron/__init__.py:1034 (https://github.com/anarcat/bup-cron/blob/master/bup_cron/__init__.py#L1034) you will see why: basically, we can't pass those paths all at once to bup index because we were having problems with bup index -x / /var.

we could however loop on bup index and then call bup save only once, but then the assumption is that each path provided is its own filesystem...

--include would require serious re-engineering here... there is already some work to be done to cleanup the snapshot/filesystem detection code here, as mentionned here:

pfrouleau/bup@1244a2d#commitcomment-7866283

but this is, yes, yet another oddity. can't hide all the weird bup corner cases here... ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants