Don't you think this is an over kill? If I remember the question "is it
possible to obtain the number of files in a directory (no sub-directories)
without to enumerate all files, for example as FindFirst and FindNext?"
Simplese way ive found (with findfirst/findnext) is:
function howmanyfiles(path : string) : integer;
var
sr : tsearchrec;
begin
result:=0;
if FindFirst(path,faAnyFile-faVolumeID-faDirectory, sr) = 0 then
begin
repeat
inc(result);
until FindNext(sr) <> 0;
FindClose(sr);
end;
end;
I believe this came from the DOS days where there was interrupt 21h (MSDOS
functions) had the "find first file in specified path" and returned a buffer
which was used for another interrupt 21 call "find next file using buffer";
I guess it has stuck until today. So I honestly don't think there is an
easier method; unless we start going to read FAT tables etc on disk. Any
idea how it is done in unix/linux?
J
PO Box 627 00502 Karen,
Nairobi, Kenya.
Mobile: +254 722 996532
Fixed: +254 20 2050859
[EMAIL PROTECTED]
_____
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf
Of Rob Kennedy
Sent: 13 May 2008 1:39 a
To: [email protected]
Subject: RE: [delphi-en] file counting
Peter Luijer wrote:
> Like others already said: you still have to count all files manually
> (with a FindFirst/FindNext/FindClose-structure).
>
> If you want I got a simple threaded fileparser-code, by assigning an
> OnFind-event you can simply increase a count-integer variable:
>
> [code]
> Unit FileFinder;
>
> Interface
>
> Uses
> Classes, SysUtils;
>
> Type
> TFinderFindEvent = Procedure(FileName : String; Var Abort : Boolean) Of
> Object;
Avoid unnecessary string reference counting. Pass strings as const.
> TFileFinder = class(TThread)
> Private
> fAbort : Boolean;
> fCur : String;
> fPath : String;
> fExt : String;
> fRec : Boolean;
> fOnFind : TFinderFindEvent;
> Protected
> Procedure Execute; Override;
> Procedure UpdateFind;
> Public
> Constructor Create(AFilePath : String;
> AExtension : String;
> ARecursive : Boolean;
> AOnFind : TFinderFindEvent);
> Procedure Abort;
Since this method is public, and it never gets called from code in this
unit, it must be something you expect to be called by other code in other
threads. Keep this in mind for a later comment....
> End;
>
> Implementation
>
> Procedure TFileFinder.Execute;
>
> Procedure ProcessRec(Rec : TSearchRec);
Avoid unnecessary copying of records on the stack. Pass records as const.
Or, since this is a local procedure anyway, don't pass it at all. Just
declare R before ProcessRec, and then use R wherever you now use Rec.
(Doing that also avoids the confusing situation of Rec and fRec having
similar names but completely different meanings within the same
statements.)
> Begin
> fCur := fPath + Rec.Name;
> If (Not fAbort) Then
> If (Rec.Attr And faDirectory > 0) And
> (Rec.Name <> '.') And
> (Rec.Name <> '..') And
> (fRec) Then
> TFileFinder.Create(fCur, fExt, fRec, fOnFind)
With this, you create a new thread for every directory on the system. That
could mean hundreds of threads running at the same time!
If you want to allow having multiple threads traversing the file system at
once, I suggest you use a thread pool to limit the number that are
contending for the same resource at the same time.
> Else
> If (fExt = '') Or
> (LowerCase(ExtractFileExt(Rec.Name)) = fExt) Then
> Synchronize(UpdateFind);
Note that the OnFind event will not receive paths that end with directory
names. Instead, a directory path will end with a backslash and a dot or
dot-dot. Valid, but probably not what's expected.
> End;
>
> Var
> R : TSearchRec;
> Begin
> fAbort := False;
> fCur := '';
> fPath := IncludeTrailingPathDelimiter(fPath);
> If (FindFirst(fPath + '*.*', faAnyFile, R) = 0) Then
> Try
> ProcessRec(R);
> While (Not fAbort) And
> (FindNext(R) = 0) Do
> ProcessRec(R);
I notice that you don't check the Terminated property in this loop. That
property seems to serve the same purpose as your FAbort field.
> Finally
> FindClose(R);
> End;
> End;
>
> Constructor TFileFinder.Create(AFilePath : String;
> AExtension : String;
> ARecursive : Boolean;
> AOnFind : TFinderFindEvent);
> Begin
> Inherited Create(True);
> FreeOnTerminate := True;
You set FreeOnTerminate to True, meaning that the object could get freed
at any time. The code that instantiated this thread class won't get any
notification when the thread terminates, but you've still provided a
public method to call on this thread. This is a dangling pointer waiting
to happen.
> If Assigned(AOnFind) Then
> Begin
> fPath := AFilePath;
> fExt := LowerCase(AExtension);
> fRec := ARecursive;
> fOnFind := AOnFind;
> Resume;
> End
> Else
> Free;
If having a callback method is a precondition for creating the thread,
then the proper way to enforce that is by raising an exception. Do not
make the object silently free itself. That could lead to an access
violation (since the AfterConstruction method will still get called on the
now-stale object reference, and TThread's AfterConstruction method
actually does non-trival work!). Either call Assert(Assigned(AOnFind)) or
raise your own exception.
Even if the call to AfterConstruction doesn't crash, you run the risk of
returning a stale object reference from the constructor. The caller is
given a non-null reference to an object that already doesn't exist. That
typically *never* happens. It's ingrained in developers' minds that if a
constructor returns, then the result is a valid object reference -- a
reference that should be safe to call Abort on, in this case. Don't
violate that rule.
> End;
>
> Procedure TFileFinder.UpdateFind;
> Begin
> If Assigned(fOnFind) Then
> fOnFind(fCur, fAbort)
Since a non-null OnFind event is a precondition for creating the object,
you don't need to check it here.
> Else
> fAbort := True;
> End;
>
> Procedure TFileFinder.Abort;
> Begin
> fAbort := True;
If someone calls Abort on this thread, isn't the expectation that there
will be no more (or at most one more) OnFind event? So what do you do
about the possibly hundreds of other enumeration threads that this thread
has spawned? Shouldn't they be aborted, too?
> End;
How is the program supposed to know when file enumeration in this class
has finished?
--
Rob
[Non-text portions of this message have been removed]
