Ok, I see
I haven't tried the "old" sysfiletree with UNC path so have no clue if it 
differs in result returned, probably not.
The "new" sysfiletree seems to work with UNC path's from Win7 anyhow and the 
returned values is in arbitrary order, the same arbitrary order is returned if 
the the path is on a mapped network drive (drive letter), but looking at the 
same path/drive letter in  windowsexplorer shows files in alphabetic order, 
maybe they are sorted before display!

Maybe a note in the manual about this can be useful, if this behaviour is 
confirmed by others/testing.
/hex






-------------------------
Ursprungligt Meddelande:
Från: Mark Miesfeld <[email protected]>
Till: [email protected], Open Object Rexx Developer Mailing List 
<[email protected]>
Kopia: 
Datum: onsdag, 08 augusti 2012 20:47
Ämne: Re: [Oorexx-devel] "New" SYSFILETREE order of returned values
On Wed, Aug 8, 2012 at 11:07 AM, hakan <[email protected]> wrote:
> This is on win7 64bit and oorexx 4.2.0 8149.
> Using the new SYSFILETREE , maybe it also applies to the "old" SYSFILETREE!,
> I have a question.

There is nothing in the reworked code that would change this from the
previous version.

> In what order is the result returned in the steam ?
> Reading a windows path, it seems the result is returned in alphabetic order,
> but reading a networkpath (UNC path) I can't figure out in what order the
> result is returned.
> Using this:
> call SysFileTree "\\mypath\*.*", "file", "LB", "**-**"
> the result seems to be returned in a arbitrary order.
> \\mypath is a linuxmachine

SysFileTree does nothing to change the order of the files returned by
the Windows API.  It uses the Windows APIs, FindFirstFile() /
FindNextFile().  Whatever order these APIs return the found files in,
will be the order in the stem.  This is dictated by the operating
system, there are no options to pass into the APIs to change the
order.

Note that I would be careful about using UNC path names for
SysFileTree().  There is nothing in the docs saying UNC path names are
acceptable.  And there is nothing in the original IBM code that points
to any consideration being given to the possibility of UNC path names
being used.

I'm not saying it won't work, and maybe there is no problem.  I'm just
saying it doesn't look like any thought was given to that possibility.
 I didn't dig into that possibility while going through the code
either.

--
Mark Miesfeld

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to