Subject: Sporadically corrupt files after submitting with sFTP component
Date: 2018-05-18 10:01:38
From: fredy.wenger@matso.ch
Source: sporadically-corrupt-files-aftter-submitting-sftp-component
----------------------------------------------------------------------

Hi  
For a project, I have implemented the sFTP component in a sFTP client that transfer files from and to a sFTP server.  
Unfortunately, I don't have any meaningful support from the sFTP server side (no competent contact).
The transferred files are .xml files.
Principally the transfer work stable:  
 - more than 15'000 files were transferred **from** the sFTP server yet **-> no corrupt files**
 - more than 26'000 files were transferred **to** the sFTP server yet **-> three corrupt files** 

So from a total of more than 41'000 files, three files were stored corrupt on the sFTP server after transfer.   
(that shows, that it is not a principal problem)  
Process (send files):
The .xml files are exported by another application (over a timer).  
The sFTP client (with the sFTP component):
 - query a directory for new files over a timer
 - reads new file names in an array (in memory)  
 - copy all new exported files to the sFTP server
 - checks, if the files are transferred and - if yes - moves the files to an \archive\ directory  

Details to the error:  
The corrupt stored files are exported correct (the complete file content is stored in the file)  
The files are transferred normally (without sFTP error) and the moved to \archive\ as they were transferred.
On the sFTP server the files are stored **corrupt (the end of the .xml file is missing)**

**This then causes a stop of the whole import queue on the sFTP server (what means, the whole interface is dead)**  
Note: For me a clear design error in the import interface, but - as I wrote - I have no support on the sFTP server, so... no chance, that this will be changed...  
Nevertheless, I (unfortunately) now have to try, to solve the problem...  

Questions:  
**- is this a known problem (sporadically corrupt files)?**  
**- can it be, that the sFTP library start to transfer a file, although the file is not written completely by the export application?**  
**- can it be, that the sFTP library cannot write the file completely on the sFTP server, as the file is opened on the sFTP Server, before it is written completely (whereby, I think, this should cause a crash of the transfer...?)**  
**- do you have some other ideas, what can cause the problems?**  
  
Note: As I don't have any support from the sFTP server side, it's no solution to check the file size / checksum after submission and simply send the file once again, if not equal (as the file is read as soon it is stored on the sFTP server).  
**Thanks for meaningful answers to my questions above...**  
Fredy

----------------------------------------------------------------------

Note: This question has been asked on the Q&A forum of Thang Dang's fraudulent ComponentPro brand
If you purchased anything from ComponentPro, you have been scammed. Contact the payment processor
who sold you the license and ask for your money back.

Back to ComponentPro Q&A Forum Index