On Thu, Nov 08, 2001 at 01:28:00PM -0500, Glenn Maynard wrote: > > I don't think ListInfo should handle path-to-file argument. Anyway, it > > would have to list all parent directory to get the info. > > It would have to list the parent to do this, yes (another reason for it > to be optional, at least at the API level).
Err, no, that's not right. (Replying to mails first thing in the morning ...) That's the reason for the two chdir()s: preventing extraneous LISTs (since chdir is much cheaper.) Here's the API I'm thinking about: init with a path argument and a boolean "list directory entries instead of contents" flag. Example: given "/dir/path" and a false flag, it first tries "CWD /dir/path". If the CWD succeeds, it just uses ListInfo to return the contents. If the CWD fails (or if the flag was true), it tries "CWD /dir". If that fails, the operation fails. If it succeeds, it uses ListInfo to get a listing, and excludes everything except "path". If it doesn't exist, fail. If it's a directory, fail (this would happen if the path is actually a directory, but the Chdir failed because we don't have access to it). Otherwise return the ListInfo with just "path" in it. The only tricky part: "which directory is the FileSet actually in?" Two options: we can make the class itself make this available, or we can add a char *dir to FileSet. Any reason not to do the latter? It'd be nice to keep this class fully API-compatible with ListInfo--perhaps even be a ListInfo implementation. The directory path itself seems appropriate for FileSet, too. (Well, a relative path, not an absolute path unless that's what was actually given.) du momentarily. -- Glenn Maynard
