> 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."
Then we should have an API describing the capabilities, but of course those will vary from volume to volume depending on the file system. 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. 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. > > #define APR_FINFO_USER 0x00010000 > > #define APR_FINFO_GROUP 0x00020000 > > #define APR_FINFO_UPROT 0x00100000 > > #define APR_FINFO_GPROT 0x00200000 > > #define APR_FINFO_WPROT 0x00400000 > > 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. But if I'm not mistaken, there are unices without _any_ group concept whatsoever, correct? > >... > > 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. 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.
