FlashFXP Forums - View Single Post

Yil · 11-02-2009, 07:42 PM

paja1: "This is usually caused by another thread holding the loader lock." HA! Since I don't believe it's possible to manipulate the loader lock directly and ioFTPD is not a dll with an initialize routine with strict restrictions on what can be done during initialization, I claim it shouldn't be ioFTPD's fault

Not sure what it is doing that is triggering the bug, but I'll keep on trying to squash it and re-writing the way it listens for incoming control connections is one of two ideas to try... [update: this is the classic lockup bug in all it's annoying glory... sad to see it's not gone as this is confirmation].

Which 3rd party scripts are you using? The other idea I've recently thought of is that I need to protect TCL's socket and process creation much like I do in the server itself. I'm guessing IMDB lookups, or calls to zip,rar executables might make the problem more likely so if you are using them it might make sense. If you have a simple server then it's most likely not that...

mantonio: Hmm, good point...

mave: pfft! I got sidetracked writing all these nifty TCL scripts to do resolving, etc and then started finding other people wanted these features for scripts and figured I'd best add them into the server

Good news for virtual dir coders. I'm 90% done on allowing you to enable an option to make ioFTPD preserve symlinks in paths. This is important because you can now link out of virtual dirs and CDUP will return you back to the virtual dir. PWD also reports the correct path for clients that query it after directory changes to track where you are. I'm not done testing the side effects of this, and will probably need some help there which is why this is an option. TCL [resolve]ing works as before, but new arguments to it allow you to get the new behavior. I'm still not sure what to do with $pwd though. I'm thinking I should force the path to be resolved completely as before, and add a new variable for people who want the preserved symlink'd path. I just don't know what scripts might break if the path can't be manipulated the way it was before or that multiple paths mean the same real directory...

11-02-2009, 07:42 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	paja1: "This is usually caused by another thread holding the loader lock." HA! Since I don't believe it's possible to manipulate the loader lock directly and ioFTPD is not a dll with an initialize routine with strict restrictions on what can be done during initialization, I claim it shouldn't be ioFTPD's fault Not sure what it is doing that is triggering the bug, but I'll keep on trying to squash it and re-writing the way it listens for incoming control connections is one of two ideas to try... [update: this is the classic lockup bug in all it's annoying glory... sad to see it's not gone as this is confirmation]. Which 3rd party scripts are you using? The other idea I've recently thought of is that I need to protect TCL's socket and process creation much like I do in the server itself. I'm guessing IMDB lookups, or calls to zip,rar executables might make the problem more likely so if you are using them it might make sense. If you have a simple server then it's most likely not that... mantonio: Hmm, good point... mave: pfft! I got sidetracked writing all these nifty TCL scripts to do resolving, etc and then started finding other people wanted these features for scripts and figured I'd best add them into the server Good news for virtual dir coders. I'm 90% done on allowing you to enable an option to make ioFTPD preserve symlinks in paths. This is important because you can now link out of virtual dirs and CDUP will return you back to the virtual dir. PWD also reports the correct path for clients that query it after directory changes to track where you are. I'm not done testing the side effects of this, and will probably need some help there which is why this is an option. TCL [resolve]ing works as before, but new arguments to it allow you to get the new behavior. I'm still not sure what to do with $pwd though. I'm thinking I should force the path to be resolved completely as before, and add a new variable for people who want the preserved symlink'd path. I just don't know what scripts might break if the path can't be manipulated the way it was before or that multiple paths mean the same real directory... Last edited by Yil; 11-02-2009 at 07:47 PM.