为什么FindFirst返回与掩码不匹配的文件名？ [英] Why does FindFirst return file names that don't match the mask?

问题描述

我将参数值'* 1.dat'传递给FindFirst，仍然是FindFirst（）例程返回的第一个文件是 46checks5。 dat ，非常一贯。

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 res=0 do
    begin
      vlist.add(search.name);   //searchname returned is 46checks5.dat!!!
      res:=findnext(search);
    end;
  finally
    findclose(search);
  end;
except
  result:=false;
end;

推荐答案

原因是文件有一个长名称，即超过8个字符。对于这样的文件，Windows还创建短名称，通常以 longna〜1.dat 的形式创建，通过 *可以找到这个简短的名称。 1.dat 通配符。

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

FindFirstFile（） ，这是 FindFirst 状态：

搜索包括长短
文件名

The search includes the long and short file names.

然而，为了解决这个问题，而不是使用Delphi的包装器来 FindFirstFile（），调用Win32 API FindFirstFileEx（） 。通过 FindExInfoBasic 到 fInfoLevelId 参数。

To workaround this issue, then, rather than using Delphi's wrapper to FindFirstFile(), call the Win32 API FindFirstFileEx(). Pass FindExInfoBasic to the fInfoLevelId parameter.

这篇关于为什么FindFirst返回与掩码不匹配的文件名？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！