https://issues.dlang.org/show_bug.cgi?id=12391

Timothee Cour <timothee.cour2@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timothee.cour2@gmail.com
           Severity|normal                      |major

--

https://issues.dlang.org/show_bug.cgi?id=12391

--- Comment #3 from Timothee Cour <timothee.cour2@gmail.com> ---
ping on this.

I made local modifications to my git repo as this error was a blocker:

auto h = directory.length ? opendir(directory.tempCString()) : opendir(".");


                if(!h) {
                    auto s = strerror(errno).to!string;
                    import std.stdio;
                    stderr.writeln("ERROR: ", __FILE__,":",__LINE__,"
",directory , " ",s);
                    return false;
                }

--

https://issues.dlang.org/show_bug.cgi?id=12391

b2.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christof@schardt.info

--- Comment #4 from b2.temp@gmx.com ---
*** Issue 12513 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=12391

--- Comment #5 from b2.temp@gmx.com ---
It seems to be by design. By hand it's possible to catch silently (e.g the /srv/tftpboot folder on linux).

void scan(string root)
{
    foreach(DirEntry entry; dirEntries(root, SpanMode.shallow))
    {
        try
        {
            writeln(entry.name);
            if (entry.isDir) scan(entry.name);
        }
        catch (FileException fe) {continue;}
    }
}

void main()
{
    scan("/srv/");
}�

The error happens in "bool stepIn(string directory)�" (std.file) because the
folders are only put on a stack if they have a valid handle.

What could be done is to put them on the stack, always, and to test later, when the stack is used if the handle of each item is valid, but then the control is lost over when and why a problem happens. The iterator could even return a DirEntry with a special flag (hasNoHandle) to denote that an error occured.

--

https://issues.dlang.org/show_bug.cgi?id=12391

--- Comment #6 from Jason Spashett <jason@spashett.com> ---
Could we not take something out of python's book (or some other language):

os.walk https://docs.python.org/2/library/os.html

(1) This [os.walk] gives an opportunity to have an error handler during the
walk.
(2) alternatively a parameter that accepts a range that becomes a list of
errors.
(3) something else...

#2 doesn't seem that flexible looking at it, #1 would seem to be the way, as it acts as a predicate in python too, if an exception is thrown from the error handler the walk is stopped, otherwise it is not.

Often times I would like to ignore errors but log them. Other times better to stop the traversal.

--

https://issues.dlang.org/show_bug.cgi?id=12391

dlang@ryanjframe.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlang@ryanjframe.com

--

https://issues.dlang.org/show_bug.cgi?id=12391

Andre Artus <andre.artus@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andre.artus@gmail.com

--- Comment #7 from Andre Artus <andre.artus@gmail.com> ---
I would really like to see either a complementary function, or a parameter, or any other solution to this problem. At the moment I have to maintain a parallel implementation of dirEntries. While I'm sure it exists for someone, I don't have a use case favouring the current behaviour.

Most of my utilities where using dirEntries would be useful scan the full filesystem. I cannot even exclude these directories by name as the crash happens before I get the result.

auto dFiles = dirEntries(path,"*.{d,di}",SpanMode.depth);
foreach (d; dFiles) {
// nothing happening here
}

std.file.FileException@std\file.d(4573): [Folder]: Access is denied.

--

https://issues.dlang.org/show_bug.cgi?id=12391

Chris Katko <ckatko@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ckatko@gmail.com

--- Comment #8 from Chris Katko <ckatko@gmail.com> ---
This issue from 2014 is still not resolved?

The function as-is, is completely broken (and nearly useless) if it cannot handle a simple permissions issue. That means every single program using this function is subject to breaking if a file/folder with inaccessible permissions is placed in a desired search directory. Even if you catch exceptions overall, it's still going to terminate the loop from searching, breaking whatever file listing the program depended on.

And even if that was acceptable, it's still not documented that this happens.

This definitely needs addressed as it's a fundamental building block of D's standard library. You are basically expected to use this for any enumerated file access.

--

https://issues.dlang.org/show_bug.cgi?id=12391

--- Comment #9 from Dlang Bot <dlang-bot@dlang.rocks> ---
@ntrel updated dlang/phobos pull request #8656 "Document dirEntries throws without read permission" mentioning this issue:

- Document dirEntries throws without read permission

  Part of:
  Issue 12391 - dirEntries throws in foreach

  Add example showing how to handle subdirectory read permission failures.

https://github.com/dlang/phobos/pull/8656

--

https://issues.dlang.org/show_bug.cgi?id=12391

--- Comment #10 from Jason Spashett <jason@spashett.com> ---
I see that some documentation has been added to this, which is helpful. I do think however that SpanMode.depth is somewhat unhelpful to have, given that there is no possibility of handling errors and continuing; some people may miss the fact that it behaves in the way it does.

It may be better to remove the depth mode altogether if the API isn't going to
be adjusted in any way, but equally I don't see why this API does not follow
that of countless other languages that have solved the same problem as I
previously mentioned. Here is rust's effort if the python one was unsound in
some way.
https://rust-lang-nursery.github.io/rust-cookbook/file/dir.html#recursively-find-duplicate-file-names

--