Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

I was pillaging and testing Path.d and found a bug

Moderators: kris

Posted: 04/01/08 12:26:50 Modified: 04/01/08 13:13:10

//The calls to the function padded, use the $-1, when it should be $

h = FindFirstFileW (padded(toString16(host, folder[0..$-1]), "*\0").ptr, &fileinfo);

//should be folder[0..$] May be your test case already has a folder seperator as last character. It fails without, as it chops the last character of the directory name.

For my purposes, I have my own scanner that returns the next file result, similar to FindFirstFile?, FindNextFile?, and can access all of the FIND_DATA results. I do not want to hide the windows System and Hidden files, as I think the caller should decide the filtering. However I've found a lot of interesting code bits inside, and await further developments with interest. Michael Rynn --((0))--

Author Message

Posted: 04/04/08 04:18:42 -- Modified: 04/04/08 04:20:38 by


Yeah, the hidden and system folders thing was added to sidestep a problem where Win32 would fail after recursing down a specific system folder. We should have some flags for filtering those instead.

The $-1 is there for stripping the trailing \0 on the input. You'll notice the comment at the top of that Path struct :)