Help with GetFiles

  • Thread starter Thread starter EL OSO
  • Start date Start date
E

EL OSO

Hi! I am about to create a small application that needs to process some
files stored in a directory.

GetFiles() returns a string array, OK, but I'm expecting to find MANY (over
150.000) files in the directory and I'm worried about getting a memory
overflow, since I expect something like... 15 letters per name in the
average.

Is there any way of accessing the files one by one like it was possible in
C++ with the _movefirst, _movenext, and _finddata_t type instead of storing
all names in memory?

PS: Sorry about my poor english!
 
My understanding of that example is that it will just store the results of
GetFiles() in a temporary variable, and be no differant than:

string[] files = Directory.GetFiles("path");
foreach(string file in file);

Unfortunatly, there doesn't seem to be any native way to enumerate the files
without using PInvoke and FindFirstFile, FindNextFile, and FindClose.

- Pete
 
AFAIK, that's correct, it's just if you use numeric iteration, you control
the subset a little eaiser.
AirPete said:
My understanding of that example is that it will just store the results of
GetFiles() in a temporary variable, and be no differant than:

string[] files = Directory.GetFiles("path");
foreach(string file in file);

Unfortunatly, there doesn't seem to be any native way to enumerate the files
without using PInvoke and FindFirstFile, FindNextFile, and FindClose.

- Pete

William Ryan said:
Check out this link...
http://www.knowdotnet.com/articles/recursivedirectorysearch.html

You could change this so you used a numeric index instead and only loop
through x at a time instead of all of them...
Click to expand...
possible
in
Click to expand...
Click to expand...
 
I understand your concern, but I don't think you need to worry about it too
much.

Even with as many files as you're talking about, it's not going to consume
all that much memory.

150.000 files * 30 bytes (2 bytes per char) = 4.500.000 bytes

That's almost 4.3 megabytes. That's not too terribly much memory.


I do agree though, that the .NET framework should have exposed a funciton
that returns an IEnumerator wrapping a Win32 call to FindFirstFile,
FindNextFile, etc.

You could write such an enumerator if you wanted using P/Invoke, if you
don't mind calling unmanaged code. This will depend on your security and
portability requirements, though.


Anyway, sometimes you don't need to be able to index a collection of file
names...but when you do, the .NET way is very nice. Still, I could see
where the IEnumerator option would have been nice (imagine an IEnumerator
for recusive searching!)

--Matthew W. Jackson
 
Back
Top