Messages in this thread | | | Date | Wed, 02 Jun 1999 13:36:20 +0200 | From | Michael Tross <> | Subject | Re: [PATCH] ncpfs bug |
| |
"Petr Vandrovec Ing. VTEI" wrote: > > On 1 Jun 99 at 10:42, Michael Tross wrote: > > Absolute, you're definitely right. But as I read file.c (v2.2.9), if > > ncp_read() returns without error and read_this_time is ==0, then > > ncp_file_read() breaks out of the loop cause of (read_this_time < > > to_read); but the point is that ncp_file_read() then exits with the > > return code 0. My patch changed this to return an error in this case. > > The ncpfs misbehaviour I described occured in all kernels I have tested > > in the last year, 2.0.32, 2.0.36, 2.2.0 and now 2.2.9. I have LANalyzer > Hi, > maybe that it is more problem with ncpfs_nopage. It is legal for > *_read filesystem procedure to return with 0 at the end of file (I think, > it is normal behavior for read syscall).
Again I can reproduce the bug I described last week. I downloaded netperf from HP, extracted it on a mounted ncpfs volume, typed make and - the linker hangs. I analyzed the network traffic with a packet sniffer and found: - my workstation sends about 2500 requests/sec to the NetWare server, all these requests are identical packets with incrementing sequence number - the request is: ncp read file, offset 0xfc00, length 1236 - the server replies with: ncp return code success, data length 0 I running 2.2.10-pre1. Again I will apply my patch. Michael
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |