🚀 go-pugleaf

Jos� wrote:

> 1. What is the order of files? It can be arbitrary, numeric (2, 19,
> 20) and alphabetic (19, 2, 20)
> 
> 2. What happens when files are created, deleted or renamed between two
> invokations of findnext/FindNext?

These are usually just wrappers around calls to the operating system
functions so their exact behaviour depends on the operating system and
file system being queried.

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

"Jos�" <jose@127.0.0.1> wrote in message 
news:5v4b725541pgl6mgme0m2sc5n0ni1bm94p@4ax.com...
> Dear friends
>
> There are two sets of functions to search for files:
> findfirst/findnext and FindFirst/FindNext.
>
> It is my impression that their behaviour differs on differint
> computers. Can anything be said about this?
>
> 1. What is the order of files? It can be arbitrary, numeric (2, 19,
> 20) and alphabetic (19, 2, 20)


I don't know for sure, but I'd guess that these functions search the 
file allocation table from beginning to end. That is, the first file 
returned will be first first one in the FAT that matches the search 
criteria. Since the OS re-uses deleted entries, the order may not 
correspond to the creation times of the files. This means that the 
file orders are essentially random.

> 2. What happens when files are created, deleted or renamed between 
> two
> invokations of findnext/FindNext?

If you are part way through the FAT, any change that happens "behind" 
the current position will go unnoticed. The ones "ahead" will be 
discovered when you call findnext. So you can't be sure that you have 
seen everything. I think you can lock a folder using CreateFile() and 
specifying FILE_FLAG_BACKUP_SEMANTICS. I haven't tried this in 
conjunction with using the Find functions, though.

HTH,
Bruce 

On Thu, 25 May 2006 11:20:44 -0500, " Bruce Salzman"
<bruce@nospam.org> wrote in borland.public.cppbuilder.nativeapi:

>> There are two sets of functions to search for files:
>> findfirst/findnext and FindFirst/FindNext.
>>
>> It is my impression that their behaviour differs on differint
>> computers. Can anything be said about this?
>>
>> 1. What is the order of files? It can be arbitrary, numeric (2, 19,
>> 20) and alphabetic (19, 2, 20)
>
>
>I don't know for sure, but I'd guess that these functions search the 
>file allocation table from beginning to end. 

More likely: the directory (or folder)

In fact my computer produces the file names in alphabetical order (2
is more than 19), but AFAIK there is no guarantee that this always
happens. The Windows Explorer even displays filenames in a very smart
numerical order (where 2 is less than 19), and it seems reasonable to
expect  that the same ordering is used by findfirst/findnext, but this
is not the case.

In fact I am making a program which renames all files sequentially.
Therefore the order of files is important to me. Furthermore, funny
things might happen if a file is found again after having been
renamed.
-- 
Jos�

"Jos�" <jose@127.0.0.1> wrote in message 
news:ovnb72hoepr9mer64jeikc1pth6t427c5l@4ax.com...
> In fact I am making a program which renames all files sequentially.
> Therefore the order of files is important to me. Furthermore, funny
> things might happen if a file is found again after having been
> renamed.

Then I would read them all at once, sort them however you want, 
generate the new names, then finally rename them.

-- 
Bruce 

On Thu, 25 May 2006 12:02:17 -0500, " Bruce Salzman"
<bruce@nospam.org> wrote in borland.public.cppbuilder.nativeapi:

>> In fact I am making a program which renames all files sequentially.
>> Therefore the order of files is important to me. Furthermore, funny
>> things might happen if a file is found again after having been
>> renamed.
>
>Then I would read them all at once, sort them however you want, 
>generate the new names, then finally rename them.

That's exactly what I am doing. But it should not be needed.
-- 
Jos�

> That's exactly what I am doing. But it should not be needed.

Why should they be arranged in the manner you now wish?  Why shouldn't they 
be arranged in the manner that I wish or Andrue Cope wishes or someone else 
wishes?

How would you propose Microsoft change the operating system to arrange them?

Should they be ordered in the sequence of how they exist in the directory, 
by time of creation, by file size, by file type, by name, by last access 
time, by last write time?

No matter which is chosen there are those who want something else. 
Microsoft elected to provide the names in the order they exist in the 
directory, the order which takes the least processing time.

.  Ed

> Jos� wrote in message
> news:soqb725uhu86oqk3qfqi78ks5bovudrtgp@4ax.com...
>
> ...
>>Then I would read them all at once, sort them however you want,
>>generate the new names, then finally rename them.
>
> That's exactly what I am doing. But it should not be needed.

On Thu, 25 May 2006 14:32:16 -0400, "Ed Mulroy"
<dont_email_me@bitbuc.ket> wrote in
borland.public.cppbuilder.nativeapi:

>Why should they be arranged in the manner you now wish?  Why shouldn't they 
>be arranged in the manner that I wish or Andrue Cope wishes or someone else 
>wishes?

Quite right, of course. However, I only asked whether a certain
ordering is guaranteed to work on any computer.
-- 
Jos�

 Bruce Salzman wrote:

> I don't know for sure, but I'd guess that these functions search the
> file allocation table from beginning to end.

Nope :)

The FAT only stores allocation information and it stores it for the
entire volume. Directory information is stored separately as a file in
it's own right (except for the root in FAT 12/16 volumes). Each
directory has its own file and /these/ are scanned from first to last.

NTFS is completely different and because it stores directories as
B-Trees objects come back sorted.

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

Jos� wrote:

> Quite right, of course. However, I only asked whether a certain
> ordering is guaranteed to work on any computer.

The simple answer is no.

If you want your objects to be in a particular order you need to sort
them yourself. Oh and don't bother trying to write them back in a
sorted order. The general guideline here is to let the file system do
what the file system wants to do :)
-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

On Fri, 26 May 2006 08:57:05 +0100, "Andrue Cope [TeamB]"
<no.spam@not.a.valid.address> wrote in
borland.public.cppbuilder.nativeapi:

>Each
>directory has its own file and /these/ are scanned from first to last.
>
>NTFS is completely different and because it stores directories as
>B-Trees objects come back sorted.

This probably means that the behviour of findfirst/findnext cannot be
predicted.

It is interesting to know that the Explorer sorts files in numeric
order (where 2 is less than 19) while findfirst (on my computer, NTFS)
sorts them in the simpler alphabetic order (where 2 is more than 19).
-- 
Jos�

Jos� wrote:

> This probably means that the behviour of findfirst/findnext cannot be
> predicted.

Aye. There is one other difference that can trip people up. The
standard directory search algorithm is:

  Find_First

  do
  {
    if( last_found__is_Dir )
      recurse_to_search_dir
  }while( More_to_find

The problem with this is that it leads to multiple directory search
handles being open concurrently. Such handles can be quite resource
intensive and some OSes can't tolerate large numbers being left open.

As a result I feel it is better to use this algorithm:

  Find_First

  do
  {
    if( last_found__is_Dir )
      add_dir_to_list
  }while( More_to_find

  search_each_dir_in_dir_list

This way only one search is active at a time.
-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

> ...handles being open concurrently. Such handles can
> be quite resource intensive and some OSes can't
> tolerate large numbers being left open. ...

FWIW:
I used to routinely do the recursive search into lower directories as you 
show in your warning.

I have been totally destroyed by too many open file search handles under 
Win95/98, NT version <= 3.51 or when searching on a Novell system.  The 
worst ones were Novell and when networked with NT.  Occasionally everyone on 
the network would lock up!

.  Ed

> Andrue Cope wrote in message
> news:447bfaec@newsgroups.borland.com...
> Jos� wrote:
>
> Aye. There is one other difference that can trip people up. The
> standard directory search algorithm is:
>
>  Find_First
>
>  do
>  {
>    if( last_found__is_Dir )
>      recurse_to_search_dir
>  }while( More_to_find
>
> The problem with this is that it leads to multiple directory
> search handles being open concurrently. Such handles
> can be quite resource intensive and some OSes can't
> tolerate large numbers being left open.
>
> As a result I feel it is better to use this algorithm:
>
>  Find_First
>
>  do
>  {
>    if( last_found__is_Dir )
>      add_dir_to_list
>  }while( More_to_find
>
>  search_each_dir_in_dir_list
>
> This way only one search is active at a time.

Ed Mulroy wrote:

> The worst ones were Novell and when networked with NT.  Occasionally
> everyone on the network would lock up!

I bet that made you popular :)

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html