ioFTPD v6.0 is HERE !

[tuff]

Originally Posted by pion

afaik it's not possible to do without loading a module for it, meaning it's not possible to use a script for it..? Feel free to correct me if I'm wrong

eh? your logic is flawed :P if you couldnt script something without a module then there would be very little scripts for io :P

what exactly are you wanting to do? if its simply sync the userbase with an sqldb then a scheduled script simply using [resolve uid/gid $uid/$gid] etc and the extended itcl userfile commands is more than enough to do that, using a dll would also allow the script to put the info into the sqldb, dunno why you would need a module

[Yil]

In theory there is no need for a user module. You could simply have an application connect to the server and issue commands to create/delete/modify user accounts... I'll bet you that 99% of the functionality sought by a user module could be achieved with a new event run at password validation if used in combination with existing events. The new event could create/modify/etc the account and perhaps take over validating the password. If it had to fetch the user info from somewhere, create the account, etc isn't that what the user module would be doing anyway? That's probably the way I'd go... Definitely would still require some sort of background sync routine though in case the central authority was off-line or something...

[isteana]

hope next version will full support unicode(make 100% handling it) for non english

[tuff]

imo Yil should be spending time fixing the stability issues reported, and not wasting time adding features atm

[ESP]

I can't get Idle_Exempt to work.

What exactly is the format? Here's what I have:
Idle_Exempt = 1M!

Tried rehashing and restarting and it still doesn't work. Anybody else having this problem?

[tuff]

you didnt read the changelog that well? Idle_Exempt = -user =group !*

[peep]

Yli: Sadly I didn't have the time to post while still at home but I've encountered that io also crashes when not running it as service, so it's not due to running as service. the crash.log had the same exception but different addresses (compared with the previous crashlog when running io as service).
This baffles me, hasn't anyone else encountered the same kind of crashes that I am encountering? I didn't have time to test it any more before running off.
Won't be home before tuesday next week but perhaps you'll stumble across what might be causing the crashes before that, fingers crossed

Happy easter (to all of you who celebrate it),
peep

[Yil]

I redid the whole source tree last night so I can distribute it in an easy to compile form that includes the tcl/php includes and libraries in the next release. I fixed Idle_Ignore, the directory rename problem, and the permission setting issue with drive root dirs, and a shutdown issue with the timer thread.

I also spent a lot of time the last couple days trying to track down the instability in shutting down. I'm reasonably convinced there is something wrong with the windows socket code. Whether it's the use of it in ioFTPD or the library itself is unknown right now though. If I comment out the closesocket() and WSAcleanup() calls everything is fine. If I leave them in it's dieing very often in one of those two functions. When it somehow makes it past those calls it crashes in the exit code in the windows library itself. There is clearly some form of memory corruption going on (the debug version reports that as the error). I'm going to keep looking into this but tools like Purify aren't finding anything which leads me to believe ioFTPD itself isn't corrupting memory but the actual windows socket library is doing the corrupting. For the record the unhandled exceptions starting with 0x7 are where the various windows dll's are loaded. I'm guessing that if memory corruption is actually taking place via the windows socket library in some cases that's also the cause of the runtime stability issue as users log in/out/etc. Interestingly enough pasv/active connections don't seem to have issues. I've transfered tens of thousands files to get it to crash and couldn't, but try forcing some connections closed during shutdown (or maybe during an idle timeout?) and all hell breaks loose...

[LordM]

If I understand you correctly, then it could be, that it has to do with the windows dlls. And that would somehow explain, why I get a lot of crashes on Win 2k3 Server but it runs nearly stable on WinXP. Just my guess, that there are different dlls in it.

[Yil]

New version! Let me know how this works...

ioFTPD-v6.0.2.zip

v6.0.2 Release Notes:

1) Script compatility update! REMOVE THE "lib\tcl8.4\encoding" DIRECTORY.
   Looks like tcl might return strings in utf-8 format when configured
   correctly.  We could probably get around this using
   "fconfigure $handle -encoding identity" when trying to push stuff
   like .nfo files to the user but if TCL is able to find the default
   encoding for the windows system codepages it starts internally keeping
   everything in utf-8.  To play it safe and prevent other things
   from getting converted the only choice is to delete the directory which
   we clearly didn't need before...

2) Fixed an issue with the timer thread during shutdown.

3) The PHP function io_group_list_seek is now available.

4) Fixed Idle_Ignore. It was broken for all but single word commands.

5) You can now chmod/chown/etc mounted drive letters.  Since the code
   refused to access raw drives for permission info in some cases this
   may have been causing other issues.

6) Rename directory fixed.  It considered any rename a full move before
   and thus would copy all the files over if even in some drive.

7) Non-perfect fix applied to chmod/chown -R and move directory that
   prints status information every 10 seconds or so.  This should prevent
   FTP clients from disconnecting you on long operations and give you
   a happy feeling that the server is still there.

8) Changed around a lot of the shutdown logic.  Probably not really stable
   but you're exiting anyway...

9) For scripters added version info to the end of the executable.  The
   end of the file is now
     [version-string] NULL [length-of-version-string] NULL
   i.e. 6-0-2r\0\06\0

[Flow]

Yil, /me love you long time never forget

ioftpd started @ 06/04/2007 15:11:51, running for 0d 3h 25m 27s

Berry Nice !

[tuff]

http://www.iotools.co.uk/forum/viewtopic.php?p=162#162

an updated site version for 6.0.2+

[pion]

Originally Posted by Yil

In theory there is no need for a user module. You could simply have an application connect to the server and issue commands to create/delete/modify user accounts... I'll bet you that 99% of the functionality sought by a user module could be achieved with a new event run at password validation if used in combination with existing events. The new event could create/modify/etc the account and perhaps take over validating the password. If it had to fetch the user info from somewhere, create the account, etc isn't that what the user module would be doing anyway? That's probably the way I'd go... Definitely would still require some sort of background sync routine though in case the central authority was off-line or something...

io wouldn't be aware of any outside changes then?

Main problem as I see it would be to sync stats and credits between multiple io servers.. also renuser I can imagine would cause trouble, which io got the correct one to sync..

[Yil]

You can't have it both ways pion. Either a user module would need to have a constantly updating local copy of the shared state (which is doable today) or it would need to consult a 3rd party like a database or master to get the info at the time of the request (not currently possible for logins). Since it's possible to keep ioftpd sync'd with the existing site admin commands the only functionality I see missing is the non-sync'd approached which is what I presume you were looking for. The idea of a pre-login event where you could issue ftp commands to create/rename/modify/validate users would appear to solve that.

The problem of which server to sync to is left to the reader. I've worked with distributed systems for a very long time and there is no single right answer. Whatever method would have been used by a module could be used by the event. You could even run an existing module standalone and then use the ioFTPD events to simply communicate with it that way.

[isteana]

it crashed again with 6.0.2

Unhandled exception 3221225477 at address 0x7c9624b2 (0x00000000)
0x00000000 0x706ea002
Unhandled exception 3221225477 at address 0x0042d7b6 (0x00000000)
0x00000000 0x9d47ec94