FlashFXP Forums - View Single Post

Yil · 04-24-2008, 02:57 PM

Flow: I've got a few goals for 6.5 but the first is I'd like to eliminate scripts accessing ioFTPD configuration files. This means I'll provide a TCL extension and a shared memory solution for access to VFS configuration data, etc. I think I'll also extend the interface a little to support resolving merged directories so scripts can handle that better in the future when disk spanning gets introduced.

The second, and much more serious problem, is I'm going to add fields to the userfile. I made sure to add them to the end of the userfile on purpose to minimize breakage in any 3rd party executable scripts requesting the userfile over the data exchange interface. Compiled scripts that just read existing information from the userfile may work depending on how they allocate buffer space, but those that try to update/store data in userfiles will probably cause problems... TCL scripts usually use the ascii2bin and bin2ascii and thus should work without any changes.

In particular, here are the new fields I'm playing with. Chime in now if you've got a suggestion as these are not permanent yet!

Code:

CreatorUid   - uid of user who created account
CreatorName  - name of creating user in case deleted
CreatedOn    - time account created
LogonCount   - number of successful logins
LogonTime    - time of last successful login
MaxUploads   - number of simultaneous uploads, -1 = unlimited, 0 = denied
MaxDownloads - number of simultaneous downloads, -1 = unlimited, 0 = denied
Opaque       - 256 byte opaque character field for use by scripts,
               sitebot, etc.  Format is "tag" "value" pairs suitable for
               input to TCL.

The created and logon stuff are just useful to have. The Max Up/Down will eliminate the need for external dual leech scripts and allow you to give someone 1 or 2 download slots but 5-10 logins which they can use to mass upload. The Opaque field I view would be used by large scripts and specifically sitebots to stash info like online nicks, etc. I've toyed with the idea of a last created dir, last upload/download time, and official nick support by giving it a whole field. Let me know what you think, or if I've missed something.

FTPServerTools: You have one of the few actively maintained executable addons, so I'm particularly interested in what you need done if you couldn't access configuration files, and what userfile changes mean to you.

nxShareDb: will require a few simple changes to store/retrieve the new fields but should be trivial to do and of course a recompile. The ascii2userfile function already provides default values for userfiles who don't have the new fields so you don't need to worry about any of that.

I'm also thinking of adding support for handling bad and/or abandoned symlinks. Site wipe scripts, automatic space making scripts like WarChive, etc just go ahead and delete directories and the zipscript never gets a chance to cleanup sorted symlinks, incomplete tags, etc. So I'm toying with 2 solutions. Both ideas use the feature that allows you to store extra data in the .ioFTPD file alongside special permissions and symbolic link information like ioSFV uses. I'd make VFS ID 2 and/or 3 contain a list of symbolic links pointing to this dir which the zipscript and the built-in site symlink command can update. Then everyone knows where to look to cleanup those links on deletion or perhaps the server just does it automatically! The other idea is to stash the name of a script that wishes to run when the dir gets deleted/moved/etc. This is a bit more flexible and powerful, and perhaps a special case of a built-in script can handle manually created symlinks. Or perhaps I just do both... call the script first, then automatically cleanup whatever symlinks are still left in the list of known symlinks.

Neither of these cleanup after manually deleted/moved directories outside the FTP, so a regular symlink cleaner would probably still be needed, but this should seriously resolve a lot of wasted disk activity running around looking for links as that could be run on demand or every few days.

04-24-2008, 02:57 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	Flow: I've got a few goals for 6.5 but the first is I'd like to eliminate scripts accessing ioFTPD configuration files. This means I'll provide a TCL extension and a shared memory solution for access to VFS configuration data, etc. I think I'll also extend the interface a little to support resolving merged directories so scripts can handle that better in the future when disk spanning gets introduced. The second, and much more serious problem, is I'm going to add fields to the userfile. I made sure to add them to the end of the userfile on purpose to minimize breakage in any 3rd party executable scripts requesting the userfile over the data exchange interface. Compiled scripts that just read existing information from the userfile may work depending on how they allocate buffer space, but those that try to update/store data in userfiles will probably cause problems... TCL scripts usually use the ascii2bin and bin2ascii and thus should work without any changes. In particular, here are the new fields I'm playing with. Chime in now if you've got a suggestion as these are not permanent yet! Code: CreatorUid - uid of user who created account CreatorName - name of creating user in case deleted CreatedOn - time account created LogonCount - number of successful logins LogonTime - time of last successful login MaxUploads - number of simultaneous uploads, -1 = unlimited, 0 = denied MaxDownloads - number of simultaneous downloads, -1 = unlimited, 0 = denied Opaque - 256 byte opaque character field for use by scripts, sitebot, etc. Format is "tag" "value" pairs suitable for input to TCL. The created and logon stuff are just useful to have. The Max Up/Down will eliminate the need for external dual leech scripts and allow you to give someone 1 or 2 download slots but 5-10 logins which they can use to mass upload. The Opaque field I view would be used by large scripts and specifically sitebots to stash info like online nicks, etc. I've toyed with the idea of a last created dir, last upload/download time, and official nick support by giving it a whole field. Let me know what you think, or if I've missed something. FTPServerTools: You have one of the few actively maintained executable addons, so I'm particularly interested in what you need done if you couldn't access configuration files, and what userfile changes mean to you. nxShareDb: will require a few simple changes to store/retrieve the new fields but should be trivial to do and of course a recompile. The ascii2userfile function already provides default values for userfiles who don't have the new fields so you don't need to worry about any of that. I'm also thinking of adding support for handling bad and/or abandoned symlinks. Site wipe scripts, automatic space making scripts like WarChive, etc just go ahead and delete directories and the zipscript never gets a chance to cleanup sorted symlinks, incomplete tags, etc. So I'm toying with 2 solutions. Both ideas use the feature that allows you to store extra data in the .ioFTPD file alongside special permissions and symbolic link information like ioSFV uses. I'd make VFS ID 2 and/or 3 contain a list of symbolic links pointing to this dir which the zipscript and the built-in site symlink command can update. Then everyone knows where to look to cleanup those links on deletion or perhaps the server just does it automatically! The other idea is to stash the name of a script that wishes to run when the dir gets deleted/moved/etc. This is a bit more flexible and powerful, and perhaps a special case of a built-in script can handle manually created symlinks. Or perhaps I just do both... call the script first, then automatically cleanup whatever symlinks are still left in the list of known symlinks. Neither of these cleanup after manually deleted/moved directories outside the FTP, so a regular symlink cleaner would probably still be needed, but this should seriously resolve a lot of wasted disk activity running around looking for links as that could be run on demand or every few days.