On Feb 9, 2008 5:27 PM, Dan Kegel dank@kegel.com wrote:
On Feb 9, 2008 2:15 AM, Damjan Jovanovic damjan.jov@gmail.com wrote:
Try my patch, it should help that case.
It only helps if I change
if (type != FILE_TYPE_PIPE) {to
if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) {That makes me as uneasy as I bet it does you; switching to detecting EOF by noticing zero byte reads as you suggested sounds safer. Try the attached patch and let me know what you think.
It works with jdb, and all msvcrt tests still pass. I was trying the same thing a while back, but some tests always kept failing, so well done!
Well, if the MSDN is correct about ReadFile() returning only when the requested number of bytes is read unless an error occurs (it's a big if :-), then it would be an NTDLL NtReadFile() issue where pread() returns too soon due to a signal. But I haven't been able to get a signal to interrupt pread() in my tests, maybe wine handles signals.
Wine's ReadFile already tries to handle interrupted reads, but it looks offhand like it only handles the case where the read is interrupted before getting any bytes. Wine uses signals internally, maybe a stress test that tickled that part of wine heavily while doing lots of extremely large ReadFile() calls would cause a partial read. But it's possible that no apps would care, especially if we get rid of the "short read = EOF" bug you pointed out in msvcrt.
- Dan
Thank you Damjan