View Single Post
Old 06-03-2008, 02:18 PM  
Too much time...
Join Date: May 2005
Posts: 1,194
Default Changelog

v6.6.0 Release Notes:

1) Files in \system:
   Changed : ioFTPD.[exe,pdb] - Version
   Changed : ioFTPD.ini - summary of changes by section...
    [Locations] : Cache_Files (deleted)
    [File]      : MessageCache_Size (comments changed)
    [Events]    : OnVirtualSearch

2) Files in \doc:
   Changed : itcl.txt
   Changed : Cookies.txt

3) Files in \source: 
   Added   : ioNxSearch.itcl [Only for users using nxTools]
   Changed : Some headers in include dir needed for UserFiles.

4) Files in text\ftp:
   Deleted : UserInfo
   Added   : UserInfo.[Header, Sections, Footer]

5) Delete the entire \text\telnet directory as it is no longer needed.

6) Delete the entire \cache directory as it is no longer used.

*** New Features:

7) New ioFTPD.ini option (OnVirtualSearch under [Events]).  This event
   provides support for the new TOTALLY virtual directory ("/Search") which
   can be used by scripts to support dynamic search queries which return the
   results as a real directory listing!  *** READ THAT AGAIN! ***

   In order to activate the dynamic /Search directory you must have a real
   /Search directory (preferably a subdir under / and not a mountpoint) and
   have defined the OnVirtualServer event.  If you do not define the event
   then the /Search directory just displays the real directory contents.

   If the event is defined then the indicated script is called whenever a
   directory listing requesting contents from the /Search dir.  The argument
   to the script is any filename/glob pattern provided.  This is true
   regardless of which list command (LIST, STAT, MLSD, NLST) initiated the
   listing and works for any local listing (pwd=/Search and something like
   "LIST foo"), or a targetted list such as "list -al /Search/foo" in which
   case the "/Search/" portion of the argument is automatically stripped off.

   As a special case a symbolic link that points to /Search/ will strip the
   /Search/ off and perform a search on the remaining text!  Thus you can
   setup things like /Top10 -> /Search/;Top10; (use site chattr +l since this
   is an invalid filename) and dynamically create the list of top 10
   downloaded directorys.  Or perhaps a Latest link which will on the fly
   list the last 20 directories created.  This should be wonderfully useful!

   NOTE: Many FTP clients cache the results of directory listings to avoid
         having to request them each time you enter the directory.  This
         causes 2 problems.

         1) Attempting to follow links /Search/Top10 followed by
            /Search/Latest will probably show you the Top10 results until
            you hit refresh to download a new listing.

         2) FTP Clients are often not smart enough to realize that a manually
            entered "list -al /..." probably doesn't refer to the current
            directory and shouldn't be cached as that directory's listing...
            Just hit refresh to get the real listing.

   The script can return 2 types of lines:
      N<text to show up a local directory>
      L<text to show up as a linked directory>|<absolute-path-to-target-dir>
   N lines are really just for informational purposes and are shown as a
   local directory with a current timestamp and any attempt to cwd into
   one will always fail.  L lines are shown as a symbolic link with the
   timestamp/permissions/size of the target directory which must exist or 
   the line isn't displayed.  If you cwd into the name returned it will act
   just like a symbolic link and take you to the linked directory. It'
   important to note that there are very few limitations on the names
   returned so except for "|", NULLs, and CR/LF everything else is valid.
   A simple case insensitive search through the buffer of lines starting
   with L looking for the text of the CWD command (after "/Search/" is
   removed from the front if present) is done until a match is found and
   then the target dir is used from that point on.  Thus it's possible you
   could return things like "1) Match", or even invalid names like "1;foo",
   "1*foo", or "1/foo".  The last is particularly useful because it allows
   you to return a fully qualified pathname for both the name (normally not
   allowed but OK with some FTP clients) AND the target directory so when
   viewed by most FTP clients you will see things like /dir/0510/foo instead
   of just foo in the listing.   It may be necessary to use the new itcl
   function [user ClientType] below to tailor output to different clients...

   The first time a user does a search the script is always called.  Thus
   "list", "list -al", "stat -l", etc will all call the script with no
   arguments which should be an indication to return some N style lines
   explaining what to do or possibly some top-10, latest, etc links.  Once
   the script returns a result it will be cached internally and the script
   will only be called when arguments to the listing function are provided.
   This allows you to refresh the directory and/or return to it later and
   still see your results.

   I have provided an example script that uses nxTools as the underlying
   search engine.  It should be simple enough for other scripters to write
   their own for other dupe/search engines.  If you use nxTools and want
   to try this feature out copy ioNxSearch.itcl from the /source directory
   to the /scripts directory and set
     OnVirtualSearch = TCL ..\scripts\ioNxSearch.itcl

8) New FTP command (CLNT <ftp-client-name-and-version>).  This command is
   also advertised in the FEAT response.  FTP clients that see this in the
   FEATure list often issue this command to register with the server the
   name and version of the FTP client being used.

9) New iTCL command ([user ClientType]).  Returns whatever text followed the
   CLNT command if issued by the client, or -1 if not provided.

10) New FTP command (XCRC filename;start;end).  This is used by some FTP
    clients to confirm that files transfered correctly and/or that a remote
    file matches a local file without transfering it.  My implementation has
    a couple of tricks up it's sleeve.  Normally the computation of the CRC32
    value is done on the fly while a file is uploaded if the ioFTPD.ini
    Compute_CRC setting is set to true (it is by default) and never done
    for downloaded files.  After the first XCRC command the server assumes
    that you will be requesting this information for all transfered files
    so it automatically starts computing the CRC on the fly for both up and
    downloaded files all the time to avoid having to read the entire file

    XCRC is also a bit tricky with respect to the last uploaded file.  In
    this case the first XCRC for the file will return the cached CRC32 value
    for the file BEFORE any OnUpload events were run which means means that
    it might not reflect the current file on disk.  This is useful because
    zipscripts may add/delete files (like site .nfos) immediately upon upload
    and this would cause the FTP client to think it didn't transfer correctly.
    This only applies to the last upload file and only the first time XCRC is
    called for that file so a second call immediately after upload will
    re-compute the value based on the file on disk just like the command will
    do for any other file.

11) Modified site command (site uinfo <username> [totals])  Previously this
    command simply looked up the indicated user and displayed the UserInfo
    file with the user's info loaded.  The problem was dealing with sections.
    Using the %[IF] cookie I supported up to like 5 sections but figured
    supporting all 25 by default was a whole lot of processing for 24 unused
    sections in simple site configurations.  I suggested users just copy,
    paste, and modify more sections info the file if they used more than 5.
    That really was sort of painful for novice users because the syntax for
    %[IF] sucks and making a change to the format meant editing a LOT of
    lines.  Therefore I've split the UserInfo file into 3 parts now (Header,
    Section, Footer) with the middle Section piece being called once for each
    defined section.  In that file you can refer to the simply named
    $CreditSection, $StatsSection, and $Section cookies and they will refer to
    the section to display information for instead of the section associated
    with the user's current VFS path.  This makes the file MUCH cleaner and
    easier to maintain.  The Footer is also special now in that I've added
    functionality to total up all statistics across all the sections into
    section 0.  Thus you can use the AllUp, DayUp, etc of section 0 in the
    footer and it will be the TOTAL bytes/file/time uploaded...  If you
    specify the optional "totals" argument after the username it will not
    call the Section file for each section, but will still total all the
    sections together so you can present summary infomation in the Footer if
    you want.  This is kind of useful if you have 25 sections but don't care
    about seeing any of that for a particular call.

    NOTE: Sections are looked up based upon their STAT section number. Thus
          while it is usually true that $CreditSection == $StatsSection don't 
          assume it.  $Section is the stat section name, ratio should use
          $CreditSection to get the ratio, but the actual credits are
          controlled by whether shared credits are being used which can be
          looked up via %[sharedcredits].  For more info see [Sections] in

12) Added REST STREAM to FEAT response to formalize support for the REST
   command that is already available and commonly used.

13) Added TVFS to FEAT response which confirms "/" as a directory separator.

14) Partially implemented the MLSD (machine parsable directory listings), but
    FlashFXP MLSD improperly converts UNIX.owner and to all
    lowercase which will cause all sorts of problems if you refer to %o in
    custom commands, etc.  Since so many people use FlashFXP here I am not
    advertising support for the command in the FEAT response because FlashFXP
    notices it and will use it by default for all listings.  I have not
    implemented the trivial MLST and OPTS commands that go with MLSD and are
    part of the standard because they aren't used much but will do so when
    ready to use this.

15) The ".ioFTPD.cwd" file, if present, is now displayed before the
    ".ioFTPD.message" file when you cwd into a directory.  This file can
    contain cookies to support things like nxtools, but probably should not
    be generated by zipscripts which should continue to use the
    .ioFTPD.message file.

*** Functionality changes:

16) Redid the internal message cookie caching logic.  Previously this would
    parse a file for cookies, save the parsed internal representation into
    the /cache directory and then read it back in from there each time it
    was needed again.  Now the server just caches the files in memory and
    returns pointers to cached copies.  This should be much faster.  With
    the v6.5 change of not parsing cookies in .ioFTPD.message files this
    effectively means that the server won't be reading message files over
    and over again.

*** Bug Fixes:

17) All old userfile field names are now back to being all lowercase in the
    userfiles to support older scripts.

18) It should REALLY supports 25 sections now :)
Yil is offline   Reply With Quote