On Mon, Mar 17, 2008 at 6:47 PM, Michael Ruck <[EMAIL PROTECTED]> wrote: > Hi all, > > Another step towards the VFS is wildcard expansion. There are many different > ways to implement it and the operating systems in use have chosen different > approaches to it. Basically there are two approaches and several in between > these two: > > > 1. The shell performs the wildcard expansion. > > > This approach is used in *nix and is usually available in usermode as the > glob function [1] in libc. (Conforming to several POSIX standards.)
This would be my choice... this would only introduce more complicated code... what may be a better idea would be to allow filesystem drivers to add rules or somehow extend the globbing :-) That way, all the standard globbing constructs will work everywhere, and if you know the result is going to be on a certain kind of filesystem, then you can use the extensions. The interface to use in the filesystem drivers is non-obvious for sure but it's worth looking into. > Other uses are likely, just don't come to mind. How about a metadata FS? Granted, the same could be done with some virtual directories and special handling but you could do: /path/to/place/**/[Project:Work] ...to find all files under /path/to/place which had an attribute "Project" with the value "Work"... Lots of extensions come to mind for this sort of thing. But naturally, making globbing an entirely FS-based thing would result in the need of yet another common library to implement those standard globbing mechanisms, when we could merely provide the standards with an extension syntax like this: /path/to/place/**/[meta(Project: Work)] > It applies to SharpOS primarily as a question, who is responsible to > implement the wildcard expansion which may be requested through > Directory.GetDirectories, Directory.GetFiles, Directory.GetFileSystemEntries > or DirectoryInfo.GetFiles, DirectoryInfo.GetDirectories, > DirectoryInfo.GetFileSystemInfos (does anyone else think that name is > wrong?). > > We can move this into a helper function used by all of those functions, > implement this as a helper function in the VFS or have the filesystems > themselves do the right thing. Your opinion? > > My vote is to implement this stuff in [K|c]orlib. Home directory lookup > should imho not be done by the VFS in order to prevent tight coupling > between the VFS and any kind of user management. I'd like the VFS to remain > almost free of references. (The only other Kernel component I currently need > is some sort of TEB for the threads current directory.) Korlib would be the right place to do that yeah. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ SharpOS-Developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sharpos-developers
