Docu buglet in apr_file_info_t?

[Sander Striker <st...@apache.org>]

Hi,

I always thought ctime was 'creation' time.

However in include/apr_file_info.h:209
    /** The time the file was last modified */
    apr_time_t mtime;
    /** The time the file was last changed */
    apr_time_t ctime;

Aaron pointed out to me that OtherBill has
explained this misconception of creation time
in the past.  Bill, could you please document
in that file what is understood as a 'modification'
and what is known as a 'change'?

Thanks,

Sander

Re: Docu buglet in apr_file_info_t?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

The ctime field is interpreted differently, and misunderstood even by Unix
programmers, as Martin spelled out very nicely a while ago.

When a file is created [on unix or win32] the inode is instantiated.  So ctime
and mtime are set to the 'creation time'.

When the file is modified, the mtime value is updated.  Now mtime is the last
modified, or file-write time stamp, and ctime remains the creation time.

Copy this file with cp -p, and the mtime and perhaps the ctime values are
preserved for this new file.  They may still maintain the file data's 
modification
and creation time.

However, call touch on the file, and the ctime is set to now().  You simply
modified the last-write time, and the inode time is definitely no longer the
creation time.  Change the ownership or group of a directory tree and you
have just wiped all the ctimes.  So ctime can never be used to represent
a 'creation time', even though some utilties may attempt to do so.

The current implementation is wrong, we should maintain separate
inode-change-time and file-creation-time fields.  My only question would
be how to name them.  itime and ctime strike me as making sense, but
that would lead to ctime confusion in unix programmers.  ctime and crtime
might be better, but would lead to unrecognized typos.

I would truly like to adopt itime and ftime as the inode-change and file-create
times.  Corresponding valid bits would be APR_FINFO_ITIME
and APR_FINFO_FTIME.

Would there be significant objection to this change?  additional thoughts?

Bill

At 02:08 PM 4/28/2002, Brian Pane wrote:
>What *is* the meaning of ctime in apr_finfo_t supposed to
>be?  On Unix, it's set to the Unix ctime (last modification
>time of the inode).  On Windows and OS/2, it looks like
>it's being set to a file creation time instead.

Exactly why it's all so misleading.


>Sander Striker wrote:
>
>>Hi,
>>
>>I always thought ctime was 'creation' time.
>>
>>However in include/apr_file_info.h:209
>>    /** The time the file was last modified */
>>    apr_time_t mtime;
>>    /** The time the file was last changed */
>>    apr_time_t ctime;
>>
>>Aaron pointed out to me that OtherBill has
>>explained this misconception of creation time
>>in the past.  Bill, could you please document
>>in that file what is understood as a 'modification'
>>and what is known as a 'change'?

Re: Docu buglet in apr_file_info_t?

[Brian Pane <bp...@pacbell.net>]

What *is* the meaning of ctime in apr_finfo_t supposed to
be?  On Unix, it's set to the Unix ctime (last modification
time of the inode).  On Windows and OS/2, it looks like
it's being set to a file creation time instead.

--Brian

Sander Striker wrote:

>Hi,
>
>I always thought ctime was 'creation' time.
>
>However in include/apr_file_info.h:209
>    /** The time the file was last modified */
>    apr_time_t mtime;
>    /** The time the file was last changed */
>    apr_time_t ctime;
>
>Aaron pointed out to me that OtherBill has
>explained this misconception of creation time
>in the past.  Bill, could you please document
>in that file what is understood as a 'modification'
>and what is known as a 'change'?
>
>Thanks,
>
>Sander
>