nxTools working with dupe checking (and searching I presume) means that characters are being properly transferred back and forth between ioFTPD and TCL. If you rebuild the nxTools DB (on a test setup) and search for things does that work? The reason I ask is the name given for newly created directories may just be stuck into the DB unchanged and untested and thus searching for things you just entered into the DB should work.
What's interesting is that once you need to find a real directory on disk things break. I tested some of this locally in my TCL code and it appears to be working OK. I can find the dir with korean characters in it but I needed to process the directory names very carefully because if I ever treated them as a list via any list operation the [], {}, $, and spaces would start causing problems. That just means the script needs to be careful and wrap string in[list] and/or use lindex to retrieve the data and never lrange. This is true of any non-list string with special characters though. On the other hand with directory names that are only a couple of simple (but non-ascii) characters this shouldn't be a problem. Can you double check even the simplest of directory names is having issues?
It just came to me, but it's possible that TCL is doing character conversion based on the computer's OS code page which is exactly the right thing for it to be doing most of the time, but not something we want happening. That may explain why it works for me, but not you. Could you try setting up a test server in vmware or something but using a default english install? If this turns out to be an issue, I'll see about configuring TCL to think it's always running on a simple ascii OS install which means it won't try to convert characters back and forth from the OS calls.
|