Parsing of remote file path doesn't work - "/" or not??

[rhino]

I keep getting the "Default remote path cannot be parsed error" within Site Manager when I try to set a value for the remote path. This happens whether I proceed that path with a slash or not. (Yes, I searched the Wiki and forums before I asked this and found the information that all remote paths needed to be preceded by a '/' as of version 3.2.)

I'm a new user of FileZilla but I am an experienced IT professional who has used several different file transfer programs over the years. FileZilla seems to be working in every respect except this one. I'm using FileZilla 3.3.2.1, freshly downloaded this morning, on Windows XP with SP2.

For the connection I'm currently playing with, the remote path is very simple: html. I've tried putting html in the remote path and I've tried using /html in the remote path but both cause the same error message, as cited in my first sentence. Is there some other syntax I should be using??

Is there something else I need to do in the setup? Since I don't know the operating system being used by the remote server and I'm not sure how to determine it conclusively, I've left the servertype as "Default (autodetect)". Would changing the servertype to the correct type help me here? If yes, what is the best way to determine the remote servertype?

If there is nothing I have omitted in the setup, is there any solution to this problem other than waiting for a fix in a later version of the FileZilla client?

This is not a huge problem - I can simply click on the remote directory(ies) until I get to the one I want - but it would certainly be convenient if I could get this to work correctly.

[rhino]

For what it's worth, I have this working better now.

The full path to my remote directory had additional directories in it so I typed in the FULL path (from the root directory), instead of just the relative path and it worked fine. The relative path, i.e. the subdirectories beneath the one where the client actually connects on the server, is all you need in some file transfer programs I've used so I assumed it would work in FileZilla too. Apparently, I was wrong.

So, to summarize, when I signed in with no remote path supplied at all, FileZilla parked itself at /udd/s/sfl and I assumed that all I needed to put in the remote path box in the Site Manager settings was either "html" or "/html" but both gave me a parsing error. Simply changing the server type to Unix didn't resolve the problem: I didn't get the parsing error but FileZilla claimed that the directory "html" didn't exist. However, when I specified the full path on the remote server, /udd/s/sfl/html, I was able to get to the directory I wanted immediately upon connecting. I was also able to change the servertype back to "Default (autodetect)" and still connect to the exact directory I wanted.

Therefore, if anyone else gets this error sometime in the future, don't bother messing with your servertype and just make sure you specify the FULL path right from "/" to the directory you want and you should be good to go.

May I suggest that this information be added to the FAQ? I know I'm not the first person to stumble over this issue.....

Another option that would avoid the problem altogether would be to change the client so that if a partial path is provided in the remote path box, the rest of the path is inferred by the software. Then, if FileZilla takes me to the /udf/s/sfl directory when it connects me and I have specified only 'html' (or '/html') in the default path box, FileZilla could infer that I actually want to go /udf/s/sfl/html.

Just a friendly suggestion.....

[botg]

So, to summarize, when I signed in with no remote path supplied at all, FileZilla parked itself at /udd/s/sfl

Not quite, it is the server that parks the client in that location.