X-Spam-Check-By: sourceware.org From: "Dave Korn" To: Subject: RE: rsync over ssh hang issue understood Date: Fri, 7 Jul 2006 00:13:32 +0100 Message-ID: <003901c6a151$cd173170$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44AD884A.6010201@netbauds.net> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 06 July 2006 23:02, Darryl Miles wrote: > Christopher Faylor wrote: >> On Sat, Jul 01, 2006 at 11:05:24AM -0400, Christopher Faylor wrote: >> Since I'm not getting any nibbles when I talk about "the person >> responsible" here, I guess he must be long gone by now. >> >> So, his pipe code, which seemed to be based on correct concepts, is >> basically up for grabs for some enterprising soul to either take it the >> rest of the way or prove that it can't be made to work. > > I've done as you have asked and investigated as much as I can into the > current solution using NtQueryInformationFile(). > > > However according to MSDN this function is undocumented. No, it's documented in the DDK these days. http://msdn.microsoft.com/library/en-us/Kernel_r/hh/Kernel_r/k111_822ab812-a64 4-4574-8d89-c4ebf5b17ea5.xml.asp?frame=true (ZwQueryInformationFile == NtQueryInformationFile) > * There is no contractual specification with the API. > > * There is therefore no guarantee MS won't change its behavior between > patch levels and builds. Infact I think this problem has been pointed > out to this list before due to problems between specifics ServicePacks. > > * There is therefore no guarantee the next version of Windows will > support it at all. > > * There is therefore no guaranteed meaning to the return values. > > * Maybe a MS rocket scientist is watching this last and would be able > to provide some authoritative understanding of how this function call > works between different windows versions. Maybe the original author got > the idea out of a "behind the scenes" book on Win32 API and tested out a > hunch. The core native API functionality has been very stable since NT3.51 days. If NT messed with ZwQueryInformationFile now, *tonnes* of stuff would break. Cygwin would be the least of our problems, it'd instantly knacker every anti-virus and desktop firewall software. And it would be pointless and daft considering they've got an infinitely extensible API there already. If they want to extend or alter the API, they'll extend the FileInformationClass enumeration and define new FileInformation structs; it's very unlikely they'd gratuitously break the backward compatibility, and even less likely they'd change any of the fundamental ones like the names or timestamps. Even if they do, you can mitigate the risk of an error in your code by strictly checking the size of the returned data against the size you expect that particular struct to be; use precisely-sized buffers and any under- or overflow means that the format isn't what you expect it is and you can discard the bad data and error or fallback in some way. (Admitted that won't catch struct changes that don't affect the size, but we're reducing the probability of anything slipping past us). Assuming the use of Zw/NtQueryInformationFile /can/ be taken as reliable and effective, how do you evaluate the rest of what's there? cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/