I pass the parameter value '*1.dat'
to FindFirst, still the first file that the FindFirst() routine return is 46checks5.dat
, very consistently.
Is this a known problem?
vpath:=trim(vpath);
result:=true;
try
res:=findfirst(vpath+'\'+vmask,faarchive,search); //vmask = *1.dat
try
while re开发者_运维问答s=0 do
begin
vlist.add(search.name); //searchname returned is 46checks5.dat!!!
res:=findnext(search);
end;
finally
findclose(search);
end;
except
result:=false;
end;
The reason is that the file has a "long" name, i.e. with more than 8 characters. For such files Windows also creates "short" names, that usually are created in the form longna~1.dat
and this short name is found via *1.dat
wildcard.
You can easily reproduce the same behaviour in command prompt in an empty directory:
C:\TEMP>echo. > 46checks5.dat C:\TEMP>dir /x *1.dat Volume in drive C has no label. Volume Serial Number is 5C09-D9DE Directory of C:\TEMP 2011.04.15 21:37 3 46CHEC~1.DAT 46checks5.dat 1 File(s) 3 bytes
The documentation for FindFirstFile()
, which is the underlying API for FindFirst
states:
The search includes the long and short file names.
To workaround this issue, then, rather than using Delphi's wrapper to FindFirstFile()
, call the Win32 API FindFirstFileEx()
. Pass FindExInfoBasic
to the fInfoLevelId
parameter.
You have something else wrong.
I created a folder C:\Temp\Test
, and put three files in it:
TestFile1.txt
TestFile2.txt
TestFile3.txt
I then dropped a TMemo
on a new blank form in a new project, and added this code to the 'FormCreate' event:
procedure TForm1.FormCreate(Sender: TObject);
var
sPath: string;
sFile: string;
SR: TSearchRec;
begin
sPath := 'C:\Temp\Test';
sFile := '*1.txt';
Memo1.Lines.Clear;
if FindFirst(sPath + '\' + sFile, faArchive, SR) = 0 then
begin
try
repeat
Memo1.Lines.Add(SR.Name);
until FindNext(SR) <> 0;
finally
FindClose(SR);
end;
end;
end;
When the form was shown, the TMemo
showed exactly one file, TestFile1.txt
, just as I would expect.
精彩评论