> >
>> * Should I modify srclib/apr/include/apr_file_info.h?
>
>That will break binary compatibility. Fine today, horrible tommorow.
>
>I think we need an extension schema that won't keep breaking. Care to propose one :-?
>
>If you wanted to add stuff that -many- systems support, I don't know that anybody
>would
>object (physical size in storage [which maps to the '.size' if unknown], etc.) Let's
>finish
>defining those today, and agree to relagate all future growth into the extension
>schema.
UNIX hasn't changed in the last 30 years, I doubt it will in the next 5000.
In other words I don't see anybody else using these.
If I were to propose a serious solution I would start by defining an arbitrary
metadata/file attribute standard for vfs then plead that standard UNIX file management
tools like cp used the API. But I don't see that happening.
I don't know enough about Apache to propose specific changes in the API, but I would
like to propose that certain assumptions be dropped like all mime-related declarations
are only related to filename extensions. I don't really think that suggestion will be
taken seriously so I'll just wait until I can implement what I want to, whenever that
is.
>If we are adding the content/language stuff, I suggest that goes in the extensible
>mechansim. Simply add an APR_FINFO_EXTRA bit if there might be something more to ask.
I guess. It's a pity most commonly used filesystems aren't more flexible so that
adoption of things like mime type file attributes were easier to implement. Of course
there would probably also have to be an extension to the ANSI standard library too.
The decisions made 30 years ago still haunt me.
> > * What is the difference between mtime and ctime? Also, would anybody have any use
>for creation date (as opposed to modification
>date)? I don't think anything outside the mac world uses creation dates.
>
>modified versus created (I think that answers your question.) And yes, Win32 NTFS
>and some other systems have ctime. So does unix.
I thought ctime was when a file was last 'changed'. From apr_file_info.h:
/** The time the file was last accessed */
apr_time_t atime;
/** The time the file was last modified */
apr_time_t mtime;
/** The time the file was last changed */
apr_time_t ctime;
'changed' doesn't sound equivalent to 'created'. I'm pretty sure UNIX does not support
creation date (since it didn't 30 years ago). Maybe somebody can double-check that.
Basically the creation date shouldn't change, not even if the file was copied (thus
the distinction).
> > Once I know which attributes I need to fill out, I can get them using one call of
>getattrlist(). Those attributes a file system
>can't fulfill will be null.
>
>Essentially, if you can grab them on your first apr_file_info_get or apr_stat call,
>then do so, but stash them in the more info pointer. It can be an abstract (void*)
>member of the structure. Allocate it on the pool.
If/when this 'more' info pointer exists, I may need some source code to get me going.
I'm not yet familiar with Apache memory management.
> > Question: How does Apache write files? What if somebody uploads a file via webdav
>or something, and I wish to set the correct
>attributes. Is that even possible? (I don't know what information web browsers will
>send when uploading a file. I fear the worst in
>that they will only send the file name)
>
>mod_dav_fs extended the 'vanilla' DAV protocol to the file system. If they upload
>by something other than webdav, I'm afraid it's that module/cgi author's job to
>deal with it.
>
>If we get mod_dav_fs right, it will be a fine example for the rest of those authors :)
>
So does webdav provide hooks to include more file attribute information? The problem
is Apple is probably going to transition to webdav and I don't see how that's going to
preserve important data like creation date when the standard http protocol doesn't.
