This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: rsync over ssh hang issue understood


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]