https://www.freepascal.org/docs-html/rtl/sysutils/findfirst.html

1) add to the list of attribs the value faAnyFile.

2) correct the example: call FindClose only inside block "if FindFirst(..)=0"

AlexeyT wrote

https://www.freepascal.org/docs-html/rtl/sysutils/findfirst.html 1) add to the list of attribs the value faAnyFile.

Done.

2) correct the example: call FindClose only inside block "if FindFirst(..)=0"

This is already so in trunk.

Michael.

Hello,

Le 22.09.19 à 16:59, Michael Van Canneyt a écrit :

From https://www.freepascal.org/port.html about porting Turbo Pascal codes:

the dos unit Findfirst() call must always be followed by a Findclose to release some resource.

What's right ?

Cheers, Ched'

Ched schrieb am So., 22. Sep.
2019, 21:11:

Both. AlexeyT and Michael are talking about
SyeUtils.FindFirst/FindNext/FindClose while the page you mentioned is about Dos.FindFirst/FindNext/FindClose. Same names, but different units with slightly different behavior.

Regards,
Sven

The sysutils one. I will adapt the 'port' document.

Michael.

Michael Van Canneyt wrote

On Sun, 22 Sep 2019, Ched wrote:

.
.

As mentioned by Sven, there's probably no reason for any adapting it - people porting Turbo Pascal code use Dos.Find* rather than the sysutils version and since Dos.FindFirst doesn't return a handle directly (it's hidden within the SearchRec record), calling Dos.FindClose always is the safest bet.

Tomas

Ah, I thought the dos one meanwhile called the sysutils one.

In that case, you're probably right.

Michael.

I have ported Turbo Pascal code but then use Sysutils instead of DOS, my intention was to convert it to a windows console application that used windows features, and I had no interest in maintaining Turbo Pascal backward compatibility, and the use of findfirst, findnext, etc, was part of the code that never changed. I actually was not aware that there even was a command called findclose, and I never did it in Turbo Pascal.. it IS in there now, and I believe it was a discussion on this list that prompted me to add it. Anyway, just wanted to say, there are reasons to want to port Turbo Pascal code and then switch over to systutils, so having documentation that includes the differences between the versions would be helpful.

James

As mentioned by Sven, there's probably no reason for any adapting it - people porting Turbo Pascal code use Dos.Find* rather than the sysutils version and since Dos.FindFirst >doesn't return a handle directly (it's hidden within the SearchRec record), calling Dos.FindClose always is the safest bet.

James Richters wrote

I have ported Turbo Pascal code but then use Sysutils instead of DOS, my intention was to convert it to a windows console application that used windows features, and I had no interest in maintaining Turbo Pascal backward compatibility, and the use of findfirst, findnext, etc, was part of the code that never changed. I actually was not aware that there even was a command called findclose, and I never did it in Turbo Pascal.. it IS in there now, and I believe it was a discussion on this list that prompted me to add it. Anyway, just wanted to say, there are reasons to want to port Turbo Pascal code and then switch over to systutils, so having documentation that includes the differences between the versions would be helpful.

Turbo Pascal (for DOS) didn't have a FindClose function, as "officially", this would not be necessary on DOS. On all other OS, including Windows, for many, many years (I first stumbled about missing "FindClose" call in OS/2 some time in the early '90s) and got used to *alway**s* terminate a file search with it, even if it is in the case of DOS just a dummy routine that just returns without doing nothing. Saves a lot of headaches trying to find the source of apparent memory leaks in larger applications that do a lot of of file searches...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Related,

It would seem on Linux that FindFirst, FindNext or TSearchRec that none of them can properly detect a symbolic link. For example, if you wanted enumerate files and folder, and there exists a symbolic link inside one folder to some parent of said folder, it's not possible to detect leading to endless recursion. faSymLink currently isn't picked up. I have to use code like this:

uses
  BaseUnix;
function IsSymLink(const Path: string): Boolean;
var
  Stat: TStat;
begin
  fpLstat(PChar(Path), Stat);
  Result := fpS_ISLNK(Stat.st_mode);
end;

Which slows down the search a bit.

It works here. Did you specify faDirectory together with faSymlink ?

If you don't, directories will not get picked up since the directory attribute is included in the resulting info (as windows does this too).

I.e. this won't work:

uses sysutils;
var
   info : TSearchrec;
begin
   if findfirst('*',faSymlink,Info)=0 then
     try
     repeat
       if (info.attr and faSymlink)0 then
         Writeln('symlink :',info.name)
     until findnext(info)0;
     finally
       findclose(info);
     end;
end.

It will only pick up symlinked files.

But

uses sysutils;
var
   info : TSearchrec;
begin
   if findfirst('*',faSymlink or faDirectory,Info)=0 then
     try
     repeat
       if (info.attr and faSymlink)0 then
         Writeln('symlink :',info.name)
     until findnext(info)0;
     finally
       findclose(info);
     end;
end.

will report directories.

Tested in trunk and 3.0.4

Michael.

Op 2019-09-24 om 03:03 schreef Ralf Quint:

Note that afaik Long File Name supporting versions of the Dos unit with Turbo Pascal did have findclose, as afaik the LFN apis required it too.

I don't recall that there was a "DOS" unit in Turbo Pascal that was LFN aware, at least not as part of an official Borland distribution up to Borland Pascal Professional 7.01, the last version that I bought way back then. I just checked the Reference Manual... ;-)

I have personally never cared about LFN in pure DOS, don't know if it was maybe part of Borland Pascal for Windows or in Delphi 1.02, but I think FindClose was part of Delphi 3, which I didn't buy until I moved to the US and then used on Windows 95 and NT 4. Checking RBIL states that FindClose is an INT21h function required for Long Filenames (AX=71A1h) but "this function is only available when IFSMgr is running, not under bare MS-DOS 7"

I now remember that I stumbled across the FindClose issue when running a BP7 program in an OS/2 DOS box, rather than true OS/2 program. And that I found the reason/solution in a Beta (alpha?) version of Metrowerks Codewarrior for OS/2, which I had access to for a while (to bad that that never got officially released, it would have given Borland a run for their money)...

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Op 2019-09-24 om 18:57 schreef Ralf Quint:

There are several, e.g. in Swag. IOW they are 3rd party reimplementations of the dos unit based on int21 ah=7x functions, often also supporting things like copy/pasting to clipboard. I skipped win3.x TP(W)/Delphi versions, so I don't know their exact status either.

I assume anything win32s or win32 will use findclose.

Such units checked this, as did FPC soon after, supporting both cases with one RTL. There are also lfn giving TSRs buy apparantly YMMV.

I came back to BP in that period very shortly, moving on to FPC swiftly after.

Michael,

Okay I tested and it turns out you are right. I was omitting faDirectory or faSymLink in FindFirst, so the faSymLink is only set in TSearchRec if you request it. Thanks.

You're welcome.

You would not be the first to be confused by the use of the attributes mask. I get confused myself sometimes... :(

Michael.