USA: +1 (725) 712-1730 
Sign in
An organization’s head office is connected to its branch office over the Internet. The network connection works fine without errors. The users at the branch office connect to the head office by using telnet to access UNIX-based servers and a virtual network console (VNC) to access Windows-based servers. They transfer data across the network by using FTP. However, the users complain of a mismatch in the content sent from the head office and that received by them at the branch office.
Based on your understanding of the above scenario create a Microsoft Word document, answering the following:
What can be the cause of the problem? Suggest some ways to resolve the problem.
Which is the best way to resolve the problem and why?
Expert Answer
While using the FTP to transfer data across the network, there will be a file size mismatch rather than disk size mismatch.
Whenever disk space requirements are allocated by the OS to store the contents of a file, a fixed size of area is allocated. This fixed area is known as a cluster and varies among file systems. Microsoft itself uses various types of file systems, like FAT16, FAT32, NTFS and so on. And this can be easily understood and explains why the file size on disk may be differ.
This is the main cause for the content mismatch while using FTP.
Steps to follow to resolve the problem:
Always remember that you need to verify the size in bytes and in KB or MB. If there is still a mismatch of bytes then first zeroed on the source file. Chances are that your source file is corrupted.
you are able to see all the contents of your text file, but not in the remote machine because it has been silently and partially posted/copied/uploaded.
Text file transfer (to FTP) may be done in other than ASCII/Text format
It is always adviseable to use binary mode transfer to make an exact byte copy. But exceptions can always occur. This may behave strange for EOL notation character(s). Some operating systems only use a carriage return to indicate a new line. A few operating systems use a line feed character to indicate a new line. The Microsoft operating systems uses both, a carriage return and a line feed for each new line. So, when a file is transferred in binary mode, this conversion is not done and the result is junk characters, loss of characters or even a corrupt transfer. So, it is a good idea to have a switcher in code that will change the transfer-mode from binary to ASCII/text for files like txt, htm, CSS and so on. Note that this may also provide you some exceptions in some cases, because now a days text files are rich and use 2 bytes for a single character (UTF files).
Your source file itself has been copied from another remote machine (using MSRTC/RDP)
In this case, text files are more likely the victim of corruption. It is always adviseable to download your files by zipping them on the server and then copying them. After downloading in Zip format, unzip them in their actual form. In this way you can at least minimize the risk of corruption.
