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

Michael Rynn Joined: 04/01/08 Posts: 1

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
kris Joined: 03/27/04 Posts: 581	Posted: 04/04/08 04:18:42 -- Modified: 04/04/08 04:20:38 by kris thanks! 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 :)