On Thu, Nov 08, 2001 at 10:46:30PM -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. > ...
I've implemented this. "glob -a cls *" works similarly to "ls *" in a shell; so does "glob -a cls -d *". FileCopyPeerCLS::Do is simpler, too. There are a couple problems: Easy one: "550 Not a directory." spams the output. Any reason not to move 550 for CWD to 4? Second, chdir results aren't cached, so it keeps doing the test chdirs every time. Of course, most chdir results shouldn't be cached; it's only useful for this case. Do you think we could use a more generalized cache? Perhaps a simple CacheObject base class, containing a type and a virtual destructor; allow searching for cached objects by name (path or whatever is appropriate) and type. (It'd mean using MI, but I don't think that's a problem.) Third, "glob -a cls *" is slow for large directories: cls has to re-parse the directory for each file. This is another incentive to have generalized caching: we could cache FileSets, too. We could also cache FileSets inside LsCache explicitely, alongside ls text, but that's a hack. Currently, the output of the above command isn't very good: it makes a separate column set for each file and directory. I'm going to make this operate like GNU ls (group files into one set, and one for each directory). This can't be done until the above two are fixed, however; it'd be too slow. Not going to bother you with a patch until I work out these issues, since it's not useful yet. (I've attached the class source, if you want to look at it; don't drop it in yet, though.) cls -d dir/ does work, too. (The only exception is "cls -d ."; it doesn't try to get to the parent path to get that; I might make it do that, though it won't always work. MLSD could deal with this cleanly, but nobody implements that ...) Since there are a lot of ways the caching could be worked out, I won't try implementing anything until you get back to me. The only basic problem that I'm not sure how to fix: what if we know a better way to do this? Doing this at a lower level would allow doing it different ways for different protocols. However, it's currently efficient (only one extra command; you'd need that no matter how you did it) and the logic is already generic enough to work for both FTP and HTTP, so we probably won't need that. -- Glenn Maynard
