Click here to Skip to main content
15,885,767 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
The real question is: is there a known problem with Windows' ReadFile(HANDLE hFile,
LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead,
LPOVERLAPPED lpOverlapped) function giving a return value of TRUE where hFile is valid, lpBuffer is a valid pointer, lpNumberOfBytesRead is the same as nNumberOfBytesToRead but the contents of lpBuffer is corrupt, given that the file is on another computer?

Context:
A file on a remote computer is growing and I want to keep a copy of that file on the local computer as it is growing. I could use CopyFileEx(), and that does work correctly, but because the file is growing and could get to be very large, I would rather find the differences between the files and copy (read and then write) the differences to the local file.

I've done a little bit of research and I know that when a file on a network computer is opened, the requests are made using SMB (Server Message Blocks) and the response is sent back using TCP. I have actually recorded the transactions using Wireshark and have found that the network computer is receiving the request correctly and is sending the correct data back, but the receiving computer is getting a lot of CRC errors.

Local Machine:
Windows 7 Pro 32-bit
Remote Machine:
Windows XP Pro 32-bit (virtual machine using Virtual PC 2007)
Windows 7 Ultimate 32-bit (actual machine)

Sorry for not putting up actual code, I am working on a test case. But I am more interested in knowing if there is something in the knowledge base on this.

The code is written in C/C++.

Thanks,
Posted

1 solution

CRC errors are not related to SMB or TCP or IP, but to the underlying "line protocol" (probably Ethernet) of the receiving computer, and relate to corruption of bits along the physical media.

You've most likely done a "bad installation" in term of cable/connectors quality respect to the environmental electric noise.
There is no code that can adjust a packet gone bad (apart requiring a retransmission, but it is exactly what the TCP does, but loosing in performance)
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900