apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wilfredo Sanchez <wsanc...@apple.com>
Subject Re: apr_stat
Date Sat, 20 Jan 2001 04:34:42 GMT

On Friday, January 19, 2001, at 06:06  PM, William A. Rowe, Jr. wrote:

>> 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."
> 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.


> 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 
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 
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 
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.


<Attachment missing>
View raw message