You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Robert Simonson <si...@us.ibm.com> on 2002/03/14 19:30:27 UTC

[PATCH] Adding an apr_utime() function

This patch adds apr_utime() to the APR.  I did this against the unix
directories.
I don't know how this affects (if at all) other platforms.

Thanks.

Rob Simonson
simo@us.ibm.com


apr/file_io/unix/filestat.c
===================================================================
--- filestat.c.old      Thu Mar 14 11:20:04 2002
+++ filestat.c    Thu Mar 14 12:13:49 2002
@@ -245,3 +245,24 @@
     return apr_stat(finfo, fname, wanted | APR_FINFO_LINK, cont);
 }

+APR_DECLARE(apr_status_t) apr_utime(const char *fname, apr_utimbuf_t *buf)
+{
+#if APR_HAVE_UTIME_H
+    struct utimbuf utb;
+    int rc;
+
+    if (buf != NULL) {
+        utb.actime = (time_t)(buf->atime / APR_USEC_PER_SEC);
+        utb.modtime = (time_t)(buf->mtime / APR_USEC_PER_SEC);
+        rc = utime(fname, &utb);
+    }
+    else {
+        rc = utime(fname, NULL);
+    }
+    if(rc != 0)
+        return errno;
+    return APR_SUCCESS;
+#else
+    return APR_ENOTIMPL;
+#endif
+}


apr/include/apr_file_info.h
===================================================================
--- apr_file_info.h.old Thu Mar 14 11:21:06 2002
+++ apr_file_info.h     Thu Mar 14 11:47:26 2002
@@ -144,6 +144,12 @@
 #endif

 /**
+ * @defgroup APR_utime struture
+ * @{
+ */
+typedef struct apr_utimbuf_t apr_utimbuf_t;
+
+/**
  * @defgroup APR_File_Info Stat Functions
  * @{
  */
@@ -219,6 +225,16 @@
 };

 /**
+ * The utimbuf structure analogous to POSIX.1 definition.
+ */
+struct apr_utimbuf_t {
+    /** The new access time */
+    apr_time_t   atime;
+    /** The new modification time */
+    apr_time_t  mtime;
+};
+
+/**
  * get the specified file's stats.  The file is specified by filename,
  * instead of using a pre-opened file.
  * @param finfo Where to store the information about the file, which is
@@ -244,6 +260,21 @@
  */
 APR_DECLARE(apr_status_t) apr_lstat(apr_finfo_t *finfo, const char *fname,
                                     apr_int32_t wanted, apr_pool_t *cont);
+
+/**
+ * Set the specified file's access and modification times. The file is
+ * specified by filename, instead of using a pre-opened file. If the file
is a
+ * symlink, this function will resolve the link and set times for the file
the
+ * symlink refers to.
+ * @param fname The name of the file to set times.
+ * @param buf The desired access and modification times. If buf is a NULL
+ * pointer, the access and modification times are set to the current time.
+ * @deffunc apr_status_t apr_utime(const char *fname, apr_utimbuf_t *buf)
+ * @tip This function returns APR_ENOTIMPL if the platform does not
support
+ * change of file access and modification times.
+ */
+APR_DECLARE(apr_status_t) apr_utime(const char *fname, apr_utimbuf_t
*buf);
+
 /** @} */
 /**
  * @defgroup APR_DIRECTORY Directory Manipulation Functions


apr/include/arch/fileio.h
===================================================================
--- fileio.h.old  Thu Mar 14 11:36:35 2002
+++ fileio.h      Thu Mar 14 12:07:19 2002
@@ -105,6 +105,9 @@
 #ifdef BEOS
 #include <kernel/OS.h>
 #endif
+#if APR_HAVE_UTIME_H
+#include <utime.h>
+#endif

 #if BEOS_BONE
  #ifndef BONE7


apr/include/apr.h.in
===================================================================
--- apr_h.in.old  Thu Mar 14 12:20:25 2002
+++ apr_h.in      Thu Mar 14 12:21:59 2002
@@ -63,6 +63,7 @@
 #define APR_HAVE_SYS_WAIT_H      @sys_waith@
 #define APR_HAVE_TIME_H          @timeh@
 #define APR_HAVE_UNISTD_H        @unistdh@
+#define APR_HAVE_UTIME_H         @utimeh@

 #define APR_HAVE_SHMEM_MMAP_TMP     @havemmaptmp@
 #define APR_HAVE_SHMEM_MMAP_SHM     @havemmapshm@



Re: [PATCH] Adding an apr_utime() function

Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> 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...

Re: [PATCH] Adding an apr_utime() function

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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?
In this way, non-unixes that don't support ctime could return the
APR_ENOTSUPP error when the user calls to change ctime, but would
succeed on changing mtime or atime.

On that note, nearly all real platforms [that is _very_ tounge in cheek,
folks] track the file creation time.  It's being abused as ctime, but Unix
ctime is certainly not file creation time.

Shall we add crtime to track the file creation timestamp, and mark ctime
as not present on all the non-unix platforms, while marking crtime as
invalid on win32?  That means we grow apr_stat_t by one time value
[8 bytes or so] but I don't see that as a 'bad thing.'  APR_FTYPE_CRTIME
would be added to the possible .valid flags.



Bill



At 12:53 PM 3/14/2002, you wrote:
>"Robert Simonson" <si...@us.ibm.com> writes:
>
> > This patch adds apr_utime() to the APR.  I did this against the unix
> > directories.
>
>A missing piece for unix is detecting the presence of utime.h and
>setting the utimeh variable.  I think you just need to add utime.h to
>the APR_FLAG_HEADERS invocation in configure.in, then add an
>AC_SUBST(utimeh) invocation with the rest of them.
>
> > I don't know how this affects (if at all) other platforms.
>
>If somebody cares they will implement; if not, then it will be missing
>until somebody starts caring.  I wonder if a feature test macro is
>needed.  Initially we'd need to set APR_HAVE_UTIME_H to 0 in apr.hw
>(Win32) and apr.hnw (Netware).
>
>As far as the name apr_utime():
>
>   no freakin' way :)  I'd suggest something like apr_file_time_set().
>
>As far as which times to set (atime, ctime, mtime):
>
>   I don't care about ctime either.  I wonder if anybody else cares.
>
>As far as how to specify those times:
>
>   I'd vote for separate parameters instead of stuffing them in a
>   structure.  I don't see the benefit to the structure.
>
>--
>Jeff Trawick | trawick@attglobal.net
>Born in Roswell... married an alien...



Re: [PATCH] Adding an apr_utime() function

Posted by Jeff Trawick <tr...@attglobal.net>.
"Robert Simonson" <si...@us.ibm.com> writes:

> This patch adds apr_utime() to the APR.  I did this against the unix
> directories.

A missing piece for unix is detecting the presence of utime.h and
setting the utimeh variable.  I think you just need to add utime.h to
the APR_FLAG_HEADERS invocation in configure.in, then add an
AC_SUBST(utimeh) invocation with the rest of them.

> I don't know how this affects (if at all) other platforms.

If somebody cares they will implement; if not, then it will be missing
until somebody starts caring.  I wonder if a feature test macro is
needed.  Initially we'd need to set APR_HAVE_UTIME_H to 0 in apr.hw
(Win32) and apr.hnw (Netware).

As far as the name apr_utime(): 

  no freakin' way :)  I'd suggest something like apr_file_time_set().

As far as which times to set (atime, ctime, mtime):

  I don't care about ctime either.  I wonder if anybody else cares.

As far as how to specify those times:

  I'd vote for separate parameters instead of stuffing them in a
  structure.  I don't see the benefit to the structure.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...