On Oct 23, 2015, at 3:20 AM, Corinna Vinschen wrote: > > Well, it was *you* asking "How could we prove that the problem is the > Apple SMB server?" I was just trying to help. If that's not desired, > I don't have to.
I shouldn’t have suggested attacking the problem at the SMB protocol layer to begin with. That requires the sort of expertise that the Samba and Apple developers have, and I doubt I can get access to either. Since I’m not going to go and acquire such expertise myself just to answer the question, it’s a hopeless line of inquiry. Instead, it would be better if we can refine the Windows API C code we’ve been playing with to show the problem. Then I can attach it to an Apple bug report. I’m sure they like STCs, too. :) I’ve made the suggested changes to the program, here: http://pastebin.com/uZdDZPgi Is that enough to take to Apple? I mean, does this let them wiggle out and say, “You’re doing it wrong”? >>>>> HANDLE handle = CreateFile ("P:\\", ...); >>>> >>>> I guess I’m not seeing what values to pass to CreateFile() >>> >>> Opening a directory requires to use the FILE_FLAG_BACKUP_SEMANTICS >>> flag. >> >> Yes, silly me for not guessing that Windows requires that I tell it I >> am about to do a backup before I attempt to open a directory for >> reading. What was so wrong about the design of opendir() that MS had >> to reinvent it this way? > > Think DOS/early Windows. CreateFile was not meant to open directories > to perform a directory search I was reacting more to the revelation that Windows has workarounds for the known-problematic file access semantics, and that they’re specifically labeled as “for backup programs” when in reality they’re just ad hoc post facto fixes to a poorly thought out initial design. They’ve reinvented Unix, poorly. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple