Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 56200 invoked by uid 500); 21 Mar 2002 18:26:48 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 56189 invoked from network); 21 Mar 2002 18:26:47 -0000 Subject: Re: [PATCH] Adding an apr_utime() function To: Jeff Trawick Cc: dev@apr.apache.org, "William A. Rowe, Jr." X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Simonson" Date: Thu, 21 Mar 2002 12:26:23 -0600 X-MIMETrack: Serialize by Router on d27ml502/27/M/IBM(Release 5.0.9a |January 7, 2002) at 03/21/2002 12:26:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Finally got to this. Sorry for the delay... My case is a proxy cache implementation that we have here. We want the ability to reset the mtime and atime when doing a cache maintenance so that when the proxy code is run, it has an accurate mtime/atime. We don't care about ctime. In fact, we can't change ctime anyway. As for polluting the API, I'm not sure how it does. If this type of function is implemented for Unix platforms, can't the other platforms simply return APR_ENOTIMPL? And as for not passing a structure (as was in my original patch), why not? It doesn't seem to be much different than defining apr_stat_t or some other apr_* structure abstraction. Thanks. Rob Simonson simo@us.ibm.com ----- Forwarded by Robert Simonson/Rochester/IBM on 03/21/2002 12:15 PM ----- "William A. Rowe, Jr." writes: > Before anyone even _considers_ polluting the API [which would > raise an instant veto from me] we have to finally address the create > time issue on non-Unix. Then we can get such a patch committed > to fit this resolution of this issue.. > > Unix has ctime, mtime and atime. How often will we change all three > at once, or do we want to change a single requested time-at-a-time? That is a key question. I wish I knew the answer :) Rob, what is your use case by the way? Not that it is the answer for everybody, but I'm curious. The change-one-time per call handles your issues nicely. It might be nice to have a flag that says to just set everything to the one time so that we don't waste a syscall trying to preserve the times we don't think we're supposed to modify. -- Jeff Trawick | trawick@attglobal.net Born in Roswell... married an alien...