[fpc-devel] findfirst with ':' names
Hi,
Does findfirst not return filenames with a ':' character in them
properly? I only get the last part of the filename, the part after the
':'. Try listing /sys/bus/pci/devices with findfirst on a Linux system.
FindFirst('/sys/bus/pci/devices/*', faAnyFile, Info); etc...
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] findfirst with ':' names
On 24 Jan 2008, at 15:47, Micha Nelissen wrote: Does findfirst not return filenames with a ':' character in them properly? I only get the last part of the filename, the part after the ':'. Try listing /sys/bus/pci/devices with findfirst on a Linux system. Almost all rtl filename routines treat ':' and '\' wrongly on *nix systems (both are usually treated as some sort of separator). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FindFirst under Linux doesn't set faHidden
Hi, As per the documentation: http://lazarus-ccr.sourceforge.net/docs/rtl/sysutils/findfirst.html - faHidden The file is hidden. (On unix, this means that the filename starts with a dot) --- I've tried this today using FPC 2.1.5 and faHidden doesn't seem to be set, ever. Below is a list of files I tested on under Linux. I first printed the filename found by FindFirst/FindNext and then I printed True or False if the faHidden attribute was set. As you can see even for files with the '.' (dot) prefix, the faHidden is never set. .. FALSE .svn FALSE units FALSE . FALSE filegrid.lpr FALSE filegrid.lps FALSE filegrid.compiled FALSE filegrid.lpi FALSE filegrid FALSE .I_should_be_hidden FALSE I know unix OS's don't have a real notion of 'hidden' files, but it is a standard to treat dot prefix files as hidden. The FPC documentation mentions that and Kylix treated it like that as well. Can anybody else confirm this, before I submit a bug report? Oh, and here is the function I use to test the attribute: // Example: HasAttrib(sr.Attr, faHidden) returns True if faHidden was set. function HasAttrib(fileAttrib, testAttrib: Integer): Boolean; begin Result := (fileAttrib and testAttrib) 0; end; Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FindFirst with faAnyFile doesn't return all files.
Thanks. Reported as bug 9440. Graeme. On 15/08/07, Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 15 Aug 2007, Graeme Geldenhuys wrote: Hi, This was posted in the Lazarus mailing list a while back. Has this been report or fixed in FPC? Neither reported nor fixed. Please create a bug report in the FPC bugtracker. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FindFirst / FindNext gives random results in FPC 2.1.3
Hi,
I modified the example43 included with the documentation of FindFirst
(see below) so it can take a patch as parameter.
I then created a few dummy test files in numerical order.
Run the example43 test app and expected them to be in numerical order
(Delphi behavior and FPC 2.0.5 2.1.1 behavior). But for some reason
FPC 2.1.3 has now randomly changed the order of how it finds the
files.
I'm testing on Linux (i386) with FPC 2.1.3 (r7241).
Is this a bug? As I mentioned, it used to work fine on 2.0.5 and
2.1.1 and Delphi.
[EMAIL PROTECTED]:~/programming/tests/FilesToStringList$ ppc386 example43.pas
Free Pascal Compiler version 2.1.3 [2007/05/02] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling example43.pas
Linking example43
35 lines compiled, 0.5 sec
[EMAIL PROTECTED]:~/programming/tests/FilesToStringList$ ./example43
/tmp/Common/Modules/AD32/001
004.swf 37
Dir : .. 4096
003.swf 37
001.swf 37
002.swf 37
005.swf 37
Dir :. 4096
Finished search. Found 7 matches
[EMAIL PROTECTED]:~/programming/tests/FilesToStringList$
Here is my modified Example43 application
---[examlpe43.pas]---
Program Example43;
{ This program demonstrates the FindFirst function }
Uses SysUtils;
Var Info : TSearchRec;
Count : Longint;
lPath: string;
Begin
if Paramcount 0 then
begin
lPath := ParamStr(1);
lPath := IncludeTrailingPathDelimiter(lPath);
end;
Count:=0;
If FindFirst (lPath + '*',faAnyFile and faDirectory,Info)=0 then
begin
Repeat
Inc(Count);
With Info do
begin
If (Attr and faDirectory) = faDirectory then
Write('Dir : ');
Writeln (Name:40,Size:15);
end;
Until FindNext(info)0;
end;
FindClose(Info);
Writeln ('Finished search. Found ',Count,' matches');
End.
---[end-
--
Graeme Geldenhuys
General error, hit any user to continue.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FindFirst / FindNext gives random results in FPC 2.1.3
On Mon, 14 May 2007, Graeme Geldenhuys wrote:
Hi,
I modified the example43 included with the documentation of FindFirst
(see below) so it can take a patch as parameter.
I then created a few dummy test files in numerical order.
Run the example43 test app and expected them to be in numerical order
(Delphi behavior and FPC 2.0.5 2.1.1 behavior). But for some reason
FPC 2.1.3 has now randomly changed the order of how it finds the
files.
I'm testing on Linux (i386) with FPC 2.1.3 (r7241).
Is this a bug? As I mentioned, it used to work fine on 2.0.5 and
2.1.1 and Delphi.
No ordering is guaranteed.
Not in windows, not in Linux.
That you get them ordered is most likely because you created them in
that order, and the directory entries were therefor filled 'ordered'...
Michael.
[EMAIL PROTECTED]:~/programming/tests/FilesToStringList$ ppc386 example43.pas
Free Pascal Compiler version 2.1.3 [2007/05/02] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling example43.pas
Linking example43
35 lines compiled, 0.5 sec
[EMAIL PROTECTED]:~/programming/tests/FilesToStringList$ ./example43
/tmp/Common/Modules/AD32/001
004.swf 37
Dir : .. 4096
003.swf 37
001.swf 37
002.swf 37
005.swf 37
Dir :. 4096
Finished search. Found 7 matches
[EMAIL PROTECTED]:~/programming/tests/FilesToStringList$
Here is my modified Example43 application
---[examlpe43.pas]---
Program Example43;
{ This program demonstrates the FindFirst function }
Uses SysUtils;
Var Info : TSearchRec;
Count : Longint;
lPath: string;
Begin
if Paramcount 0 then
begin
lPath := ParamStr(1);
lPath := IncludeTrailingPathDelimiter(lPath);
end;
Count:=0;
If FindFirst (lPath + '*',faAnyFile and faDirectory,Info)=0 then
begin
Repeat
Inc(Count);
With Info do
begin
If (Attr and faDirectory) = faDirectory then
Write('Dir : ');
Writeln (Name:40,Size:15);
end;
Until FindNext(info)0;
end;
FindClose(Info);
Writeln ('Finished search. Found ',Count,' matches');
End.
---[end-
--
Graeme Geldenhuys
General error, hit any user to continue.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FindFirst / FindNext gives random results in FPC 2.1.3
On 5/14/07, Michael Van Canneyt [EMAIL PROTECTED] wrote: No ordering is guaranteed. Thought so... I couldn't find any reference to the result order in the Delphi or Kylix help. Not in windows, not in Linux. That you get them ordered is most likely because you created them in that order, and the directory entries were therefor filled 'ordered'... What is strange is that it always gave consistent results in Delphi 7 and FPC 2.0.4, 2.0.5 and 2.1.1. As a workaround, I store the results in a sorted TStringList and work from there... Thanks for the quick response Michael. -- Graeme Geldenhuys General error, hit any user to continue. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FindFirst
Hi,
Can the FindFirst optimization in 2.1.1 for unix/sysutils.pp be merged
to 2.0.5 ? Revision 4772. Not only is it more efficient, it also fixes a
bug: I cannot find a single directory with FindFirst in 2.0.5.
Furthermore, attached is a patch for another optimization: do not
allocate a record in case user is requesting info for a single file.
Apply in rtl/unix please.
Thanks,
Micha
Index: sysutils.pp
===
--- sysutils.pp (revision 4823)
+++ sysutils.pp (working copy)
@@ -424,9 +424,9 @@
if not fpstat(s,st)=0 then
exit;
WinAttr:=LinuxToWinAttr(PChar(s),st);
- If ((WinAttr and Not(PUnixFindData(f.FindHandle)^.searchattr))=0) Then
+ If (f.FindHandle = nil) or ((WinAttr and
Not(PUnixFindData(f.FindHandle)^.searchattr))=0) Then
Begin
- f.Name:=Copy(s,PUnixFindData(f.FindHandle)^.NamePos+1,Length(s));
+ f.Name:=ExtractFileName(s);
f.Attr:=WinAttr;
f.Size:=st.st_Size;
f.Mode:=st.st_mode;
@@ -503,26 +503,27 @@
fillchar(Rslt,sizeof(Rslt),0);
if Path='' then
exit;
- { Allocate UnixFindData }
- New(UnixFindData);
- FillChar(UnixFindData^,sizeof(UnixFindData^),0);
- Rslt.FindHandle:=UnixFindData;
- {Create Info}
- UnixFindData^.SearchSpec := Path;
- {We always also search for readonly and archive, regardless of Attr:}
- UnixFindData^.SearchAttr := Attr or faarchive or fareadonly;
- UnixFindData^.NamePos := Length(UnixFindData^.SearchSpec);
- while (UnixFindData^.NamePos0) and
(UnixFindData^.SearchSpec[UnixFindData^.NamePos]'/') do
- dec(UnixFindData^.NamePos);
{Wildcards?}
if (Pos('?',Path)=0) and (Pos('*',Path)=0) then
begin
if FindGetFileInfo(Path,Rslt) then
Result:=0;
- UnixFindData^.SearchType:=1;
end
- else
-Result:=FindNext(Rslt);
+ else
+ begin
+{ Allocate UnixFindData }
+New(UnixFindData);
+FillChar(UnixFindData^,sizeof(UnixFindData^),0);
+Rslt.FindHandle:=UnixFindData;
+{Create Info}
+UnixFindData^.SearchSpec := Path;
+{We always also search for readonly and archive, regardless of Attr:}
+UnixFindData^.SearchAttr := Attr or faarchive or fareadonly;
+UnixFindData^.NamePos := Length(UnixFindData^.SearchSpec);
+while (UnixFindData^.NamePos0) and
(UnixFindData^.SearchSpec[UnixFindData^.NamePos]'/') do
+ dec(UnixFindData^.NamePos);
+ Result:=FindNext(Rslt);
+ end;
End;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FindFirst broken due to ExpandFileName bug?
Michael Van Canneyt wrote: This is a snapshot compiler, please use the official compiler if you can. If you use snapshots, use only the latest possible. The development compiler is not guaranteed bug free, as you can see. The current development compiler has no problem with your code, so that is the one you should use... The fixbranch compiler also no longer has the problem: home: compiler/ppc386 -l -Furtl/units/i386-linux ~/testp Free Pascal Compiler version 2.0.1 [2005/09/02] for i386 Copyright (c) 1993-2005 by Florian Klaempfl home: ~/testp /home/michael/ Maybe you can update that one (not to the 2.1.1 branch) Thanks - I guess then that confirms that it _was_ an issue (which is why I posted this here rather than run do a bug report.) I forget exactly why I ended up grabbing the snapshot that day, but there was some reason I'm sure. I'm not one to update unless I have to or I get several months behind ;-) -Tony ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FindFirst broken due to ExpandFileName bug?
On Mon, 12 Sep 2005, Tony Maro wrote:
I just tried to use FindFirst to get a listing of files in a directory. I
passed FindFirst the following:
if FindFirst('/home/tony/test/*',faAnyFile, Res) 0 then begin
It never would return any results. Then I noticed that FindFirst calls:
GlobSearchRec^.Path:=ExpandFileName(ExtractFilePath(Path));
So I ran:
ExpandFileName(ExtractFilePath('/home/tony/test/*'));
And I got:
/home/tony/LazarusFiles/testapp//home/tony/test/
Do you still have this bug ?
The most recent compiler/rtl gives the following, which is IMHO correct:
---
home: ppc386 testp.pp
home: ./testp
/home/michael/
home: cd fpc
home: ~/testp
/home/michael/
home: cat ~/testp.pp
program testp;
uses sysutils;
begin
Writeln(ExpandFileName(ExtractFilePath('/home/michael/*')));
end.
home:
---
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FindFirst broken due to ExpandFileName bug?
Michael Van Canneyt wrote:
On Mon, 12 Sep 2005, Tony Maro wrote:
I just tried to use FindFirst to get a listing of files in a directory. I
passed FindFirst the following:
if FindFirst('/home/tony/test/*',faAnyFile, Res) 0 then begin
It never would return any results. Then I noticed that FindFirst calls:
GlobSearchRec^.Path:=ExpandFileName(ExtractFilePath(Path));
So I ran:
ExpandFileName(ExtractFilePath('/home/tony/test/*'));
And I got:
/home/tony/LazarusFiles/testapp//home/tony/test/
Do you still have this bug ?
The most recent compiler/rtl gives the following, which is IMHO correct:
I'm running:
Free Pascal Compiler version 2.0.1 [2005/07/20] for i386
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
