I can Get but can't Put (inet FTP) 1

[TheTuna]

Doesn't an Inet.execute "PUT" work just like an Inet.Execute "GET"?

I've set up an FTP site to transfer data between kiosks and server. Accounts are set up, and downloads of binary files are flawless (to kiosk from server)

But when I try to perform a PUT or SEND (from kiosk to Server), nothing seems to happen. My FTP Server shows a successful login, but no Upload takes place. Any clues?

Simple code:
<------------------------------------------------------>
inet1.URL = &quot;ftp//xxx.xxx.xxx.xxx&quot;
inet1.password = &quot;*****&quot; ' sorry, can't reveal that to you
inet1.username = &quot;user&quot; ' likewise
' The Following works great
inet1.execute , &quot;GET &quot; & sFile & &quot; &quot; & sFile1
' but this doesn't seem to do anything, am I missing something?
inet1.execute , &quot;PUT &quot; & sFile & &quot; &quot; & sFile1

<--------------------------------------------------------->

Now according to Billy Gates' help file, a put & send do the same thing, the first sFile is the local path to the file and sFile1 is the path on the ftp server



No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[CajunCenturion]

You might have read, but not write permissions on the server

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[TheTuna]

That was my first thought too... but all permissions for the account are correctly set.

CC, would you say that the code is correct? I mean, this is simple stuff, and it's a one liner, so I'm not sure where I'm going wrong. I'm trying to figure out which tree to bark up (code or ftp server).

Both seem right at this point. I'll bet I've missed something on the server, but I don't think I have.

I'm going to test sending the file using ws_ftp and if it works, I'll know it's my code.



No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[CajunCenturion]

There are a lot of issues that can come into play with the Inet control. Among them are Active vs Passive FTP, Binary vs ASCII file transfers, and embedded spaces within filenames. There may be a file handle issue on the server preventing the overwriting of an open file.

And are you checking for any FTP errors? If not, then I suggest that add a StateChanged event handler to trap for errors, and the clear FTP buffers.

I also assume that you are giving sufficient time for the operation to complete.

inet1.execute , &quot;PUT &quot; & sFile & &quot; &quot; & sFile1
While inet1.StillExecuting
DoEvents
Wend

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[TheTuna]

As always, very solid advice CC, and thanks.

I'm writing to an empty folder on the server, permissions are confirmed a second and third time. Uploading via ws_ftp is successful.

I am also implementing the statechange event to detect the full spectrum of states. They do seem to fire correctly, and no errors have presented themselves.

Oh, and I do also have the do while .stillexecuting loop wrapped around a doevents to ensure the completion of the command.

Now, the problem turns out to be READING from my C:/Program Files folder. If I move the files to the root, or, to be more precise, to the c:/temp, they upload perfectly using PUT.

What would limit the inet control from getting a file from the c:/program files/anotherfolder?





No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[CajunCenturion]

The Inet control cannot handle embedded spaces in the pathname. It cannot read from the &quot;Program Files&quot; directory because of the space. You could try using the name &quot;Progra~1&quot; instead of &quot;Program Files&quot;, and if that does not work, then you'll need to either move the file to another directory before the FTP command, or use FTP API calls.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[SemperFiDownUnda]

Another tip to debug the INET control is set up a local FTP server and log all access. 5 years ago, god its been awhile, I had a problem and couldn't get the right access to the UNIX boxes to see what was going wrong so I ended up putting a FTP server on my dev box to see what was coming through. I found out that the INET Control I used ignored the USERID and PASSWORD provided and tried logging in anon. Found a KB that said that it was a known problem and to download the new version of the control. Which I did. I tested and it worked until I agian tried to use it on the UNIX box. So back to my FTP server to look at what was going on. In the infinate wisdom of the idiots at MS that fixed the anon login problem they deemed that the path information could be changed to UPPERCASE. Which is fine for windows but Since *NIX kind of cares about case it was broke. I had to wait a few weeks for another version of the control to come down the pipe line.

Moral: don't trust MS
Also use a FTP server you have complete control over to test agianst so you can see what is happening on the server side.

 

[TheTuna]

CC, thanks... since the inet can't handle spaces, I'll simply move the files to be transferred into the temp folder on the root. That will be fine. I wanted to be sure it wasn't going to be a problem elsewhere on the kiosk.

SemperFiDU... doesn't it just make you laugh!

Thanks Again!


No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[rorubin]

ACtually why don't you just convert to a short path that way you are not limited, and you can keep your program as is. I have some code that does that. If you are interested I will find it and post it.

 

[SemperFiDownUnda]

Please do Rorubin, that path code would be handy in a few situations.

 

[johnwm]

It's here:

http://www.mentalis.org/apilist/GetShortPathName.shtml

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'People who live in windowed environments shouldn't cast pointers.'