 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jochen Kunze
Guest
|
 Posted: Tue Jan 25, 2005 3:39 pm Post subject: Findfirst findnext |
 |
|
The issue was discussed here several years ago, but I found something
new about it . In which order does findFirst findNext find the files?
Everyone says not in alphabetical order, but in the order the files
can be found on the disk. When I run this little program:
program findFirstNext;
{$APPTYPE CONSOLE}
uses
SysUtils;
var
searchRecord : TSearchRec;
f : TextFile;
begin
findFirst('d:ziel*.*', faAnyFile, searchRecord);
AssignFile(f, 'd:FindFirstLog.txt');
Append(f);
Writeln(f, SearchRecord.name);
while findnext(searchRecord) = 0 do
writeln(f, SearchRecord.name);
findclose(SearchRecord);
Flush(f);
CloseFile(f);
end.
A look in the logfile shows that in most cases the files have been
found in alphanumerical order. Only in one case the files have been
only "nearly" sorted:
I copied portions of files with different leading character in the
folder, e.g. first some files with x... than some files with o... and
so on.
Then I tried to repeat that experiment and the files were sorted
again. Very strange!
Does anyone has an idea, why mostly the files are sorted? How is it
possible to produce a scenario which surely makes findFirst FindNext
not to find the files sorted.
I would be very glad about any suggestion and idea.
|
|
| Back to top |
|
 |
Dodgy
Guest
|
| Posted: Tue Jan 25, 2005 4:34 pm Post subject: Re: Findfirst findnext |
|
|
On 25 Jan 2005 07:39:38 -0800, [email]mail (AT) gude (DOT) info[/email] (Jochen Kunze) waffled
on about something:
| Quote: | The issue was discussed here several years ago, but I found something
new about it . In which order does findFirst findNext find the files?
Everyone says not in alphabetical order, but in the order the files
can be found on the disk. When I run this little program:
program findFirstNext;
{$APPTYPE CONSOLE}
uses
SysUtils;
var
searchRecord : TSearchRec;
f : TextFile;
begin
findFirst('d:ziel*.*', faAnyFile, searchRecord);
AssignFile(f, 'd:FindFirstLog.txt');
Append(f);
Writeln(f, SearchRecord.name);
while findnext(searchRecord) = 0 do
writeln(f, SearchRecord.name);
findclose(SearchRecord);
Flush(f);
CloseFile(f);
end.
A look in the logfile shows that in most cases the files have been
found in alphanumerical order. Only in one case the files have been
only "nearly" sorted:
I copied portions of files with different leading character in the
folder, e.g. first some files with x... than some files with o... and
so on.
Then I tried to repeat that experiment and the files were sorted
again. Very strange!
Does anyone has an idea, why mostly the files are sorted? How is it
possible to produce a scenario which surely makes findFirst FindNext
not to find the files sorted.
I would be very glad about any suggestion and idea.
|
I believe it's all down to how the file system stores the files in the
FAT table, which is all the findfirst and findnext calls access.
So you're likely to see a sorted (or close to it) list from a
win2k/XP/NT system using NTFS, and a more muddled order from
95/98/ME/2000 (XP?) running FAT32.
So the basic rule should be, assume nothing. If you want the files
sorted, sort them... Either read them in and sort them, or put them in
the correct order as you read them with a binary chop insert.
D0d6y.
--
MUSHROOMS ARE THE OPIATE OF THE MOOSES
|
|
| Back to top |
|
|
Jamie
Guest
|
| Posted: Tue Jan 25, 2005 8:29 pm Post subject: Re: Findfirst findnext |
|
|
Jochen Kunze wrote:
| Quote: | The issue was discussed here several years ago, but I found something
new about it . In which order does findFirst findNext find the files?
Everyone says not in alphabetical order, but in the order the files
can be found on the disk. When I run this little program:
program findFirstNext;
{$APPTYPE CONSOLE}
uses
SysUtils;
var
searchRecord : TSearchRec;
f : TextFile;
begin
findFirst('d:ziel*.*', faAnyFile, searchRecord);
AssignFile(f, 'd:FindFirstLog.txt');
Append(f);
Writeln(f, SearchRecord.name);
while findnext(searchRecord) = 0 do
writeln(f, SearchRecord.name);
findclose(SearchRecord);
Flush(f);
CloseFile(f);
end.
A look in the logfile shows that in most cases the files have been
found in alphanumerical order. Only in one case the files have been
only "nearly" sorted:
I copied portions of files with different leading character in the
folder, e.g. first some files with x... than some files with o... and
so on.
Then I tried to repeat that experiment and the files were sorted
again. Very strange!
Does anyone has an idea, why mostly the files are sorted? How is it
possible to produce a scenario which surely makes findFirst FindNext
not to find the files sorted.
I would be very glad about any suggestion and idea.
that may have something to do with the File System. |
FAT32 verses NTFS
|
|
| Back to top |
|
|
Marco van de Voort
Guest
|
| Posted: Wed Jan 26, 2005 10:43 am Post subject: Re: Findfirst findnext |
|
|
On 2005-01-25, Jochen Kunze <mail (AT) gude (DOT) info> wrote:
| Quote: | folder, e.g. first some files with x... than some files with o... and
so on.
Then I tried to repeat that experiment and the files were sorted
again. Very strange!
Does anyone has an idea, why mostly the files are sorted?
|
IIRC if you copy the files with Windows explorer, it copies in the order of the
current view, which is typically name sorted.
| Quote: | How is it possible to produce a scenario which surely makes findFirst
FindNext not to find the files sorted. I would be very glad about any
suggestion and idea.
|
Try to sort on size and then copy files to a new folder.
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Wed Jan 26, 2005 12:10 pm Post subject: Re: Findfirst findnext |
|
|
On 25 Jan 2005 07:39:38 -0800, [email]mail (AT) gude (DOT) info[/email] (Jochen Kunze) wrote:
| Quote: | The issue was discussed here several years ago, but I found something
new about it . In which order does findFirst findNext find the files?
Everyone says not in alphabetical order, but in the order the files
can be found on the disk. When I run this little program:
|
Under FAT as Dodgy said, the order is purely determined by the 'order'
of the file names in the directory clusters.
Under NTFS things might be a bit different
I remember reading something in 1989 in the MSJ about the workings of
HPFS - the precursor of NTFS
It said something about using B*Trees for directory indexing
Regardless, I would /never/ rely on the order for anything
- it could be radically different for things like network drives
|
|
| Back to top |
|
|
Dr John Stockton
Guest
|
| Posted: Wed Jan 26, 2005 7:49 pm Post subject: Re: Findfirst findnext |
|
|
JRS: In article <11tcv01pfv3t3pfdd13u65lbl3gb6ck08t (AT) 4ax (DOT) com>, dated
Tue, 25 Jan 2005 16:34:48, seen in news:comp.lang.pascal.delphi.misc,
Dodgy <Dodgy (AT) earth (DOT) planet.universe> posted :
| Quote: |
I believe it's all down to how the file system stores the files in the
FAT table, which is all the findfirst and findnext calls access.
|
FindFirst and FindNext do not need to access the FAT for file data;
indeed, systems do not necessarily have a FAT AIUI.
They are directory-reading system calls. A directory is a file, with 32
bytes per entry (LFNs use multiple entries).
I'd expect them to ALWAYS return files in the order of their directory
entries, but that later OSs may maintain sorted or partly-sorted
directories. Utilities that re-order directory entries have been
written.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; Win98. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
|
|
| Back to top |
|
|
Terry Russell
Guest
|
| Posted: Wed Jan 26, 2005 9:32 pm Post subject: Re: Findfirst findnext |
|
|
"Marco van de Voort" <marcov (AT) stack (DOT) nl> wrote
| Quote: | On 2005-01-25, Jochen Kunze <mail (AT) gude (DOT) info> wrote:
folder, e.g. first some files with x... than some files with o... and
so on.
Then I tried to repeat that experiment and the files were sorted
again. Very strange!
Does anyone has an idea, why mostly the files are sorted?
IIRC if you copy the files with Windows explorer, it copies in the order
of the
current view, which is typically name sorted.
|
except the item actually clicked (if dragdrop) may be swapped with first on
the list
select
1
2 <- drag drop rightclick here
3
4
drop order
2
1
3
4
and order found may depend on what slots are already filled in the
destination
(depending on OS filesystem)
| Quote: | How is it possible to produce a scenario which surely makes findFirst
FindNext not to find the files sorted. I would be very glad about any
suggestion and idea.
Try to sort on size and then copy files to a new folder.
|
copy/create the files in timeorder of required searchorder
edit the directory entry with direct disk access
(if you have an old machine easily rebuilt from backups  )
|
|
| Back to top |
|
|
VBDis
Guest
|
| Posted: Sat Jan 29, 2005 11:40 pm Post subject: Re: Findfirst findnext |
|
|
Im Artikel <7X4CZsF9Q$9BFwhv (AT) merlyn (DOT) demon.co.uk>, Dr John Stockton
<spam (AT) merlyn (DOT) demon.co.uk> schreibt:
| Quote: | I believe it's all down to how the file system stores the files in the
FAT table, which is all the findfirst and findnext calls access.
|
Every file system can implement different directory structures and procedures.
Consider FindFirst etc. as virtual methods of some FileSystem object, with no
information about polymorphic implementations.
DoDi
|
|
| Back to top |
|
|
Dr John Stockton
Guest
|
| Posted: Sun Jan 30, 2005 11:22 pm Post subject: Re: Findfirst findnext |
|
|
JRS: In article <20050129184039.11141.00000131 (AT) mb-m02 (DOT) aol.com>, dated
Sat, 29 Jan 2005 23:40:39, seen in news:comp.lang.pascal.delphi.misc,
VBDis <vbdis (AT) aol (DOT) com> posted :
| Quote: | Im Artikel <7X4CZsF9Q$9BFwhv (AT) merlyn (DOT) demon.co.uk>, Dr John Stockton
[email]spam (AT) merlyn (DOT) demon.co.uk[/email]> schreibt:
I believe it's all down to how the file system stores the files in the
FAT table, which is all the findfirst and findnext calls access.
Every file system can implement different directory structures and procedures.
Consider FindFirst etc. as virtual methods of some FileSystem object, with no
information about polymorphic implementations.
|
I did not write that; please be more careful with your quoting.
I see no useful meaning in what you added. This particular twig of the
thread is referring only to systems with FATs.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3 Turnpike 4 ©
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Mon Jan 31, 2005 1:50 pm Post subject: Re: Findfirst findnext |
|
|
On Sun, 30 Jan 2005 23:22:10 +0000, Dr John Stockton
<spam (AT) merlyn (DOT) demon.co.uk> wrote:
| Quote: | JRS: In article <20050129184039.11141.00000131 (AT) mb-m02 (DOT) aol.com>, dated
Sat, 29 Jan 2005 23:40:39, seen in news:comp.lang.pascal.delphi.misc,
VBDis <vbdis (AT) aol (DOT) com> posted :
Im Artikel <7X4CZsF9Q$9BFwhv (AT) merlyn (DOT) demon.co.uk>, Dr John Stockton
[email]spam (AT) merlyn (DOT) demon.co.uk[/email]> schreibt:
|
Dodgy wrote :-
| Quote: | I believe it's all down to how the file system stores the files in the
FAT table, which is all the findfirst and findnext calls access.
|
DoDi wrote :-
| Quote: | Every file system can implement different directory structures and procedures.
Consider FindFirst etc. as virtual methods of some FileSystem object, with no
information about polymorphic implementations.
|
JS wrote :-
| Quote: | I did not write that; please be more careful with your quoting.
I see no useful meaning in what you added. This particular twig of the
thread is referring only to systems with FATs.
|
It _is_ referring to systems with FATs
- because systems without (MSDOS) FATs have to go through a
translation layer so that they appear to FindFirstFile (not FindFirst)
as if they /are/ systems with FATs
Therefore all systems /appear/ to have FATs
- to FindFirstFile (not FindFirst which is just a simple wrapper)
The crucial point is that the physical FAT and Directory structures
(while well known) are 'officially' undocumented by MS
Therefore differences in 'internal' behaviour are to be expected
As anybody knows from the days of pre-Novel network servers
|
|
| Back to top |
|
|
Marco van de Voort
Guest
|
| Posted: Mon Jan 31, 2005 2:03 pm Post subject: Re: Findfirst findnext |
|
|
On 2005-01-31, J French <erewhon (AT) nowhere (DOT) uk> wrote:
| Quote: |
I see no useful meaning in what you added. This particular twig of the
thread is referring only to systems with FATs.
It _is_ referring to systems with FATs
- because systems without (MSDOS) FATs have to go through a
translation layer so that they appear to FindFirstFile (not FindFirst)
as if they /are/ systems with FATs
|
No they don't.
| Quote: | Therefore all systems /appear/ to have FATs
- to FindFirstFile (not FindFirst which is just a simple wrapper)
|
No they don't. Under NT, there is a filesystem object that implements FS services.
There is one for FAT, one for NTFS etc.
NTFS is not pushed through a FAT API.
| Quote: | The crucial point is that the physical FAT and Directory structures
(while well known) are 'officially' undocumented by MS
|
They are patented afaik, so it is on public record.
| Quote: | Therefore differences in 'internal' behaviour are to be expected
|
True.
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Mon Jan 31, 2005 3:57 pm Post subject: Re: Findfirst findnext |
|
|
On Mon, 31 Jan 2005 14:03:00 +0000 (UTC), Marco van de Voort
<marcov (AT) stack (DOT) nl> wrote:
| Quote: | On 2005-01-31, J French <erewhon (AT) nowhere (DOT) uk> wrote:
I see no useful meaning in what you added. This particular twig of the
thread is referring only to systems with FATs.
It _is_ referring to systems with FATs
- because systems without (MSDOS) FATs have to go through a
translation layer so that they appear to FindFirstFile (not FindFirst)
as if they /are/ systems with FATs
No they don't.
|
They have to provide the information to fill in a WIN32_FIND_DATA
| Quote: | Therefore all systems /appear/ to have FATs
- to FindFirstFile (not FindFirst which is just a simple wrapper)
No they don't. Under NT, there is a filesystem object that implements FS services.
There is one for FAT, one for NTFS etc.
|
Ok - something that provides the info for WIN32_FIND_DATA
| Quote: | NTFS is not pushed through a FAT API.
|
Ok it is 'pulled into' a FAT API
| Quote: | The crucial point is that the physical FAT and Directory structures
(while well known) are 'officially' undocumented by MS
They are patented afaik, so it is on public record.
|
Even so, like the 'List of Lists' they are officially unsupported
- or more precisely their private practises are not defined
| Quote: | Therefore differences in 'internal' behaviour are to be expected
True.
|
Hopefully the OP will have picked up enough to /never/ rely on the
order of FindFirst / FindNext
|
|
| Back to top |
|
|
Martin Harvey (Demon acco
Guest
|
| Posted: Mon Jan 31, 2005 9:55 pm Post subject: Re: Findfirst findnext |
|
|
On Mon, 31 Jan 2005 15:57:53 +0000 (UTC), [email]erewhon (AT) nowhere (DOT) uk[/email] (J
French) wrote:
| Quote: | They have to provide the information to fill in a WIN32_FIND_DATA
|
And that is blatantly not a FAT.
MH.
|
|
| Back to top |
|
|
Terry Russell
Guest
|
| Posted: Tue Feb 01, 2005 12:13 am Post subject: Re: Findfirst findnext |
|
|
"J French" <erewhon (AT) nowhere (DOT) uk> wrote
| Quote: | On Mon, 31 Jan 2005 14:03:00 +0000 (UTC), Marco van de Voort
[email]marcov (AT) stack (DOT) nl[/email]> wrote:
On 2005-01-31, J French <erewhon (AT) nowhere (DOT) uk> wrote:
I see no useful meaning in what you added. This particular twig of the
thread is referring only to systems with FATs.
It _is_ referring to systems with FATs
- because systems without (MSDOS) FATs have to go through a
translation layer so that they appear to FindFirstFile (not FindFirst)
as if they /are/ systems with FATs
No they don't.
They have to provide the information to fill in a WIN32_FIND_DATA
Therefore all systems /appear/ to have FATs
- to FindFirstFile (not FindFirst which is just a simple wrapper)
No they don't. Under NT, there is a filesystem object that implements FS
services.
There is one for FAT, one for NTFS etc.
Ok - something that provides the info for WIN32_FIND_DATA
NTFS is not pushed through a FAT API.
Ok it is 'pulled into' a FAT API
The crucial point is that the physical FAT and Directory structures
(while well known) are 'officially' undocumented by MS
They are patented afaik, so it is on public record.
Even so, like the 'List of Lists' they are officially unsupported
- or more precisely their private practises are not defined
|
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
1. LIMITED LICENSE AND COVENANT NOT TO SUE.
a fair approximation to ,but not quite, unsupported and undocumented:-)
a FAT system with more than a few tens of thousands of files in a directory
suffers very significant delays, down to only a very few finds per second
at the end of 64k
most windows systems with more than a few tens of thousand files
in a directory will have crashed or at least snoozed for a very long time
when the user looked at it in explorer or dialogs
The first thing that should be done with findfirst/next is place it within a
directory manipulation class and never use it directly again.
The class overhead,even if sorting, is miniscule compared to the directory
read time.
| Quote: | Therefore differences in 'internal' behaviour are to be expected
True.
Hopefully the OP will have picked up enough to /never/ rely on the
order of FindFirst / FindNext
|
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Tue Feb 01, 2005 12:09 pm Post subject: Re: Findfirst findnext |
|
|
On Mon, 31 Jan 2005 21:55:02 GMT, "Martin Harvey (Demon account)"
<martin (AT) nospam_pergolesi (DOT) demon.co.uk> wrote:
| Quote: | On Mon, 31 Jan 2005 15:57:53 +0000 (UTC), [email]erewhon (AT) nowhere (DOT) uk[/email] (J
French) wrote:
They have to provide the information to fill in a WIN32_FIND_DATA
And that is blatantly not a FAT.
|
Ok emulation of an embellished FAT directory entry
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
