GetDataToBuffer/GetDataToBufferAt (wodSFTP / wodSFTP.NET / wodSFTPdll)

Greetings!

We recently purchased this DLL to add secure FTP to one of our mission-critical applications. So far, I've been able to code and successfuly test everything that we've needed (GetFile, PutFile, DeleteFile, etc.).

I run into problems, however, in trying to access the contents of a remote file. I understand the use of a temporary file for the GetData/GetDataAt functions, but I see no need for a local file for the buffered versions of those functions, GetDataToBuffer/GetDataToBufferAt. I've supplied a buffer to the DLL for writing file contents, there is no need to write to a file. Why should I be getting an error 30024 when I use that command?

Moreover, why do these buffered commands not conform to the age-old standard for buffered commands? Each of your buffered property retrieval commands (e.g., GetListItem, GetErrotText, etc.) uses an int pointer to send the buffer size to the function and return the size written into the buffer. Why is this not the case with GetDataToBuffer/GetDataToBufferAt?

I need a way to retrieve remote file contents without having to allow guest user access to my local drive. Can someone help?

Best Regards,

Lyle Janney
Lead Analyst/Programmer
Purdue University

Lyle,

I agree with you, I don't think it should need local file. I'll check that out.

As for int pointer.. Hmm. I don't think it's needed because component cannot tell you how much to allocate, can it? It depends on remote file size which is not known to the component until it sends actual request. So, you could perform this if you want prior to calling GetDataToBuffer.

Greetings!

Thank you very much for your swift response to this issue. I appreciate you looking into it and hope that you have a resolution for me very soon. So that you know, I will soon also be making use of the buffered PutData commands -- I'll let you know if I run into any problems with temp files.

Regarding the use of an int pointer to send the buffer size and return the number of bytes written to the buffer, I understand that it wouldn't be useful in determining how large to make the buffer. However, it would be very useful for understanding how many bytes to read from my buffer (especially if it is binary and could have embedded 0-value bytes). It would also be very useful if I were retrieving a large file in parts -- I could check the number of bytes written to the buffer and know that I was done when that value was less than my buffer size.

Please don't get me wrong... I very much like this product and have otherwise found it to be an excellent resource. I look forward to hearing back from you.

Best Regards!

Lyle

Lyle,

this was a bug (as you already know). Component didn't know when to stop when buffer was exhausted, and it requested more data. Since writing to buffer failed, it returned 30024. Fix will be online in few minutes. Request update in 20 minutes plz.

As for int pointer... Hmm.. You could be right. I'll see if this can be changed. Since this isn't ActiveX, we could change interface (ehm...) but we need to update helpfile, etc.. so it's not going to be done today, but probably by the end of the week.

Greetings!

I apologize, I was out of the office yesterday -- is the update with the bug fix available? Also, to get the update, do I need to have our purchaser request the update?

Finally, thank you very much for considering my suggested modification to using int pointers for the buffered commands. I look forward to hearing from you when that is available.

Best Regards!

Lyle

Lyle,

yes, go to http://www.weonlydo.com/index.asp?update=1 and request it using same email you used when order was placed.

Greetings!

Thank you, very much for the bug fix -- it works quite well now.

What is the status regarding the change request for the bufferSize parameter?

Best Regards!

Lyle

Lyle,

let's get back to it. Since you partially download the file (or part of the file), what would you expect to return as needed buffer size? Full size of the file? If so - you already have way to achieve that, don't you?

I am hoping that you would return the number of bytes actually written to the buffer during that method call, just as you already do for each of your buffered property retrieval commands (e.g., GetListItem, GetErrorText, etc.).

I have developed a workaround for using the GetDataToBufferAt method to retrieve an ASCII file, but it's pretty ugly. I use a freshly zeroed buffer for each successive call to the method -- when the size of the string returned is less than the buffer size, I know that I have reached the end of the file.

However, this will not work for BINARY files since 0x00 is a valid byte value in binary files.

I cannot access the DLL asynchronously from my application, so I am unable to use the GetAttributes method to invoke the Attributes callback in order to obtain the file size. If I could get the file size, I would be able to to use that as my boundary condition when calling GetDataToBufferAt.

The algorithm would be very straight forward if the bufferSize parameter for the GetDataToBuffer and GetDataToBufferAt methods was an int pointer -- the programmer would send in the buffer size and the DLL would return the actual number of bytes written into the buffer (like with GetErrorText, etc.).

Instead of going through the hassle of changing the existing interface, perhaps you could create a new version of those two methods that would use the int pointer?

Lyle,

I missed the point of making it int *...

Ok, I think this is now changed and working. Can you please send email to techsupport@weonlydo.com so I can reply with new version for test?

Kreso