transfer to ftp server problem - CMODE

[darobmeister]

I've been troubleshooting a second and third PC that wouldn't work with coreftp 1.3b, 1.3c beta, etc. All not working properly - I can't transfer a file to the ftp server - Novell 6.5 SP2 file server.

It's working on my main PC, no problem. So I'm trying all the relevant connection and other options, making sure every setting is exactly the same as my PC. Some were different because my University changed some settings in their distro. But none of them in the GUI worked.

So I go into the registry. Sure enough, the one setting that makes a difference? CMODE - under HKCU\Software\FTPWare\CoreFTP\Sites\6. CMODE on my PC is set to 0xffffffff. On the PCs that aren't working, it's set to 0xffff.

I change it to 0xffffffff, and now they work like a charm. Wow. Why would this setting make such a difference?

Thanks,

Rob

[darobmeister]

If you don't select it as your default ftp client, it installs with different values in the registry and doesn't transfer. If you do install it as your default, it works like a charm.

Why would it put in different values (not just one, many different) if it's not the default ftp client?

Thanks,

Rob

[darobmeister]

I wonder then if it's due to USC's repackaging of the distro. I'll check with them and hopefully I'll get a response back. All I can tell at this point is the logic in my previous message.

I'll try it with the 1.3c beta version which is not a USC distro and let you know.

Rob

[darobmeister]

I just tried it with the standard 1.3b wiping out all previous core files and reg entries, and it works like a charm. Checked the reg now and it properly put in the settings.

now if only I can get ISD to change their distro. That should be fun

Thanks for all your help, and sorry for any trouble.

[heatoniv]

Hmmm... so the USC distro doesn't write any HKCU keys. So any HKCU keys must be created by the app itself. Further the only keys created in HKLM are the USC registration number and USC default sites. USC used the vendor instructed method to create the 8 default usc sites. Those created sites have the CMODE value is set to 0xffff. However USC did test their distro and didn't find any problems connecting with the sites they have defined in their distro. So those eight sites connect without problem.

It is possible that the site key data import/export was created using unicode but the final release of the distro was ANSI as there were last minute required fixes made only to the ANSI version. And at least at the time there wasn't any documents/instructions saying that the import/export site info couldn't cross binary boundaries. In fact this is the first I've heard of it.

However in general I'm confused how us creating 8 sites in HKLM are stopping the binary from establishing connections to custom user session created sites (HKCU). I can't logically come up with how one is affecting the other. But I'm probably missing something obvious.

Regardless sounds like the binary has been fixed to resolve whatever problem there was. Just so you know whenever there is a next official release (non-beta) preferrably of the unicode version USC will update it's distro accordingly.

Yes I'm aware of how long that can sometimes take. However barring large changes to how the application interfaces with the OS, core being updated should never take too long.

-Oh yeah I know these things cause I created the distro. :wink: