From: SMTP%"cjc@dsc.com" 25-NOV-1997 21:01:03.09 To: "'ntdev@atria.com'" CC: "'rick@rdperf.com'" , "'joni@march.co.uk'" Subj: RE: [ntdev] File functions Return-Path: owner-ntdev@atria.com Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Tue, 25 Nov 1997 20:57:11 -0500 Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by mercury.mv.net (8.8.8/mem-971025) with SMTP id SAA04195 for ; Tue, 25 Nov 1997 18:47:26 -0500 (EST) Received: by gw.atria.com id Tue, 25 Nov 1997 13:11:19 -0500 Received: from gypsum.dsc.com by gw.atria.com id Tue, 25 Nov 1997 13:11:15 -0500 Received: by gypsum.dsc.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCF98A.62830CD0@gypsum.dsc.com>; Tue, 25 Nov 1997 10:10:41 -0800 Message-ID: From: "Ciechanowski, Chet" To: "'ntdev@atria.com'" Cc: "'rick@rdperf.com'" , "'joni@march.co.uk'" Subject: RE: [ntdev] File functions Date: Tue, 25 Nov 1997 10:10:39 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ntdev@atria.com Precedence: bulk An API for Win32 wildcard file searching, including directory names, was described by Cornel in the April 1995 issue of The C/C++ User's Journal. The source code can be downloaded from http://www.cuj.com/code/archive.html. The code isn't very pretty, but it seems to work. Chet Ciechanowski Digital Sound Corp. Carpenteria, CA http://www.dsc.com >-----Original Message----- >From: rick@rdperf.com [SMTP:rick@rdperf.com] >Sent: Monday, November 24, 1997 2:06 PM >To: joni@march.co.uk; ntdev@atria.com >Subject: Re: [ntdev] File functions > >> >>Can anyone please tell me the NT system functions I should be looking at >>to do the following: >> >>I need to write a wildcard expansion routine for a product of ours. >>I want to be able to expand both directories and files. >> >>Example: >> >>C:\*\DEVEL\*.abcd >> >>to >> >>C:\XYZ\DEVEL\jon.abc >>C:\PQR\DEVEL\peter.abc >> >>Any pointers appreciated. >>TIA >>Jon > >You can use the following WIN32 calls to do wildcard lookup within a >single directory: > > FindFirstFile / FindNextFile > >To do multi-level scans, I have not found anything. If anyone knows of >a fully functional API to do this, I am sure many people who follow this >list would be interested. > >I have written my own primitive multi-level scanning, but it can't >handle wildcarded directory specs. The parsing/matching stuff is >quite a lot of work. Also, there does not exist a multilevel wildcarding >specification within directories for NT as is present in OpenVMS. > >On VMS: > [Rick...test.*]*.* does all sub directories in the "Rick" tree > one level below a "test" directory. ie. > > [Rick.test.foo]*.* > [Rick.more.stuff.test.ABC]*.* > not > [Rick.test]*.* > [Rick.test.foo.stuff]*.* > [Rick.more.stuff.for.you]*.* > >On NT, I suppose one could use a syntax like: > > \Rick...\test\*\*.* > >I don't know if this would be a problem because I suspect that a spec like >"Rick..." would be legal for a directory. Perhaps something like: > > \Rick\*\test\*\*.* > >The problem with that is that it does not let you do either one level or >all levels below the current. Maybe something like: > > \Rick\*...\test\*\*.* > >My problem with inventing a syntax to use is that I don't want it to conflict >with syntaxes the file system recognizes. Clearly I am not looking to pass >the full syntax on. However, you have to be able to specify a syntax that >does not exist in the real filesystem. ie. "\Rick...\", or "\...\" might >specify valid filespecs wheras something like "\*...\" might not. That >would make it an ideal candidate for lower level processing and would be >fairly self-explanatory ("*" for full wildcarded and "..." for whatever >levels are below). > >There is also the issue of whether it immediately scans downward upon seeing >a directory or waits until all files are returned at the current level. >Also, there's the issue of whether you get back the directory specs as well. >I believe they are necesary provided they can be easily identified as such. > > >Rick Cadruvi >R&D Performance Group, Inc. >1180 E Patricia #102 >Simi Valley, CA 93065 >rick@rdperf.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >[ To unsubscribe, send email to ntdev-request@atria.com with body >UNSUBSCRIBE (the subject is ignored). ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ]