ioFTPD v6.6.1 BETA Released

[exitwin98]

another serious problem. I tested ioFTPD for a whole day, It happened twice that i could NOT login the ftp because the process of ioFTPD took up very high percentage of the CPU. So I had to terminate the process of ioFTPD. Now I get back to use version6.4.3, version 6.5 not tested yet.

thank you so much for your prompt reply.

[Yil]

New version:
ioFTPD-v6.6.1.zip

v6.6.1 Release Notes:

1) Files in \system:
   Changed : ioFTPD.[exe,pdb] - Version 6.6.1.0
   Changed : ioFTPD.ini - summary of changes by section...
    [FTP] : Show_HostMask_Error


*** New Features:

2) New ioFTPD.ini option (Show_HostMask_Error under [FTP]).  Previously when
   a user tries to login but doesn't match any of the hostmasks for the
   account they received a generic "Invalid Password" error message.  I
   believe this is the safest response because the server isn't susceptible
   to leaking usernames.  However, by popular demand, and for the sanity of
   admins who have users who can't figure out why they can't login, you can
   now enable this option and the user will see:
     "Your IP/hostname is not authorized"


*** Functionality changes:

3) The test for deleted and expired accounts is now performed after the
   check for valid hostmasks.  Thus a user trying to login to an account
   must match the hostmask before they can see they've been marked for
   deletion or that the account has expired.


*** Bug Fixes:

4) Site purge <user> would incorrectly return a command successful reply
   if the specified user was not marked for deletion or hadn't expired.  It
   didn't do anything before, but now it returns an error code and says:
     "User not marked for deletion or account hasn't expired"

5) CWD was always trying to initiate a virtual search instead of only
   on directories which were symbolic links to /Search/*.  Since it would
   just use the cached result when not under /Search the script wasn't being
   called, but the OnVirtualSearch event in the config file was being looked
   up each time and this can be avoided now.

6) Site swho <users to match> would cause a crash if a user was connected to
   the server but hadn't logged in yet.

[hennie1nl]

crc error in ioftpd.exe when unpacking...

[Yil]

hennie1nl: Try downloading it again. I didn't get any errors when I tested the zip on the server.

[exitwin98]

"site who" doesn't show the transmitting rate correctly.
I have limited the transmitting rate for every user to 100k/s, and the actual rate is 100k/s indeed. But the value of transmitting rate told by "site who" is between 700k/s and 800k/s.

[Yil]

Just a quick update: For 2 weeks or so starting Monday I'll be offline. So continue to post any issues you have but don't expect a quick response

[Flow]

I have like this;

/-
|---- DIR1-------A
|-----DIR1-------B
|-----DIR2
|-----DIR3
|-----DIR4

When uploading somethin to DIR1-B, the timestamp within root of DIR1 is not change, since thare is a new folder within it (B). Wow, how ugly explaination, the best i can think of rigt now, sorry, i hope you understand the issue.

[rolan]

this version can works in the windows 2008?

[Yil]

I'm back...

rolan: I haven't personally tested it with 2008, but other people have reported that it worked under 2008 betas when they tried it so I think you should be fine.

Flow: I'm not sure exactly what you mean, but that is the correct behavior for most filesystems. The Dir1 timestamp in your example will only be updated when the actual contents of Dir1 are changed such as through the creation/deletion of a file or subdirectory. Modifications to existing subdirs won't change the timestamp of the directory.

[Flow]

Hmmm....you understood me correctly wow

But still .... i guess is a wish maybe since when entering root dir of ftp server and use the "sort" by date to show whare is latest created is at does not work in this term. If it is correct way then is fine.

[Yil]

Flow: that behavior is correct and indeed common to all filesystems I'm aware of for performance/scaling reasons. Taken to the extreme if every file modification anywhere was propagated up to the root directory it would immediately become a point of contention which would affect system performance dramatically.

On the other hand, this is an FTP and not a general purpose filesystem. I've toyed with schemes to track the total size of a directory (the whole directory tree) and stuff like that but it would be better off as a feature on a newly designed server...

However, I hinted at a potential solution to what you want when I wrote the comments for v6.6! Just write a custom /Search module! You can extract the latest entries to the dupelog, or search backwards for directory creation events in the ioFTPD.log file and return them as a response to /search/[latest-20] query or something that can be setup by creating a symbolic link using a name like [Latest] or something...

The dynamic virtual directory feature is really pretty powerful and I'm hoping some script writers really find creative uses for it.

[noelek]

Hi Yil, please read pm. I sent to you 2x crashlogs.

[rolan]

hi,when i upload a sample file(.avi .mkv etc) to sample folder, it will random produce any crash(show 426 connect closed) in a day, but i can't get that crash.log file, how can i get it to send to u?
i use the lastest version:ioftpd BETA v6.6.1 and ioiNiNJA BETA 0.6.1.1

[Yil]

Heya rolan. Is ioFTPD itself crashing and exiting? A 426 connect close error for the passive connection isn't a crash unless the control connection and the server itself also die. 426's can happen for a variety of network related reasons...

[rolan]

ioFTPD itself working, and can login, but can't "list -al", "stat -l" can list out, but can't fxp,download,upload, it show 426 connect closed.
its network question?
thank you reply!