apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: apr_stat
Date Sat, 20 Jan 2001 02:06:05 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> 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.

View raw message