> From: Wilfredo Sanchez [mailto:[EMAIL PROTECTED] > Sent: Friday, January 19, 2001 10:35 PM > > On Friday, January 19, 2001, at 06:06 PM, William A. Rowe, Jr. wrote: > > > 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.
The only pain is the wasted cpu ticks to test throughout. Dunno... anyone else have feelings on this? > > 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. Ack, that would be a very good decision here. > 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... I believe metadata (streams in NTFS/W2K) is useful, but will grow it's own api as we find uses for it. > - 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. I really like this! But is it worth adding to stat, or should we grab it based on a seperate query (removable media shouldn't be removed that often, I wouldn't want to picture stating a directory worth of files if this id isn't handy.) btw... I use the volume id on win32 already... nothing stoping this from being 64 bits on some platforms. I think we agree around here that inode/dev don't necessarily represent their original unix implementation, but act as uniquifiers. I'd pitch the usual dev and go for the volume id if it's handy. The tricks we might want to play with dev involve anticipating mount characteristics, such as case sensitivity, but it would be nice to recognize removable media changes. > - 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. Ack... we need to leave some bytes for platform specific optimizations, but they really have to stay transparent. I'm envisioning opening an apr_file_t from an apr_finfo_t, on Win32 this is because we can dup the stat handle. Sounds very similar on OSX. > - backup time Reasonable... any other filesystems tracking this yet? > - 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 This -really- sounds like a seperate api, it can't possibly be that convient within the context of a stat? I envision that dav will be the driver here, in terms of requirements. Definately -not- a showstopper :-) > - allocation size asize - already caught it. > - block size; perhaps good for tuning I/O in terms of the device, that ought to land in it's own dev api. csize should represent the space consumed (blocks * blksz, adjusted for an compression going on.) > - invisible bit (advisory) this is a good idea - had this since the ms-dos days. can be a test for the '.' char in unix. > 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). I saw those ... arguments pro/con for y'er favorites, anyone? > 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.
