On Friday, January 19, 2001, at 06:06 PM, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED] Sent: Friday, January 19, 2001 7:52 PM
apr_stat will reply in a new member value, finfo_valid, to describe the results returned. It will only fail for the current reasons. If it can't get a particular result, it just goes on, and it's the caller's job to check finfo.valid.
If I ask for a value and it can't return it, then I should get an error. I've explicitly said "give me this."
I could live with an APR_INCOMPLETE ... I couldn't live with an APR_FAILED. If we got something out of the call and can deal with it, great. If you had to have it, check the fileinfo.valid bits. Pretty stupid to abort the program for 'no activity date' on a file system, when you were mostly just looking for the file size.
Yes, absolutely.
One alternative, both a 'wants' and 'needs' value, or simply a APR_FINFO_FAIL bit that does what you ask. Apache won't use it, dav quite likely would in the properties area.
I like the fail bit idea, though I don't se why it's necessary... well you could abort as soon as you fail as opposed to trying to get as much of the data as available, so that could be a win.
I don't think we need to differentiate between user/group/world perms. Return none or return them all.
Each ONE of these adds clock ticks on Win32 to decipher... are you looking if the file is locked against world? Then ask.
There is a shorthand APR_FINFO_PROT, and APR_FINFO_OWNER, since most folks would be pissed off having to spell all these out.
+1.
But if I'm not mistaken, there are unices without _any_ group concept whatsoever, correct?
None that i know of, but the detailed API plus shortcut is good all around and covers all bases.
... I'm suggesting we add asize (allocated size, e.g. for filesystems with preallocation) and csize (the actual size consumed on disk.)
Let's leave these out until we have a real need and can properly support
them. This stuff is all so non-portable to begin with, let's not bite off
more than we truly need.
Well since it's a public type, we are screwed on binary compatibity if we wait for those decisions until later. Love reading that sys/stat.h header :-/ I'm actually interested in any feedback from Fred or Brian, if there are other things we should have our eyes on.
You can pad the structure with some reserved field space. We do that with device driver API, and it's saved us a few times.
We do have additional metadata support in the system API, though I don't
know that it's useful to APR to include them. <sys/attr.h> (attached)
describes them on Darwin. This includes you typical Unix info plus some
more. Note that while this was largely driven by HFS+, we also need it
for UDF (DVD filesystem), possibly NFSv4, and others...
- filesystem ID; more unique than device ID, as a device may switch media, but still have the same ID, and a repeated dev/inode pair may be on different media. - object permanent ID; like an inode, but can be used to open the file. Good for performance because the path lookups are bypassed, also good if you want to find the file again even if it moved. - backup time - number of named attributes - size info for each named attribute - the named attributes; perhaps useful to a WebDAV fs plugin for property storage which is actually attached to the associated resource - allocation size - block size; perhaps good for tuning I/O - invisible bit (advisory) - etc.
There is also BSD flags information (immutable bits, append-only, etc.;
see chflags(1)). Also see the POSIX patchconf() API, which provides similar
info about case, max path length, etc.; see pathconf(2).
Never mind that we don't have to ever fill anything in them, we just need
to declare today what we expect we need tommorow. I doubt we will even
try assulting this for a revision or three, and I doubt I'll drop in win32
owner/group/perms this week. The point is, put the hooks right there so
we can move forward later. We have some more serious problems, also
tangled in these issues, on the win32 platform.
So I think there's a lot that we might want (32 bits might not cut it!),
and more we won't anticipate. So maybe we want to decide that we aren't
interested in anything more than we have to have (but what's that?) or
pad some space and use it up as we need it.
-Fred
attr.h
Description: Binary data
