FlashFXP Forums - View Single Post

Yil · 02-06-2010, 01:34 AM

o_dog: I think the general requirement for optional ioFTPD per-file information is really whether or not it might ever get output in regular directory listings... Any script maintained piece of information would require the use of virtual directories to get at. In theory I could see simple numbers or strings in [chattr] fields being used and have toyed with this idea. For example, overloading the user/group fields with MP3/video information in the listings in some directories. I originally added the virtual directory stuff to do things just like that since you can do anything with them, but I am toying with the idea of letting script writers set a few more special [chattr] fields that the server would understand. Of course, what gets output in directory listings would be controlled by the user so standard owner/group information would always be the default. I'd really love to return all of it via MLSD and let the user view what they want but I'm not aware of any client that allows you to view data from newly made up field names in the actual listing itself... I did submit it as a feature request for FlashFxp though

The new v7.1 tcl libraries should acquire the same lock ioFTPD uses when creating sockets/pipes and processes. In theory this should guarantee that inheritable handles don't end up in processes they shouldn't now. I once thought I proved that if that happened and the child process hanged that ioFTPD would stop accepting new connections. It might not have been the full on lockup bug, but it was a bug and it should be gone now.

If we are still having problems (and it looks like we are) then I have no choice but to blame the MS crypto library which is getter rather long in the tooth and not really maintained anymore. It constantly does a lot of stuff that involves the loader lock which is what is getting stuck... I went and grabbed the openSSL code but I haven't found a nice simple example of how to use it with async callbacks like windows/ioFTPD uses yet... If anyone knows of one, drop a link

o_dog: What kind of things are you seeing with TCL sockets? Is the behavior different in v7.1 from say 6.8? Also, what are you using [resolve list] for? It should make walking directory trees really easy for rescanning

Since it handles merged directories it's kinda cool that it solves a lot of edge cases and thus is really useful, but zipscripts dealing with a single regular dir (which is the goal since nobody currently handles anything else) probably don't get any real benefits. Another useful trick is dealing with broken links in the sorted dirs since they would show up now and are easy to spot.

o_dog: Why wouldn't the waitobject be required now? Even if the file transfer speed was server maintained wouldn't a count of outstanding files, race leader, etc all require locking?

02-06-2010, 01:34 AM
Yil Too much time... Join Date: May 2005 Posts: 1,194	o_dog: I think the general requirement for optional ioFTPD per-file information is really whether or not it might ever get output in regular directory listings... Any script maintained piece of information would require the use of virtual directories to get at. In theory I could see simple numbers or strings in [chattr] fields being used and have toyed with this idea. For example, overloading the user/group fields with MP3/video information in the listings in some directories. I originally added the virtual directory stuff to do things just like that since you can do anything with them, but I am toying with the idea of letting script writers set a few more special [chattr] fields that the server would understand. Of course, what gets output in directory listings would be controlled by the user so standard owner/group information would always be the default. I'd really love to return all of it via MLSD and let the user view what they want but I'm not aware of any client that allows you to view data from newly made up field names in the actual listing itself... I did submit it as a feature request for FlashFxp though The new v7.1 tcl libraries should acquire the same lock ioFTPD uses when creating sockets/pipes and processes. In theory this should guarantee that inheritable handles don't end up in processes they shouldn't now. I once thought I proved that if that happened and the child process hanged that ioFTPD would stop accepting new connections. It might not have been the full on lockup bug, but it was a bug and it should be gone now. If we are still having problems (and it looks like we are) then I have no choice but to blame the MS crypto library which is getter rather long in the tooth and not really maintained anymore. It constantly does a lot of stuff that involves the loader lock which is what is getting stuck... I went and grabbed the openSSL code but I haven't found a nice simple example of how to use it with async callbacks like windows/ioFTPD uses yet... If anyone knows of one, drop a link o_dog: What kind of things are you seeing with TCL sockets? Is the behavior different in v7.1 from say 6.8? Also, what are you using [resolve list] for? It should make walking directory trees really easy for rescanning Since it handles merged directories it's kinda cool that it solves a lot of edge cases and thus is really useful, but zipscripts dealing with a single regular dir (which is the goal since nobody currently handles anything else) probably don't get any real benefits. Another useful trick is dealing with broken links in the sorted dirs since they would show up now and are easy to spot. o_dog: Why wouldn't the waitobject be required now? Even if the file transfer speed was server maintained wouldn't a count of outstanding files, race leader, etc all require locking?