Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!apollo!vijay From: vijay@apollo.HP.COM (Vijay Sundaram) Newsgroups: comp.sys.apollo Subject: Re: WBAK/OmniBack mod/create times Keywords: backup archive wbak rbak omniback Message-ID: <45570a6d.122ae@apollo.HP.COM> Date: 30 Aug 89 15:17:00 GMT References: <3188@wasatch.utah.edu> Reply-To: vijay@apollo.HP.COM (Vijay Sundaram) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 35 In article <3188@wasatch.utah.edu> zeleznik%cs.utah.edu@wasatch.utah.edu (Mike Zeleznik) writes: >Is there a good reason why wbak uses the mod time of a file instead of its >create time for incrementals? > >The problem is if you "cp -p" in from another machine, or tar stuff in, the >mod times will stay as the original (which is usually what one wants, along >with keeping the modes). But now, in general, these "new" files won't get >backed up til the next full save (unless the mod times happened to be >in the right window). I don't think this would happen with ctime. > >This seems kind of a big hole for people who move things around. > >I understand OmniBack uses mod times also (correct me if I am wrong). > >Is there a reason for not using ctime? Thanks. > >Mike > > Michael Zeleznik Computer Science Dept. > University of Utah > zeleznik@cs.utah.edu Salt Lake City, UT 84112 > (801) 581-5617 OmniBack uses the modified time (dtm) *as well as* the time the attributes were changed (dta). When you do a "cp -p" the modified time remains the same, the time of creation and use gets updated. The dta also gets updated. Since OmniBack looks at whichever was updated from {dta, dtm}, no undue penalty is incurred. -- Vijay-- ------------------------------------------------------------------------------------ Vijay Sundaram vijay%apollo.hp.com Apollo Division of Hewlett-Packard {decwrl!decvax, mit-eddie, attunix}!apollo!vijay ------------------------------------------------------------------------------------