> On Dec 31, 2016, at 01:38, Colin Percival <[email protected]> wrote: > > On 12/30/16 15:53, Scott Wheeler wrote: >>> On Dec 31, 2016, at 00:29, Graham Percival <[email protected]> wrote: >>> On Sat, Dec 31, 2016 at 12:19:09AM +0100, Scott Wheeler wrote: >>>> bela: /tmp/foo> sudo tarsnap -xvf test --newer "Jan 1, 2016" >>> >>> --newer is only specified for working with -c: >> >> Ah, odd, missed that when scanning the docs. [...] > > Hmm, the code which checks options for validity thinks they're ok in [cxt] > modes (bsdtar.c):
[...] > > So I think the man page is wrong here. > > As for the precise formats accepted... this is some very historical > date/time parsing code, so I'd assume that "201601010000" would be > parsed as the start of January 1, 2016 (see `touch -t`). Looking at > the code, it's clear that a variety of other formats can be parsed; > but I don't think the exact set is documented anywhere... I poked a bit into the get_date() implementation before posting, but it looked like it should parse a number of formats, none of which seemed to work. Unfortunately, the scheme you suggested doesn't either. This is with the same test case I posted earlier (one empty file in one dir, created with `touch` earlier today): bela: /tmp/foo> sudo tarsnap -xvf test --newer "201601010000" x test/ x test/foo bela: /tmp/foo> sudo tarsnap -xvf test --newer "201701010000" x test/ x test/foo > (BTW, for your exact use case I think the --keep-newer option might > do what you want much far less aggravation?) Hmm, yes, I interpreted that option too literally. I assumed it would only keep files that were newer, not newer or the same age. Maybe an alias is in order? --only-updated-files? --only-new? (The latter is perhaps confusing as it'd seem to imply only files that were new to that archive.) One quirk here is that it exits non-zero when doing exactly what I've instructed it to do: bela: /tmp/foo> sudo tarsnap -xvf test --keep-newer x test/ x test/foo: File on disk is not older; skipping. tarsnap: Error exit delayed from previous errors. bela: /tmp/foo> echo $? 1 Printing an error message (not just a notice to stderr) and exiting with a non-zero code seems incorrect for something that is explicitly expected to happen. -Scott -- Scott Wheeler | Co-founder | Directed Edge | www.directededge.com | @directededge
