If nobody is working on this (and no one objects to me trying), I will attempt to correct it. I don't know if I will be successful as I've only just started looking at the source. But, it seems it should just be a "simple" matter of adding a new server type and handling the file name semantics.
Any objections?
Leland
Bug: [ 942941 ] Slashes in directory name
Moderator: Project members
What do you want to achive?
Add a completely new server type (which uses anything but slashes as separator) or just add support for filenames containing slashes?
Adding a complete new servertype is rather easy. (see CServerPath). However, adding support for files with slashes is next to impossible, if using the standard path format (with slashes as separator). FileZilla won't be able to distinguish between paths and folders then.
If you ever see a file with slashes, enter the 'RNFR file/with/slashes' and 'RNTO file_without_slashes' commands manually.
Add a completely new server type (which uses anything but slashes as separator) or just add support for filenames containing slashes?
Adding a complete new servertype is rather easy. (see CServerPath). However, adding support for files with slashes is next to impossible, if using the standard path format (with slashes as separator). FileZilla won't be able to distinguish between paths and folders then.
If you ever see a file with slashes, enter the 'RNFR file/with/slashes' and 'RNTO file_without_slashes' commands manually.
New server type, I believe. I'd seen in CServerPath that it seemed to be fairly simple, so I figured that would be where I would start.botg wrote:What do you want to achive?
Add a completely new server type (which uses anything but slashes as separator) or just add support for filenames containing slashes?
Mind, I'm at work right now and don't have access to a compiler to test my ideas, so I'll just have to talk off the top of my head. (Or the other end...
)I'll use z/OS filenames as an example...
Under z/OS, standard filenames (or dataset names as we call them) use more of a flat namespace. They are at most 44 characters long and each node (or qualifier) of the name is separated by a period. For example:
HIGHLVL.NODE1.NODE2.LOWLVL
If the name is wrapped in aposts ('), then it is considered to be "fully qualified" and can be thought of as an absolute path. If no aposts are used, the OS usually prepends the current userid and is more like a relative path.
Here's an example of my changing directories (FileZilla message log):
Command: cwd 'tsslll.jcl.lib'
Response: 250 The working directory "TSSLLL.JCL.LIB" is a partitioned data set
Here's an example of me changing to the the parent node:
Command: cwd ..
Response: 250 "TSSLLL.JCL" is the working directory name prefix.
But, notice what happens when I attempt to move up 2 levels:
Command: cwd ../..
Response: 501 A qualifier in "../.." begins with an invalid character
The biggest issue seems to be when FileZilla adds the leading and trailing slashes to the name. Like when I try to use:
'tsslll.jcl.lib'
FileZilla converts that to:
/'tsslll.jcl.lib'/
And the FTP server complains with:
Command: CWD /tsslll.jcl.lib/
Response: 550 CWD cmd failed : EDC5129I No such file or directory.
Error: Could not retrieve directory listing
So anyway, there's probably enough weird naming issues that a new server type would probably be the best way to go. That way nothing else is broken. It looks like the VMS type may be quite useful as a guide.
(I hope all that made sense...)
Leland
[/quote]