www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - std.file.listdir()

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I've just looked at this, and it seems like a waste of time to me, given recls.
All it returns is strings, requiring stat()-like calls to acquire the other
characteristices of the given entries, throwing away this already-aquired
information on Win32. Since the kernel operations are the latency in such
searches, masking any slight complexity in recls, I wonder whether we're served
by having two ways to do the same thing, one of which is considerably crippled
compared to the other?
Jul 14 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 15 Jul 2004 11:08:28 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 I've just looked at this, and it seems like a waste of time to me, given 
 recls.
 All it returns is strings, requiring stat()-like calls to acquire the 
 other
 characteristices of the given entries, throwing away this already-aquired
 information on Win32.

What does recls do on *nix? Does it automatically aquire the stat info? or do you call a method/fn to get it, meaning on Win32 it simply returns what it already has and on *nix it gets and returns it.. but then, next time you ask for it, does it get it again as it may be stale or..
 Since the kernel operations are the latency in such
 searches, masking any slight complexity in recls, I wonder whether we're 
 served
 by having two ways to do the same thing, one of which is considerably 
 crippled
 compared to the other?

Is recls in Phobos? Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsa5n28yk5a2sq9 digitalmars.com...
 On Thu, 15 Jul 2004 11:08:28 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 I've just looked at this, and it seems like a waste of time to me, given
 recls.
 All it returns is strings, requiring stat()-like calls to acquire the
 other
 characteristices of the given entries, throwing away this already-aquired
 information on Win32.

What does recls do on *nix? Does it automatically aquire the stat info? or do you call a method/fn to get it, meaning on Win32 it simply returns what it already has and on *nix it gets and returns it.. but then, next time you ask for it, does it get it again as it may be stale or..

All states in recls are at the epoch of the API "touching" the operating system. In other words, when a file is located, all the information that will be represented for it by the API is acquired at that time.
 Since the kernel operations are the latency in such
 searches, masking any slight complexity in recls, I wonder whether we're
 served
 by having two ways to do the same thing, one of which is considerably
 crippled
 compared to the other?

Is recls in Phobos?

It most certainly is, and has been for a long time.
Jul 14 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 15 Jul 2004 11:44:34 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa5n28yk5a2sq9 digitalmars.com...
 On Thu, 15 Jul 2004 11:08:28 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 I've just looked at this, and it seems like a waste of time to me, 

 recls.
 All it returns is strings, requiring stat()-like calls to acquire the
 other
 characteristices of the given entries, throwing away this 

 information on Win32.

What does recls do on *nix? Does it automatically aquire the stat info? or do you call a method/fn to get it, meaning on Win32 it simply returns what it already has and on *nix it gets and returns it.. but then, next time you ask for it, does it get it again as it may be stale or..

All states in recls are at the epoch of the API "touching" the operating system. In other words, when a file is located, all the information that will be represented for it by the API is acquired at that time.

So on *nix when you list a directory you stat all files at the same time? Is this slower than simply listing the directory contents? If so, shouldn't this be optional. What if I do not care that file foo is 10k big, I just want a list of existing files.
 Since the kernel operations are the latency in such
 searches, masking any slight complexity in recls, I wonder whether 

 served
 by having two ways to do the same thing, one of which is considerably
 crippled
 compared to the other?

Is recls in Phobos?

It most certainly is, and has been for a long time.

Shows what I know. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsa5oy9jd5a2sq9 digitalmars.com...
 On Thu, 15 Jul 2004 11:44:34 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa5n28yk5a2sq9 digitalmars.com...
 On Thu, 15 Jul 2004 11:08:28 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 I've just looked at this, and it seems like a waste of time to me,

 recls.
 All it returns is strings, requiring stat()-like calls to acquire the
 other
 characteristices of the given entries, throwing away this

 information on Win32.

What does recls do on *nix? Does it automatically aquire the stat info? or do you call a method/fn to get it, meaning on Win32 it simply returns what it already has and on *nix it gets and returns it.. but then, next time you ask for it, does it get it again as it may be stale or..

All states in recls are at the epoch of the API "touching" the operating system. In other words, when a file is located, all the information that will be represented for it by the API is acquired at that time.

So on *nix when you list a directory you stat all files at the same time?

Yes
 Is this slower than simply listing the directory contents?

It might be, but it's not proved to be a problem as yet.
 If so, shouldn't this be optional.

I guess. There's already an option not to deduce the directory parts collection for each entry. I could add this also, but I really don't think it's necessary. Premature optimisation, and all that .. ;)
 What if I do not care that file foo is 10k big, I just want a list of
 existing files.

listdir() doesn't help you there, does it? You'll get files and directories. To its credit, it does at least elide the dots directories.
 Since the kernel operations are the latency in such
 searches, masking any slight complexity in recls, I wonder whether

 served
 by having two ways to do the same thing, one of which is considerably
 crippled
 compared to the other?

Is recls in Phobos?

It most certainly is, and has been for a long time.

Shows what I know.

No worries, mate. I only know the libs I've written or use regularly. ;)
Jul 14 2004
parent "Matthew Wilson" <dmd synesis.com.au> writes:
Thinking about it, a list of files and sub-directories is just about
useless. The minimum you'd want to do is differentiate between the two,
which means a stat() call. Since this has to be done, better to keep hold of
that information, as recls does.

Make sense?


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cd4pf4$1blv$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa5oy9jd5a2sq9 digitalmars.com...
 On Thu, 15 Jul 2004 11:44:34 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa5n28yk5a2sq9 digitalmars.com...
 On Thu, 15 Jul 2004 11:08:28 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 I've just looked at this, and it seems like a waste of time to me,

 recls.
 All it returns is strings, requiring stat()-like calls to acquire





 other
 characteristices of the given entries, throwing away this

 information on Win32.

What does recls do on *nix? Does it automatically aquire the stat




 or
 do you call a method/fn to get it, meaning on Win32 it simply returns
 what
 it already has and on *nix it gets and returns it.. but then, next




 you ask for it, does it get it again as it may be stale or..

All states in recls are at the epoch of the API "touching" the



 system.
 In other words, when a file is located, all the information that will



 represented for it by the API is acquired at that time.

So on *nix when you list a directory you stat all files at the same


 Yes

 Is this slower than simply listing the directory contents?

It might be, but it's not proved to be a problem as yet.
 If so, shouldn't this be optional.

I guess. There's already an option not to deduce the directory parts colle

 for each entry. I could add this also, but I really don't think it's

 Premature optimisation, and all that .. ;)

 What if I do not care that file foo is 10k big, I just want a list of
 existing files.

listdir() doesn't help you there, does it? You'll get files and

 its credit, it does at least elide the dots directories.

 Since the kernel operations are the latency in such
 searches, masking any slight complexity in recls, I wonder whether

 served
 by having two ways to do the same thing, one of which is





 crippled
 compared to the other?

Is recls in Phobos?

It most certainly is, and has been for a long time.

Shows what I know.

No worries, mate. I only know the libs I've written or use regularly. ;)

Jul 14 2004