ioFTPD v7.5.9 Released (Beta) - Page 2

Yil · 05-20-2010, 11:20 PM

I successfully transferred 5K files totaling roughly 250GB using 10 FXP sessions back to itself without problems using SSL. I then did it again. I saw 1 interesting event but it had no side effects that I'm aware of and I changed the code to handle that case better now.

Everyone should upgrade to fix the bugs, and I removed the extra debug junk except for the new "rare" cases that I'm interested in.

pion · 05-21-2010, 02:39 AM

Uploading: While crashed, and issuing PORT command, nothing is happening in logs. By enabling reverse transfer and send PASV, I see the following in log:

05-21-2010 09:36:36 WSAAsyncSelectWithTimeout socket re-use: 4472 - Flags: 0

Single line, but multiple failed transfers.

Flow · 05-21-2010, 12:04 PM

Login on local server with SSL (TLS) enabled. DIRs list fine, smooth. Login to another site trying grabing a file for FXP test, then i get this;

[1] RETR pzs-ng_v1.0.X_r2563.tgz
[1] 425 Can't open data connection.
[2] ABOR
[2] 426 Connection closed: Your user class requires you to use secure connections.
[2] 226 ABOR command successful.
[2] DELE pzs-ng_v1.0.X_r2563.tgz
[2] 550 pzs-ng_v1.0.X_r2563.tgz: No such file or directory.

What'v missed?

Yil · 05-21-2010, 12:23 PM

Flow: You enable the FXP SSL checkbox in your client for both sites? The "426 Connection closed: Your user class requires you to use secure connections." message indicates you were trying to upload/download a file without encryption turned on so it denied you.

That restriction is controlled by the 'Require_Encrypted_Data' under [FTP_Service].

Your client probably has 3 SSL settings btw... Login, Listings, and FXP...

Yil · 05-21-2010, 12:36 PM

pion: That's the interesting case I saw as well. It's a known possible race condition and it is handled correctly now. It also shouldn't affect anything as the 20 second connection timer (or the idle_timeout) will close the listening/connecting socket and everything should continue normally. Still, when did that appear? It sounds like just after things went bad which sorta makes sense...

It's looking like winsock stops delivering these async socket events notifications completely... I'll have to explore this some more... perhaps a build for you with extra debugging around this since you can obviously reproduce the issue.

I can also look into using the data connection async notification method to build another feature into the deadlock detector so it can catch that as well for you.... Or perhaps change the way this is done entirely.

pion · 05-22-2010, 04:33 AM

I sent PORT command to io for hours in crashed state. The second I switched to reverse transfer and issued PASV, that line appeared

Flow · 05-23-2010, 01:57 PM

Hi Yil, uploaded 3 greek-to-me file for you. Hope it point out something for development.

pion · 05-24-2010, 09:59 AM

(16:57:56) [io745] PWD
(16:57:56) [io745] 257 "/" is current directory.
(16:57:56) [io745] STAT -l
(16:58:09) [io745] List Complete: 504 bytes in 12,34 seconds (0,04KB/s)

This is with preload disabled.

The dir doesn't have a single 'actual' dirs, they're all just mountpoints from the vfs, which are emtpy dirs like FTP-ROOT-DIR and the like.

This slow dirlisting happends every time, for every dir.

Preloading enabled, with delay=true:

05-24-2010 17:27:37 PRELOAD: "begin" "..\etc\default.vfs"
05-24-2010 17:28:50 PRELOAD: "points=55" "..\etc\default.vfs"
05-24-2010 17:53:29 PRELOAD: "count=9383" "..\etc\default.vfs"
05-24-2010 17:54:17 SSL: "Found certificate" "name=abcd" "Service=FTP_Service" "(Certificate_name)"

Then when (finally) logging in:

(17:54:47) [io745] STAT -l
(17:58:07) [io745] Timeout, Connection closed

Please put some more sane timeouts on dirlisting stuff!

o_dog · 05-24-2010, 11:45 AM

it seems ntfs junctions is broken i last rel, dunno how long it's been that way but it can't handle ntfs junctions on network shares. No matter how you set it up it tries to manipulate the links in some way ending up with some crappy files instead of links. They show up as 0byte link files for some reason, my guess is that the manipulation you added thinks they're regular windows links.

Yil · 05-24-2010, 12:52 PM

o_dog: Hmm. What 'NTFS_Reparse_Method' option are you using? If you switch to IGNORE that should be the old behavior and everything would work like it did pre v7. SHARE/SYMLINK are very different and I process the re-parse points internally to figure out the target dir, etc. It's possible I missed something simple when dealing with network shares, so I'll test that and get back to you. Try the IGNORE option though and see if that offers a temp fix.

pion: My hands are pretty much tied. It's the client (not the server) that times out the directory listings and there isn't really much that I can do about that. The simplest option includes sending some sort of bogus / generic data to keep the client happy but what that should be I'm not really sure... A later release with that saved-cache feature I thought about seems like the best option but that doesn't solve your short term problem... Of course speeding up cache processing in general wouldn't hurt either...

o_dog · 05-24-2010, 01:14 PM

as i said it doesn't matter what option you use, when using symlink they show up as symlinks and point nowhere, if you use the other two they show up as 0byte files. Ignore doesn't seem to ignore it

pion · 05-24-2010, 01:19 PM

Preloading taking 15 (!!) minutes is what I'm referring to

pion · 05-24-2010, 01:50 PM

Downloading io 7.5.2 zip file, running the ioftpd-start.exe out of the box fails:

Win7: (ioftpd.exe starts)
ioGui2
Component 'MSCOMCTL.OCX' or one of its dependencies not correctly registered: a file is missing or invalid

I might add that iogui is unable to connect to io on the first run also.
Maybe an idea to have ioGui start proper out of the box?

Flow · 05-24-2010, 04:24 PM

Hi Yil, the CRASH, MINIDUMP and TINYDUMP are generated when manually stopping the ioFTPD service in the contorlpanel. Just noticed that.

Yil · 05-25-2010, 12:50 AM

To run ioGUI on vista/win7 you need to register the .ocx files.

Open up a command prompt using the "Run as administrator" option as you'll need admin rights.

cd c:\ioftpd\ioGUI
regsvr32 MSCOMCTL.OCX
regsvr32 MSWINSCK.OCX

Then try to start the GUI again. If that doesn't work you might need to copy the .ocx files to c:\windows\system32, cd to that dir, and try to register them there...

It's been a while since I've had to do it, but I think that's right.

ioGUI only tries to connect once. It's kinda stupid that way. I didn't write it, but it's better than nothing for some things. I added a delay feature to ioFTPD-start if you pass it a number it will wait that many seconds before spawning the GUI in the hopes the server has started by that point. ioGUI is based on the original .NET release way back when and won't work with newer compilers so it's kind of a tricky build which is why nobody has bothered to modify it and we are still using the old version.