FlashFXP Forums - View Single Post

Yil · 05-06-2008, 11:02 PM

Here's the interesting bit with unicode and tcl. ioFTPD is clearly not unicode aware, but it appears to do OK writing goofy looking utf8 encoded file/directory names that on disk appear weird but when viewed back by FTP clients are correct. Thus while not actually unicode aware it just sorta works if you ignore the local filesystem

I'm not sure why TCL using a binary encoding for the passed in arguments wouldn't handle things the same way, but I'm going to be looking into it. Note that this would not support any REAL unicode paths/files not created by the server, but at least it would solve some people's problems until the day ioFTPD becomes unicode compliant....

Actually, if I enable unicode in TCL by distributing the encoding directory again you could convert the utf8 name to utf16 and look for the files on disk and thus be unicode complaint right now. But since ioFTPD wouldn't really know what to do with those names it wouldn't matter anyway, and it would break a lot of other scripts that assume TCL is stupid right now.

waitobject's interface did seem a little poor since close/delete were 2 separate actions. I however have fixed that in 6.5 now, but it sounds like you might not need it.

.diz parsing... corepda releases are wierd and often look like this and currently fail:

Code:

[OS:SMARTPHONE2005] [DATE:08/01/31] [DiSK:o1/
                    o1]

some other types look like this and fail:

Code:

2x6.61mb

and of course some fail to include a .diz at all in any zip file, but if you parse the .nfo you can extract the same information sometimes if no .diz is available although this would obviously have a higher error rate.

PRE/POST: I'm not sure about the pre bit. What information besides the name could you need? Remember, the POST event won't get called unless the file was actually deleted and thus checks for it's existence, permissions, etc have already been done so it's just update the race and adjust the completion tags. Not sure what information from the file itself would be required...

05-06-2008, 11:02 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	Here's the interesting bit with unicode and tcl. ioFTPD is clearly not unicode aware, but it appears to do OK writing goofy looking utf8 encoded file/directory names that on disk appear weird but when viewed back by FTP clients are correct. Thus while not actually unicode aware it just sorta works if you ignore the local filesystem I'm not sure why TCL using a binary encoding for the passed in arguments wouldn't handle things the same way, but I'm going to be looking into it. Note that this would not support any REAL unicode paths/files not created by the server, but at least it would solve some people's problems until the day ioFTPD becomes unicode compliant.... Actually, if I enable unicode in TCL by distributing the encoding directory again you could convert the utf8 name to utf16 and look for the files on disk and thus be unicode complaint right now. But since ioFTPD wouldn't really know what to do with those names it wouldn't matter anyway, and it would break a lot of other scripts that assume TCL is stupid right now. waitobject's interface did seem a little poor since close/delete were 2 separate actions. I however have fixed that in 6.5 now, but it sounds like you might not need it. .diz parsing... corepda releases are wierd and often look like this and currently fail: Code: [OS:SMARTPHONE2005] [DATE:08/01/31] [DiSK:o1/ o1] some other types look like this and fail: Code: 2x6.61mb and of course some fail to include a .diz at all in any zip file, but if you parse the .nfo you can extract the same information sometimes if no .diz is available although this would obviously have a higher error rate. PRE/POST: I'm not sure about the pre bit. What information besides the name could you need? Remember, the POST event won't get called unless the file was actually deleted and thus checks for it's existence, permissions, etc have already been done so it's just update the race and adjust the completion tags. Not sure what information from the file itself would be required...