i want to Upload Files via sftp to a server (it's local for testing issues).
The server provides the uploaded Files using tcp sockets. for this reason i need to know when a file is opened on the server before i can overwrite the file using sftp. i used the following code, but it doesnt return null when the target file is opened:
You already have the correct usage of createDisposition. The "blockWrite" keyword means the following:
The server MUST guarantee that no other handle has been opened with write access, and that no other handle will be opened with write access until the client closes the handle.
If another SFTP session opens the file with read-only access, it would not block access. Also -- realize that "blockWrite" applies to other SSH/SFTP sessions (i.e. things that the SSH/SFTP server knows about). It does not apply to, and cannot apply to other completely unrelated processes on the server that might be opening the file for read and/or write access.
Having issues where the destination server SFTP does not deliver the entire file, last bytes missing. Our side shows Good return code.
I think that the batch process on the server is processing the file before it is complete. What would those parms be to lock that file exclusive so that the batch process cannot open the file?
Any suggestions as to how I can prove that there is nothing wrong with our ChilKat process?
i had some problems with interrupted uploads, too. some files (>10mb) werent uploaded correctly, lasterror told me "invalid handle", so i have to use resumeupload. seems to be a kind of timeout, but i dont know what exactly the problem is. to be on the safe side, i'm using a workaround: i'm uploading files with a random suffix, lile '.$TMP', which the server application (or batch) ignores. when the whole upload progress is done, i can rename them and do stuff with them.
We do that with some of the other clients, call that safe mode, and can configure our outbound to be any tag, .Filepart, .tmp, .xfr. Others we have is that we send a file in addition to the main one, that indicates done.
But we do run into some clients that will not change their side, come hell or high water.
Our servers are Globalscape, and on inbound we use event rules, File Upload that runs our generic event handler when the file is completely sent, A thousand times better than trying to figure out when the file is ready for process.