FlashFXP Forums - View Single Post

Yil · 04-10-2010, 01:26 PM

Let me take the posts one at a time, starting from before my last post.

pion: I'm guessing the old version is at fault in the preloading taking a while problem. Look carefully at the logfile entries you showed. If preloading must be performed before the server is allowed to accept connections (DELAY=True mode) then the PRELOAD: lines will appear before the START: entry in the logfile. This is clearly true of your example so you need to set the DELAY option in VFS_Preload to FALSE. V7.0 defaulted this to TRUE if undefined and v7.1+ changed this to default to FALSE if undefined. So set it to FALSE explicitly to get the same behavior across those 2 versions. You can examine the logfile to make sure you get the correct behavior.

pion: The color warning error you are seeing probably is because you are running an older version. Perhaps to test with? V7.2+ changed all the theme color codes into letters and got put into Theme.ini instead of ioFTPD.ini so the line you are showing isn't possible. Also, the theme format changed between v6.9 and v7.0 to support sharing subthemes and the "+" sign was added to make sure an error just like the one you showed was displayed to indicate the definitions weren't updated. I'm guessing you tested v6.9 or something just to check behavior and thus you can ignore this error as it will only disable the theme and isn't a big deal.

Directory caching of entries in the mountfile do not decend into the directory tree, however they do have to process all immediate subdirs in order to get their sizes. Thus a large XVID folder will take a little bit of time because it has a lot of entries but a folder with just months like 01xx will be fast. The optional preloading section in the .ini file where you can specify where and to what depth to decend can be used to make it go deeper.

pion (and perhaps o_dog from earlier?): Take a look at that exchange. The FTP Client is at fault not the server!

(21:17:06) [Site2] PORT 1,1,1,1,165,166
(21:17:06) [Site2] 200 PORT command successful.
(21:17:06) [Site2] STOR my.sfv

No ABOR command was EVER sent, the client just kept trying to send new PORT commands and they should be rejected, in fact it even says so in the error reply! After like 20 seconds ioFTPD will timeout the attempt and it would probably continue working from that point. I forget which version of FlashFXP had this bug, but I know many earlier versions of the current beta did and it's possible other clients do/did as well. Newer, or older, versions of FlashFXP work fine and send the ABOR command before trying again...

pion: "Error converting string" errors were fixed in v7.1 when the TCL temporary internal name for the waitobject was increased in size to handle paths instead of just short names. Just use a newer version.

pion: That v7.0.3 lockup isn't that useful to me, but your next post with the minidump/crashlog might be. However, v7.1+ included a number of bugfixes that might have solved the reason for the problem, but I'll take a look at the crashlogs and get back to you if it's something new.

04-10-2010, 01:26 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	Let me take the posts one at a time, starting from before my last post. pion: I'm guessing the old version is at fault in the preloading taking a while problem. Look carefully at the logfile entries you showed. If preloading must be performed before the server is allowed to accept connections (DELAY=True mode) then the PRELOAD: lines will appear before the START: entry in the logfile. This is clearly true of your example so you need to set the DELAY option in VFS_Preload to FALSE. V7.0 defaulted this to TRUE if undefined and v7.1+ changed this to default to FALSE if undefined. So set it to FALSE explicitly to get the same behavior across those 2 versions. You can examine the logfile to make sure you get the correct behavior. pion: The color warning error you are seeing probably is because you are running an older version. Perhaps to test with? V7.2+ changed all the theme color codes into letters and got put into Theme.ini instead of ioFTPD.ini so the line you are showing isn't possible. Also, the theme format changed between v6.9 and v7.0 to support sharing subthemes and the "+" sign was added to make sure an error just like the one you showed was displayed to indicate the definitions weren't updated. I'm guessing you tested v6.9 or something just to check behavior and thus you can ignore this error as it will only disable the theme and isn't a big deal. Directory caching of entries in the mountfile do not decend into the directory tree, however they do have to process all immediate subdirs in order to get their sizes. Thus a large XVID folder will take a little bit of time because it has a lot of entries but a folder with just months like 01xx will be fast. The optional preloading section in the .ini file where you can specify where and to what depth to decend can be used to make it go deeper. pion (and perhaps o_dog from earlier?): Take a look at that exchange. The FTP Client is at fault not the server! (21:17:06) [Site2] PORT 1,1,1,1,165,166 (21:17:06) [Site2] 200 PORT command successful. (21:17:06) [Site2] STOR my.sfv No ABOR command was EVER sent, the client just kept trying to send new PORT commands and they should be rejected, in fact it even says so in the error reply! After like 20 seconds ioFTPD will timeout the attempt and it would probably continue working from that point. I forget which version of FlashFXP had this bug, but I know many earlier versions of the current beta did and it's possible other clients do/did as well. Newer, or older, versions of FlashFXP work fine and send the ABOR command before trying again... pion: "Error converting string" errors were fixed in v7.1 when the TCL temporary internal name for the waitobject was increased in size to handle paths instead of just short names. Just use a newer version. pion: That v7.0.3 lockup isn't that useful to me, but your next post with the minidump/crashlog might be. However, v7.1+ included a number of bugfixes that might have solved the reason for the problem, but I'll take a look at the crashlogs and get back to you if it's something new.