FlashFXP Forums ioFTPD v6.5.0 BETA released
 Tickets Search Today's Posts Mark Forums Read

 05-24-2008, 04:02 AM #2 Yil Too much time... FlashFXP Beta TesterioFTPD Administrator   Join Date: May 2005 Posts: 1,194 Code: v6.5.0 Release Notes: *** INCOMPATIBILITY WARNING *** This version of ioFTPD introduces a large number of changes to the UserFile structure in memory and the associated UserFile on disk. I have kept the existing shared memory interfaces byte compatible with previous releases, but added new function identifiers (DC_NEW_USERFILE_*) so newer shared memory applications can access the new fields in the UserFiles. This should mean all existing 3rd party compiled .exe files will still work although they will be limited to using 10 sections. ioGUI2 using shared memory, for instance, appears to be working fine, however I still believe it is better to use the .itcl interface of ioGUI2 (and this is the default) since you can connect remotely that way and you get accurate idle times, etc. WARNING: nxShareDB as a user module manipulates UserFiles directly and as such doesn't stand a chance of working and will likely corrupt your user database. Wait for a new version before upgrading to v6.5 if you use this! TCL based scripts usually use the iTCL commands to open/close/lock/etc UserFiles and the ascii2bin and bin2ascii functions to parse them. Since these functions have been updated I don't believe TCL based scripts should have any issues, but I've been wrong before so report any problems. *** SCRIPT CONFLICTS *** There are a number of new built-in site commands. You can choose to use the new ioFTPD versions by removing the your reference to the 3rd party script under FTP_Custom_Commands, or you can use the new "^" prefix to disable the ioFTPD internal version and continue using the external script. You should pick one or the other as running both is probably a bad idea! See the detailed ChangeLog below for details on the ^ prefix. * site who is now a built-in command. This conflicts with the venerable SiteWho.exe addon, nxTool's site who, ioB's site who, and a bunch of similar scripts. See below for configuration options. * site open/close are now built-in commands. This conflicts with nxTool's open/close. See below for configuration options. * site purge/readd are now built-in commands, and site deluser has changed. This conflicts with ioDELUSER. --------- *** File Modifications: 1) Files in \system: Changed: ioFTPD.[exe,pdb] - Version 6.5.0.0 Changed: tcl85t.[dll,pdb] - Version 8.5.2.2 Changed: ioFTPD.ini - summary of changes by section... [Devices] : *telnet reference removed* [Services] : *telnet reference removed* [Sections] : *comments changed* [FTP_Custom_Commands] : *comments changed* [FTP_SITE_Permissions] : open, close, purge, re-add, who, swho : *alphabetical now* [Change_Permissions] : Expires, LimitPerIp, MaxDownloads, MaxUploads, Opaque, showjobs (deleted) [FTP] : Close_Exempt, Who_Hidden_Users, Who_Hidden_Paths_# [Events] : *comments changed* OnClosedLogin, OnClosedKick, OnDeletedLogin, OnDeletedKick, OnExpiredLogin, OnExpiredKick, OnUnknownLogin, OnTelnetLogIn (deleted) [Telnet_Service] : *deleted* [Telnet] : *deleted* [Telnet_Binaries] : *deleted* [Telnet_Binary_Permissions] : *deleted* [Telnet_Command_Permissions] : *deleted* 2) Replace the lib\ directory entirely with the new tcl v8.5 version which should have 2 new directories tlc8 and tcl8.5. 3) Files in \text\ftp: Added : ClientInfo.[Common, List] Changed : ClientInfo.[Download, Idle, Login, Upload] Changed : ClientList.[Download, Header, Idle, Login, Upload] Added : ClientList.[Footer, List] Added : DeletedKick Added : ExpiredKick Deleted : Free Added : ServerClosed Added : ServerStatus Changed : UserInfo Changed : UserList.[Body, Header] Added : UserList.Footer Added : Who.[Download, Footer, Header, Idle, List, Upload] 4) Files in \etc: Changed : Hosts.Rules 5) Files in \doc: Changed : itcl.txt Changed : cookies.txt 6) Replace the entire source\include directory with the new one. *** New Features: 7) The number of sections the server supports has been raised from 10 to 25. The [Sections] documentation in ioFTPD.ini has been updated with much more detailed examples. 8) New ioFTPD.ini [Events] feature. You can now use "!" to indicate that a particular event should display a message file to the user much like you can do inside FTP_Custom_Commands, etc. The [Events] documentation has changed to reflect this feature. 9) New [FTP_Custom_Commands] feature ("^"). You can now prefix events with "^" which turns on the override option which means that the server should not try to execute any built-in site command of the same name as the trigger. The [FTP_Custom_Commands] documentation changed. 10) New [FTP_Pre-Command_Events] and [FTP_Post-Command_Events] feature. You can now define pre/post events on site commands. This includes built-in commands! Just prefix the name of the site command with '@' in FTP_Pre-Command_Events or FTP_Post-Command_Events. The order for site command processing now looks like this. 1) Validate access to command via FTP_SITE_Permissions. 2) Process @cmd events in FTP_Pre-Command_Events and return failure on the first error encountered. 3) Process matching events from FTP_Custom_Commands, until one returns an error in which case the command is considered to have failed so return failure. 4) Run the internal site command of the same name if one exists and no event included the ^ prefix. If the internal site command is executed and returns an error then return failure. 5) Process all @cmd events in FTP_Post-Command_Events ignoring failures. 11) Site rename, delete, addip, deleteip, userinfo, kick and all site change commands have been modified to prevent pure group admins (G and not 1M flagged users) from performing any actions on 1M flagged users who happen to be in their group. 12) New type of cookie that's not only super, it's downright amazing! :) The new amazing %[IF] super cookie supports simple conditional logic! The first form: %[IF(cookie)(EQUAL)(string)(true-action)(false-action)] Here is any text, mangled cookie and/or mangled supercookie whose textual output is compared to and if a match then the mangled is evaluated else the mangled , if present, is evaluated. Mangled in this context means a simple character replacement where the following changes are made to the string before processing. {{'s are replace with {, }}'s with }, {}'s with []'s, << with <, >> with >, and <>'s with ()'s. This is necessary because the cookie parser is pretty dumb and making it stateful isn't worth the hassle it would take. Example: %[IF(%{$VFS})(EQUAL)()()(| VFS : %-60{$VFS} |)] Read this as if %[$VFS] evaluates to then don't print anything, else pretty print a formatted VFS field. The second form: %[IF(super-cookie)(THEN)(true-action)(false-action)] Here is a syntax mangled super cookie which evaluates to true if no error in parsing takes place and at least one character would have been printed, else it's false. Example: %[IF(%{sectionname<0>})(THEN)(| DAYUP: %7.0{dayup<0>} |)] Read this as if a name can be found for section 0 (which means it has an entry in ioFTPD.ini) then print the number of megabytes the user uploaded into section 0 today. NOTE: with appropriate formatting you CAN enclose an %[IF] inside the true/false clause of another %[IF] although it looks ugly... See the UserInfo file for examples of this. 13) New message super cookie (%[RemoveBlankLine]). Because of the way the message parser works a line that contains only a %[IF] super cookie that evaluates to nothing will result in a prefixed (i.e. "200-") empty line. If this isn't desired use this super cookie at the end of the line and it will erase the prefix and return character thus eliminating the line. 14) Updated site command (site shutdown [cancel|now|]). If you issue "site shutdown now" or "site shutdown 0" the server responds as before and immediately begins terminating all connections and exits. If, however, you don't specify any arguments (assumes default of 300), or you specify a number, the server will consider this the length, in seconds, of the grace period to allow for the orderly logging out of connected users. After the grace period expires the server will revert to terminating all connections and then exiting. During the shutdown grace period non-M flagged users will be prevented from logging in and will be informed that the server is shutting down as the reason why. All currently logged in non-M flagged users, except the user who initiated the shutdown command if you allow non-M users access to the command, will be logged out as soon as they try to enter a command after their current transfer, if any, is completed. Once the user who initiated the shutdown is the only user left online the server will exit even if the grace period hasn't expired. If the server doesn't immediately exit because it is waiting for someone to log off you can use the "site shutdown cancel" command to stop the shutdown sequence. 15) New message super cookie (%[ShutdownGrace]). This returns the number of seconds until the server shuts down or 0 if it isn't shutting down. 16) New site command (site close [-kick|-new] ). This command is used to prevent non-exempt users (see Close_Exempt below) from logging into the server, and optionally to force already connected non-exempt users to be logged out. If neither -kick or -new is specified then site close will default to gracefully logging users off as soon as they try to enter a command after their current transfer, if any, is completed. The optional argument can be used to provide a reason for the closure. Before logging a user off gracefully the server will call the "OnClosedKick" event which, if used in the default configuration below, will display the time since the server closed along with the reason if one was specified. If the -new argument is supplied then the server will only prevent logins from new non-exempt users and will not logoff existing users. The -kick argument will immediately close the connections and terminate any transfers of non-exempt users and is therefore not considered graceful. Non-exempt users trying to login to a closed server will see the results of the "OnClosedLogin" event, as well as having the login denied with the following error: "Server is closed". 17) New site command (site open). This command returns to normal a previously closed server. 18) New ioFTPD.ini option (Close_Exempt under [FTP]). This is a permission style expression which should match users who are allowed to login to a closed server. Default is 1M flagged users, although adding "-sitebot" (if you use one) probably makes sense. 19) New ioFTPD.ini settings (close, open under [FTP_SITE_Permissions]). Both close and open are set to "1M", but this setting should match whoever is listed in Close_Exempt since anyone who closes a server who isn't exempt will get kicked off and be unable to open it again. 20) New message cookie (%[$ClosedOn]). Returns the time() the server was closed or 0 to indicate the server is open. 21) New message cookie (%[$ClosedMsg]). Returns the argument to site close if one was provided. Only valid if$ClosedOn != 0. 22) New ioFTPD.ini event (OnClosedKick, OnClosedLogin under [Events]). OnClosedKick is run when a non-exempt user is about to be logged off gracefully because the server has been closed. OnClosedLogin is run when a non-exempt user tries to login to a closed server. The suggested settings are: OnClosedKick = !..\text\ftp\ServerClosed OnClosedLogin = !..\text\ftp\ServerClosed The ServerClosed file just prints the time since the close command and optionally the reason for the server being closed. "Server closed
 05-24-2008, 05:08 AM #3 pointBreak Junior Member   Join Date: Nov 2004 Posts: 18 Looks great, thanks Yil
 05-24-2008, 06:11 AM #4 JoC Member FlashFXP Registered UserioFTPD Foundation User   Join Date: Feb 2004 Posts: 76 Impressive list of changes, great work Yil.
 05-24-2008, 03:38 PM #5 Mave Member FlashFXP Registered UserioFTPD Foundation User   Join Date: Jul 2005 Posts: 43 Holy moly! I guess when you came to earth you had a vision Great work!!!
 05-25-2008, 02:54 AM #6 Yil Too much time... FlashFXP Beta TesterioFTPD Administrator   Join Date: May 2005 Posts: 1,194 .ioFTPD.message I've been poking around scripts and noticed that nxTools can be setup to do some really cool things with the %[execute] cookie. I expect things like oneline messages, latest dirs, etc to go in the Welcome file, but others like listing the requests or section rules probably went into various .ioFTPD.message files. Unfortunately I just broke that because I've disallowed cookie processing in those files. I was only thinking of zipscripts, at the time, and the potential problems they pose writing to .ioFTPD.message. Because of those problems I won't be re-enabling that feature. I also thought the parsing and caching of hundreds or thousands of .diz/.nfo/sample/etc extracts that get stuffed into .ioFTPD.message files was stupid which happens because of the cookie parsing. I expect I'll return the functionality by automatically showing a new filename like .ioFTPD.cwd which will have cookie parsing enabled and be shown whenever someone enters the directory. Right before the text of ioFTPD.message is displayed. If anyone knows of any situation where this won't be sufficient speak up now As I mentioned in the v6.5 discussion thread, I'm looking at ways to eliminate or at least reduce configuration of the server and the duplication of data. For example I'd like to make site free support in sitebots not need to know about physical paths/sections. I'll probably add a new site command to provide all this dynamically since the server clearly knows where everything is. Once I figure out what disk spanning fits in hehe... For those of you who use nxTools with a sitebot do you use Alcobot with the nxTools module for your sitebot? ioNinja looks like it has some nxTools supports and it calls and loads some Alcobot libraries but doesn't use the module. Just sort of taking a poll, what configuration are people using it in and why?
 05-25-2008, 12:36 PM #7 o_dog Senior Member   Join Date: May 2007 Posts: 692 what do you mean by site bots knowing about physical paths and sections? i mean that part of the sitebot has nothing whatsoever to do with ioftpd. changing cases in userfile on wkup etc might cause problems with some older scripts, and i really see no point to it. mistake? __________________ ioNiNJA Last edited by o_dog; 05-25-2008 at 12:57 PM.
 05-25-2008, 04:20 PM #8 Yil Too much time... FlashFXP Beta TesterioFTPD Administrator   Join Date: May 2005 Posts: 1,194 If the sitebot config file has stuff like section GAMES is d:\Games then it needs to know real paths. Clearly it needs to know this somehow so it can do things like site free, but what I'm looking to do is have the sitebot get this information from the server so if you change the VFS file you don't have to also change the sitebot... I expect a few new iTCL functions and perhaps a new site command should make all this really easy to do. Sitebots will likely always have to know most section names since output is often redirected different places based on section, but I don't think there is any reason for it to know about real paths. On the other hand, the "default" configuration could just enumerate the section names as well and only if you want to do something like suppress messages or redirect them would you need to configure it manually. Hmm, good point on the case changes in the userfile. It's simple enough to go back, but let's see what breaks. If it's TCL scripts parsing the output of bin2ascii they will be trivial to change, and if it's other scripts reading the userfiles directly then I want to discourage that anyway. The shared memory interface never sees any of this so it won't care. Things like nxShareDB won't have local userfiles and going to something like SQLite for the user db in the future would break direct userfile access anyway. Best to query the server for the info. It's simple enough to go back to all lowercase for the older fields though so if something important can't be fixed easily I'll get a new version out... Last edited by Yil; 05-25-2008 at 04:36 PM.
 05-25-2008, 11:35 PM #9 o_dog Senior Member   Join Date: May 2007 Posts: 692 the sitebot does not get any information through the ftpd. It uses shared memory. The real paths for example could be used when determining where a release resides for nuking purpose from irc. It also converts paths to pwd and sections. I wouldn't waste my time on this if i were you. The point beeing that not many of the scripts around are under active development, if it breaks stuff it wont get fixed. __________________ ioNiNJA
 05-27-2008, 12:19 AM #10 jeza Senior Member ioFTPD Scripter     Join Date: May 2003 Posts: 530 what do u mean with "sitebot get this information from the server ". my scripts also use shared memory to get info from ftpd. do u plan something with itcl, so bot can directly get info from ftpd (free, stats, delete user,...)? in this case all .exe scripts (sitewho and other stuff) would not be needed anymore - and this is cool
 05-27-2008, 05:31 AM #11 pion Senior Member   Join Date: Feb 2006 Posts: 138 I know I've asked about this before, but would it be possible to add the option for downoading a file in use? E.G getting uploaded. And keep sending the data stream until the upload of the file is complete.
 05-27-2008, 11:32 PM #13 jeza Senior Member ioFTPD Scripter     Join Date: May 2003 Posts: 530 it would be the best if u write some .dll or .exe with ioFTPD, that we could use with sitebots. it will be always updated, because u will develop it with ioFTPD. if u plan to do it, it should give info about WHO, FREE, STATS/section, CREDITS/section, get settings from CONFIG and also posible to manage users (CHANGE, DELETE, ADDIP, DELIP,...) maybe if u have some free time, u can write it
05-28-2008, 02:21 AM   #14
Flow
Senior Member
FlashFXP Beta Tester
ioFTPD Foundation User

Join Date: Dec 2001
Posts: 306

*phew*, just upgraded. This one was big

I dont get howto disable buildin sitewho (since i use nxTools). Cant be be turn off ? Is listed double now.

^who = TCL ..\scripts\nxTools\nxUtilities.tcl WHO
^close = TCL ..\scripts\nxTools\nxClose.tcl CLOSE
^open = TCL ..\scripts\nxTools\nxClose.tcl OPEN

Quote:
 9) New [FTP_Custom_Commands] feature ("^"). You can now prefix events with "^" which turns on the override option which means that the server should not try to execute any built-in site command of the same name as the trigger. The [FTP_Custom_Commands] documentation changed.

05-28-2008, 06:37 AM   #15
pion
Senior Member

Join Date: Feb 2006
Posts: 138

Quote:
 pion: don't think so. I know glftpd supports that, but it has to do some extra checks to make sure the upload is still making progress, etc. Seems like a lot of work. On the other hand, if the problem is you are fxping files that are still being sent and thus arriving incomplete, it would make sense to go the other direction and prohibit downloading of files being uploaded altogether. That would make far more sense especially since I can see zipscripts adding or subtracting .nfo files from a zip which could completely corrupt a file that had been partially transmitted before the change and the rest after...
glftpd supports this, yes. But VideoLan player also support reading a file beiing written to.. which is also open source.. dunno how easy it would be to use the logic from there?

The problem is that the file is unavailible when it's uploaded, any media file with a complete header can be viewed which is handy for multiple purposes.