On 09.10.2013 01:26, Andy Lutomirski wrote: > On Tue, Oct 8, 2013 at 4:19 PM, Colin Percival <cperc...@tarsnap.com> wrote: >> On 10/07/13 10:37, Andy Lutomirski wrote: >>> On Sun, Oct 6, 2013 at 3:46 PM, Colin Percival <cperc...@tarsnap.com> wrote: >>>> On 10/06/13 14:26, Andy Lutomirski wrote: >>>>> On Sun, Sep 29, 2013 at 10:27 AM, Colin Percival <cperc...@tarsnap.com> >>>>> wrote: >>>>>> Tarsnap stores a 512-byte tar header for each file, and this header >>>>>> includes the file modification time. 22,000 files x 512 bytes/file = 11.2 >>>>>> MB, so this looks like the reason for the new data you're seeing. >>>>> >>>>> Aha! Is there an easy way to turn that off? I archive a fair amount >>>>> of autogenerated data, and the timestamps are completely worthless as >>>>> far as I'm concerned. >>>> >>>> No way to turn it off. The best I can suggest is to compare your old and >>>> new autogenerated data and only install the new data if it's different. >>> >>> Yuck. Can I request this as a feature for the next release >>> (--no-cmtime or something like that)? >> >> I've put this onto my "requested features" list, but at the moment I can't >> see >> any good way to do this -- the (tar) format Tarsnap uses internally has a >> field >> for file modification time and if I just zero that field you'd get files >> being >> extracted with an mtime of January 1, 1970... >> > > That's would actually be fine with me. You could also use some other > sentinel value that gets extracted as "now".
Shouldn't it be possible to reset ctime and mtime of files before adding them to the archive (in a script, outside of tarsnap)? Philipp
