FindFirst /FindNext on Linux stops reporting entries if there are folders/files with very long names in the path
Original Reporter info from Mantis: pitwalker
-
Reporter name: pitwalker
Original Reporter info from Mantis: pitwalker
- Reporter name: pitwalker
Description:
From the test directory structure (with long names), 46files & 20folders
Lazarus for Windows finds: 24files & 16folders
Lazarus for Linux finds: for me 0files and 0folders !!! because the first one long name blocks the search
In Windows with the "result" code of findfirst(UTF8) and findnext(UTF8)
is diagnosable the partiality of the search. (not 18 the RESULT code)
On Linux always ends the searc with -1 RESULT code.
Steps to reproduce:
In the attached .zip exists the sample filesystem
with 46 files (5 hidden "descript.ion" as well) and 20 folders
a maximum length of a path is 527 character if X:\ is the root.
- extract the sample fs to "extractionPoint" (on linux I use /tmp/fsystem)
(on WinXP can use "subst" command "subst x: extractionPoint",
in Win7 I use c:\temp\fsystem)
- run the "findfirst" test application included in the .zip
- correct the pathname in the "edit" to "extractionPoint" (or subst)
- run the two search button and examine the results
(5. modify "edit" in linux to find out something)
(text mode UniCode Far Manager 3 finds all, http://www.farmanager.com/download.php)
Additional information:
I have no workaround.
Mantis conversion info:
- Mantis ID: 24885
- OS: Linux, Windows
- OS Build: URaring,XP,Win7
- Build: 2013-06-09
- Platform: multiplatform
- Version: 1.0.10
- Fixed in version: 3.0.0
- Fixed in revision: 26150 (#5b58162d)
- Target version: 3.0.0