There's a thread about fixing some issue in Subversion w.r.t. writing large amounts of data to a console handle.
This issue is an example of a broader issue: Windows doesn't support arbitrary amounts of data to be written to all of its handle types. Smaller writes *are* supported, but it doesn't automatically fall back to smaller writes when the underlaying handle only supports small writes. I'd say the apr_file_write() API allows for partial writes, meaning the internals on Windows can compensate for the behaviour in Windows (by falling back to smaller writes when detecting certain error return codes). There were a number of patches contributed until now, with the following properties (please correct me if I'm wrong or incomplete): 1) Split all writes into 'always supported' smaller writes 2) Split writes for handles with specific numbers into 'always supported' smaller writes 3) Fall back to a buffered file once the condition has been detected which signals this kind of problem 4) Fall back to a small write (once) when detecting this condition, returning an incomplete write (1) was rejected because the increased performance on 'other' handles must be an OS issue not to be worked around in a portability layer (2) was rejected, because it doesn't solve the issue when other handle numbers are of the same class (3) Wasn't rejected (yet?), but feels wrong to me: an unbuffered file was created, then it should probably stay unbuffered (since starting to buffer will change the behavior of the file significantly on smaller writes) (4) Was rejected because the same condition was detected over and over again, resulting in too many failed OS calls. Patch #4 can be easily extended to cache the result of the fallback in the file structure. Would that be enough to get this change committed / issue resolved? If not, what more would you expect? bye, Erik.
