More Auto Rename Options Needed?

[dilettante]

I'm currently working with Core FTP Lite v. 1.3 build 1391.

One of the servers I need to work with has some limitations I don't have a good workaround for. Basically, file naming conventions are getting me.

Issue # 1

The server doesn't support any form of file extension. The kind of thing a PC, etc. typically signifies via the file extension is defined on this server through a completely distinct "hard" (predefined range of legal values) file attribute entirely unrelated to the file name.

I don't expect any support for this "filekind" attribute, and the server exposes no related functionality via FTP anyway.

My problem is that trying to transfer a file like JOEBLOW.TXT yields an error result from the server, because periods and many other non-alphanumeric characters are illegal in file names on this platform. In fact, only uppercase letters, digits, hyphen, and underscore are permitted, from 1 to 17 characters. Lowercase gets mapped to upper without intervention.

Code: Select all

TYPE A  
200 The TYPE has been set to ASCII Non-Print.  
PASV  
227 Passive mode entered  (167,240,190,3,148,210)  
STOR JoeBlow.txt  
Connect socket #732 to 167.240.190.3, port 38098...
501-Error in STOR command parameters;  Scanning JoeBlow.txt.  
501 Invalid File Name. Scanning .  
Transfer time: 00:00:09  
PASV  
227 Passive mode entered  (167,240,190,3,148,211)  
LIST  
Connect socket #744 to 167.240.190.3, port 38099...
150 Opening a Type ASCII Data connection for "SERVERTEST".  
226 Transfer complete;  Data connection closed.  
Transferred 0 bytes in 0.040 seconds

Issue #2

As already described, only a limited filename alphabet is allowed. Not only does a file like JOEBLOW.TXT (or joeblow.txt, case isn't a big issue here) cause an error, but even a file named JOE BLOW (with no extension) leads to an error because of the space.

Code: Select all

TYPE A  
200 The TYPE has been set to ASCII Non-Print.  
PASV  
227 Passive mode entered  (167,240,190,3,148,233)  
STOR Joe Blow  
Connect socket #732 to 167.240.190.3, port 38121...
501-Error in STOR command parameters;  Scanning Joe Blow.  
501 Invalid Option. Scanning Blow  
Transfer time: 00:00:09  
PASV  
227 Passive mode entered  (167,240,190,3,148,234)  
LIST  
Connect socket #704 to 167.240.190.3, port 38122...
150 Opening a Type ASCII Data connection for "SERVERTEST".  
226 Transfer complete;  Data connection closed.  
Transferred 0 bytes in 0.030 seconds

The error here is really a problem with the parsing of the FTP PUT (STOR) command, and I'm not too sure how the server is supposed to figure out what to do in this case. Surely this name needs to be escaped in some way?

I'm not even getting to the point where the server will choke on the space yet.

So What I Think I Need

Does it make sense to have a more sophisticated scheme for Auto Renaming? Something that goes beyond file extension mappings? A rule like "change spaces to underscores and drop extensions" might be an example I could live with. Another option might be "drop spaces from names and hyphenate extensions."

Am I missing something obvious? Is the needed functionality here already, and I'm just too impatient to winkle it out? Is the real answer to manually rename files before/after transfers?

Is the spaces-in-the-name problem a bug in Core FTP or am I missing some unwritten rule of FTP like "never try to FTP a file name with spaces in it?"

Thanks.

[dilettante]

Thanks, but I can see there isn't any really good resolution. It seems to be an issue with many platforms and I suppose everyone just manually renames files before attempting to upload them.

I imagine the issue might exist for downloading too, if a server allows filenames that aren't legal for Windows.

In effect what I suppose we'd need for uploads is something like what Windows does in creating the short filename equivalent of a long filename. This could be hazardous because the user can't necessarily predict what name Core FTP might generate for the upload, leading to a possible undesired overwrite at the server:

This is a long filename.txt -> THISISALONGF
This is a long file too.txt -> THISISALONGF

Without knowing what's going to happen (here we set maxlength=12, uppercase alphanum, no extension) the user might upload the second file and unintentionally replace the first file.

One can imagine all kinds of things of course like chopping the extension, dropping the spaces, upcasing the letters, taking the 1st 10 or less characters, then adding a 2 hex digit checksum of all the original characters:

This is a long filename.txt -> THISISALOND4
This is a long file too.txt -> THISISALONA5

But now it's getting absurd, and how would one set up the rules for each server type such as legal alphabet, length limit, what to do with an extension, drop illegal chars or translate/substitute, etc? It could get messy and the destination (uploaded) filename still would have predictability problems as well as possible name collisions.

You'd almost need to make the user/deployer responsible for writing a script function for kunkerizing the upload/download names. This would require something like making Core FTP a host for Windows script engines or else incorporating a custom script engine. I'm not sure the payback is there.

Thanks for thinking about it though.

[dilettante]

Worth a thought. I'll look into it.

Thanks.

[spc]

Would like to find and replace a filename. I have 2.1.

Is this option supported?