Code:
v7.7.3 Release Notes:
1) Files in \System:
Changed : ioFTPD.[exe,pdb] - Version 7.7.3.0
Changed : ioFTPD.ini - summary of changes by section...
[FTP_SITE_Permissions] : ciphers = M
[Ftp] : Show_HostMask_Error = True
2) Changed the default configuration for 'Show_HostMask_Error' in the .ini
file to True, and explicitly stated the Cipher command permissions.
*** Bug Fixes
3) Fixed a bug in the internal resolver that was improperly resolving paths
involving NTFS junctions/symlinked directories when NTFS_Reparse_Method
was either SHARED or SYMLINK.
4) Fixed two bugs when trying to delete a NTFS junction/symlink via the file
DELE command when NTFS_Reparse_Method was set to SYMLINK. The first one
didn't account for the fact that SYMLINK mode should work on directories
that are shown as symlinks, and the second didn't remove the NTFS junction
or symlink before attempting to delete the directory so it would only
delete empty dirs.
5) Fixed a bug where files created or deleted from a directory didn't mark
the cached parent directory as stale which meant that the parent wouldn't
show the size of the subdir correctly. This bug was masked by the fact
that most zipscripts touched or modified the directory in some way and
that forced an update.
6) Fixed a bug where unkillable zombie connections could be created if a data
connection was arranged but the connection had not been established and the
control connection was closed via a kick/kill or the client closed it.
What was particularly annoying about these zombie connections is that
you couldn't get rid of them until the FTP was restarted.
NOTE: There are still 2 known ways to create zombies.
a) An idle control connection where the user machine bluescreens, looses
power, or has a network interruption. In this case TCP/IP on the client
cannot inform the server that the client closed the connection. These
clients can be kick/killed at anytime, and TCP KEEPALIVES could be
enabled on the machine to test the connection every few hours if this
ever becomes an issue. These are not a problem.
b) TCL scripts that never return are not currently handled. EXEC scripts
have for a while checked to make sure they aren't zombies, but TCL
scripts can create an unkillable zombie. There is an interface to let
TCL check status after a certain number of commands or after a timeout
has expired but I'm not using it because it won't handle all situations
and this hasn't been a big problem.