Hi all,
on system with long file name support activated (I have FreeDos with doslfn), the example below types all files instead of directory only.

program test;
uses dos;
var f:searchrec;
begin
findfirst('*',directory,f);
while doserror=0 do begin
writeln(f.name);
findnext(f);
end;
findclose(f);
end.

Looking at the Ralph Brown's list I found the problem which arises as the attribute value must be loaded twice in the cx register in his low and high halves for (respectively) the allowable and required search criteria. Changes to accomplish that are in the diff attached, $37 is AnyFile constant cleared of the volume label bit.
A total different point: in the zip file of the source of the compiler all texts are in the Unix end line format, the result are broken recompilation process on Dos'es. Maybe it would be better to convert it, Info-Zip has a specific option during compression. Marco

Marco Borsari wrote

on system with long file name support activated (I have FreeDos with doslfn), the example below types all files instead of directory only.

That is by design, see http://www.freepascal.org/docs-html/rtl/sysutils/findfirst.html (the same goes for the findfirst from the Dos unit), in particular:

***
It is a common misconception that Attr specifies a set of attributes which must be matched in order for a file to be included in the list. This is not so: The value of Attr specifies additional attributes, this means that the returned files are either normal files or have an attribute which is present in Attr.

Specifically: specifying faDirectory as a value for Attr does not mean that only directories will be returned. Normal files and directories will be returned. ***

You have to check the attributes of the returned entries to see whether they match what you want. This is TP/Delphi-compatible.

Jonas

Jonas Maebe wrote

That is by design, see http://www.freepascal.org/docs-html/rtl/sysutils/findfirst.html (the same goes for the findfirst from the Dos unit) You have to check the attributes of the returned entries to see whether they match what you want. This is TP/Delphi-compatible.

I don't know of Delphi compatibility, but sure not for TP and/or FPC itself when doslfn is disabled. It cannot be other than that, because the interrupt service which lies on short FindFirst don't accept in the cx required criteria, but only allowable. Retaining this discrepance makes old application that use file searching to crash when running on new environment.
Marco

Marco Borsari wrote

Jonas Maebe wrote:

Marco,

Jonas is right, it is no bug. The difference you get between the case of having LFN enabled or not is most likely related to the fact that you search for '*' mask rather than '*.*' in your example. As you might know, '*' matches or names with or without extensions on LFN enabled drives (or operating systems - see below) whereas SFN limited access (which includes TP/BP) requires you to use '*.*' to get the same result. Typically, directories don't have any extensions on DOS drives which is the most likely explanation for your results. You can check the results with the attached example program (I just did and the results if compiled with TP/BP and FPC are exactly the same for me).

Tomas

Il 28/02/2012 23:34, Tomas Hajny ha scritto:

Jonas is right, it is no bug. The difference you get between the case of having LFN enabled or not is most likely related to the fact that you search for '*' mask rather than '*.*' in your example. As you might know, '*' matches

I missed that, thank you for the explanation, and Jonas too. Anyway it suffices to put $1010 instead of Directory in FindFirst in the release version of FPC for listing only dirs in LFN mode.

Correct, but it is just a coincidence (as opposed to the situation with SysUtils.FindFirst, where it is part of the specification).

Tomas