Warning: Newbie post!!!
I think I may have found a bug (Not a major one!),
If I upload a file (eg: "fred.doc"), then upload another file with the same name but in a different case (eg: "FRED.doc"), it will overwrite the original file, which is correct. But the client sees it as a different file and shows both versions in the right panel file list, even though, after the upload the file check returns a 550 "The system cannot find the file specified".
Any date for the next release?
Bug with filenames - case-sensativity
Command line or GUI
I've noted elsewhere that the commandline interface can be devious in the handling of case, but I hadn't noted a problem (yet) in the GUI.
The symptom I've found in the command line is that if the source specified in the command line is "fred", then the command line is find "Fred" and "fred" (and probably "fRed" etc.) If no destination name is specified, then that destination files will get the name of the input specification. So a source filename of "Fred" would become "fred" if the source spec in the command line were "fred". Subsequent attempts to transfer cases of "fred" would attempt to overwrite "fred".
IMHO the command line should report file not found if "fred" is specified as a source in the command line and only "Fred" is found in the source directory. In other words COREFTP command line should preserve case sensitivity. At least with Unix and Windows clients and servers. OpenVMS would present a special case. OpenVMS ODS-3 disks will have all filenames in uppercase, so treating that as case insensitive makes some sense. However OpenVMS ODS-5 disks allow for mixed case filenames, so those should be treated with case sensitivity.
Perhaps the best treatment of case sensitivity would be to allow it to be a setting of the site. That way a COREFTP user could select case sensivity on a site-by-site basis. In the case of an OpenVMS systems with both ODS-3 and ODS-5 disks, the user could set up two sites in the site manager for the system. One with and one without case sensitivity.
Todd
The symptom I've found in the command line is that if the source specified in the command line is "fred", then the command line is find "Fred" and "fred" (and probably "fRed" etc.) If no destination name is specified, then that destination files will get the name of the input specification. So a source filename of "Fred" would become "fred" if the source spec in the command line were "fred". Subsequent attempts to transfer cases of "fred" would attempt to overwrite "fred".
IMHO the command line should report file not found if "fred" is specified as a source in the command line and only "Fred" is found in the source directory. In other words COREFTP command line should preserve case sensitivity. At least with Unix and Windows clients and servers. OpenVMS would present a special case. OpenVMS ODS-3 disks will have all filenames in uppercase, so treating that as case insensitive makes some sense. However OpenVMS ODS-5 disks allow for mixed case filenames, so those should be treated with case sensitivity.
Perhaps the best treatment of case sensitivity would be to allow it to be a setting of the site. That way a COREFTP user could select case sensivity on a site-by-site basis. In the case of an OpenVMS systems with both ODS-3 and ODS-5 disks, the user could set up two sites in the site manager for the system. One with and one without case sensitivity.
Todd
Re: Command line or GUI
Because there are so many deviations and different OSs that will behave differently with case sensitivity, I think this would probably be the easiest solution as well.maurert wrote:Perhaps the best treatment of case sensitivity would be to allow it to be a setting of the site. That way a COREFTP user could select case sensivity on a site-by-site basis.
I know that if I upload a file called "Fred.html" and "fred.html" to my Linux server, I wouldn't want one to take precedence over another and rewrite the file...on the other hand, on a Windows server, I would want it to do that. So, rather than it be server specific, site specific sounds easy enough.
another bug with names
yeah, and it does not recognize directories in cyrillic