From owner-cvs-all@FreeBSD.ORG Tue Apr 10 17:26:14 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3676516A400; Tue, 10 Apr 2007 17:26:14 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB9F13C4BB; Tue, 10 Apr 2007 17:26:13 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (store.lan.Awfulhak.org [172.16.0.35]) by storm.uk.FreeBSD.org (8.13.8/8.13.8) with ESMTP id l3AHQB08020230; Tue, 10 Apr 2007 18:26:12 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4D44C1957C90; Tue, 10 Apr 2007 17:26:18 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Postfix) with ESMTP id E3CB01957C74; Tue, 10 Apr 2007 17:26:09 +0000 (GMT) Received: from conflict.ca.sophos.com (brian@localhost [127.0.0.1]) by gw.Awfulhak.org (8.13.8/8.13.8) with ESMTP id l3AHPutR011363; Tue, 10 Apr 2007 10:25:56 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Tue, 10 Apr 2007 10:25:55 -0700 From: Brian Somers To: "Greg 'groggy' Lehey" Message-ID: <20070410102555.2c877a30@conflict.ca.sophos.com> In-Reply-To: <20070410010510.GB61460@wantadilla.lemis.com> References: <200704090219.l392Jc1f064727@repoman.freebsd.org> <20070409021942.C150B16A529@hub.freebsd.org> <20070409024826.553be564@dev.lan.Awfulhak.org> <20070410010510.GB61460@wantadilla.lemis.com> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,SPF_HELO_PASS, SPF_PASS autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gw.lan.Awfulhak.org Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Brian Somers , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/touch touch.1 touch.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 17:26:14 -0000 On Tue, 10 Apr 2007 10:35:10 +0930 "Greg 'groggy' Lehey" wrote: > [heavily trimmed] > > On Monday, 9 April 2007 at 2:48:26 -0700, Brian Somers wrote: > > On Mon, 9 Apr 2007 02:19:42 +0000 (UTC) Greg Lehey wrote: > >> grog 2007-04-09 02:19:37 UTC > >> > >> FreeBSD src repository > >> > >> Modified files: > >> usr.bin/touch touch.1 touch.c > >> Log: > >> Add -A flag to adjust existing time stamps. > >> diff -u src/usr.bin/touch/touch.1:1.14 src/usr.bin/touch/touch.1:1.15 > >> --- src/usr.bin/touch/touch.1:1.14 Sun Feb 13 22:25:24 2005 > >> +++ src/usr.bin/touch/touch.1 Mon Apr 9 02:19:37 2007 > >> +.It Fl A > >> +Adjust the access and modification time stamps for the file by the > >> +specified value. > >> +This flag is intended for use in modifying files with a time stamp > >> +relative to an incorrect time zone. > > > > I don't understand what this means. File times are in UTC aren't > > they? > > No, they're in time_t. But if you import files from other systems, > you frequently get times which are off by some time zone offset. Ah, this is the bit I was missing then. Maybe instead of "This flag is intended for use in modifying files with a time stamp relative to an incorrect time zone", something like "When files are transferred from an external system with an incorrect clock, this flag can be used to correct the file times". [.....] > > Why this format? > > It's basically a simplification of the format that touch(1) uses to > specify timestamps. > > > My guess is that the delta is expected to be a DST difference, but > > if it is, I'm even more confused. > > Yes, that seems confusing. For the +1030 time difference that I had > to contend with on Sunday, you'd write -103000 (HHMMSS). > > But why limit it to exact time zone offsets? How accurate is the > clock in your digital camera? Did you reset it when the clocks went > forward a couple of weeks ago? Also, currently there is no time zone > anywhere in the world that is +1030. > > I've just checked my camera and discovered that it said 10:01 when in > fact the time was 9:23. That's one hour for forgetting to put the > clock back, compensated for by it having lost 22 minutes since last > set. If I put a time zone in there, rather than an exact offset, I'd > be restricting the functionality. I see the dilemma. I was originally thinking that a format of [[CC]YY]MMDDhhmm[.SS]] would be more practical, or maybe even [[[[[CC]YY]MM]DD]hh]mm[.SS]], but as this is a time delta, perhaps anything more than what you already have is a mistake (an hour is always 60 minutes (well!), but sometimes a day isn't 24 hours). So after wrestling with the thought for a while, I figured a number of seconds would be the least ambiguous. It's fairly easy to change "touch -A 003800" to "touch -A $((38 * 60))", so maybe a number of seconds is not much more difficult to write? > >> +.Pp > >> +When used in conjunction with the > >> +.Fl a > >> +flag only, the modification time is adjusted by the time specified as > >> +argument to the > >> +.Fl A > >> +flag, while the access time is modified from the base time described > >> +above. > > > > Wow. So -A changes both times in addition to the > > access-only time change. This is really unintuitive > > to me. I'd expect ``-A 000001 -a' to adjust the access > > time only (as -a previously meant). I wouldn't expect > > the modification time to be bumped by a second and the > > access time to be set to one second in the future. > > > > But again, I don't know why you'd want to do this... > > I can't see any earthly reason to use -m or -a in conjunction with -A. > I was simply documenting what would happen. But see below. > > >> +.Pp > >> +If the file does not exist, and creation is allowed, > >> +.Fl A > >> +does not change its time stamps. > > > > So if I ``touch -A 000001 something'' where ``something'' > > doesn't already exist, the file is created and the time > > is left at now? That's also confusing. > > What would you set it to? I was thinking of prohibiting the use of -c > altogether, since it doesn't make sense. What do you think? > > >> - aflag = cflag = fflag = mflag = timeset = 0; > >> + myname = argv[0]; > > > > myname should be set to the base name, not the full argv[0]. > > OK. Will change. > > > I personally think this option is a mistake. I would > > think that something like this would be better: > > > > [-A adjust] - adjust the updated time(s) by the given > > ``adjust'' number of seconds. > > Then you're asking people to calculate the number of seconds. Why? I > suppose you could add a second format. I was sorely tempted to write > HH:MM:SS, but that doesn't match the format for the -t option, which > is enshrined in POSIX.1. As above, it just seems more correct.... > > I would imagine this to be useful in (say) a test script that wanted > > to set up a bunch of files with time stamps set to specific relative > > values. > > Yes, agreed. > > > But I'm clearly missing the point here...? > > Is it clearer now? > > After thinking about this, it's clear that the interaction between -A > on the one hand and -a and -m on the other is confusing. I'll change > it so that only the specified time stamps are changed under these > circumstances. I think that'd be better - the -c and -a semantics then stay the same. Also, allowing -c with -A is useful for test scripts, so probably shouldn't be disallowed. > Greg > -- > See complete headers for address and phone numbers. -- Brian Somers Don't _EVER_ lose your sense of humour !