Socket ftp and changing directories.
I am have trouble changing diretories when using the ftp command CWD when connected to an ftp through a Socket. Sometimes it changes forward and sometimes it doesnt, and it never goes back one directory.
I use "CWD /webStuff", then I try to go back using "CWD ftp.host.com/rootFolder and it gives an error. Any suggestions on the proper format using CWD to change up and down directories?
Do i need to type the full path (ex. ftp://ftp.host.com/)? I have no idea how this changing directories work, online they only talk about CD and the ftp I am using doesn't recognize CD. Only CWD. Can't find much about using CWD. Please help.
> I am have trouble changing diretories when using the
> ftp command CWD when connected to an ftp through a
> Socket.
Keep in mind that FTP is a protocol that runs over TCP. If you couldn't connect in might be a TCP problem. But because it has to do with FTP commands it has nothing to do with TCP (sockets.)
> Sometimes it changes forward and sometimes it
> doesnt, and it never goes back one directory.
> I use "CWD /webStuff", then I try to go back using
> "CWD ftp.host.com/rootFolder and it gives an error.
I wouldn't think that the second command would ever work.
> Any suggestions on the proper format using CWD to
> change up and down directories?
To go up a directory you might try "cwd .."
> Do i need to type the full path (ex.
> ftp://ftp.host.com/)?
That is a url not a directory. I wouldn't expect it to work.
> I have no idea how this
> changing directories work, online they only talk
> about CD and the ftp I am using doesn't recognize CD.
> Only CWD. Can't find much about using CWD. Please
> help.
Since 'CD' isn't part of the protocol either they are actually referring to 'CWD' or they are referring to an extension.
Keep in mind that some of the older protocols tend to be a bit free form. Things don't work consistenly across different versions. In a case like this get a FTP client and try various things manually for each version you need to connect to. Then build your code based on the results of that manual test.
well, I tried testing the ftp from the DOS prompt in windows XP. I can connect, but CWD is not a command in the windows command prompt. So i don' t know how I would test it. Also, I can connect to the ftp using a Socket object. Then I can log in using USER and PASS. The problem I have is changing directories. CWD is really confusing. I found something that using "CWD .." or "CWD ../" might work. I have to try those. But what I'm really looking for is the ability to go lets say I log into ftp.host.com/Folder. And then I want to change to ftp.host.com/Folder/NextFolder/FinalFolder.And finally I want to change from that point to ftp.host.com/Folder/AnotherFolder/YetAnotherFolder.
In windows command prompt you can use "cd \anyfolder" and it wil take you there. But am I limited to only going "CWD nextFolder" and "CWD ../" or can i jump to any Folder on the ftp somehow like I can in windows?
> well, I tried testing the ftp from the DOS prompt in
> windows XP. I can connect, but CWD is not a command
> in the windows command prompt.
Sorry but that doesn't make any sense.
Either you are or are not running a ftp client. An ftp client would have a console window. That console window is not the same as the windows command prompt.
> So i don' t know how
> I would test it.
If you are in fact running a ftp client and the CWD command does not work then it means the ftp server does not support that command. That command is optional in the FTP protocol. In that case you can't 'move' within the directory tree - you have to connect directly to each directory.
> Also, I can connect to the ftp
> using a Socket object. Then I can log in using USER
> and PASS. The problem I have is changing
> directories. CWD is really confusing. I found
> something that using "CWD .." or "CWD ../" might
> work.
You can try 'CDUP' as well. (And I have no idea why that is the name but it does go up the tree.)
>I have to try those. But what I'm really
> looking for is the ability to go lets say I log into
> ftp.host.com/Folder. And then I want to change to
> ftp.host.com/Folder/NextFolder/FinalFolder.And
> finally I want to change from that point to
> ftp.host.com/Folder/AnotherFolder/YetAnotherFolder.
>
The command 'LIST' should return a list of directories. You would have to parse that list. Keep in mind that the result of this will vary by FTP server version. You can use the parsed list to
'NLST' returns files names.
Of course test both of the above to verify that not only that they work but what they actually return.
> windows command prompt you can use "cd \anyfolder"
> and it wil take you there. But am I limited to only
> going "CWD nextFolder" and "CWD ../" or can i jump
> to any Folder on the ftp somehow like I can in
> windows?
Again, this depends on the FTP server. Like I said you need to actually test it. And test each version that you need to connect to.
thank you. I think your right, I have to write a seperate java program to test what works and what doesn't. I can't use the same one I am. I guess I can make a console ftp in java pretty easily.. I agree that testing it out would be the best way to know for sure. Thank you for your help with the CWD .. and CWD ../ and CDUP. I don't think the LIST approach is gonna be my preferred way, I'll probably just use a console through java to test.
Also, windows does have an ftp clinet on the console. If you type
"ftp ftp.host.com" it will attempt to connect and if it can it will ask for your user name then password. However, the windows clinet uses CD and the actual FTP server (or else its Java) uses CWD. I don't know why but I have gotten CWD to work on Java but not on windows and vice versa.
Thank you for your help
> Also, windows does have an ftp clinet on the console.
> If you type
That isn't what I meant.
When you run that then the 'console' is that of the ftp client. It is no longer the windows console. Thus, for example, 'dir' works in the windows console but it does not work in that ftp console.
> ftp ftp.host.com" it will attempt to connect and if
> it can it will ask for your user name then password.
> However, the windows clinet uses CD and the actual
> FTP server (or else its Java) uses CWD. I don't
> know why but I have gotten CWD to work on Java but
> not on windows and vice versa.
You understand that the ftp app you are referring to is a client correct? Not the server?
And although 'cd' is a command in that particular ftp client that doesn't mean that the command is being used as part of the FTP protocol. Actually if it is then that would be a bug - since that is not a part of the defined protocol.
Has anyone posted the fact that Java includes an FTP client?
i finally figured it out.. well sort of. I don't know why, but it just started working. Thats good enouph for me.
> i finally figured it out.. well sort of. I don't> know why, but it just started working. Thats good> enouph for me.A disaster waiting to happen!
possibly, but I'll worry about that if it happens
you mean when it happens? No 'if' about it.
ejpa at 2007-7-15 2:59:01 >
If it does I'll post it here.. So far so good
> > i finally figured it out.. well sort of. I don't
> > know why, but it just started working. Thats good
> > enouph for me.
>
> A disaster waiting to happen!
Having done a bit of this in the past going with what works with FTP is about all one can hope for. There are many variations so the best one can do with out spending a lot (really a lot) of time on it is to get the commands done that work.
One can create a script engine that runs from a file. But that just makes it a little bit easier to deal with future failures. It doesn't necessarly make it easier to figure out why it failed either.
< Has no idea what a script engine is =0?null
> < Has no idea what a script engine is =0?
>
Interpreter.
You create a mini-language that drives a FTP session. The script is specific to something (like a FTP server/version). An interpreter uses that script to drive the processing for an FTP session.
This is only easier to the extent that you don't have to modify the code for different versions. It is initially harder to implement and will probably also be harder to maintain (if you are only dealing with one server.) And one still needs to manually determine what new servers actually do and then one has to build the script itself.
