[Yil]

List of user requests as well as numerous ideas of mine.

1) Change the way credits work to support a global credit system like glftpd: [DONE: Just use Default.User to specify default ratios/credits, and use the new [Section] field <share credit #> to force credit sharing]

2) Redo the directory structure of the releases. Make everything a subdirectory of c:\ioFTPD and not 2 levels deep. Ditch the startup link/batch file since window's links suck and use a real process to start ioFTPD and the GUI instead. [DONE]

3) Make ioFTPD runnable as a fully aware service process with a service installer. [DONE]

4) Make crc32 file calculation configurable. If Calculate_File_CRCs is True then calculate the entire file CRC for an uploaded file, but only IF there is a registered event. If False then don't bother and just pass 0 to any external script. [DONE, calculate is the default]

5) Provide a callable itcl function to compute the crc of any file or portion of a file. [DONE]

6) itcl zip support (Update: this is looking more likely but with limited functionality, just enough for most zipscript operations)

7) user db library module (not likely by me).

8) Support for shared user files. I favor the modify user file via itcl/script option instead of an entirely separate module so I think this is the way to go though it probably needs a new event such as the pre-password validation event that would allow you to create/modify the user account to be tested. Would even support 1 time passwords if you wanted. (later)

8) unicode support - utf8? (ouch, lots of attempts to support unicode all over, but not sure I'd trust the code compiled with unicode right now since I don't think any of it has ever been tested)

9) a new GUI with a cool tray icon showing status (need one of these, but not sure when - I'm thinking one in C# with the VS2005 GUI builder might not be so bad...)

10) Stealth ftp server for non-recognized IPs. [DONE]

11) New itcl feature to resolve the VFS path from a real path. (UPDATE: not sure since it's best to resolve paths via the VFS)

12) site adduser should create new user in group of creator unless it's the default server group in which case it reverts to NoGroup (1). [DONE - read 6.1 changelog since it's more complex]

13) [deleted because functionality already exists via gadduser ]

14) CPSV [DONE]

15) Change the scheduler to support events evaluated in localtime or UTC time to better handle end of month scheduling. Also enable support for handling missed events just in the case of the server being down during a month end event which wouldn't reset the stats or a daily dir not getting created. I'm thinking something for the hour field like 4 -> localtime, =4 -> UTC, and +4 -> run if missed and of course +=4 for a UTC missed run. Thinking of a simple timestamped file in the /system directory, if it's missing nothing happens, if there it runs events since that time. Probably have to deal with passing/faking the time somehow though to scripts...

16) Rewrite the way ioFTPD handles TCL files. Currently it interprets TCL files as text. It should instead create a TCL object containing the text of the TCL file and interpret it as an object. This will allow TCL to byte compile the code. The key here is that only needs to happen once if the object is kept around thus making the 2nd call much faster since the file is already parsed/compiled. Of course the stored compiled object can only be re-used as long as the file it represents hasn't been updated. All told though this should be a nice performance improvement especially for larger files like ioSFV.

17) Option to enable IP/hosts (and users if feasible) to be immune from auto-banning.

18) Option to force a minimum IP host mask length. i.e. x.y.*.* would be 2 and x.y.z.* would be 3.

19) There are currently 2 unused integers in the .ioFTPD structure for each file. I was thinking the first should be a count of the number of times the file was downloaded and when a new list option was used the group field would be replaced with the download count. This is what glftpd does for up to the first 99 downloads since groups id's for the actual file in the filesystem are all multiples of a hundred thus leaving the last 2 digits for this purpose. I originally thought of using the link count of the file but Flash,etc all ignore this field in the directory listing as useless so no way to view it except on the raw listing.

20) An an option for minimum free space on a drive necessary to accept a file upload or a new directory. Goal is to make sure you don't completely fill up the disk.

21) Add an option for the minimum free space on a drive necessary for a new directory IF a merged/raided directory is available. This gets you limited spanning ability. By only working on directories it won't split a release up though you'll have to set the threshold greater than the largest expected release + the min free space of the previous option. This also implies that some physical parent directories may need to be created on the other drive.

22) When resolving the directory to upload a file in care should be taken to search all merged paths to find the existing directory. I believe it currently just uses the last entry listed in the .vfs file but this would split the release if it worked, but more than likely it would fail since the physical directory often doesn't exist on the last drive.

23) Enable pre/post event processing for site and site change commands. This would allow overriding of even the builtin commands. I think the simplest way to do this is to use the already existing FTP PRE/POST events but instead of just looking for core FTP commands it will look up site commands as "SITE-command" and as a special case "SITE-CHANGE-command".

24) Add a new event USERFILE_CHANGE to the POST events that is called whenever the userfile is changed. Perhaps a GROUPFILE_CHANGE as well. The ability to catch site and site change commands doesn't help when scripts modify the userfile directly and thus this is necessary to catch those situations. The command could be given the before and after userfiles, but the way the code works the actual changes made are unknown so it would have to be deduced by the script. This is the key to replication and hence a shared userfile !