PDA

View Full Version : ioFTPD v7.0.3 Released


Yil
07-15-2009, 10:56 PM
Highlights:

* Integrated support for "real" virtual filesystems into the core resolving logic. You can now fake out entire directory trees anywhere in the filesystem through TCL scripts.

* VFS Admins are now more powerful.

* 3 New/Modified site commands

* 10 New/Modified .ini features

* 8 New/Modified cookies

* 2 new TCL vars and 10 New/Modified iTCL commands.

* Fixed the "426 Connection closed: Overlapped I/O operation is in progress." annoying error.

* Fixed several serious memory leaks causing server stability issues in some configurations.

* Potentially fixed the "lockup" bug.

* EXEC event anti-timeout feature.

Latest Version:
ioFTPD-v7.0.3.zip (http://home.comcast.net/~yil/ioFTPD-v7.0.3.zip)

Source:
ioFTPD-v7.0.0-src.zip (http://home.comcast.net/~yil/ioFTPD-v7.0.0-src.zip)

Yil
07-15-2009, 11:06 PM
v7.0.0 Release Notes:

1) Files in \System:
Changed : ioFTPD.[exe,pdb] - Version 7.0.0.0.
Changed : tcl85t.[dll,pdb] - Version 8.5.2.7 (tcl version 8.5.7)
Deleted : php4ts.dll, php.ini
Changed : dbghelp.dll, symsrv.dll - version 6.11.1.404
Changed : ioFTPD.ini - summary of changes by section...
[Network] : Added Ignore_Hostmask_Idents
[Virtual_Dirs] : *New section*, after [VFS] section.
[VFS_PreLoad] : *New section*, after [Virtual_Dirs] section
[FTP_SITE_Permissions] : Added myinfo = !A *
[Ftp] : Added LeechName
[Threads] : Added Keep_Alive_Text, Create_Tcl_Interpreters,
Debug_Tcl_Interpreters, Log_Exiting_Worker_Threads
[Events] : Modified comments. (2 new events in doc\Events.txt)
[Themes] : *Replace entire section*
[HTTP_Service] : *deleted section*
[Http] : *deleted section*
[Http_Permissions] : *deleted section*

2) Directories in \lib:
Replace entire tcl8 directory.
Replace entire tcl8.5 directory (* see note below *).
Added : reg1.2 directory
Added : dde1.3 directory
NOTE (*): if you have installed o-dog's nxTools temp fix you will have
a \lib\tcl8.5\reg1.1 directory that I think should no longer
be needed as I've included reg1.2, but you WILL need to
keep the lib\tcl8.5\twapi directory.

3) Files in \text\ftp: (nearly everything changed, consider replacing entire
dir and just saving your Welcome file customizations.
A list of unchanged files is listed below)
Added : MyInfo.[Header, Section, Totals, Footer]
Changed : [AllDn, AllUp, WkDn, WkUp, MonthDn, MonthUp, DayDn, DayUp].Header
[AllDn, AllUp, WkDn, WkUp, MonthDn, MonthUp, DayDn, DayUp].Body
[AllDn, AllUp, WkDn, WkUp, MonthDn, MonthUp, DayDn, DayUp].Footer
ClientInfo.[Common, Download, Idle, List, Login, Upload]
ClientList.[Header, Download, Idle, List, Login, Upload, Footer]
DeletedKick
ExpiredKick
GroupInfo.[Body, Header]
GroupList.[Body, Header]
TransferComplete
UserInfo.[Header, Section, Totals, Footer]
UserList.[Header, Body, Footer]
Who.[Header, Download, Idle, List, Upload, Footer]
Unchanged: Color, [GroupInfo, GroupList].Footer, LogIn, LogOut,
SecureRequired, ServerClosed, UserList.Footer, Welcome

4) Delete the entire \text\http and \test\http2 directories.

5) Files in \doc:
Added : Events.txt
Changed : Cookies.txt, itcl.txt


6) Files in \source:
Replace entire \include directory. ***** TODO *****
Changed : nxSearch.itcl


*** Important security related changes:

7) VFS Admins ('V' flagged users) are now treated the same as Masters ('M'
flagged users) with regards to VFS "private" directories [chattr 0].
Previously both were exempt from normal file and directory access checks,
however private directories used to required VFS Admins to have explicit
access before showing up in directory listings (just like all old non-M
flagged users), and they were unable to modify the access list of those
directories. This created a problem because VFS Admins can create, edit,
and delete "private" directories, but if they forget to include themselves
on the access list they become unable to modify it any further or even to
see it!

NOTE: By default the ioFTPD.ini file grants 'V' flagged users access to
just 2 site commands not available to normal '1' flagged SiteOps:
"site chown" to change file/directory ownership, and "site chattr"
which allows direct symbolic link manipulation and "private"
directory access control. It is unlikely that a user trusted as a
VFS admin wouldn't also be a SiteOp but it isn't implied anywhere
in the code. In fact all user account manipulation tests in the
server only look for the '1' and 'M' flags. It should also be
noted that by default the .ini file doesn't even allow a pure VFS
Admin access to a lot of normal SiteOp commands so I would expect
that VFS Admins are also SiteOps (i.e. 1V users).

NOTE: The 'V' flag used to be required to create and edit symbolic links
and this was most likely the reason some users/SiteOps would have
this flag, but now people can use the "site symlink" command so
there is no reason for SiteOps to be VFS Admins unless you expect
them to have unlimited ability to manipulate files/directories
just as M flagged users would be able to.
Consider using: "site change .V flags -V" to remove the V flag
from everyone and then re-apply it to only those you want.

NOTE: This change along with the suggested granting of VFS Admins access
to the "site rehash" and the "site shutdown" commands should remove
the need for any Master accounts with remote access which is an
important consideration.

8) VFS Admins are now subject to write (w) directory permission checks.
This should solve the problem of VFS Admins being able to "complete"
smaller sized .zip, .sfv, etc files and succeeding because they could
ignore the fact that the zipscript marked them as read-only after
verification and/or modification. This is also a safety feature to prevent
accidentally deleting stuff. Since VFS Admins can just use site chmod to
grant themselves write permissions it won't prevent them from deleting
whatever they want, just make it less likely to goof up. The use of
"site wipe" commands, however, will limit the impact of this change, but
let me know what problems creep up and I can turn it into a configuration
option if needed. It's possible this should also apply to M flagged
accounts as well in the future.

9) Given the increased abilities of VFS Admin accounts a regular SiteOp can
no longer create VFS Admins by giving a user (or themselves) the 'V' flag
unless they are themselves also a VFS Admin or a Master.

10) Group directory/file permissions have changed. Previously if you were
not the owner of a directory/file your primary group was compared to the
group associated with the item and if it matched then group permissions
controlled your access to the item. Now the entire list of groups you
are a member of are searched for a match to the item. This would appear
to allow more flexibility.

11) The way the server interprets directory modes (rwx) has changed. In a
traditional UNIX environment a directory with read permissions (r) means
a matching user could list the contents of the directory. A directory
with execute permissions (x) means the user could enter or recurse
through the directory. There are scenarios in standard UNIX environments
where unlistable directories make sense as a way to hide directory trees
but in the context of ioFTPD there isn't any need for that since the FTP
supports private directories [chattr 0] which are far more powerful.

Previously ioFTPD required read & execute permissions to list the
contents of a directory, but only required read to traverse through a
directory. This was a long standing bug since that should be controlled
by the execute bit instead. Thus for all intents and purposes the
execute bit offered no additional functionality. I have now formalized
this "bug", so read permissions on a directory is all that is required
to traverse or list a directory. I doubt anyone will even notice this
change. On the other hand, this now frees up the execute bit for futher
use and given that there are actually 3 execute bits (user/group/other)
and that the execute bit is already overloaded on standard UNIX to
identify set uid/gid (s) and/or sticky (t) attributes this leaves a
variety of combinations that can be used to convey information to the
user using standard (rwxst) attributes in directory listings. The
execute bit never meant anything with regards to file execute permissions
in ioFTPD since the server doesn't allow for executing processes through
the server so we don't loose any functionality that way either.

I anticipate using the execute bits for new future features such as the
automatic space creation algorithm for full disks. If let's say the user
execute bit is unset then the directory can be removed automatically to
make room. Thus the default of permanent or temporary for new
directories can be set using the Default_Directory_Attributes argument in
the vfs and site chmod can be used to toggle it easily as well as through
any script addons that may be loaded. By using "x" or "-" in the listing
itself admins can easily see what is permanent and what could be deleted
automatically just by looking at a normal directory listing. I don't
believe using the write bit (w) is a good fit for this because zipscripts
or users may choose to write protect "completed" directories but intend
for them to be automatically freed later on.

12) New login error message. If your host/IP section of a hostmask entry
matches but the ident response does not you will now receive a "Your user
ident response did not match" error message provided Show_HostMask_Error
is set to True in the .ini file. This should help user's diagnose their
own invalid configurations easier. If Show_HostMask_Error is False then
all anyone will ever see is the generic "Invalid Password" errors.



*** Feature Losses:

13) COMPLETELY REMOVED HTTP support and the old PHP 4 libraries from the
server. It's an FTP server not some crazy hybrid that nobody uses,
is broken in several ways, and I'm not interested in supporting.



*** Compatibility Issues:

14) Modified the TCL [mountpoints] command to return the name of the
mountfile as the first list item which is then followed with the
parsed output of the file as before. This allows scripts to call
[mountpoints] without any arguments to figure out what the currently
active mountfile is.



*** New Features:

15) ioFTPD now creates a shared mutex using the same name as the ioFTPD
window name which is defined in the .ini under "WindowName" in the
[Threads] section. If this mutex fails to be acquired during startup
then another ioFTPD server using the same WindowName is already running
and this is not allowed so the server logs the error and pops up a dialog
box if not running as a service. This should prevent the common problem
of starting the server twice which is really annoying if 3rd party
scripts using shared memory end up communicating with the wrong instance.

16) Rewritten EXEC event module now automatically switches to immediate
(non-buffered) output after 30 seconds of an event not completing. This
should help keep addons which didn't explicitely request non-buffered
output but do print something at least every 2 minutes from having
clients time out.

17) New ioFTPD.ini option (Keep_Alive_Text under [Threads]). The new EXEC
event module can help with events take a long to complete and fail to
provide some sort of output every minute or so. As a workaround you can
now have the server output a single line to keep the client happy if
nothing has been sent to the user within the last 90 seconds. If not
defined then this feature is disabled. The default text output is the
default prefix for the event, but if not defined or is empty this text
will be used.
Keep_Alive_Text = 200-

18) New transfer reply messages. Before:
150 Opening BINARY mode data connection for <filename>.
After:
150 Opening BINARY mode data connection for <filename> (15000000 bytes)
using SSL/TLS.
It is also colorized: BINARY, ASCII, <filename>, bytes, and SSL/TLS can
be independently colored in the theme.

19) New site command (site myinfo). This produces the same output as site
uinfo (by default) but displays your own account information. Thus this
command is made available to all users since they can only see themselves
with it.

20) You can now use site readd * to raadd all deleted/expired users.

21) New user matching specifier (:). You can now search for users based
upon their ratio. The format is ":" followed by the section number or
blank for the default section 0 then ">", "<", or "=" for the operation
you want and then the ratio to compare against:
:[section]>ratio
:[section]<ratio
:[section]=ratio
This makes some things really easy such as finding all leech users:
site users :=0
You can also use this specifier as an argument to site change so you
can modify account settings based upon a user's ratio in a section
like say change all ratio 3 users to ratio 4, etc.

22) New ioFTPD.ini option (LeechName under [FTP]). You can now control the
text string returned by %[ratio()] for users with a 0 ratio. By default
it is "Leech" if not defined... I hear "Unlimited" is popular :)

23) New option to the LIST/STAT command (-L). If you specify -L the server
will now show you the size of the target of the symlink rather than the
symlink itself! [Hint: L is for link].

24) New option to the LIST/STAT command (-Z). If you specify -Z the server
will replace the groupname of the directory with a mangled version of
the PRIVATE (chattr 0) setting for the directory. In order for the
output to be parsable by FTP clients spaces are replaced with '/'s
so the group field is processed correctly. [Hint: -Z is the SELinux
argument to ls to print security information]

25) New ioFTPD.ini section ([VFS_PreLoad]). By default the server now
preloads/caches all the directories used as mountpoints in the default
VFS file indicated by [Locations]/Default_Vfs in the .ini file during
startup. If you want additional directories loaded include lines here
with the form:
<depth-to-descend> = <starting-VFS-path>
A depth of 1 just means the directory itself, 2 would be the dir and all
its immediate subdirs, etc.

If you wish to resolve all paths defined here using a VFS file other
than [Locations]/Default_Vfs then define a line like "VFS = <vfs-file>".

During server startup only the server will create a number of temporary
threads to parallelize the loading of the various mountpoints or
directory trees. You can see the time it takes to do this by looking
at the new ioFTPD.log entries during startup:
PRELOAD: "begin" "..\etc\default.vfs"
PRELOAD: "points=15" "..\etc\default.vfs"
PRELOAD: "count=143" "..\etc\default.vfs"
Begin is just so you get a timestamp in the logfile at the start, points
is the number of mountpoints in the indicated VFS file that were loaded,
and count is mountpoints plus the number of requested directories.

If you wish the server to finish preloading all these directories before
accepting connections, define the line "DELAY = TRUE". This is useful
if you mount lots of networked folders with large fanouts and it takes
minutes for the slowest to load and thus clients would time out the
initial directory listings and have to reconnect. The only drawback
is you'll have to start ioGUI later as the server won't take connections
as soon as before.

26) New scheduler option (&PreLoad). This allows you to schedule the forced
re-caching of the directories identified for pre-loading and the default
mountpoints using any schedule if you want.

27) New ioFTPD.ini section ([Virtual_Dirs]). This section lets you define
entirely virtual directory trees anywhere in the filesystem. The format
for entries is as follows:
</path> = TCL <script>
Path must start with a / and cannot be the root dir. A number of custom
iTCL commands have been added to return the new directory listing or
to resolve/redirect the request and thus only TCL events are supported
at this time. You could however use TCL to call an executable and then
process the results in TCL yourself however.

The script is called with 3 double quoted arguments:
"<path>" "<glob>" "<old-glob>"
<Path> is either the current working directory or the requested path via
the CWD/CDUP commands. <Glob> is the non-path part of the argument to a
listing command (LIST/STAT), and <old-glob> is the glob last used for this
directory if it is currently cached in the server. <Old-glob> is actually
very useful, because if you were to CWD to /search and issue a
"LIST -al foo" and then reload the listing at a later time most FTP
clients will just issue a "LIST -al" which would likely return a
different answer than "LIST -al foo".

A couple of implementation details that are important to understand.
Each virtual directory defined in [Virtual_Dirs] is treated completely
separately with the last valid directory listing from each being "cached"
in the server. The cache is used primarily to resolve returned
references without having to call the script again. Directory change
events CWD and CDUP resolve the path completely before calling the script
and glob will always be empty. Listing commands with an abiguous path
specifier such as "LIST -al /search/foo/bar" are treated as a path
"/search/foo/" and a glob "bar" whereas "LIST -al /search/foo/bar/" would
be called with the full path "/search/foo/bar/" and no glob. Listing
commands do not fully resolve the <path> argument to the script once it
has been determined that a virtual directory mountpoint is involved.
Thus from "LIST -al /search/foo/../bar/" would have a path of
"/search/foo/../bar/" and the script will have to do the rest of the
resolving.

CWD/CDUP to a virtual directory always tries to load the directory
listing if it isn't currently cached. If it succeeds the next listing
operation without a glob will simply use the returned results. However
any additional listing operations will call the script to refresh the
listing.

If you attempt to CWD to a directory that isn't valid in the current
cached copy of the parent's virtual directory listing the script is
still called. This is to support on demand creation of virtual dirs.
However, any other attempt at referencing a missing entry will return
an error because virtual directory updates are disabled for any commands
other than user initiated directory change and list commands.

In general virtual directories may refer to other virtual directories
in the same virtual tree (parents, subdirs, etc), however they should
not refer to other defined virtual directories even though you can
manually fake such entries. This is because during the processing
of a virtual dir event no other virtual script calls can be made and
thus the only information that may be available would be whatever
happens to be currently cached and even that usage is unsupported.

If the script returns 0 it means the directory path is invalid. If it
returns 1 the path is valid and whatever entries have been faked out
should be considered the directory listing. However, if a single entry
is returned with the name "||RESOLVED||" then the result returned should
not be considered a directory listing but rather the returned link
should be used as if the resolver had returned it instead. This allows
scripts to actively resolve any fake out entries however they want.
There is one other special case. If you use "||RESOLVED||" to return
the directory's parent (i.e. /search/foo/bar resolves the script to
/search/foo) this is interpreted as an intent to reset/clear the saved
<old-glob> parameter while silently ignoring the request. This allows
you to fake out an entry to reset any active searches, etc.

You may find it useful to return completely fake directories or files
that are used to provided "feedback" to the user but are not intended
to ever be used. In that case I suggest using the <, >, and | characters
somewhere in the filename because the resolver will reject them
immediately as an invalid name. This is important because if you fake
out a directory and the user tries to access it the script will be called
and that's unnecessary overhead. Also, avoid using []'s in faked out
filenames because the script will attempt to determine if a directory
of that name exists before assuming it's a glob pattern. Thus two
calls to the script may be needed in some cases.

Virtual directories are special cased to be part of the *_VIRTUAL_*
section and will show up under that name in directory listings, etc.
It will however use the DEFAULT sections ratio/credits/etc when
displayed.

See the ioVirtual itcl command below for details on how to add entries
to the virtual directory listing during Virtual_Dir script callbacks.

28) New event (OnFtpLogOut). This event is run when a logged in user is
disconnected or logs out of the server.

29) New ioFTPD.ini event (OnFailedDir under [Events]). This event is called
when a MKD event fails at the filesystem level and the directory wasn't
actually created. Arguments are "Real path" "Virtual path" dwError

30) Added a column to site users to display the numeric ratio for the default
section (0). If your current path is in a section other than the default
it will append a '/' and then the ratio for that section as well. The
column header indicates the section number being used.

31) TransferComplete now displays the section number (if other than 0 the
default) when displaying the section name.

32) Added "folder.jpg" and "AlbumArtSmall.jpg" to the list of files (was just
"thumbs.db" and "desktop.ini") that should be ignored when determining if
a directory is empty and can be deleted. Reports indicate that WMP can
create these 2 files with the hidden and/or system attribute set which
prevents ioFTPD from displaying and manipulating them and this means an
empty looking directory to the user could not be deleted.

33) When moving directories the list of hidden/system files that are ignored
when determining if a directory is empty are also now copied.

34) Modified how the server handles an Ident_Timeout of 0 in the .ini file.
Previously it would send the ident request to the client but immediately
timeout and continue. Now the server won't even bother to send the
request.

35) New ioFTPD.ini feature (Ignore_Hostmask_Idents under [Network]). If
enabled the server will ignore any ident specified in a user's hostmask
and only match the hostname/IP portion. This feature is especially
useful if you use the new Ident_Timeout==0 feature described below.
The reason this is a separate option is because BNC's can forward ident
information and you may disable ident requests but still wish to match
forwarded info against the hostmasks.

36) The server no longer generates "LOOKUP:" log messages for dynamic
hostname lookups during login.

37) New supercookie (%[MSG(#)]). This super cookie allows the saving of
arbitrary text in one of five (1-5) locations and the triggering of
events when set. Whenever the server would normally inform the user
about things like server shutdown, site closing, etc the message cookies
are also examined and the associated message file (text/ftp/MSG#) is
processed. In the simplest case it could just print the contents of the
%[MSG(#)] cookie, but it can do far more if needed. This functionality
should cleanly support things like informing the user of new mail
messages, quota alerts, etc. The real benefit is to the server since
it will no longer be required to process lots of %[IF] statements or
call external processes just to see if you got new mail after every file
transfer. The other unique feature of %[MSG(#)] cookies is they can be
set in iTCL from a different user/connection which for the first time
allows information passing between clients. This is obviously useful
for things like setting a flag to check for new mail by setting the
recipients msg cookie to a non-empty value.

38) New supercookie option (%[stats(bodyfile)(timeperiod)(type)(section)
(max#)(limitto)(headerfile)(footerfile)]). You can now specify a 7th
and 8th argument to indicate the header/footer file to use to display
the information. This solves a problem with passing section information
to the header file and section/total information to the footer.
Users who did this:
%[include(..\text\ftp\AllUp.Header)]
%[stats(..\text\ftp\Allup.body)(allup)]
%[include(..\text\ftp\AllUp.Footer)]
would have the header and footer using the current section based upon
the user's path and the footer would be unable to indicate the number
of matching users and the total transfer statistics. Now they have
access to the correct info.

39) New supercookie (%[stats2(timeperiod)(type)(section)(max#)(limitto)]).
The %[stats] cookie allows the greatest flexibility because you can
customize the output for everything. If you want to just display stat
output such as the "site stat" command produces then %[stats2] is the
cookie for you since it doesn't require you to specify the formatting
files. Default section is -1 for total across all sections, and
output suppresses zero entries.

40) New ioFTPD.ini option (Log_Exiting_Worker_Threads under [Threads]). If
enabled a one line summary is output to the debug logfile each time a
worker thread exits that includes the count of total, free, blocking, and
initial worker threads. If you enable this option you should have at
least 2 worker threads defined to avoid thrashing the system. This is
primarily for developers.

41) Super cookie %[T(index#)] now accepts an index of 0 which is equivalent
to %[C(0)] which will resets all colors to the default but %[T] cookies
are only evaluated if a theme is currently active. Almost all references
to %[C(0)] in text/ftp/* have been changed to %[T(0)] which should
eliminate the reset escape sequence showing up at the end of lines on FTP
clients that don't know what to do with it.

42) Color themes now support sharing subtheme definitions. Previously each
theme was required to not only provide the main theme definition, but to
also provide a <Theme#>_<SubTheme> entry for every subtheme used. This
quickly becomes messy and hard to maintain. You can now declare in the
main theme definition that if no entry can be found for the subtheme it
should try the lookup again using a different theme id. To make sure
things are updated the new format is incompatible with the old on purpose.
Specify 0 for SubThemeDefault to disable this feature for a theme.
New format:
<ThemeId> = + [<SubThemeDefault> | 0] <ThemeName> <color-or-format> ...

43) New cookie (%[RatioNum(section)]). Displays the ratio as an integer.

44) New cookie (%[$ShareSection]). Display the share section.

45) The %[who(MyCID)] cookie will now return "?" if the referenced connection
ID is known to be a zombie and "+" if another of your logins in addition
to the previous functionality of "*" if the current login else "".

46) The %[stats] cookie now default to totaling stats across all sections
instead of the current path's stats section. This makes it act the same
as the "site stats [alldn|allup|...]" commands which switched to that
behavior in v6.7.0.

47) The %[stats] cookie now acts like the NoZeros flag to "site stats" was
supplied which suppresses 0 entries from being displayed. If people want
the old behavior let me know and I'll create a flag for it, but I don't
see a need for it.


*** Functionality Changes:

48) Newly uploaded files are now internally "locked" until the
OnUploadComplete event has finished. This will prevent clients from
starting to download a file that a zipscript wants to modify such as
when it strips some .nfo's out of it, etc.

49) Modified the text returned when actions are denied for insufficient
permission. Previously filesystem actions rejected because of directory
mode settings (rwx stuff), [VFS] actions in the .ini file such as Rename,
DeleteOwn, Upload, etc, and everything else such as site commands all
returned the generic "Permission denied" error. The first two now
return "Permission denied (directory mode)" and "Permission denied
(config file)" to help users and administrators understand why an action
was denied.

50) If a pre-command event configured in the .ini file returns an error
rather than yes/no and has not produced any output it now prints
"Command Failed. (pre-cmd-event script)" instead of the generic
"Command Failed." This should help catch configuration/script errors.

51) Site chmod/chown -R now include in the periodic update messages the number
of files and directories processed and the number of modifications made
"Still updating... %u dirs, %u files examined: %u modified, %u errors."
And when finished site chmod/chown now indicate the final totals:
"%u dirs examined, %u files examined: %u modifications, %u errors."

52) When using RNFR/RNTO to move a directory across filesystems the periodic
update message when sizing the directory tree to be moved now says:
"Still sizing move... %u dirs, %u files processed, %u access errors."

53) Site change stats command now returns an error if it has trouble parsing
it's arguments.

54) Site change flags command now returns an error if the account was not
modified.

55) The "site size" command on a file now complains that it wants a dir and
the periodic update report now includes access error information
"Still sizing... %u dirs, %u files processed, %u access errors."

56) "Private" directories [chattr 0] are hidden from directory listings by
users without access, however attempts to CWD into them by name or access
files under the path would return a "Permission denied" error which is
technically correct but exposes the existence of the directory/file. It
now returns the generic "No such file or directory" error instead.

57) Changed "CreateProcess failure: %s (error = %u)" message from Error.log
to SystemError.log for EXEC events.

58) Added the following error message for EXEC events to the SystemError.log
file when the server is forced to return from an event that hasn't
finished.
"Abandoned EXE process (pid=%d): %s"

59) Modified the server logging functions to enable log output during
early startup and late shutdown when normal job queuing is unavailable.

60) If the log module has been initialized and an error occurs during
startup the error information is now recorded to Error.log before the
popup window is shown if not running as a service.

61) The following "exported" commands have had their signature/arguments
changed: ioOpenFile(), ioCloseFile(), MountFile_Open(), OpenDirectory(),
Message_Compile, InstallMessageHandler, Service_Stop.




*** iTCL Changes:

62) Updated TCL to version 8.5.7.

63) New iTCL global variable (ioArgs). ioFTPD currently provides the
arguments to a script as a string of ascii text, but does not guaranteed
it to be properly escaped for TCL and thus it requires parsing and some
processing logic to recreate the original meaning when special characters
are used in filenames, etc. ioArgs attempts to preserve the original
items used to create the ascii string and stored them directly into a TCL
internal list object. It therefore requires no processing and can be
converted to an ascii string with proper escaping if required or more
likely just used directly to extract positional arguments via [lindex].
Currently it should properly convert double-quoted elements such as in
the OnUploadComplete event into a single argument but it does this by
processing the string for you. Only the new Virtual_Dir Event stuff uses
the original args without any conversion. If you find it not converting
stuff correctly let me know.

64) New iTCL global variable (ioPrefix). This is set to the default output
prefix for lines printed via iputs.

65) New iTCL command option ([resolve target <path> [<cwd>]]). Using the
optionally supplied current working directory <cwd>, or the user's
actual cwd if available, or finally "/", resolve the supplied VFS path
to an absolute VFS path and return it if "read" permission is valid for
the entire path. Returns "" on permission errors or invalid paths, but
throws an exception if there is no active mountfile or userfile.

66) New iTCL command option ([resolve mount <path>]). Take the supplied
absolute VFS path and return a list of the VFS mountpoint associated
with that path as well as 2 entries for each existing item in the real
filesystem the VFS path can resolves to. The first is the index of the
mountpoint in the VFS mount table which can be used to get the base for
the real path of the VFS mount, and the second is the full real path to
the item itself. No access checks are performed and no links are
evaluated anywhere in the path and thus the directory may resolve here
but not be accessible. Therefore this should only be called on VFS
paths that were resolved via [resolve target].
{ VfsMountPoint [ VfsMountIndex RealPath ] ... }
Returns "" if the VFS path doesn't resolve as a valid VFS path, and
throws an exception on bad arguments.

67) New iTCL command option ([user match <pattern>]). This will return the
uid's of users matching <pattern> which is a user match pattern of
the form: =group, .Flag, username, wildname*?, as well as "!" negation
logic of those types.

68) New iTCL command option ([vfs dir <directory>]). This is both an easier
and a more efficient way to retrieve all the permission/attribute
information for a single real directory at one time. It returns a list
with each element being a list composed of:
{ name uid gid mode chattr0 chattr1 chattr2 chattr3 }
NOTE: the ACTUAL permission for a directory is determined by the first
directory found in a merged mountpoint, and only the first found
file will be visible so when dealing with merged dirs extra
post processing must be done.

69) New iTCL command ([ioTheme ...]).
colors <theme#> : Returns list of theme colors
status : Returns currently active theme #, 0 if no theme
off : Turns theme/color off for user
on <theme#> : Activate theme# for user
get <index#> : Returns color of index# of active theme else 0
subtheme [<name>] : Activate named subtheme. If name ommitted revert to
main theme. Returns:
0 if themes not active or successful switch and
1 if subtheme could not be found and a generic
no-op theme was loaded.

70) New iTCL command ([ioDisk info <path>]). Returns 3 numbers (in bytes):
"<free> <size> <totalFree>"
NOTE: <free> == <totalFree> unless the user the server is running under
has an applied NTFS disk quota.
NOTE: There is currently no way to enumerate all mounted local and
network drives. This is intentional because it is expected that
scripts will examine VFS files directly or refer to a configuration
file as this prevents the server from giving out information
about drives it is not configured to see.

71) New iTCL command ([ioMsg {get|set} <uid> <cid> <msg#> ["msg"]]). This
allows you to set the MSG[1-5] cookies for a specific user connection.
get <uid> <cid> <msg#> : Get message # for the indicated user
with specific connection id.
set <uid> <cid> <msg#> "msg" : Set message # for the indicated user
with specific connection id.
NOTE: It's necessary to specify the connection id <cid> value to allow
updating a particular connection when a user is logged in more
than once and to avoid race conditions with a user logging out
and a different user logging in to the same cid.
NOTE: To clear a message just set it to "".

72) Modified the iTCL [mountpoints] command, see #14 above.

73) New TCL function (ioVirtual [type...]). This function is used to add
entries to a virtual directory - only callable during a Virtual_Dirs
callback event. Returns number of items added or throws an exception.

AddLink <Path> [<Name>]
AddLink is a simple method for adding existing items to the virtual
directory listing. It takes a complete VFS path that must be valid
in the active mounttable, verifies it's existence, and then creates a
symbolic link to that entry using either the last component of the
path or the optionally provided <Name> argument. Timestamps, owner,
permissions, etc are all the same as the referenced item.
AddDir <Size> <ModTime> <AltTime> <User> <Group> <Mode> <Name> <Link>
AddFile <Size> <ModTime> <AltTime> <User> <Group> <Mode> <Name> <Link>
AddDir or AddFile allow you to completely specify fake entries for
the virtual directory with no verification performed at all. In order
to be useful for traversing or manipulating the fake files and folders
the <Link> field must be valid. One possible use for using fake
entries instead of links via AddLink is because you can override the
actual size, date, user, group, etc for the listing. If you specify
specify "" for <Link> it should act like AddSubDir.
AddSubDir <Size> <ModTime> <AltTime> <User> <Group> <Mode> <Name>
AddSubDir <Name>
This specifies another "virtual" subdirectory that will call the
script again if entered/listed. The first form allows you to specify
all the attributes, the 2nd uses the current timestamp, user, etc to
generate a fake directory with the appropriate name.

74) When a iTCL script fails by throwing an uncaught exception it used to
print something like:
--------------------------- ErrorInfo ----------------------------
some info from TCL about the error
------------------------------------------------------------------
but because logfile messages are limited to 512 total bytes this
was sometimes cutting the TCL info and/or the last line of dashes off.
Errors now look like:
--- ErrorInfo ---
some info from TCL about the error
----

75) New ioFTPD.ini option (Create_Tcl_Interpreters under [Threads]). If
enabled worker threads will try to pre-create their TCL interpreters
instead of doing it on demand. This can speed up the response time for
servers with lots of TCL scripts during startup and after rehashes. It
works by having each worker threads randomly check every few seconds to
see if they have their associated TCL interpreter created and if it's
still valid. If they need one and no other worker thread is already
trying to create one then it goes ahead and pre-creates it.

76) New ioFTPD.ini option (Debug_Tcl_Interpreters under [Threads]). If
enabled it logs creation/deletion of interpreters to the Debug logfile.
This is primarily for developers.

77) Fixed an old bug where the TCL interpreter was being created and calling
../scripts/init.itcl before the ioFTPD itcl custom commands were
registered and thus unavailable during interpreter initialization.

78) The iTCL [timer <delay> "command"] function now special cases a delay
of 0 by just adding a new low priority job to ioFTPD's internal
scheduling queue instead of trying to start a timer that will
immediately trigger.

79) Documented the iTCL [VFS flush] command in itcl.txt file which marks a
cached directory item as dirty.



*** Bug Fixes:

80) Fixed a bug in SSL FXP client negotiation routine that resulted in users
getting "426 Connection closed: Overlapped I/O operation is in progress."
messages from the server. It turns out that during the handshake it's
possible to return an empty token at one point and that is a valid
response. Not sure why, but evidently Java's SSL implementation seems
to trigger that case more often so it was most often seen with FXP
between ioFTPD and DrFTP.

81) Fixed a HUGE problem in the recursive action function. It wasn't closing
most of the directories it traversed! On sites that have more
directories than cache slots or sites with rapidly changing directories
this would cause serious memory leaks for "site size", "site chmod -R",
"site chown -R", and directory moves/renames across filesystems as this
does an implicit recursive sizing operation.

82) Fixed a severe problem with inheritable file handles. For some reason
Windows decided that all socket handles should be marked inheritable by
default. This is the opposite behavior of every other type of handle.
This resulted in all child processes (EXEC events) getting a duplicate of
every open socket. If the child processes exited quickly there wasn't
much of a problem, however long running child processes would hold open
references to sockets. In some cases this meant that closing a socket
which should trigger an error wouldn't actually do so because of the
open reference. The error would only be sent after the child process
exited and the reference was implicitly closed. To fix this all sockets
created in the server are now explicitly marked as uninheritable and
are now protected by a creation lock that must also be held during child
process creation to avoid race conditions. The Locking requirement
is also extended to include the explicitely inheritable pipe handle to
avoid passing it to more than one child by accident.

83) Fixed a potentially severe problem with re-use of still active Overlapped
I/O callback structures. The server had a race condition on outputting
data to the control channel. It took a bit of work to eliminate this,
but it's possible that the re-use of the Overlapped structures which
contains private WinSock data might have resulted in the server lockup
bug.

84) Fixed a severe bug where dynamic IP lookups were resulting in worker
threads not being unmarked as blocking after the blocking DNS lookups
completed which could cause excessive thread creation and memory growth.

85) Fixed a bug where the Device\Out_Ports setting in the .ini file was being
ignored. This was caused by a bug in Device_Load() which was freeing
the newly allocated memory holding the parsed input of the Out_Ports
setting instead of the no longer needed old value. Because it always
freed the new memory this didn't leak memory, and since the data was
read only it didn't corrupt anything. However the end result was always
a random output port similar to the Out_Ports=0 option instead of the
specified port(s).

86) Fixed a bug where [FTP_Post-Command_Events] defined for builtin site
commands weren't being run.

87) Fixed a bug with internal site commands trashing the arguments to
[FTP_Post-Command_Events].

88) Fixed a bug in %[include] that was deleting the previous empty newline
and causing doubled line prefixes like "230-230-..."

89) Fixed a bug where the server would crash on startup if the /users or
/groups directories were missing. Now it reports that the associated
module could not be initialized and exits.

90) Totally rewrote the IoMoveDirectory() function. Previously it would
"hide" the destination directory from ioFTPD while the move/copy
operation was in progress which would prevent a race condition on
permissions being applied/updated. However, if the operation couldn't
complete before the server was shutdown it would leave the directory(s)
as NTFS hidden dirs which are inaccessible for security reasons to the
server and would thus require someone to manually change/delete them
from the filesystem outside of the FTP. The new version makes use of
the new semi-locked directory cache feature to lock both the source and
destination dirs and takes care to copy the perms first so that any
interrupted operation is safe and easily recovered.

91) Fixed a bug where the server's idle timeout was incorrectly being
applied to idle exempt users after any data connection was attempted
and after it finished transfering. It was cleared when the next command
was issued but a user who issued a port/pasv operation as part of LISTing
a directory and then sitting there would catch a lot of exempt users if
they didn't have a no-idle feature enabled in their client which upon
the first NOOP would clear the timeout again.

92) Attempting to eliminate the bug where error messages look like:
Unknown error (##)
that can occur on non-English OS installed. Worker threads now use
SetThreadLocale to specify a preference for US English so it can now
specify the default search behavior to the system when calling the
windows error formatting function instead of only allowing US English
responses which appears to fail on non-english configurations.
This should result in string lookups in the following order:
Language neutral
Thread LANGID, based on the thread's locale value (US English now)
User default LANGID, based on the user's default locale value
System default LANGID, based on the system default locale value
US English

93) Fixed a bug where a logfile message that was truncated to 512 bytes
wasn't guaranteed to end in \r\n.

94) Fixed a bug in the "site symlink <target> | <name>". If <target> was a
relative path it would check for the <target>'s existance by resolving
the path using the current working directory instead of using any path
specifiers in <name>. Most of the time <name> doesn't contain path
components so this wasn't a big problem.

95) Fixed the following messages not processing color control commands.
ABOR command successful.
PBSZ is not a supported command.
Bad sequence of commands. (RNTO without a RNFR)
Command not implemented for that parameter. (invalid TYPE)
No such file or directory. (failed/invalid CDUP)
Active transfer in progress, terminate transfer with ABOR before
proceeding.
Already logged in.

96) Fixed incorrect idle times showing up in site who listings.

97) Fixed a bug in the user/group file writing algorithm that would truncate
multiple entries. This would often mean you could only store a limited
number of hostmasks instead of the 25 allowed.

98) Fixed a bug in directory cache logic that could cause invalid lookups.

99) Fixed a bug in IoRemoveDirectory and IoMoveDirectory where the check
for .ioFTPD* filenames was case sensitive and it shouldn't be.

100) Fixed a bug where the parent directory (..) in directory listings wasn't
showing the correct information for merged directories.

101) Fixed a bug with incorrectly looking up directory permission info for
files.

102) Fixed a bug in the implementation of internal timers. The documentation
states that the MS function SetWaitableTimer() cancels the timer if the
thread that called it exits before the timer expires. This means if we
allow any extra worker threads to exit that we are cancelling any timers
they may have set. Since extra worker threads stay around for 2 minutes
to make sure they aren't needed and almost all timers are under 2 minutes
we usually got lucky. The code no longer uses the SetWaitableTimer()
function at all.

103) Fixed a bug in UpdateFileInfo(). When updating the file permissions,
file owner, directory attributes, etc of a directory the server would
also update any faked out directory information in the parent directory
if the No_SubDir_Sizing option was enabled. If No_SubDir_Sizing was not
enabled the information would usually be updated automatically as it
held a fileinfo pointer to the root entry of the newly updated directory.
However it is possible for the updated directory to be flushed from the
cache, or for the root entry to be realloc'd as part of a chattr
modification and this would freeze any further updates as the parent
would loose track of the current root entry pointer. Thus it is now
necessary to mark the modified subdir entry in the parent as dirty and
to mark the parent as needing to update itself.

104) Fixed a race condition in client register/unregister.

105) Fixed a lot of small bugs with freeing allocated resources during
shutdown to help highlight any memory leaks.

106) Fixed a small memory leak in "site chmod" where a directory path wasn't
being freed.

107) Fixed a bug where an invalid socket handle could be closed if the PORT
command was given an improperly formatted port specifier.

108) Fixed a bug where certificate contexts in Secure_Load_Credentials() were
not being properly released.

109) Fixed a bug during shutdown where credential handles for the service
weren't being released.

110) Fixed a bug where the default groupname (Default=groupname) of groups
wasn't being freed when the group is deleted or during shutdown.

111) Fixed a bug where the service's message location string and the
certificate name weren't being freed during shutdown and
&ServiceUpdate events.

112) Fixed a small memory leak during site rehash when knock ports are being
used.

113) Fixed a bug where the ident cache wasn't being cleaned up on shutdown.

114) Removed allocation of a 1MB heap used in the original custom memory
allocation routines that are no longer used.

115) Fixed a memory leak that occurs when TCL events throw an error.

116) Fixed a bug where an invalid memory pointer was being freed as part of
[Network]/Immune_Host processing when it involved more than one host.

117) Fixed a bug that would reject filenames ending in "."

118) Removed the trailing period on the error string "Action blocked by
external script" which shouldn't have been there and resulted in two
periods showing up in error messages to the user from the server.


*** Internal non-visible changes:

119) Added support for reading and writing an alternate directory timestamp
(ftAlternateTime) into the .ioFTPD files in currently unused space so
it's completely compatible with existing .ioFTPD files. Support for
displaying this in directory listings is currently disabled as there is
presently no way to set this value yet.


120) If an event (TCL or EXEC) failed to successfully return yes/no this was
considered the same as no. It is now possible to distinguish these
two cases.

121) Improved performance for directory cache lookups.

122) Added S_PRIVATE, S_SYMBOLIC, and S_REDIRECTED as internal only bits to
dwFileModes. These bits indicate that the associated directory
attribute [chattr] has been set so it is no longer necessary to scan
all the attributes to test if present. This nicely speeds up all
directory access checks when 3rd party scripts set lots of attributes.

123) Optimized a few routines by keeping track of the max client id ever used
so can avoid scanning entire 16k entry client array.

124) Updated sha1 algorithm code [http://www.gladman.me.uk/]

125) Redid the directory cache locking logic to consolidate it into one
place and support semi-exclusive locking.

pointBreak
07-16-2009, 04:14 AM
Looks great, thanks man!

FTPServerTools
07-16-2009, 02:55 PM
Source code?? I only see the usual sources...

Mave
07-16-2009, 03:11 PM
Amazing Job :):):) ioYIL wil it follow soon? :D:)

Yil
07-16-2009, 04:02 PM
FTPServerTools: Check the first post again, I added a link to v7 sources.

Mave: I hope I'll get some time to work on ioYil now. A number of things I stuffed into the core should make life easier although some things like automatic free space creation still need to be done. I'm hoping that things like ioArgs will make things easier for scripters in general and hopefully a few more will show up :)

o_dog
07-16-2009, 04:05 PM
why the changes in the itcl?

Yil
07-16-2009, 06:50 PM
o_dog: You'll have to be more specific. There's a whole pile of new commands or options, including ioArgs which I think will really help you in dealing with filenames that contain []'s, etc and the other stuff is just plain useful. The only actual change was to [mountpoints] and being a relatively new command wasn't used by anybody but me so far so I don't think there's a single change that affects any running code.

o_dog
07-16-2009, 07:02 PM
I use mountpoints....wonder if it broke it, I guess I'll notice.

I don't really need ioArgs, the reason ioNiNJA doesn't support the filenames is not that it's hard to do, just that i never saw any point in it and don't really want it to support it. The more you adapat the scripts the more crap people do....

I meant all the changes to itcl, I didn't really see anything in there that couldn't be done by a script or a simple tcl proc (just looked through it real quick though). the freedisk thing for example works just fine with twapi as do most other things.

I just don't see the point of adding more stuff to the core.

Yil
07-16-2009, 08:37 PM
Hmm, I didn't realize the test dir I was using was so old (v0.7). I actually checked the source of Ninja to confirm it wasn't used but I guess v0.8 uses it. Here's a new release undoing that change to make things easier on people.

ioFTPD v7.0.1 out, check first post for link.

Yil
07-16-2009, 08:38 PM
v7.0.1 Release Notes:

1) Files in \System:
Changed : ioFTPD.[exe,pdb] - Version 7.0.1.0.

2) Modified the TCL [mountpoints] command to return to original behavior
of just returning the parsed mountpoints without the first element
being the name of the file.

isteana
07-17-2009, 06:53 AM
did great job with 7.0 !

but as i told todo 3 features below

1. autowipe - delete latest release(by created order) when space running low beacuse warchive does
not working perfect(long dir doesnt supporting to delete)

2. nuked cleaner - find nuked release from selected section and wipe it

3. chgadmin - should work instead of site change <user> admingroup and site change <user> flag +G

o_dog
07-17-2009, 10:52 AM
nr 1 and 2 are not ioftpd features but script features, also there was a notimeout in changelog so you can set warchive not to timeout.

Flow
07-17-2009, 11:09 AM
Sweet, oh thanks Yil for still beeing around. You rock man. I think is time for me to make a update. Feel kinda outdated :p
Im still looking farward for your ioYil addon script. When the release plan for that one?

YS
Flow

isteana
07-17-2009, 01:01 PM
o_dog:
make sure warchive REALLY work with VERY LONG CHAR
and that problem have nothing todo with ioftpd timeout
you can watch it without ioftpd, the warchive pretty work with alone

and if autowipe merge on core, it could be check disk space with REALTIME
then it will faster than any script and no need scheduler to check to disk space

to excute warchive need very short cycle for make stable free space but sometimes its useless crap
becuase bandwidth is not regular on any site

so i think to execute by sheduler is very bad way for any space tools
working on core with REALTIME is much better

mr.babek
07-17-2009, 04:52 PM
Yil,

thanks for another update of the best ftpd for windows.

I have got one issue, I tried copying the user and group dirs from my 6.9.3 install, but it wont recognize users nor groups?

o_dog
07-17-2009, 04:57 PM
no, it's not actually. Adding those to core would be stupid, this is really what scripting is for. And if you spent half the time you do *****ing at others learning to code you would realize this is a simple ass script that takes almost no time at all to code....

Second of all what do you mean by VERY LONG FILENAMES? and why tha hell are you using them? I've told you before, adding support for all your crazy ass ideas is a waste of time and effort since most of them are just plain ass stupid!

As for wiping nuked dirs is even simpler...Might be a good start to learn how to code?

o_dog
07-17-2009, 04:58 PM
mr.barbek: you need to copy the files from ./etc too.

isteana
07-17-2009, 06:56 PM
i think you and i have different points of view
for example look at this one:

PDC.Darts.Las.Vegas.Desert.Classic.1st.Round.Adria n.Lewis.vs.Vincent.Van.Der.Voort.WS.PDTV.XviD-xxx!
then it will be not deleted with warchive! because dir name is long or unknown reason of bug

anyway i also dont want to long dir name for make warchive working fine but some group does it because that rls name is long

you dont know how annoying about this problem so i always wipe MANUALLY

will you write about this script? ( but anyway it lies beyond the boundaries of scripting by scheduler)

or do not self centered thinking

Not all scripting is best way in every situation

so How about looking at things from a different angle?

mr.babek
07-18-2009, 05:51 AM
odog: thanks, I somehow forgot about that :)

Yil
07-18-2009, 11:40 AM
It appears that the bytes to transfer field in the "Opening BINARY mode data connection for xxx (48828 bytes) using SSL/TLS." line is showing up wrong... Annoying to see, but doesn't actually impact anything so going to wait to see what else might need to be tweaked.

kingleo
07-19-2009, 11:14 AM
hi there, is there any chance ioftp will be supported unicode?

Yil
07-19-2009, 01:47 PM
kingleo: There is almost no chance that it will support unicode anytime soon. The codebase I inherited was really bad and while I've learned a lot about supporting unicode on the Window's platform it would take a lot of work to fix all the character width/formatting issues. It's just not worth my effort when I want to work on ioYil and continue adding the last of the features I want. I would happily encourage and support anyone willing to work on it though!

The server does support code pages though as I've seen servers with Korean characters in filenames, etc. So you should be able to localize it for any one language at least.

o_dog
07-20-2009, 07:19 AM
YiL: did you fix the lsiting bug with broken ntfs junctions and unicode? if it can't access the dir it will not list the directory?

Yil
07-20-2009, 12:10 PM
Hmm, I remember a discussion about NTFS junctions but I didn't try to fix anything with them. I did change some of the directory listing logic to fix some bugs so the behavior might be slightly different but I doubt it. I think the comments about junctions might have gotten lost when the forum ate those months worth of posts so could you give me a clue how to reproduce it and I'll fix that for you. I did make a few tweaks in the unicode conversion routines and local testing showed no errors. I was using latest nxtools but only v0.7 of your script for my testing though. Does it still spit out error messages for you? If so, I'll try v0.8 and see what happens.

o_dog
07-21-2009, 05:25 AM
cmd
mklink /J link target
after that you delete the target.

thats not really the problem though. But when ioFTPD can't find a directory it doesn't list any in that dir. This has nothign to do with ntfs junctions, but with how it reacts when it can't find a dir.

Flow
07-24-2009, 04:17 AM
Thare, now im back up2date :)

o_dog
07-24-2009, 12:52 PM
on the ioDisk info it would be nice to see whats wrong in an error message in order for debugging, right ow it only throws the error "Command Failed". would also be nice if it returned type, either network or loca, maybe filesystem too.

FTPServerTools
07-25-2009, 04:39 PM
Good work so to see. And i forgot to say thanks for the sourcecode..

Yil
07-30-2009, 06:16 PM
Looks like there is a problem with deleted users not being removed from UserIdTable which is impacting a few eggdrop scripts that read that file. Now, the really annoying part is the function "site ioverify" which is supposed to fix/catch things exactly like this has new bug introduced into v7+ as part of the new cleanup logic. v7 actually cleans up all the memory correctly, but before it didn't so the fake temp DBs used by "site ioverify" to find inconsistencies used to clean up after themselves but this results in bad things like the server crashing. This is a hard-coded M flagged command so the workaround for now is me telling you... don't run it :)

After jettisoning the HTTP service there is no more need for some annoying pointer manipulation tricks which I am in the process of removing. I'm also eliminating quite a number of annoying VOID * definitions where there is no good reason for not using the actual type of things. Have I mentioned that the codebase I inherited sucks recently? :) Anyway, I'll wrap that up, fix a few other little things, and get a v7.1 release out in a bit.

pion
08-04-2009, 02:14 PM
Would that bug affect the use of nxmydb? Or would that work around the problem?

Yil
08-04-2009, 09:43 PM
I have been totally unable to reproduce that problem, however I did see it on a live site so I know something was wrong. However, the DB was in an invalid state at the time and perhaps that contributed to it acting strangely and not fixing itself. You will see warnings in the error log like: Module 'STANDARD' reports item ID=510 NAME='testing' deleted from database '..etcUserIdTable'. If you start seeing something like that let me know so I can see what's going on... I believe nxmydb would have the exact same issue as it relies on the server to translate id<->name via the UserIdTable.

Bad news: I also saw what looks like the good old lockup bug on a site that wouldn't die via "site crashnow". On the other hand I have several reports that sites that got this frequently on win23k (where it was always a problem) are now running smoother.

pion
08-05-2009, 06:54 AM
The problem you are describing with the warnings is present at the previous versions also. A way to reproduce it is using nxmydb, and disconnect it from the mysql server - while you delete users in the database. Then connect again - and the error should come up

ArtX
08-05-2009, 05:44 PM
YiL in future release's could you tell us what files only need to be updated instead of the whole thing, or is it best to copy over the whole release every time you update, backing up etc groups and user folders?

Yil
08-05-2009, 06:46 PM
Carpo: Every file modified, deleted, or added is documented at the very top of the Changelog so just replace the files it mentions there. It even documents, by section and in order, what additions/changes need to be applied to the .ini file. Of course a big release like v6 to v7 changes a lot of files so there are even a few comments about what you need to keep (like nxtools dirs or text/ftp/Welcome) to make swapping whole directory trees easier instead of by files.

opcode
08-06-2009, 05:07 AM
ioFTPD 7.0.1 runs fine for me the first time i start it. If i have to kill the process and then restart it again, it crashes on startup and the process terminates itself. I can send crashlog & memdumps if neccessary.

razoor
08-06-2009, 08:57 AM
it does that for me to. i just changed the delay on preload to false and that did the trick for me.

opcode
08-06-2009, 09:14 AM
actually if i let the pc idle for some time (like 1hr+) i can restart ioFTPD again, even with vfs_preload delay on. I don't really see what vfs_preload delay does anyway, it still takes ages to cwd into huge dirs for the first time.

Yil
08-06-2009, 02:44 PM
By default preloading just caches mountpoints in the default VFS file and thus this could mean just a single directory if you only have a root entry. It is up to you to specify what else it should preload. In practice if you have large directories/fanouts that take minutes to load the first time that aren't mountpoints then specify them manually in the .ini file so the server can do the work ahead of time. This is especially true for large fanout dirs on networked drives.

The Delay= setting which determines whether the server should wait around and finish caching the dirs before allowing connections to the server fundamentally changes the way preloading occurs. With Delay=False the server queues a low priority task onto the internal worker thread queue and it will process the directories one by one. If Delay=True the server hasn't really started yet, and thus there are no worker threads, so it spawns a new thread per mountpoint / manual entry and does the preloading in parallel so completion time is basically the slowest task to finish. Remember though that ioGUI/etc won't be able to connect while this is going on because that's the point of this setting...

If you are experiencing crashes at startup try switching the Delay= setting and see if that makes a difference because the =True option is the one I used for testing most of the time since it seemed far more fragile with all the thread creation/synchronization/etc.

opcode
08-06-2009, 02:58 PM
@Yil: that makes sense, i just checked again and i am indeed just mounting the parentdir, which then contains three subdirs with lots of dirs in them. So it just caches the parent, but not the contents of the subdirs that are actually a pain to cwd into. I'm too lazy to do separate mountpoints for those, so i'll just disable the delay stuff like you recommended.

Yil
08-06-2009, 04:02 PM
opcode: You don't have to turn the dirs into mountpoints to preload them. See the comments for the VFS_Preload section. You append a line like "2 = /" which will cache everything in / and all it's subdirs. Or pick on particular dirs with something like "1 = /Games/Archive" which will just load the /Games/Archive dir.

Hope that helps, but do see if your startup issues go away by switching the Delay= option.

ArtX
08-08-2009, 08:35 AM
just to make sure i have this right do you mean

[VFS_PreLoad]
# By default the server now preloads all the directories used as mountpoints
# in the default VFS file indicated by [Locations]/Default_Vfs. If you want
# additional directories loaded include lines here with the form:
# <depth-to-descend> = <starting-VFS-path>
# A depth of 1 just means the directory itself, 2 would be the dir and all
# its immediate subdirs, etc.
2 = /

if so it doesnt seem to have helped much, could just be me though :)

Mave
08-08-2009, 02:20 PM
Dont forget about ioYIL YiL :):):)

Yil
08-08-2009, 03:14 PM
Carpo: Yup, that should attempt to load /*/*. If you look at ioftpd.log it should indicate the number of directories that matched and were preloaded...

Mave: :)

opcode
08-08-2009, 06:23 PM
Yil: seems to work flawless with the preload turned off

ArtX
08-08-2009, 07:22 PM
ok don't know if this is an error with ioFTPD or ioNINJA, i had this before in systemerror.log and i vaguely remember reading something about it.

Error converting string:

seems to be when i upload something, i also seem to have a debug.log file now which has

Created TCL Interpreter #1 (this goes from #1 to #5)

if these can be safely ignored its not an issue, just thought i would check :)

o_dog
08-09-2009, 07:33 AM
next time try the search function before you post =)

Yil
08-09-2009, 03:54 PM
Hmm... The option "Debug_Tcl_Interpreters = TRUE" was supposed to be commented out in the released version. Obviously I enable this for testing, but when I copied over the new feature I forgot to disable it by default. Go ahead and disable it and that should remove the spam it sends to Debug.log.

I had also intended to disable the "Log_Exiting_Worker_Threads = TRUE" line but I'm not convinced this isn't something to leave enabled now. If you have like say 5 worker threads and 30 users it's possible you are probably creating/destroying lots of real threads and expensive TCL interpreters and suffering performance problems because of it. If that's the case some extra lines in the logfile probably aren't the worst thing to make you aware of the situation so you can tweak the setting a bit higher.

"Error converting string:" I've still never seen one of these myself... It's possible that I need to upgrade to v.8 of Ninja or something. What version are you running? You can ignore these, but clearly something isn't happy and it's probably my fault somewhere but I haven't been able to reproduce it.

ArtX
08-09-2009, 06:00 PM
next time try the search function before you post =)

why would i need the nxtools fix if im not using any of his scripts? or is something in ioninja using it?

edit: just did a complete fresh install of ioftpd 7.0.1 and latest version of ioninja 8, and uploaded a few files and the Error converting string: msg no longer appears, and the debug.log is no longer there after i changed what you said and deleted it, must have been something left over from the update.

plakjekaas
08-14-2009, 03:27 PM
Yil, thanks very much for the updates ! running ioftpd for many years now and happy to see there is 'maintenance' again.

Mave
08-24-2009, 02:43 PM
Ola everyone still alive yet?
More then a week no massages :p
Yil dont fall asleep .... stay awake and finish ioBILL :P

pion
08-31-2009, 12:01 PM
Io 7.01 crash on dir cache - clean setup

08-31-2009 18:51:00 SSL: "Found certificate" "name=abcd" "Service=FTP_Service" "(Certificate_name)"
08-31-2009 18:51:00 START: "PID=220" "CmdLine="
08-31-2009 18:51:00 PRELOAD: "begin" "..\etc\default.vfs"
08-31-2009 18:51:00 PRELOAD: "points=1" "..\etc\default.vfs"

If I completely empty the default.vfs it starts...

"If you are experiencing crashes at startup try switching the Delay= setting and see if that makes a difference because the =True option is the one I used for testing most of the time since it seemed far more fragile with all the thread creation/synchronization/etc." does not help

i put DELAY = False but it just crashes later

monk-
09-18-2009, 09:21 PM
it seams that THE lockup bug is gone
this is great, awsome work, i want to kiss u ;P

oke, i got arround the preload crashing problem by puting all preload paths in a seperate VFS=..\etc\sections.vfs

but now i cant run warchive anymore, io just crashes
warchive is the only autowipe/move tool arround, that always worked with io
i like u to look into this anoying problem
warchive will prolly works when i make a windows schedule
but thats not the proper way..
same goes for ioA newdate. i always used ioa for 0day dir creation,
but with io7 it crashes
and both tools are of the same creator,...

i also would really like a STABLE release now,
the lockup problem is gone now, now u can make a real STABLE
plz dont add new features for a while

luv ur work

later

Dahlia
09-25-2009, 03:00 PM
it seams that THE lockup bug is gone
this is great, awsome work, i want to kiss u ;P

oke, i got arround the preload crashing problem by puting all preload paths in a seperate VFS=..\etc\sections.vfs

but now i cant run warchive anymore, io just crashes
warchive is the only autowipe/move tool arround, that always worked with io
i like u to look into this anoying problem
warchive will prolly works when i make a windows schedule
but thats not the proper way..
same goes for ioA newdate. i always used ioa for 0day dir creation,
but with io7 it crashes
and both tools are of the same creator,...

i also would really like a STABLE release now,
the lockup problem is gone now, now u can make a real STABLE
plz dont add new features for a while

luv ur work

later

Yes warchive 2.0x keep crashing io7.x, use older version 1.4. And ioA is rly too old script so use nxtools 1.2.1 (or if you preffer old scripts, try NewDay.1.1.5.zip *not tested on 7.x, im using nxtools ;] ...)

Sc0tTyXL
09-25-2009, 11:49 PM
Io 7.01 crash on dir cache - clean setup

08-31-2009 18:51:00 SSL: "Found certificate" "name=abcd" "Service=FTP_Service" "(Certificate_name)"
08-31-2009 18:51:00 START: "PID=220" "CmdLine="
08-31-2009 18:51:00 PRELOAD: "begin" "..\etc\default.vfs"
08-31-2009 18:51:00 PRELOAD: "points=1" "..\etc\default.vfs"

If I completely empty the default.vfs it starts...

"If you are experiencing crashes at startup try switching the Delay= setting and see if that makes a difference because the =True option is the one I used for testing most of the time since it seemed far more fragile with all the thread creation/synchronization/etc." does not help

i put DELAY = False but it just crashes later

Same problem, fresh download, whenever i add a mount to the vfs default file it crashes. if i leave it empty except for the default root mount it loads fine. with DELAY false or true

I've been running 5.8.0 beta for yearsssss, but i'm sick of the sometimes corrupt files, so want to upgrade + do a new config :) i hope this can be fixed soon, i'm building a new server soon and i'd like to run 7.x on that box :)

( glad to see support/developing has been active again )

Dahlia
09-27-2009, 06:20 PM
Same problem, fresh download, whenever i add a mount to the vfs default file it crashes. if i leave it empty except for the default root mount it loads fine. with DELAY false or true

I've been running 5.8.0 beta for yearsssss, but i'm sick of the sometimes corrupt files, so want to upgrade + do a new config :) i hope this can be fixed soon, i'm building a new server soon and i'd like to run 7.x on that box :)

( glad to see support/developing has been active again )

hmm. that issue with default.vfs is weird. but wtf ? make a new.vfs. i'm using different vfs for few members and i never used default.vfs for anything. leave default.vfs as it is make new and everything is alright! :)

Sc0tTyXL
09-28-2009, 09:21 AM
hmm. that issue with default.vfs is weird. but wtf ? make a new.vfs. i'm using different vfs for few members and i never used default.vfs for anything. leave default.vfs as it is make new and everything is alright! :)

ill give it a try, but i dont think it will work

edit:

okay i added a siteops.vfs ,also set it as default and added it to my siteops group, then i also added this
[VFS_PreLoad]
1 = /tmp

and now it works, but imho isnt it strange that it wont load default.vfs and without that preload :/

Dahlia
09-29-2009, 06:42 AM
ill give it a try, but i dont think it will work

edit:

okay i added a siteops.vfs ,also set it as default and added it to my siteops group, then i also added this
[VFS_PreLoad]
1 = /tmp

and now it works, but imho isnt it strange that it wont load default.vfs and without that preload :/

mby its strange mby not. but since now i never heard about this trouble with default.vfs because i never used that vfs :-)

and in [VFS_PreLoad] i have another 'vfs'. VFS = ../etc/start.vfs with DELAY = TRUE and everything work like a charm.

P.S.
and LF active scripter ...need to add some options to nxtools and so on! :]

Yil
09-29-2009, 03:28 PM
Hey folks, I got some time yesterday to work on the server and came up with a potential fix for the preloading problems. My single core non-hyper-threaded machine doesn't seem to trigger the problem (perhaps I need to upgrade!) but I found what I think is a race condition that could show up on better machines. This particular problem is entirely of my own making unlike the vast majority of pre-existing issues. My bad, I'll try to get the few things I started finished up and get a 7.1 out soon.

paja1
09-29-2009, 06:11 PM
Hi,
i'm playing a bit with 7.0.1 on my DualCore P4@3.8Ghz (Windows Server 2003 sp2) and this version crashes quite a lot!
Yil, if you are interested i can send you all crachdumps i have with description what i'm doing and ehat sort of configuration i have. The only solution for me is rollback to version 6.x.

Even i like ioVirtual a lot.. but it crashed here very often.
I'm trying to generate whole virtual tree, like 3-4 levels deep and practically always it crashes on level 3, eg.: /INDEX/A/Auto/

Again i can provide you as much information as you may need.

Thanks you for your work and please don't give up!

Yil
09-29-2009, 07:03 PM
paja1: Woohoo someone playing with pure virtual dirs. I PM'd you info on where to upload the crashdumps. If you have some simple test cases that show the problem I'll be happy to try those out locally and/or see what I can make from the dumpfiles. I tested the simpler 1 and 2 level deep cases since I had scripts around I could modify to play with. But it looks like something isn't happy when things get deeper.

Yil
09-30-2009, 02:13 PM
Paja1: I've diagnosed the problem from the minidumps you sent me. I improperly allocated the size of an internal virtual info array by forgetting to multiply the number of elements by the size. If you can test the rest of the functionality by only using 25 or so entries per directory things should become stable again until I can get v7.1 out with the fix for larger dirs.

Dahlia
09-30-2009, 03:50 PM
Yil please,
i read in your To-Do list that you want to add option to change:

SITE UTIME support (1 arg version?)
SITE ATIME/PTIME support (alternate-time) setting for dirs

i hope this is what im looking for. because is very annoying to have on server with ioftpd always +1(or 2h) server time than is my real time in my time-zone.

for example:
im in european UTC (CET) +1 zone. if i have real server time and if i make dir with ioftpd the dir has always wrong time (-2h). if i want to have correct time on dirs i need to change my server time to +2h (now in summer). but with this option i wont use for example script like Topstats (i run that script everyday at 23:55) because topstats is reading ioftpd.log and xferlog and those files have correct server time (not like dirs made by ioftpd) and this script at 23:55 give me only stats (created/deleted dirs, etc,...) from 1h and 55minutes from next day. i hope you understand what i mean :X

it takes so much time or is it possible to add that TIME option (something like SET your TIMEZONE: CET +1) already to io7.1 version ? :)

thank you

paja1
09-30-2009, 04:54 PM
Paja1: I've diagnosed the problem from the minidumps you sent me. I improperly allocated the size of an internal virtual info array by forgetting to multiply the number of elements by the size. If you can test the rest of the functionality by only using 25 or so entries per directory things should become stable again until I can get v7.1 out with the fix for larger dirs.

Hi Yil,
thank you for a good news.. i'll try and play with it but under restriction of max. 25 items in one fodler. Btw, i do have troubles with caching, when i enter SubDir script is invoked but in FlashFXP i can see content from parent folder. When i press F5 to refreh the content i can see proper one. The same situation if you are going back, one level up.

To the stability of 7.0.1, i;ve discovered another unstable moment, if you have folder with a lot of gigs and try to rescan crc or call any long, long running script.. you will lost connection, which is the same behoviour like in 6.x.x, but daemon dies.. which is new and quite unpleasant. Can you please check it out? :)

Thanks!

Yil
09-30-2009, 06:28 PM
dahlia: All times in the server are in UTC time. Have you tried setting the timezone for the server in your FTP client? I think that's probably a simpler solution. If you've tried that what still doesn't work?

paja1: Hmm, not sure on the caching issue. Try disabling caching in the client for the site and see if that makes a difference. If so take a look at the return values and see what's going on. I do know FlashFXP cwd's and then does a pwd to figure out where the server ended up to check if it already has it in the local cache. Perhaps I'm returning the wrong directory name after a change for directories more than 1 or 2 layers deep in a virtual dir...

Long running scripts. Is this a tcl or an exec script? I totally rewrote the whole exec scripts module to prevent the v6 timing out behavior and ran a number of test cases on the changes but maybe I missed something... Which script did this and if you have minidumps send them over and I'll get that fixed for ya.

paja1
10-01-2009, 04:32 AM
paja1: Hmm, not sure on the caching issue. Try disabling caching in the client for the site and see if that makes a difference. If so take a look at the return values and see what's going on. I do know FlashFXP cwd's and then does a pwd to figure out where the server ended up to check if it already has it in the local cache. Perhaps I'm returning the wrong directory name after a change for directories more than 1 or 2 layers deep in a virtual dir...

Ok, will try to play with it a bit, and also will try to compare comunication as in 'normal' folders everything works just great.


Long running scripts. Is this a tcl or an exec script? I totally rewrote the whole exec scripts module to prevent the v6 timing out behavior and ran a number of test cases on the changes but maybe I missed something... Which script did this and if you have minidumps send them over and I'll get that fixed for ya.

It's definately exe, and its zip script for checking consistancy, ioZS but not the latests version. On 6.x it's working fine. On 7.0.1 it crashes quite often, on timeout everytime.

I'll try to get some crash dump or you.

Br,
Pavel

Dahlia
10-01-2009, 09:52 AM
dahlia: All times in the server are in UTC time. Have you tried setting the timezone for the server in your FTP client? I think that's probably a simpler solution. If you've tried that what still doesn't work?



I tried to set TimeZone in my ftp client (FTPRush)
http://img9.imageshack.us/img9/5679/timezone.th.png (http://img9.imageshack.us/i/timezone.png/)
1. "Casablanca/Monrovia timezone" is the only one timezone that give me the correct date of created dir - but i'm in GMT +1 timezone
2. It's almost impossible to say to every single user -> "set your timezone in your ftp client to 'something what is not even your timezone'"

and here is normal setting in ftpclient (-2h of created dir/file)
http://img185.imageshack.us/img185/2669/timezone2f.th.png (http://img185.imageshack.us/i/timezone2f.png/)

I think everyone who is in some different timezone than UTC must have the same problem.

The only one problem is incorrect date/time of created dirs/files. Every single log message in ioftpd is correct 'with current real server time'. Some internal script for change date/time of created files might help but dunno how much will that script slowdown the writing process.

thank you for answer

razoor
10-01-2009, 08:13 PM
i have mentioned the UTC before in ioFTPD since i want it to be changed to. ;)

https://oss.azurewebsites.net/forum/showthread.php?t=12503

paja1
10-02-2009, 09:09 AM
Yil, i'm playing with ioVirtual for a while already and i have to say:
*I LOVE* your implementation of Virtual FS!!!!
It's soooo powerfull .. thank you, thank you!!!!

Just please fix that 25 items limitation and problem with cashing... and we are ready to go! :)

Yil
10-02-2009, 06:49 PM
New Version:
ioFTPD-v7.0.2.zip (http://home.comcast.net/~yil/ioFTPD-v7.0.2.zip)


v7.0.2 Release Notes:

1) Files in \System:
Changed : ioFTPD.[exe,pdb] - Version 7.0.2.0.
Changed : ioFTPD.ini - summary of changes by section...
[Themes] : Theme #4 should say Light-Min instead of Light-Max


*** Bug Fixes:

2) Fixed a bug in the EXEC module that improperly manipulated the input buffer
and would crash the server when the undocumented redirect commands such as
!vfs:add were used by scripts such as ioZS. Redirect commands allow EXEC
scripts to ask the server to perform operations. These command lines are
stripped from the output before it's sent to the user. For the record the
full list of redirect commands are: !putlog, !vfs:add, !vfs:chattr,
!change, !unlock, !newlines, !prefix, !buffer, and !detach.

3) Fixed a bug in InsertVirtualInfo that failed to allocate enough space
for the VirtualInfo array.

4) Fixed a bug in "site ioverify". The faked out user/group databases used
to verify accounts were being freed twice because of a bugfix in v7 that
started to properly cleaned up memory during shutdown.

5) Fixed a bug in %[IF] which would improperly evaluate to true if the
comparison string was a prefix of the input string.

6) Fixed a bug that would output an incorrect error message on non-english
systems. Lines would look like:
426 Connection closed: The system cannot find message text for message
number 0x%1 in the message file for %2.

7) Fixed a type in ioFTPD.ini where theme #4 was labeled Light-Max instead
of Light-Min. Start of new line should look like "4 = + 2 Light-Min ..."

8) Fixed a race condition in directory PreLoading during startup that may have
been causing the crashes.

Yil
10-02-2009, 06:54 PM
Timestamps in ioFTPD. Are you changing the timezone setting for the site in FlashFXP,etc to YOUR timezone or to UTC? That setting is for the timezone the server is in. If I set it to UTC all the times look fine for me for newly created items.

Also, be careful about the latest version's of FlashFXP's automatic timezone discovery mechanism. It will choose files that are old enough that they would show up as Oct 2 2007 instead of a current Oct 2 16:40 format and totally screw up the time offset...

Yil
10-02-2009, 08:08 PM
I forgot to include this in the Changelog when first posted...


8) Fixed a race condition in directory PreLoading during startup that may have
been causing the crashes.

paja1
10-03-2009, 03:33 AM
Yil, one word: THANK YOU!
(was actually two :))

Btw, what about Virtual Folders caching/refreshing 'problem'?

dr.owned
10-03-2009, 12:35 PM
hi.
i've been using ioftpd for quite some time. scripting support kicks a$$, and finally there is a feature i've been lookin for so long - virtual dirs.
after some tests i discovered the following things i look forward to be fixed\explained:
- not really an issue but still: with only one mount point present - root mount point - virtual directory just doesn't work. cwd tells no such file or directory.
- commands like AddFile and AddLink create links to target files which are displayed along with faked filenames when viewed from a ftp-capable web browser ("file.ext -> /original_mount/file.ext") and hence couldn't be downloaded. i wonder if it will be fixed or become configurable (like HideVirtualSymlinks = TRUE/FALSE). i guess server can show ordinary filenames in listing while preserving linkage info internally.
- this one might be a noob question but how do you make the server give you a file requested with a full path from a virtual directory while working dir is root?
CWD /
RETR /virtual_dir/subdir/filename.ext
what scripts should i write and where do i put them?

thanks in advance.

Yil
10-03-2009, 04:33 PM
dr.owned: Hmm, I'm not aware on any reason why just having a root mount point would prevent virtual directories from working but that should be easy to test. I can point out that v6 style virtual directories requires a real directory or mountpoint in the location of the virtual mountpoint and v7 requires there to NOT be a real directory in that location. Make sure you don't have a /search or a /latest, etc directory.

Hmm, interesting tidbit on FTP capable web browsers not understanding symbolic links. I was under the impression that they just ignore the link part and everything works fine since I'm pretty sure I've traversed links in FireFox on FTP connections before... You can use AddDir/AddFile with "" specified for the LINK field and the listing will show up without a link (see doc/itcl.txt). However, the server has no idea what the heck that entry is so when accessed it will act like AddSubDir would and call the script to resolve the link at which point you return a ||RESOLVED|| type result. That is obviously more expensive but should act as a workaround right now. I'll have to see about a special LINK syntax like a leading : or something that would keep the linkage internally but not show it...

Full path syntax to virtual files. You just need to return the ||RESOLVED|| result from your script because the request resolved to an item and not a virtual directory listing. That should work.

dr.owned
10-04-2009, 12:36 AM
Yil, could you please check out this script i wrote?

putlog -general "Script called"

set remount [string range [lindex $ioArgs 0] 1 end-1]
if {[string index $remount end] == "/"} {set remount [string range $remount 0 end-1]}
if {[string index $remount 0] == "/"} {set remount [string range $remount 1 end]}
set remount "/_$remount"

set path [resolve pwd $remount]

if {[file isfile $path] == 1} {
ioVirtual AddFile 0 1 1 "anonymous" "nobody" 0755 "||RESOLVED||" "$remount/[file tail $path]"
return 1
}

set dirs [glob -nocomplain -type d "$path/*"]
if { [llength $dirs] > 0 } {
foreach d $dirs {
putlog -general $d
ioVirtual AddSubDir [file tail $d]
}
}

set files [glob -nocomplain -type f "$path/*"]
if { [llength $files] > 0 } {
foreach f $files {
ioVirtual AddFile [file size $f] 1 1 "anonymous" "nobody" 0755 [file tail $f] ""
}
}

return 1

here i'm just trying to popullate virtual directory with contents of another mounted directory ($remount). as you suggested, i use empty string "" as a link and file listing in web browser looks great ^) but when i try to retr a file ioftpd says "modifying virtual directories is not allowed" and does not call my script to ||resolve|| the file (there is no "Script called" line in the log).

and why stor to virtual dir is not allowed? following the same idea of ||resolve||-ing filenames, a script should just point out a vfs destination for server and the rest is just like a normal upload..

Yil
10-04-2009, 01:27 AM
"modifying virtual directories is not allowed" - I'll have to look into that. If you CWD into the directory can you download the virtual files by using a simple name?

Modifying virtual directories just seemed like a bad idea. I assumed that people would sort, etc real directories and return links to them and thus everything would pretty much work normally from that point on. I can look into letting the virtual resolver attempt to get a path for pure virtual files and see if the script returns a RESOLVED style link and then use that...

dr.owned
10-04-2009, 01:46 AM
hmm.. not sure i understood "by simple name" right..

here
ioVirtual AddFile [file size $f] 1 1 "anonymous" "nobody" 0755 [file tail $f] ""
if i put "$remount/[file tail $f]" instead of empty string "" for the last parameter, files are downloaded ok, but web-listing is broken. and if i put an empty string there i get "modifying virtual directories is not allowed" whether i CWD into directory and say RETR file.ext or just say RETR /virtual/dir/file.ext.

hope you get this figured out soon because there is an idea in my mind that depends heavily on ioftpds virtual dirs :)

as of actually "modifying" virtual dirs - i'd like to be able just to upload files at the moment, and if you think it's not worth the effort then nevermind :)

paja1
10-04-2009, 05:48 AM
Yil: About 'caching' problem with browsing Virtual Folders.

Ok, i founded out what is happening...
It seems like the code is ok, it just that in first call is the cookie/variable $pwd outdated... means from last call.


CWD /INDEX/
250 CWD command successful.
PWD
257 "/INDEX" is current directory.
NLST *.*

$pwd = "/INDEX/"


CWD /INDEX/Foo
250 CWD command successful.
PWD
257 "/INDEX/Foo" is current directory.
NLST *.*

$pwd = "/INDEX/"


NLST *.*

$pwd = "/INDEX/Foo" (correct)

Are you updating $pwd AFTER calling iTCL script or what? :D

I'm doing that wrong or there is something wrong in the code?
I'm convinced this is the only problem so far!

Btw: in first call (first virtual folder) it's working well.


THANKS!!!!!!
Pavel


******* UPDATE *********************************

After replacing $pwd with $ioArgs[0] everything works quite well!

dr.owned
10-04-2009, 11:11 AM
to be more specific, here is the detailed log of different browsers talking to ioftpd (script included).
http://d.padfly.com/ioftpd?download

the following link is given - ftp://127.0.0.1/public/10.jpg
/public - virtual directory
/_public - dir mount whose contents are duped in /public
as a result, opera succeeds and iexplore fails

hope this'll help

dr.owned
10-05-2009, 03:18 AM
oh man.. ignore my last post :) i found an error in my script.
so file retrieval using full path works ok.
and the only problem remaining is weblinks...

also during debugging of my script i noticed the following two things.

- it would be nice to know which command caused server to call the script, to be able to respond accordingly. for now i imitate such feature by having specific tcl scripts bound to all possible pre- and post- handlers :) where i save and clear the last command respectively. it works, but still.. :)

- and since scripts will be able to find out the command they were called by, why not make the same script handle the processing of all commands which somehow involve its virtual directory. on the one hand it eases VDs implementation by leaving all handling to programmer, but on the other it's a performance loss. so maybe there is a point in making it configurable (like ForceVirtualDirectoryScriptCalls = TRUE/FALSE) so those who don't require speed could benefit from extended functionality.

dr.owned
10-05-2009, 06:50 AM
i'm sorry for this onslaught of posts :)

1. i patched ioftpd.exe not to return symlinks and voila, weblinks look great and thay work :)

2. i also experimented with uploads. and i actually managed to upload files to virtual directory! :)) as well as all other operations like deleting and renaming. i don't know if you planned it from the beginning, Yil, but these are certainly great news:) thanks for being around and supporting ioftpd:)

paja1
10-05-2009, 01:36 PM
*** Bug Fixes:

2) Fixed a bug in the EXEC module that improperly manipulated the input buffer
and would crash the server when the undocumented redirect commands such as
!vfs:add were used by scripts such as ioZS. Redirect commands allow EXEC
scripts to ask the server to perform operations. These command lines are
stripped from the output before it's sent to the user. For the record the
full list of redirect commands are: !putlog, !vfs:add, !vfs:chattr,
!change, !unlock, !newlines, !prefix, !buffer, and !detach.


Hi Yil,
unfortunately.. this is still not working.. please check my crashdumps on your ftp.
Thanks!

Yil
10-05-2009, 02:59 PM
dr.owned: Can you give me some examples of why knowing the command being run makes a difference as to what the script should return? It's possible to record the command being executed and pass that to the script whenever the virtual directory script is being executed and perhaps even when a pure virtual directory is being accessed from the cache. It would be difficult to entirely replace virtual directories with scripts because all commands would have to resolve their targets normally first (to support things like list -al /search/foo from /) and then handle things differently depending on it being virtual or not. That's a lot of commands to have to modify unless I found some cool way to do it I can't think of right now.

My initial implementation of virtual directories caches the last directory listing for each user per virtual mountpoint. I commented somewhere that once I could get some usage data that a single directory might be too small if people were using trees instead of say a simple /latest dir. I'm open to say caching 3-5 dirs per mountpoint. Let me know if you think that would dramatically change the number of times the script would be called in your implementations and if that would be desirable.

I also liked the ":" link prefix idea I mentioned before. That would allow you to symbolically link a directory but to hide the link in listings. That should dramatically reduce the script load I assume because the server would internally resolve things instead of having you return RESOLVED links from the script. If I can find/solve paja's problem I'll perhaps slip in this "new" feature into the next bugfix release sometime soon.

paja1
10-05-2009, 03:23 PM
Yil,

I've found potential error... but maybe I'm just wrong.

Event OnUploadComplete returns invalid CRC32 value... i'm trying to get rid of ioZS as it's making ioFTPD 7.0.2 crashing... so i started with this value.. but as I already mentioned, this value is wrong :(

Compared to iTLC crc32 or TotalCommander, etc...

Should be this value correct crc32 of currently upoloaded file or something else?

Thanks!

Pavel

paja1
10-05-2009, 03:27 PM
Yil,

do you think that durring VFS preloading the server can respond with message that server is initializing or starting up...? I have quite a lot of virtual mounts oven on network drives.. and it takes about 40 sec to startup/preload server.

Just idea... not requested at all.... but will be better to know what happening.

Or allow to (M) masters to login anyways.

What do you think?

Yil
10-05-2009, 04:03 PM
paja1: I'm considering a requested feature of allowing the server to startup as if the site was closed. A new option to the site close command would make it carry over until it was removed even if restarted. Probably just via a simple file being created in the system dir with the reason. Assuming I do this I don't see why I can't use similar login logic and let the server startup normally and respond with a "server coming up" message as the closed message (provided you haven't set a real one) while preloading finishes. Perhaps even applying a different CloseExempt parameter. I'm also looking at ways to prevent LIST/MLST from timing out during 2+ minute listings by just spitting out 200- keep alive messages although it's a bit tricky to do. The real problem is STAT/NLST is very specific about what you can return so I'm looking into faking out the "." entry or something if needed. Preloading makes logins appear snappier when connecting to a newly started server but were really designed to get around 2+ minute initial directory listings which clients timeout...

Event OnUploadComplete returns invalid CRC32 value? Provided you haven't disabled computing it in the .ini file I think it should be working fine. I remember ioSFV used it for a while and I'm pretty sure ioNinja uses it now. I added support somewhere like v6.3 or so that it would compute the CRC32 value over the whole file and not just the uploaded section as it did before that which made a difference for resumed files. The builtin XCRC (XCRC32?) FTP command is special cased though. It will return the CRC32 value for the uploaded file the first time it is called immediately after uploading (so clients can check if the file transferred OK), however this might not be the same as the file on disk if the zipscript modified (i.e. added/stripped .nfo files) so you can call it again and it will give you the disk based result on all further calls. If the OnUploadComplete CRC32 value when called is different than that called by the [crc32] command then that indicates a problem. Is it reproducible? I can't believe ioNinja would work without it being correct at least most of the time... Nothing weird like attempting to upload a single file via multiple connections going on?

paja1
10-05-2009, 04:39 PM
paja1: I'm considering a requested feature of allowing the server to startup as if the site was closed. A new option to the site close command would make it carry over until it was removed even if restarted. Probably just via a simple file being created in the system dir with the reason. Assuming I do this I don't see why I can't use similar login logic and let the server startup normally and respond with a "server coming up" message as the closed message (provided you haven't set a real one) while preloading finishes. Perhaps even applying a different CloseExempt parameter. I'm also looking at ways to prevent LIST/MLST from timing out during 2+ minute listings by just spitting out 200- keep alive messages although it's a bit tricky to do. The real problem is STAT/NLST is very specific about what you can return so I'm looking into faking out the "." entry or something if needed. Preloading makes logins appear snappier when connecting to a newly started server but were really designed to get around 2+ minute initial directory listings which clients timeout...


Thanks.. sounds like a good solution... even i can understand that implementation of 'progress' messages can be quite tricky.. and i think (maybe) not necesary.


Event OnUploadComplete returns invalid CRC32 value? Provided you haven't disabled computing it in the .ini file I think it should be working fine. I remember ioSFV used it for a while and I'm pretty sure ioNinja uses it now. I added support somewhere like v6.3 or so that it would compute the CRC32 value over the whole file and not just the uploaded section as it did before that which made a difference for resumed files. The builtin XCRC (XCRC32?) FTP command is special cased though. It will return the CRC32 value for the uploaded file the first time it is called immediately after uploading (so clients can check if the file transferred OK), however this might not be the same as the file on disk if the zipscript modified (i.e. added/stripped .nfo files) so you can call it again and it will give you the disk based result on all further calls. If the OnUploadComplete CRC32 value when called is different than that called by the [crc32] command then that indicates a problem. Is it reproducible? I can't believe ioNinja would work without it being correct at least most of the time... Nothing weird like attempting to upload a single file via multiple connections going on?

Unfortunately I'm not able to reproduce it any more... and seems like it works well atm actually. :(
I'd experienced this on text file (*.bat) but works fine with this one as well.. dunno why it returns wrong values at that point... but i restarted ioFTPD serveral time between, so anything could happen.

Thanks for you quite good answer and explanation.

Pavel

dr.owned
10-05-2009, 07:35 PM
dr.owned: Can you give me some examples of why knowing the command being run makes a difference as to what the script should return?

that's really easy. say i'm renaming or deleting a subdir in a virtual directory. the sciprt is only aware of that he should process "/virtual/subdir", so it looks at the specified path, determines it's a directory and returns its listing. but instead it should have returned ||resolve||-d link to it. there a no means by which the script should know what to do (only with a workaround i mentioned before).

or another example - to fake responses to commands like MDTM, RETR... or reversively, to make responses more ftp-client-understandable. because "modifying virtual directories is not allowed" isn't exactly what ftp clients expect when they commit something they can't.

and when RETR-ing, it would be nice to know whether it starts from byte 0 or a REST 123123 command was issued earlier and the requested file is resumed. same goes to pre-retr event.

Let me know if you think that would dramatically change the number of times the script would be called in your implementations and if that would be desirable.

in my case the whole point is that contents of virtual directory is about never the same, it is changed constantly so caching isn't helping me at all. so it seems like a waste to enable caching (=> memory consuming) functions for directory that doesn't require it.

I also liked the ":" link prefix idea I mentioned before.

it seems like a nice idea. but to me actually NOT adding ":" should return usual name, and adding it return a symlink :)

p.s. also check the situation when a declared virtual directory path already exist and it is a non-empty mountpoint. ioftpd crashes while only warning should have been issued.

Yil
10-05-2009, 09:28 PM
dr.owned: Interesting. First comment I'd make is that most of the problems you appear to be having are caused by trying to fake out pure virtual files/dirs instead of letting the server know they are links to real items. MTDM, RETR w/RESTORE, etc all would work correctly if you weren't trying to hide the link from the server because it's outputting in a way that some web clients don't like. If I fix that with the ":" option for you all that should become cleaner while still outputting as you like. For the moment try using links and see how much of a difference that makes and let me know what still doesn't work right. Also, see if there is a difference between dir and file handling in practice.

Having said that you bring up an interesting point with renaming. If the original directory is a real directory then once you realize that the script should return a resolved link to it. I'm not sure what the target should do however. That's a pretty special case but just returning an error probably works since the item shouldn't exist anyway. It gets even weirder if you try to rename purely virtual items since even if I pass the current command in as an option that wouldn't give you enough data to completely understand what is going on. I can however pass as an extra argument the stored source name if I have one. Renaming is already handled as one of a very few special case multiple command sequences with the other being downloading/uploading. I'm not convinced yet that with using resolved links and by letting the server know about existing items that normal file up/down won't work correctly without all that extra stuff.

The resolver when running does have a couple of flags that might be interesting to pass to the script. The most important are the EXIST and DIRECTORY flags which indicate the item must actually exist (i.e. downloading needs to actually find a file, or the dir must be already created, etc) and/or that the target must be a directory and not a file. I can certainly arrange to have those passed along if it would make a difference but right now it just looks at the results of the script and applies the flags to that.

dr.owned
10-05-2009, 09:42 PM
Yil

yep, seems like if I just return resolved links from the script in all cases, everything works just fine.

as of the rest - you're the boss and i'm just a humble user :) i can't make you do what you think shouldn't be done :)

p.s. crash report.
1. virtual directory script returns resolved link to existing file.
2. this file is then RETR-ed (i'm not sure whether REST 0 or REST >0 in this case)
3. in pre_retr event i decide to decline RETR request by saying:
iputs -noprefix "550 $fname: No such file or directory."
set ioerror 1
return 1
4. ioftpd goes away.
5. note - same works fine for non-virtual transfers

who's guilty? :)

dr.owned
10-05-2009, 10:06 PM
hm... looks like if I return resolved link to a subdirectory when generating virtual directory contents, i can CWD into generated item, but ioGui shows that i'm not inside the virtual directory but inside a linked one. which makes sense but kinda spoils the fun because you can't distinguish between being in a virtual directory and being in its linked counterpart.

dr.owned
10-05-2009, 10:13 PM
and a final noob question - how do you make a mountpoint that is hidden (from everybody, except maybe only M-s) but still accessible for everyone. so users can't see it but are able to cwd into it and from there do what they want.

Yil
10-06-2009, 12:10 AM
dw.owned: There really isn't any way to hide a directory and yet have it still be accessible. You can use private settings [chattr 0] to specify who can see/access a private directory via "1 !A =group" type settings but if the user matches they can see it. I presume you want to do something like have a /_real normal users can't see and yet make everyone access stuff through virtual directories like /music or something?

You could try creating a 000 permissions directory that would show up like d--------- so it wouldn't really be hidden. Nobody but VM flagged users could enter it normally because they are immune to +r checking. The tricky part is you couldn't make normal symbolic links into that directory because access requires +r to the entire directory path. You can however try returning links into there via virtual directories. I believe I was smart though and as a safety check resolved paths from virtual directories are fed back into the system to verify +r for the whole path. I haven't tested that though so it's worth a shot...

I don't suggest VFS mountfile tricks, because I'm working on a reverse resolver to take real paths and turn them back into VFS paths as both a useful feature for scripts and as a safety feature for NTFS symbolic and junctions that could expose parts of the filesystem that shouldn't be visible.

I'm open to suggestions like 000 dirs marked as Private and thus only accessible to VM flagged users that start with a "." (to prevent exposing dirs on existing setups when upgrading by accident) should be hidden from user listings for regular users but ignore +r checks in path resolving or something. I would guess that would be similiar to -r+x style unix dirs and would suffer from user's being able to guess at names as well. If you have a suggestion feel free to chime in!

dr.owned
10-06-2009, 12:55 AM
I presume you want to do something like have a /_real normal users can't see and yet make everyone access stuff through virtual directories like /music or something?

exactly my thoughts :)

The tricky part is you couldn't make normal symbolic links into that directory because access requires +r to the entire directory path.

yep, it was my first thought. there is a trick with ntfs where you can deny directory listing permissions for the higher-level directory without applying them to lower-level children and thus hiding its contents from any unnecessary recursive searches while keeping files accessible from a lower-level directory using full path to it. it seemed pretty natural and i presumed ioftpd would do the same. but no, the server verifies read permissions for all directories in the path... too bad :( maybe it's worth being configurable? :)) like FullVirtualPathCheck = TRUE/FALSE

i also learned that there are some "undocumented" features in ioftpd :) like !vfs:add. judging by the name it should alter current connection's mountpoint list by adding one on the fly. and the next LIST command would already output new directory structure. i'd like a comment on that. what does it actually do? and if i'm correct, would there be a !vfs:remove or something like that?
i suppose you already see where i'm going with this :) !vfs:add -> process symlinks -> do file ops -> !vfs:remove -> i'm happy :)

Yil
10-06-2009, 01:56 AM
My ISP is having issues with it's FTP server at the moment... Here's a forum link to the new version.

Yil
10-06-2009, 01:56 AM
v7.0.3 Release Notes:

1) Files in \System:
Changed : ioFTPD.[exe,pdb] - Version 7.0.2.0.

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


*** New Features

3) New iTCL feature for [ioVirtual] command. The AddLink <Path> argument
and the AddDir/AddFile <Link> argument may now start with a ":" which
will be stripped off the string but modify the behavior of directory
listings so the entry will show up as a plain file/dir instead of as
a symbolic link while still keeping the linkage internally.

4) Virtual directories can now show symbolic links to files. Previously
the only symbolic links were to directories.


*** Bug Fixes:

5) Second try fixing a bug in the EXEC module that would crash the server
in some cases.

ArtX
10-06-2009, 03:34 PM
grrrr yil!!!! i just updated to 7.0.2 :D

dr.owned
10-06-2009, 09:21 PM
i'm trying to prevent direct execution of a CWD command and CWD to different directory instead. how can i do it? pre-cwd doesn't seem to help much.
it's an attempt to lock user one level below the root folder to be able to return links to other root-level directories (in virtual directory script) while user is stuck in a separate one.

Yil
10-06-2009, 09:51 PM
i'm trying to prevent direct execution of a CWD command and CWD to different directory instead. how can i do it? pre-cwd doesn't seem to help much.
it's an attempt to lock user one level below the root folder to be able to return links to other root-level directories (in virtual directory script) while user is stuck in a separate one.

I don' t think there is a way you can re-direct the user to a different location for a CWD in the normal filesystem right now. Best bet it to wait a bit for v7.1 where I can find a solution to your problem via hidden pass-through only mountpoints, +x-r dir support, the pre-cmd rewrite idea, or a feature from previous discussions which includes locking users into their home directories. Some variants of locked home dirs make it a VFS path inside a mountfile BUT it acts like '/' and you need to provide links to paths outside of it to expose directory trees. When you CDUP or CWD / you end up back in home as a special cased feature. If coupled with virtual dirs that would allow you to do whatever...

I'm also tempted to support a much more powerful form of pre-cmd. Instead of just being able to accept/reject I think it would be simple to add a new ioTCL command that would allow you to provide replacement text. Thus you could re-write CWD to redirect wherever you wanted and/or do a whole host of other cool things. You would still have to watch out for RETR/STOR/LIST /foo/bar/baz type commands as well but it would allow you to lock down where users could wander which would make it more powerful than -r+x ever could be...

Perhaps I'll have to write a script to shadow a real directory tree virtually as a local test. That might be interesting and see if I can't support virtual directory creation, etc all without too much hassle...

dr.owned
10-06-2009, 10:02 PM
wow.. so many doubts there were about my previous suggestions and all of a sudden there's a whole post promising near-ultimate features based of my reports :) and it's actually your 500-th post. is that the case? :)
anyway these are great news. can't wait :)

btw,
var Set variable value
seems to set a variable so global that even scripts triggered by other connections are able to use them. is there a way to declare connection-specific variables?

dr.owned
10-06-2009, 11:44 PM
i also often come to a conclusion that there definitely should be a pre-connect event that is triggered on a connection attempt. and from there you can choose to either accept connection (ioerror = 0) or drop (ioerror = 2, reply nothing, like there is no server at all) or reject (ioerror = 1, reply "service unavailable" or like that). because there are cases when extra connections from a certain address shouldn't even be accepted rather than just rejected later on login attempt (and having them logged in ioFTPD.log).

Yil
10-07-2009, 01:49 AM
There are a couple of points to consider when handling connections attempts. First off, there is no way short of writing a windows driver to reject a connection completely which is what I would really like to do. There used to be a way to do this years ago with winsock but then people started denial-of-service attacks against machines by initiating the TCP handshake and then not responding so MS changed the way windows works so it now always accepts TCP connections if a socket is listening for them. Therefore the server's only choice is to accept and then terminate the connection which is what happens when you get auto-banned for hammering the server.

I've taken the position that if you get auto-banned the server shouldn't respond with anything and just drop the connection. I've toyed with the idea of responding with a "you've been auto-banned" type message and the duration of the ban (it resets each attempt). I have no problem making the ban reset optional and/or making the reply optional or replying only some of the time, if people want that, but so far nobody's mentioned it. I don't think it would hurt to reply at least once and perhaps every 5 minutes there-after or something with a message to that effect. I don't believe anything should ever be returned in the case where the host is banned in Hosts.Rules.

I've also toyed with the idea of a script based accept/deny such as you are suggesting. The reason I decided against implementing it, at least until someone actually asked for it, was because external scripts are expensive to call and it's better left until later. It would be pretty easy to DDoS a server with a script handling raw connection attempts. This would be somewhat mitigated by having auto-bans checked first, but without actually knowing the username/password I figured it's best to avoid calling external scripts so I've tried to handle the common cases of rejecting valid users by allowing you to set for each user the number of connections per IP and the total number of logins.

Right now you can do exotic acceptance of login attempts by using a pre-cmd on the login or pass commands. You might also be able to do something like [iputs -nobuffer] followed by a [client kill $cid] in the OnFtpLogin event so you know you're dealing with a valid user yet you force them off. I'm not sure that's a good idea though as I'm not sure if that would always force the buffer to be completely sent in all cases which could look like a dropped connection rather than seeing a denied/logged off type message.

What I probably should do is test the return value of the OnFtpLogin event if defined and if error code text was output to the user (this would be your response to the PASS command) and an error was returned to gracefully force the user off without generating a login failed log entry as that would be up the script to do. That's going on my TODO list :)

Having given that rather lengthy response just to cover how things work right now and why, I should mention that also on the TODO list is script based manipulation of the auto-banned and permanent banned lists. I'd really like to be able to automatically add/remove addresses/masks into the server via a script...

Now, let me address the one problem I think you alluded to that might be driving the need for the accept/reject script. The ioftpd.log file is getting spammed? Check out the Max_Log_Suppression and Log_Suppression_Increment features.

Max_Log_Suppression: The maximum time (in minutes) to suppress rejection log entries (auto-banned, unmatched client, or Host.Rules) for the same reason from the same IP.

For some reason the Log_Suppression_Increment option doesn't appear in the .ini file (that's a bug) but it is documented in the Changelog...

Log_Suppression_Increment: the number of minutes to increase the delay between each suppressed message up to Max_Log_Suppression. Default is 1 additional minute per.

If you use an hour for max and an increment of an hour or so I think it should output 1 message per hour for a particular IP for each type of login error...

Would a modified version of OnFtpLogin and the log error suppression features already there solve your problem? Auto-ban manipulation (perhaps even with a limited choice of string responses) help? Should I provide a way to suppress auto-banned rejection messages completely?

I don't have any problem adding an OnConnection event like you requested, but I just want to make sure I'm helping you solve the problem you really want to solve.

--

You can't have connection specific global variables. However you can easily achieve this behavior. In ioYil I used two different methods depending on what I was doing. Just use something like foo-$cid as the name - tada! Or you can use an array of $cid->stuff mappings. However in the array case you must protect the array with a global [waitobject] lock to prevent race conditions on reading and then modifying the value across multiple threads.

ArtX
10-07-2009, 05:22 AM
v7.0.3 Release Notes:

1) Files in \System:
Changed : ioFTPD.[exe,pdb] - Version 7.0.2.0.

Little typo there Yil? or has the internal version number not been updated? :p

dr.owned
10-07-2009, 06:27 AM
Yil

no, log file spam in not an issue. but after your exhausting post i realized that scipt-controlled connection handling is really an unstable and vulnerable way to do things.

and what i think i might be off with is a function that puts given ip address to auto-ban list. since i decide to reject connection i'm confident about not having that given host connected to server again for some time.

so an auto-ban feature seems like a solution. but placing ip to auto-ban list is kinda too cruel punishment because there's that ban time auto-prolonging feature and settings in ioftpd.ini are tuned to handle ddos attempts. so maybe there's a point in giving this function parameters that specify same things present in ioftpd.ini concerning auto-ban. that would do. and since it's only about a plain ip addresses list, a function that removes specific ban or all bans should be there too.

as of deciding whether to reply or not during ban period my firm position is not to.

p.s. i found a way to lock user in his home directory ;) virtual dirs are god :)

dr.owned
10-07-2009, 06:42 AM
is there a reason why i can't specify an arbitrary-depth mountpoint? for now i either have to create full path of empty directories from a root directory or have one empty directory mounted several times once for each directory in a path.
being able to write:
"d:\ftproot" /
"d:\data\dummy" /dir
"d:\data\distr" /dir/subdir/distr
"d:\data\music" /dir/subdir/music

in vfs file without having actual "subdir" directory anywhere but inside this the vfs file would be nice.
and also having a function call:
[resolve Mount "/dir"]
return
/dir
/dir/subdir/distr
/dir/subdir/music
instead of just
/dir
as it does now. since all three intries are surely associated with that path

and yes, all my questions and requests are driven by the need of solving existing problems and are not just obscure geeky flood :)

dr.owned
10-07-2009, 09:03 AM
hmm.. it looks like i can't set a virtual directory as a home directory. instead of using directory contents generated by script server seem to expect ||resolved|| link. and i can't return a link pointing at virtual directory itself as in this case server just defaults to root directory. the only time i can somehow get it to work is when i return ||resolved|| link pointing at another non-virtual directory. but server then just CWDs into it and ceases script calls as it is already out of virtual directory.
i think it's worth fixing.

SysOp
10-07-2009, 10:01 AM
I think I've found a bug in ioFTPD-v7.0.0-src, and I don't know whether it's fixed or not. Anyway, that's it:
In .\src\Identify.c, line 1029, before "AddClientJob(..., 10005, ... lpAcceptProc ...)", there should be an additional line like this:pConnection->szIdent = NULL;
If not, when Ident_Timeout=0, in log files, users' Ident will be 4-byte random characters instead of "*".

p.s. Where can I find the newest source file? for example, v7.0.3. Are they accessible to public?

ArtX
10-07-2009, 10:04 AM
p.s. Where can I find the newest source file? for example, v7.0.3. Are they accessible to public?

Normally there are yes,Yil puts the source out with the release, but his ISP was having issues so maybe he just uploaded 7.0.3 to this server, im sure he will put a link up to 7.0.3 source in due time :) 7.0.2 source is in this thread somewhere

pion
10-07-2009, 01:54 PM
Why not put up a repository at google code or similar?

Yil
10-07-2009, 05:44 PM
dr.owned: A specifiable ban time with optional reset feature and the ability to add/remove entries via script. Will do.

You must, however, have a valid real directory tree from root for all paths in the regular VFS. There doesn't seem to be a good reason to break that behavior especially with the future option of reverse resolving paths. On the other hand the hidden/special directory option might make it look that way to a client.

[vfs mount] should return virtual mountpoints in the current directory provided they are accessible. In your example they aren't because of the missing parent...


SysOp: Yup, that's a new bug introduced with v7.0 if you use the new feature to disable ident requests entirely! Gold star :) I think that's the first fixed bug by anyone but me in the code in years! I'll look into keeping an up to date copy of the code somewhere so you can always get the latest stuff. Previously I just released the 6.X or 7.X releases as nobody really bothered with it except for perhaps FtpServerTools...

dr.owned
10-07-2009, 08:46 PM
Yil

once again, big thanks. can't wait for the new release.

and don't forget to fix home directories declared as virtual. generated directory contents must work.

dr.owned
10-09-2009, 11:09 PM
oh man, i finally persuaded ioftpd to handle virtual home directory right and managed to lock user inside it for good :)
i wish i had a more convenient way to do it :)

pion
10-10-2009, 05:39 AM
I had a weird problem with ioFTPD 6-4-3r that I don't think have been adressed in io 7. Or it could be related to lockup bug. For some reason all pasv ports where locked out! ioftpd.exe had been running with working pasv connection for a good while, control connection was fine, and port mode was working, but all of a sudden all pasv requests went to timeout. There is no firewall or router of any kind running, nor any antivirus or similar. Once I restarted the ioftpd.exe process, the pasv ports where reacting like normal.

I have no clue on how to reproduce it, or why it happened in the first place..

My question is if this bug has been discovered, and fixed with io7 or if it's still there?

I may add that this server has been severly affected by the lockup bug before, and initial tests of io7 on it seems to be stable! :)

Yil
10-11-2009, 01:00 AM
pion: That 6.4.3 issue sounds like the lockup bug, but without trying to exit the server and having the process hang around I can't say for sure. I changed the way child processes are created and tried to protect all sockets from being inherited in v7. So far several people have reported it's much more stable so I think that's part of the problem. Some people had a terrible time running under w2k3 which seemed to trigger the bug fairly frequently now have respectable uptimes.

I missed protecting the server from the TCL library as it does create sockets as well. So I'm guessing it's only 99% fixed if people are running imdb style lookup scripts as they create TCP connections and for a very very brief window new executable child processes might trigger the problem.

dr.owned
10-11-2009, 11:10 AM
is there a more convenient (and efficient) way to retrieve full list of directory entries for a given VFS path $mnt than using [resolve Mount $mnt] and cycling through each element with [glob -type f $realPath] and [glob -type d $realPath]?

Yil
10-11-2009, 07:56 PM
dr.owned: Nope, that's the "new" way to do it actually since [resolve mount] is a very new command (I haven't even had a chance to play with using it in my own scripts). Most existing TCL scripts just use [resolve pwd] and thus can't handled merged/raided directories.

On the other hand I've added the [vfs dir] command (and again haven't used it myself yet) which you can use to determine if a directory is a symbolic link and/or get the owner of the file/directory. If you need either of those two pieces of information then this may be more efficient than globbing and then individually testing the entries. I'm pretty sure nobody else is using this command yet so it's possible to change the output to include the directory attributes information (which you can use to test for dir/file/junction/etc) as that looks like it would be really useful to have. I'm also thinking of what to do with attribute #1 for symbolic links when dealing with NTFS junctions, etc since they will be treated as links but they aren't ioFTPD links so I'll either modify this command or create a new version of it that's a bit more useful...

FYI: Internally lots of things are done with real paths. Thus even the [vfs dir] feature still operates on a single real path and you will need to cycle over the [resolve mount] output or the proposed simpler [resolve pwds] command.

I ended up writing a whole lot of resolving logic for ioYil and started to run into the problems you are seeing. So I stepped back and took what I found to be duplicating internal server logic and started exposing the server's routines as exported TCL functions instead. If you look back at the changelog you can see this trend.

I'm not adverse to try to fake out the directory listing routines to generate a VFS directory entry with detailed information so you could avoid globbing and asking the server for info entirely. I can see why that would be useful but I haven't yet needed it because there is a subtle issue when dealing with writing something like nxTools. Since the server deals with real directories it's possible for 2 different mountfiles to mount 2 or more real directories in a different order onto the same mountpoint. This means that the actual permission/ownership information varies with the active mountfile. I even wrote some logic to warn users when this was occurring just to make sure it was intentionally done, but it also meant that I didn't really want everything resolved via VFS path and instead stored entries in the DB by real path and then did the merging logic myself to handle these edge cases...

But, like I said, I don't see why I can't return all the info that is visible in a directory listings to you and let you deal with those complexities for a particular user's view of the filesystem.

dr.owned
10-11-2009, 09:54 PM
Yil
yeah, i checked out [vfs dir] as well but it returned too little information so you event couldn't tell files from directories. and i ended up globing. so i welcome your suggestion to extend that function. i'll be glad to also see file sizes and creation\mod dates in the output (to fit AddFile syntax). and especially glad if it would involve some caching to speed up frequent calls. because now [glob], [file size] and [file mtime] calls take mindblowingly much time.

+ is it a feature that data connection is assigned the same ip address as the control connection that spawned it (when viewed from ioGui)? i'm asking because i'm now using FTProxy to help me where ioftpd+tcl is not enough. and it masks real ip address from ioftpd. but when i turned off data connection relaying i expected to see real ip in ioGui for file transfers. but to my surprise ip address stayed the same.
come to think of it, the ip address logged to xferlog must be the one that connects to ftp server and actually gets data (or the one that ftp server connects to on PORT command) and not the one that said RETR. i understand that i'm digging too deep and in 99.99% cases people don't care about such tiny aspects. but still, for the sake of being absolutely correct...

dr.owned
10-11-2009, 10:09 PM
i also noticed that sometimes ioftpd outputs something like this:

426 Connection closed: xxxxxxxxx xxxxxxx xxx xxxxx xxxxxxxxxx.

yes x-es instead of message. i believe that it is a winsock error messge that ioftpd failed to output correctly on a non-english system (which is my case).

pion
10-15-2009, 07:16 AM
Does io 7.03 support reading a file in use? (EG. being uploaded)

Yil
10-15-2009, 12:49 PM
pion: Sorry pion. No reading of files being uploaded, and new in v7 no reading of a newly uploaded file until the zipscript has finished processing it (to handle .nfo addition/deletion).

Smirnoff
10-16-2009, 04:53 AM
Hi

I believe I found a minor bug in 7.0.3 using ioGui:

While creating a user, I specify FTP logins 3, Telnet 0 and HTTP 0
Once the procedure completed, I check the user settings and FTP logins i always set to 0

If I leave defaut settings I got login settings: 1 0 0

Ooops
I cannot delete my test users either from ioGui
(from site command it does works: test External 3 3 * DELETED 1m 51s ago by xxxxx *)

Cheers
Smirnoff

Yil
10-16-2009, 01:21 PM
newguy: Added some functionality to the directory listing logic to track where files/dirs are coming from in merged directories. This should allow a cool feature I was playing with that allows VM users to get an idea of where things are on disk and perhaps I can even find a way to let admins manage merged directories by moving stuff between disks easily. The other reason this is useful is I can now easily recover the real path(s) to a file when listing directory entries. Now I'm going to add a TCL command to get access to a complete directory listing with full details about each file via a single call. This should be a big performance increase and should make your job really easy and be useful to other scripts as well.

Dahlia
10-17-2009, 07:16 PM
Hi,
Yil please add option for Timezones to ioFTPD.

Even in glftpd they had some troubles with that but seems they fixed timezones.

----
[from glftpd 'known bugs' file]
*) the timezone setting doesn't change time on new files/directories, and was reported to also cause major slowdowns with cookies for some people.
- not worth fixing, since the localtime fix works 100%, right?
----

So would be cool to have some option with Timezone (UTC/local server time) in ioftpd.ini too.


Thank you!

Domin
10-18-2009, 07:53 AM
I am still getting hang/crashes on ioftpd where the only fix is to kill the process and restart ioftpd.exe to make it respond again, here is my error log:

Sun Oct 18 11:17:30 2009 - ioFTPD v7.0.3
Unhandled exception: Access Violation (0xC0000005)
Address: 0x0046891D [attempting to read data from 0x5F6E699C]
PID=3516, PATH=C:\ioFTPD\system\ioFTPD.exe
Thread ID: 3212

System information:
Processor #0 Name: AMD Athlon(tm) 64 Processor 3500+
Processor #0 Identifier: AMD64 Family 15 Model 63 Stepping 2
OS: Windows 5.2 (build 3790)
Registry: Microsoft Windows XP
Decoded: Server 2003 - Service Pack 2
Page size: 4096

Modules:
--------
[00400000 - 004e8000]: C:\ioFTPD\system\ioFTPD.exe (v7.0.3.0)
[7d600000 - 7d6f0000]: C:\WINDOWS\system32\ntdll.dll (v5.2.3790.4455)
[7d4c0000 - 7d5f0000]: C:\WINDOWS\SysWOW64\kernel32.dll (v5.2.3790.4480)
[71c00000 - 71c17000]: C:\WINDOWS\system32\ws2_32.dll (v5.2.3790.3959)
[77ba0000 - 77bfa000]: C:\WINDOWS\SysWOW64\msvcrt.dll (v7.0.3790.3959)
[71bf0000 - 71bf8000]: C:\WINDOWS\system32\ws2help.dll (v5.2.3790.1830)
[7d1e0000 - 7d27c000]: C:\WINDOWS\SysWOW64\advapi32.dll (v5.2.3790.4455)
[7da20000 - 7db00000]: C:\WINDOWS\SysWOW64\rpcrt4.dll (v5.2.3790.4502)
[7d8d0000 - 7d920000]: C:\WINDOWS\SysWOW64\secur32.dll (v5.2.3790.4530)
[10000000 - 10105000]: C:\ioFTPD\system\tcl85t.dll (v8.5.2.7)
[7d930000 - 7da00000]: C:\WINDOWS\SysWOW64\user32.dll (v5.2.3790.4033)
[7d800000 - 7d890000]: C:\WINDOWS\SysWOW64\gdi32.dll (v5.2.3790.4396)
[761b0000 - 76243000]: C:\WINDOWS\system32\crypt32.dll (v5.131.3790.3959)
[76190000 - 761a2000]: C:\WINDOWS\system32\msasn1.dll (v5.2.3790.4584)
[77b90000 - 77b98000]: C:\WINDOWS\SysWOW64\version.dll (v5.2.3790.1830)
[7dee0000 - 7df40000]: C:\WINDOWS\system32\imm32.dll (v5.2.3790.3959)
[03000000 - 03121000]: C:\ioFTPD\system\dbghelp.dll (v6.11.1.404)
[7df50000 - 7dfc0000]: C:\WINDOWS\system32\uxtheme.dll (v6.0.3790.3959)
[4b3c0000 - 4b410000]: C:\WINDOWS\SysWOW64\msctf.dll (v5.2.3790.3959)
[75e60000 - 75e87000]: C:\WINDOWS\system32\apphelp.dll (v5.2.3790.3959)
[4dc30000 - 4dc5e000]: C:\WINDOWS\system32\msctfime.ime (v5.2.3790.3959)
[77670000 - 777a9000]: C:\WINDOWS\system32\ole32.dll (v5.2.3790.3959)
[7c8d0000 - 7d0cf000]: C:\WINDOWS\SysWOW64\shell32.dll (v6.0.3790.4315)
[02eb0000 - 02f02000]: C:\WINDOWS\SysWOW64\shlwapi.dll (v6.0.3790.3959)
[7dbd0000 - 7dcd3000]: C:\WINDOWS\WinSxS\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_5FA17F4E\comctl32.dll (v6.0.3790.3959)
[76920000 - 769e2000]: C:\WINDOWS\system32\userenv.dll (v5.2.3790.3959)
[71c40000 - 71c97000]: C:\WINDOWS\system32\netapi32.dll (v5.2.3790.4392)
[7db30000 - 7dbb0000]: C:\WINDOWS\system32\mswsock.dll (v5.2.3790.4318)
[5f270000 - 5f2ca000]: C:\WINDOWS\system32\hnetcfg.dll (v5.2.3790.3959)
[71ae0000 - 71ae8000]: C:\WINDOWS\system32\wshtcpip.dll (v5.2.3790.3959)
[76ed0000 - 76efa000]: C:\WINDOWS\system32\dnsapi.dll (v5.2.3790.4318)
[76f70000 - 76f77000]: C:\WINDOWS\system32\winrnr.dll (v5.2.3790.3959)
[76f10000 - 76f3e000]: C:\WINDOWS\SysWOW64\wldap32.dll (v5.2.3790.3959)
[4c9e0000 - 4c9fe000]: C:\WINDOWS\system32\wshbth.dll (v5.2.3790.1830)
[770e0000 - 771e8000]: C:\WINDOWS\system32\setupapi.dll (v5.2.3790.3959)
[68000000 - 68035000]: C:\WINDOWS\system32\rsaenh.dll (v5.2.3790.3959)
[76b70000 - 76b7b000]: C:\WINDOWS\system32\psapi.dll (v5.2.3790.3959)
[76f80000 - 76f85000]: C:\WINDOWS\system32\rasadhlp.dll (v5.2.3790.3959)
[71e00000 - 71e14000]: C:\WINDOWS\system32\msapsspc.dll (v6.0.0.7755)
[78080000 - 78091000]: C:\WINDOWS\system32\msvcrt40.dll (v5.2.3790.0)
[71e20000 - 71e70000]: C:\WINDOWS\system32\msnsspc.dll (v6.1.1825.0)
[76750000 - 76778000]: C:\WINDOWS\SysWOW64\schannel.dll (v5.2.3790.4530)
[68100000 - 68127000]: C:\WINDOWS\system32\dssenh.dll (v5.2.3790.3959)
[03470000 - 03496000]: C:\ioFTPD\lib\nxHelper\nxHelper.dll (v2.4.0.0)
[034a0000 - 03501000]: C:\ioFTPD\lib\sqlite3\tclsqlite3.dll (v0.0.0.0)
[10210000 - 10224000]: C:\ioFTPD\lib\reg1.2\tclreg12.dll (v0.0.0.0)
[03520000 - 03589000]: C:\ioFTPD\lib\tcl8.5\twapi\twapi.dll (v2.0.11.0)
[72590000 - 725dc000]: C:\WINDOWS\system32\pdh.dll (v5.2.3790.4471)
[762b0000 - 762f9000]: C:\WINDOWS\SysWOW64\comdlg32.dll (v6.0.3790.3959)
[77530000 - 775c7000]: C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.3959_x-ww_78FCF8D0\comctl32.dll (v5.82.3790.3959)
[03590000 - 0361b000]: C:\WINDOWS\SysWOW64\oleaut32.dll (v5.2.3790.4202)
[48890000 - 488cd000]: C:\WINDOWS\system32\odbc32.dll (v3.526.3959.0)
[60950000 - 60956000]: C:\WINDOWS\system32\odbcbcp.dll (v2000.86.3959.0)
[76aa0000 - 76acd000]: C:\WINDOWS\system32\winmm.dll (v5.2.3790.3959)
[71bd0000 - 71be1000]: C:\WINDOWS\SysWOW64\mpr.dll (v5.2.3790.3959)
[73070000 - 73097000]: C:\WINDOWS\system32\winspool.drv (v5.2.3790.3959)
[76cf0000 - 76d0a000]: C:\WINDOWS\system32\iphlpapi.dll (v5.2.3790.3959)
[748c0000 - 748c7000]: C:\WINDOWS\system32\powrprof.dll (v6.0.3790.1830)
[76f00000 - 76f08000]: C:\WINDOWS\system32\wtsapi32.dll (v5.2.3790.3959)
[771f0000 - 77201000]: C:\WINDOWS\system32\winsta.dll (v5.2.3790.3959)
[03620000 - 03685000]: C:\WINDOWS\system32\msvcp60.dll (v7.0.3790.1830)
[03bb0000 - 03bc7000]: C:\WINDOWS\system32\odbcint.dll (v3.526.1830.0)
[71bc0000 - 71bc8000]: C:\WINDOWS\system32\rdpsnd.dll (v5.2.3790.0)
[6a380000 - 6a39d000]: C:\ioFTPD\lib\tcl8.5\zlib1.1\zlib11.dll (v0.0.0.0)


Threads:
--------
ID: 3644 [00130000-0012fe7c]
# 1: 7D61CCC6 -> [ntdll + CCC6] ? NtDelayExecution() + 0x15
# 2: 0041BFA2 -> [ioFTPD + 1AFA2] Thread_DeInit() + 0xB2
[c:\projects\ioftpd7\7.0.3\src\threads.c, line 246]
# 3: 00450AB5 -> [ioFTPD + 4FAB5] DaemonDeInitialize() + 0x65
[c:\projects\ioftpd7\7.0.3\src\main.c, line 305]
# 4: 004511CC -> [ioFTPD + 501CC] CommonMain() + 0x8C
[c:\projects\ioftpd7\7.0.3\src\main.c, line 370]
# 5: 00451331 -> [ioFTPD + 50331] WinMain() + 0x71
[c:\projects\ioftpd7\7.0.3\src\main.c, line 517]
# 6: 004062C6 -> [ioFTPD + 52C6] __tmainCRTStartup() + 0x113
[f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c, line 263]
# 7: 7D4E7D42 -> [kernel32 + 17D42] ? BaseProcessInitPostImport() + 0x8D


ID: 3976 [02040000-0203e4f8]
# 1: 7D61C846 -> [ntdll + C846] ? NtWaitForSingleObject() + 0x15
# 2: 7D4D8C0D -> [kernel32 + 8C0D] ? WaitForSingleObject() + 0x12
# 3: 004676F7 -> [ioFTPD + 666F7] AcquireDirCacheLock() + 0xE7
[c:\projects\ioftpd7\7.0.3\src\directorycache.c, line 205]
# 4: 00468320 -> [ioFTPD + 67320] InsertAndAcquireDirCacheLock() + 0x3B0
[c:\projects\ioftpd7\7.0.3\src\directorycache.c, line 293]
# 5: 00469B6B -> [ioFTPD + 68B6B] OpenDirectory() + 0x8B
[c:\projects\ioftpd7\7.0.3\src\directorycache.c, line 1274]
# 6: 0046B227 -> [ioFTPD + 6A227] GetFileInfo2() + 0x197
[c:\projects\ioftpd7\7.0.3\src\directorycache.c, line 1414]
# 7: 0046B312 -> [ioFTPD + 6A312] GetFileInfo() + 0x12
[c:\projects\ioftpd7\7.0.3\src\directorycache.c, line 1449]
# 8: 00441A65 -> [ioFTPD + 40A65] PWD_CWD() + 0x455
[c:\projects\ioftpd7\7.0.3\src\pwd.c, line 817]
# 9: 00425561 -> [ioFTPD + 24561] Tcl_Resolve() + 0x181
[c:\projects\ioftpd7\7.0.3\src\tcl.c, line 1391]
#10: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#11: 1004701E -> [tcl85t + 4601E] TclExecuteByteCode() + 0xD5E
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 2351]
#12: 10083BDB -> [tcl85t + 82BDB] TclObjInterpProcCore() + 0x4B
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1752]
#13: 10083B74 -> [tcl85t + 82B74] TclObjInterpProc() + 0x34
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1642]
#14: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#15: 1000E92D -> [tcl85t + D92D] TclEvalEx() + 0x6ED
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 4341]
#16: 1000E22D -> [tcl85t + D22D] Tcl_EvalEx() + 0x1D
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 4043]
#17: 100662BF -> [tcl85t + 652BF] Tcl_FSEvalFileEx() + 0x19F
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 1814]
#18: 100650F0 -> [tcl85t + 640F0] Tcl_EvalFile() + 0x20
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 231]
#19: 00423C06 -> [ioFTPD + 22C06] TclExecute2() + 0x836
[c:\projects\ioftpd7\7.0.3\src\tcl.c, line 4070]
#20: 00424EB4 -> [ioFTPD + 23EB4] TclExecute() + 0x14
[c:\projects\ioftpd7\7.0.3\src\tcl.c, line 4153]
#21: 004659D8 -> [ioFTPD + 649D8] RunEvent() + 0x368
[c:\projects\ioftpd7\7.0.3\src\execute.c, line 1066]
#22: 00431738 -> [ioFTPD + 30738] SchedulerJobProc() + 0xC8
[c:\projects\ioftpd7\7.0.3\src\scheduler.c, line 569]
#23: 0041C70A -> [ioFTPD + 1B70A] WorkerThread() + 0x35A
[c:\projects\ioftpd7\7.0.3\src\threads.c, line 672]
#24: 7D4DFE37 -> [kernel32 + FE37] ? FlsSetValue() + 0x13C


ID: 3212 [02180000-0217bc3c]
# 1: 7D61D6E4 -> [ntdll + D6E4] ? NtGetContextThread() + 0x12
# 2: 7D4DA619 -> [kernel32 + A619] ? MapViewOfFile() + 0x1B
# 3: 7D4D8E5F -> [kernel32 + 8E5F] ? CloseHandle() + 0x44
# 4: 03064DE3 -> [DbgHelp + 63DE3] ? MiniDumpReadDumpStream() + 0x76B3
# 5: 0305F95D -> [DbgHelp + 5E95D] ? MiniDumpReadDumpStream() + 0x222D
# 6: 03065D99 -> [DbgHelp + 64D99] ? MiniDumpReadDumpStream() + 0x8669
# 7: 03068679 -> [DbgHelp + 67679] ? MiniDumpReadDumpStream() + 0xAF49
# 8: 7D4D132F -> [kernel32 + 132F] ? ReadProcessMemory() + 0x1B
# 9: 03065561 -> [DbgHelp + 64561] ? MiniDumpReadDumpStream() + 0x7E31
#10: 03065610 -> [DbgHelp + 64610] ? MiniDumpReadDumpStream() + 0x7EE0
#11: 0303CA83 -> [DbgHelp + 3BA83] ? SymEnumSourceFilesW() + 0x103
#12: 0045569B -> [ioFTPD + 5469B] UnhandledExceptionLogger() + 0x93B
[c:\projects\ioftpd7\7.0.3\src\iodebug.c, line 1090]
#13: 7D53556A -> [kernel32 + 6556A] ? UnhandledExceptionFilter() + 0x129
#14: 7D508F8E -> [kernel32 + 38F8E] ? HeapValidate() + 0x10C5


ID: 3848 [022c0000-022bdd08]
# 1: 7D61CCDB -> [ntdll + CCDB] ? ZwQueryDirectoryFile() + 0x12
# 2: 100A35CD -> [tcl85t + A25CD] TclpMatchInDirectory() + 0x17D
[c:\projects\tcl-v8.5.7-src\win\tclwinfile.c, line 1015]
# 3: 10065796 -> [tcl85t + 64796] Tcl_FSMatchInDirectory() + 0x66
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 1103]
# 4: 10054420 -> [tcl85t + 53420] DoGlob() + 0x150
[c:\projects\tcl-v8.5.7-src\generic\tclfilename.c, line 2338]
# 5: 10053F11 -> [tcl85t + 52F11] TclGlob() + 0x601
[c:\projects\tcl-v8.5.7-src\generic\tclfilename.c, line 1915]
# 6: 1005369B -> [tcl85t + 5269B] Tcl_GlobObjCmd() + 0xD3B
[c:\projects\tcl-v8.5.7-src\generic\tclfilename.c, line 1585]
# 7: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
# 8: 1004701E -> [tcl85t + 4601E] TclExecuteByteCode() + 0xD5E
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 2351]
# 9: 10083BDB -> [tcl85t + 82BDB] TclObjInterpProcCore() + 0x4B
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1752]
#10: 10083B74 -> [tcl85t + 82B74] TclObjInterpProc() + 0x34
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1642]
#11: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#12: 1004701E -> [tcl85t + 4601E] TclExecuteByteCode() + 0xD5E
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 2351]
#13: 10045E34 -> [tcl85t + 44E34] TclCompEvalObj() + 0xC4
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 1496]
#14: 1000F200 -> [tcl85t + E200] TclEvalObjEx() + 0x2A0
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 5095]
#15: 10017AB9 -> [tcl85t + 16AB9] Tcl_ForeachObjCmd() + 0x389
[c:\projects\tcl-v8.5.7-src\generic\tclcmdah.c, line 1818]
#16: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#17: 1004701E -> [tcl85t + 4601E] TclExecuteByteCode() + 0xD5E
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 2351]
#18: 10083BDB -> [tcl85t + 82BDB] TclObjInterpProcCore() + 0x4B
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1752]
#19: 10083B74 -> [tcl85t + 82B74] TclObjInterpProc() + 0x34
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1642]
#20: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#21: 1000E92D -> [tcl85t + D92D] TclEvalEx() + 0x6ED
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 4341]
#22: 1000E22D -> [tcl85t + D22D] Tcl_EvalEx() + 0x1D
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 4043]
#23: 100662BF -> [tcl85t + 652BF] Tcl_FSEvalFileEx() + 0x19F
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 1814]
#24: 100650F0 -> [tcl85t + 640F0] Tcl_EvalFile() + 0x20
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 231]
#25: 00423C06 -> [ioFTPD + 22C06] TclExecute2() + 0x836
[c:\projects\ioftpd7\7.0.3\src\tcl.c, line 4070]
#26: 00424EB4 -> [ioFTPD + 23EB4] TclExecute() + 0x14
[c:\projects\ioftpd7\7.0.3\src\tcl.c, line 4153]
#27: 004659D8 -> [ioFTPD + 649D8] RunEvent() + 0x368
[c:\projects\ioftpd7\7.0.3\src\execute.c, line 1066]
#28: 00431738 -> [ioFTPD + 30738] SchedulerJobProc() + 0xC8
[c:\projects\ioftpd7\7.0.3\src\scheduler.c, line 569]
#29: 0041C70A -> [ioFTPD + 1B70A] WorkerThread() + 0x35A
[c:\projects\ioftpd7\7.0.3\src\threads.c, line 672]
#30: 7D4DFE37 -> [kernel32 + FE37] ? FlsSetValue() + 0x13C


ID: 3296 [03230000-0322fedc]
# 1: 7D61CCC6 -> [ntdll + CCC6] ? NtDelayExecution() + 0x15
# 2: 7D4D14EF -> [kernel32 + 14EF] ? Sleep() + 0xF
# 3: 00429A45 -> [ioFTPD + 28A45] SocketSchedulerThread() + 0x4A5
[c:\projects\ioftpd7\7.0.3\src\socket.c, line 1797]
# 4: 7D4DFE37 -> [kernel32 + FE37] ? FlsSetValue() + 0x13C


ID: 1136 [03330000-0332ff80]
# 1: 7D61C8BE -> [ntdll + C8BE] ? ZwRemoveIoCompletion() + 0x15
# 2: 7D4DFE37 -> [kernel32 + FE37] ? FlsSetValue() + 0x13C


ID: 3144 [02e70000-02e6dd1c]
# 1: 7D61CCAB -> [ntdll + CCAB] ? ZwOpenFile() + 0x12
# 2: 100A35CD -> [tcl85t + A25CD] TclpMatchInDirectory() + 0x17D
[c:\projects\tcl-v8.5.7-src\win\tclwinfile.c, line 1015]
# 3: 10065796 -> [tcl85t + 64796] Tcl_FSMatchInDirectory() + 0x66
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 1103]
# 4: 10054420 -> [tcl85t + 53420] DoGlob() + 0x150
[c:\projects\tcl-v8.5.7-src\generic\tclfilename.c, line 2338]
# 5: 10053F11 -> [tcl85t + 52F11] TclGlob() + 0x601
[c:\projects\tcl-v8.5.7-src\generic\tclfilename.c, line 1915]
# 6: 1005369B -> [tcl85t + 5269B] Tcl_GlobObjCmd() + 0xD3B
[c:\projects\tcl-v8.5.7-src\generic\tclfilename.c, line 1585]
# 7: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
# 8: 1004701E -> [tcl85t + 4601E] TclExecuteByteCode() + 0xD5E
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 2351]
# 9: 10083BDB -> [tcl85t + 82BDB] TclObjInterpProcCore() + 0x4B
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1752]
#10: 10083B74 -> [tcl85t + 82B74] TclObjInterpProc() + 0x34
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1642]
#11: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#12: 1004701E -> [tcl85t + 4601E] TclExecuteByteCode() + 0xD5E
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 2351]
#13: 10045E34 -> [tcl85t + 44E34] TclCompEvalObj() + 0xC4
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 1496]
#14: 1000F200 -> [tcl85t + E200] TclEvalObjEx() + 0x2A0
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 5095]
#15: 10017AB9 -> [tcl85t + 16AB9] Tcl_ForeachObjCmd() + 0x389
[c:\projects\tcl-v8.5.7-src\generic\tclcmdah.c, line 1818]
#16: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#17: 1004701E -> [tcl85t + 4601E] TclExecuteByteCode() + 0xD5E
[c:\projects\tcl-v8.5.7-src\generic\tclexecute.c, line 2351]
#18: 10083BDB -> [tcl85t + 82BDB] TclObjInterpProcCore() + 0x4B
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1752]
#19: 10083B74 -> [tcl85t + 82B74] TclObjInterpProc() + 0x34
[c:\projects\tcl-v8.5.7-src\generic\tclproc.c, line 1642]
#20: 1000DD73 -> [tcl85t + CD73] TclEvalObjvInternal() + 0x283
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 3690]
#21: 1000E92D -> [tcl85t + D92D] TclEvalEx() + 0x6ED
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 4341]
#22: 1000E22D -> [tcl85t + D22D] Tcl_EvalEx() + 0x1D
[c:\projects\tcl-v8.5.7-src\generic\tclbasic.c, line 4043]
#23: 100662BF -> [tcl85t + 652BF] Tcl_FSEvalFileEx() + 0x19F
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 1814]
#24: 100650F0 -> [tcl85t + 640F0] Tcl_EvalFile() + 0x20
[c:\projects\tcl-v8.5.7-src\generic\tclioutil.c, line 231]
#25: 00423C06 -> [ioFTPD + 22C06] TclExecute2() + 0x836
[c:\projects\ioftpd7\7.0.3\src\tcl.c, line 4070]
#26: 00424EB4 -> [ioFTPD + 23EB4] TclExecute() + 0x14
[c:\projects\ioftpd7\7.0.3\src\tcl.c, line 4153]
#27: 004659D8 -> [ioFTPD + 649D8] RunEvent() + 0x368
[c:\projects\ioftpd7\7.0.3\src\execute.c, line 1066]
#28: 00431738 -> [ioFTPD + 30738] SchedulerJobProc() + 0xC8
[c:\projects\ioftpd7\7.0.3\src\scheduler.c, line 569]
#29: 0041C70A -> [ioFTPD + 1B70A] WorkerThread() + 0x35A
[c:\projects\ioftpd7\7.0.3\src\threads.c, line 672]
#30: 7D4DFE37 -> [kernel32 + FE37] ? FlsSetValue() + 0x13C



-------------------------------------------------------------------------------



And here is a link for the tinydump aso files:

[Link removed]

I am on windows xp pro x64

When i posted this poste i startede ioftpd, it have now become unresponsive but it dont seem to crash and there is no additional info in the crashlog.
What seems to be the same lock/error was also reported by other users on the irc channel a few days ago.

HiTmE
10-23-2009, 06:19 AM
Hi Yil

I have a question.
Is there a list of all possible [FTP_Pre-Command_Events] to link to ?
Is there a retr command available ?

In my case i like to catch the "retr" command.
For example:

retr = TCL ..\scripts\antileech.tcl PRERETR

Regards
HiTmE

dr.owned
10-23-2009, 11:12 PM
Yil

how soon is the next update?

and what about WINE compatibility? last time i tried to launch ioFTPd under wine it just silently failed (ioftpd ~ 6.8.3, wine ~ 1.1.1)

Yil
10-24-2009, 01:33 AM
Pre/Post commands just use the name of the command (plain) or as of v6.5+ @command (site). You should be able to use the line you wanted to catch RETR commands.

I just put together a new machine over the last day or so and am in the process of installing software. Hopefully having a real computer will allow me to run stuff easier/faster, find any multi-core/processor race conditions locally, and since it's win7 I can try out vista+ features we might want to use. I'm thinking of IO priority stuff and transacted operations for updating userfiles and .ioftpd files... So going to be a few days before I can get all my stuff ported over and begin work again when I get some free time.

fudgi
10-26-2009, 10:54 AM
doesnt ioftpd support xdupe? since i get that error that it isnt supported, but it used to work in older versions i think

Yil
10-26-2009, 11:54 PM
Nope, no built-in support for xdupe, however LOTS of 3rd party scripts are more than happy to tell you when the file you are uploading is a dupe :)

Personally, I don't like file level dupe checking and prefer it to be done only on directory names...

o_dog
10-27-2009, 06:44 AM
not what xdupe is for, it sends a list of files to the client uploading so he doesn't have to try every file if it's already there. It's just a list command reallly, but yeah there are plenty of scripts around to support it

paja1
10-29-2009, 05:39 PM
I am still getting hang/crashes on ioftpd where the only fix is to kill the process and restart ioftpd.exe to make it respond again, here is my error log:
...
When i posted this poste i startede ioftpd, it have now become unresponsive but it dont seem to crash and there is no additional info in the crashlog.
What seems to be the same lock/error was also reported by other users on the irc channel a few days ago.


Yes, i'm experiencing exactly the same...
Never had this kind of problems with v6.*.* :(
Usually it hangs after login, or at "opening ASCII Connection", or "Send Password".. and at the end it just dies... not response at all.. just listening on the port (opened socket).

No crash dump.. nothing.. happen to me up to 6x per day.. depends on the traffic on the site.
I really do like all new features in v7, especially virtual FS, but i need stability even more :(

I know, these kind of 'error reports' are not easy to follow.. but thats all i've got, so far.
I'll try to find 100% sure way to reproduce it.

Anyways it looks like it goes out of some resources, to me... dunno.

Thanks for any help with this.

Yil
10-29-2009, 06:07 PM
One thing I'd like you to try. Since the process isn't exiting, if you are running Vista/Win7/2008 try going to the task manager, clicking on ioFTPD.exe and "Create Dump File". Zip/rar the file it creates and then PM me here and I'll send you a link to an FTP where you can upload the file so I can examine it.

paja1
10-30-2009, 06:44 AM
One thing I'd like you to try. Since the process isn't exiting, if you are running Vista/Win7/2008 try going to the task manager, clicking on ioFTPD.exe and "Create Dump File". Zip/rar the file it creates and then PM me here and I'll send you a link to an FTP where you can upload the file so I can examine it.

Unfortunately i'm using Windows Server 2003 :(

Is there any other way to create dump for you? I'll do anything to help make it more stable again.

Thanks for any guide or info.

ArtX
10-30-2009, 01:19 PM
Yil - will you be adding support for IPV6 to ioFTPD?

paja1
10-30-2009, 02:25 PM
Is there any other way to create dump for you? I'll do anything to help make it more stable again.


Ok, i'we just installed Windows Debugging tools.. when it hangs again i'll start to send you minidumps... :)

Yil
10-31-2009, 11:27 PM
win7 (at least on x64) update: It appears that "site makecert" works, but for whatever reason the newly created certificate cannot be found by the ftp server until you restart it. That's not the behavior on XP, etc... Since this is a one time thing anyway during setup, it's not a big deal, but did want to bring it to your attention.

Yil
10-31-2009, 11:32 PM
Carpo: IPv6 support is actually a non-trivial change. I have little idea on how IPv6 works in practice. How do you implement user hostmasks like *@192.168.1.* or 1.2.3.* ? Do ISP's get contiguous ranges of addresses to hand out that vary at the end?

mr.babek
11-01-2009, 04:24 AM
Hey Yil,
any news on ioYIL????????

/me want =)

paja1
11-01-2009, 07:04 AM
H Yil,

i'm experiencing another "ioftpd hang" 7.0.3 again... this time is debugger not able attach to process...

Break-in sent, waiting 30 seconds...
WARNING: Break-in timed out, suspending.
This is usually caused by another thread holding the loader lock
(60c.860): Wake debugger - code 80000007 (first chance)
eax=001596f0 ebx=00000000 ecx=0000001e edx=00000000 esi=00000000 edi=00000058
eip=7c82860c esp=0012fbc8 ebp=0012fc30 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246


:(

ArtX
11-01-2009, 08:27 AM
Carpo: IPv6 support is actually a non-trivial change. I have little idea on how IPv6 works in practice. How do you implement user hostmasks like *@192.168.1.* or 1.2.3.* ? Do ISP's get contiguous ranges of addresses to hand out that vary at the end?

ATM i was just messing about with it internally, as for the isp end, until they start using it it would be hard to say how they will do it. Internally ( direct, which is how im doing it) i don't think it would be an issue and im assuming you could use the shortened version of the ipv6 address *@fe80::(some long string)

eg : fe80:0:0:0:0:0:c0a8:101 becomes fe80::c0a8:101

As the ipv4 range of address's are running out and is expected to run out in 2010/2011 i think i would start looking at ipv6 now just so i understand it, and of course have my best ftpd app supporting it ;)

http://www.subnetonline.com/pages/subnet-calculators/ipv4-to-ipv6-converter.php - is what i have been using to try and work out what the correct address would be, hopefully it will help others

Mave
11-01-2009, 04:38 PM
ioYIL?
WHats that?
a lol almost forgotten it :P

mantonio1965
11-02-2009, 04:17 PM
great job, yil. but could you please update the links to the faqs you mention in the entry description? they're all dead.

regards, mantonio

Yil
11-02-2009, 07:42 PM
paja1: "This is usually caused by another thread holding the loader lock." HA! Since I don't believe it's possible to manipulate the loader lock directly and ioFTPD is not a dll with an initialize routine with strict restrictions on what can be done during initialization, I claim it shouldn't be ioFTPD's fault :) Not sure what it is doing that is triggering the bug, but I'll keep on trying to squash it and re-writing the way it listens for incoming control connections is one of two ideas to try... [update: this is the classic lockup bug in all it's annoying glory... sad to see it's not gone as this is confirmation].

Which 3rd party scripts are you using? The other idea I've recently thought of is that I need to protect TCL's socket and process creation much like I do in the server itself. I'm guessing IMDB lookups, or calls to zip,rar executables might make the problem more likely so if you are using them it might make sense. If you have a simple server then it's most likely not that...

mantonio: Hmm, good point...

mave: pfft! I got sidetracked writing all these nifty TCL scripts to do resolving, etc and then started finding other people wanted these features for scripts and figured I'd best add them into the server :)

Good news for virtual dir coders. I'm 90% done on allowing you to enable an option to make ioFTPD preserve symlinks in paths. This is important because you can now link out of virtual dirs and CDUP will return you back to the virtual dir. PWD also reports the correct path for clients that query it after directory changes to track where you are. I'm not done testing the side effects of this, and will probably need some help there which is why this is an option. TCL [resolve]ing works as before, but new arguments to it allow you to get the new behavior. I'm still not sure what to do with $pwd though. I'm thinking I should force the path to be resolved completely as before, and add a new variable for people who want the preserved symlink'd path. I just don't know what scripts might break if the path can't be manipulated the way it was before or that multiple paths mean the same real directory...

pion
11-04-2009, 01:10 PM
Carpo: IPv6 support is actually a non-trivial change. I have little idea on how IPv6 works in practice. How do you implement user hostmasks like *@192.168.1.* or 1.2.3.* ? Do ISP's get contiguous ranges of addresses to hand out that vary at the end?

You have one external part, and one local part of the address. If you have an external tunnel broken, or isp, you get an adress which is put in front of your local adressspace. The local adresses is generated at your local machine (often based on mac address), and broadcasted to the ipv6 advertisement daemon.

Example; You set up a gateway to an external tunnel broken, put up radvd or similar as router advertisement daemon. Then you get a prefix from the tunnel broker which will be the first part of the address. Then all external calls to that prefix first hit your router daemon, which then sends the data to the correct 'internal' adress.

newguy
11-06-2009, 08:55 AM
You have one external part, and one local part of the address. If you have an external tunnel broken, or isp, you get an adress which is put in front of your local adressspace. The local adresses is generated at your local machine (often based on mac address), and broadcasted to the ipv6 advertisement daemon.

Example; You set up a gateway to an external tunnel broken, put up radvd or similar as router advertisement daemon. Then you get a prefix from the tunnel broker which will be the first part of the address. Then all external calls to that prefix first hit your router daemon, which then sends the data to the correct 'internal' adress.

Well that's not real IPv6 imo but just faking stuff.
What is ment is real IPv6 http://www.ipv6.org/

pion
11-06-2009, 02:38 PM
It's a practial use of it, even if it's through a tunnel broker it's just as much ipv6

dr.owned
11-06-2009, 11:04 PM
Good news for virtual dir coders. I'm 90% done on allowing you to enable an option to make ioFTPD preserve symlinks in paths. This is important because you can now link out of virtual dirs and CDUP will return you back to the virtual dir. PWD also reports the correct path for clients that query it after directory changes to track where you are. I'm not done testing the side effects of this, and will probably need some help there which is why this is an option. TCL [resolve]ing works as before, but new arguments to it allow you to get the new behavior. I'm still not sure what to do with $pwd though. I'm thinking I should force the path to be resolved completely as before, and add a new variable for people who want the preserved symlink'd path. I just don't know what scripts might break if the path can't be manipulated the way it was before or that multiple paths mean the same real directory...

good news :) thank you for your work

paja1
11-09-2009, 04:10 PM
paja1: "This is usually caused by another thread holding the loader lock." HA! Since I don't believe it's possible to manipulate the loader lock directly and ioFTPD is not a dll with an initialize routine with strict restrictions on what can be done during initialization, I claim it shouldn't be ioFTPD's fault :) Not sure what it is doing that is triggering the bug, but I'll keep on trying to squash it and re-writing the way it listens for incoming control connections is one of two ideas to try... [update: this is the classic lockup bug in all it's annoying glory... sad to see it's not gone as this is confirmation].

Which 3rd party scripts are you using? The other idea I've recently thought of is that I need to protect TCL's socket and process creation much like I do in the server itself. I'm guessing IMDB lookups, or calls to zip,rar executables might make the problem more likely so if you are using them it might make sense. If you have a simple server then it's most likely not that...


Hi Yil, firstly thanks for your investigation.... but to the point.
Yes, I'm using http package.


package require http

proc get_url {url} {
set h [http::geturl $url]
set r [http::data $h]
http::cleanup $h
return $r
}


An http request is called after each login. But was called in version 6.* as well, without any problem at all.

The other thing i'm doing is calling "post-processing" executable like this:


iputs -nobuffer "Executing postprocessing..."
exec $cfg_postAction [string map {/ \\} $dir]
iputs -nobuffer "Done!"


... and yes, you are probably right, because ftp sometimes refuse to connect to http server.. or hangs after calling this external executable.

But i really don't think i;m doing something wrong... do i?

Do you won't more dumps from me? Or any additional files, info?

Thanks!

Yil
11-10-2009, 03:16 AM
paja1: I don't think you are doing anything wrong. I'm just trying to determine what separates people who are seeing this problem from those who aren't. Earlier indications showed that multi-core/multi-cpu machines were far more likely to have this issue (which means a race condition) and that w2k3 seemed like to make it more likely as well. I'm trying to finish up a bunch of changes for the folks playing with virtual directories and then implement the few changes I mentioned which hopefully will fix/reduce the problem further.

I'm also going to have to go back and double check, but it's possible that the TCL socket code changed internally when the TCL libraries were updated. If that is so then it's possible this is just highlighting the flaw more... I'll have to check on that since you said v6 didn't seem to have this issue in your configuration. Any chance you could try disabling the HTTP and/or EXEC routines for a bit to see if that improves stability?

paja1
11-10-2009, 06:00 PM
paja1: I don't think you are doing anything wrong. I'm just trying to determine what separates people who are seeing this problem from those who aren't. Earlier indications showed that multi-core/multi-cpu machines were far more likely to have this issue (which means a race condition) and that w2k3 seemed like to make it more likely as well. I'm trying to finish up a bunch of changes for the folks playing with virtual directories and then implement the few changes I mentioned which hopefully will fix/reduce the problem further.


Yes, i'm running on windows 2003 server.
Yes, i do have dual core P4 CPU.


I'm also going to have to go back and double check, but it's possible that the TCL socket code changed internally when the TCL libraries were updated. If that is so then it's possible this is just highlighting the flaw more... I'll have to check on that since you said v6 didn't seem to have this issue in your configuration. Any chance you could try disabling the HTTP and/or EXEC routines for a bit to see if that improves stability?

OK, i can remove HTTP call for a while, will see if it helps. I'll keep you posted.

Thanks man!

SysOp
11-14-2009, 08:24 AM
A quite strange thing.
ioFTPD crashs right after the time when a line like this "11-14-2009 20:00:00 Rejected auto-banned IP 111.222.33.44 ()." written into "Error.log". 111.222.33.44 is not any of my IPs. Maybe this IP keeps hammering the server, but how can this make the server crashed?
Tried to set Connections_To_Ban to a very large number OR set Temporary_Ban_Duration to a very small number. It works, however, this is not the way to solve problems, isn't it?

This problem applies to every ioFTPD v7.0.* versions (at least I've tested v7.0.0 & v7.0.3). Server's using various TCL scripts including ioNiNJA, nxTools, and several home-made scripts.

Yil
11-20-2009, 08:02 AM
SysOp: Did you happen to turn on the no ident request feature in v7+? I forget who it was, but that does have a bug and the person reporting it actually sent in the one line fix too. As a workaround let it request the ident but you can use a 0 or 1 second timeout and all will work fine. If that isn't the cause I'll look for the issue locally as it should be easy to reproduce.

SysOp
11-20-2009, 09:22 PM
Yes, I've turned on the no ident request feature in v7 by setting Ident_Timeout to zero.

And about the person who found the bug, is that me: https://oss.azurewebsites.net/forum/showpost.php?p=73841&postcount=108

But I also tried my own compiled version which has been added "pConnection->szIdent = NULL;" in Identity.c, it'll still crash if somebody hammer the server.

If I am not that person, please tell me how to fix this and I can compile by myself to test. Thank you very much.

SysOp
11-21-2009, 10:14 AM
is this a typo?
Line 220 of File "./src/FtpBaseCommands.c": "AUTH SLL"
should it be "AUTH SSL"?

paja1
11-23-2009, 12:43 PM
paja1: I don't think you are doing anything wrong. I'm just trying to determine what separates people who are seeing this problem from those who aren't. Earlier indications showed that multi-core/multi-cpu machines were far more likely to have this issue (which means a race condition) and that w2k3 seemed like to make it more likely as well. I'm trying to finish up a bunch of changes for the folks playing with virtual directories and then implement the few changes I mentioned which hopefully will fix/reduce the problem further.

I'm also going to have to go back and double check, but it's possible that the TCL socket code changed internally when the TCL libraries were updated. If that is so then it's possible this is just highlighting the flaw more... I'll have to check on that since you said v6 didn't seem to have this issue in your configuration. Any chance you could try disabling the HTTP and/or EXEC routines for a bit to see if that improves stability?

Hi Yil,

so i've disabled HTTP calls, and kept just EXEC ... still the same, so looks like problem in "long" running exes is a problem.

Pavel

Yil
12-01-2009, 04:36 PM
I think I taught ioFTPD about NTFS junctions/symlinks. You can now keep the current functionality which is to just ignore them entirely which might be needed for compatibility and in case the new features don't work right (IGNORE option). Or you can let the server keep file information just once for the target directory and create a placeholder link for the junction/symlink (SHARE option). For servers with tons of links this should reduce memory usage and it helps the server keep directory timestamps up to date and to track changes better. There is also another mode which I find particularly interesting. Not only does the server know about the links but it attempts to show them as links in listings by dynamically reverse resolving the target directory to a VFS path (SYMLINK option). This has two advantages to my mind. You can delete links in FTP clients like Flash without it trying to delete the contents of the directory itself, and it's obvious that you are dealing with a link and not a directory. The fake link itself has the same owner/timestamps/etc as the target directory automatically.

No matter what option you use, broken symlinks are now no longer hidden in listings and if you are a VM flagged user it will show you the real path that is missing as the target of the link. Permissions are set to 000 to make broken links stand out as well.

If you are using the SHARE/SYMLINK options you can also enable a safety feature which prevents accessing files/directories that are not explicitly exported via the VFS file. Thus a NTFS junction/symlink to c:\windows wouldn't work since it's unlikely you actually put that into a VFS file. Sort of a safety feature for badly formed links. This was never a worry with ioFTPD symlinks because they have to be valid VFS paths already.

I've got a ton of other changes, and a lot of testing still to do. I'll likely try to finish things up sometime next week and hopefully get a few of you to try out the new features as I'll need help testing so many low level internal changes.

Mave
12-05-2009, 06:37 AM
Hey i still getting mass of error converting strings in my logs.
What kind of error is it anyway? What use to put them in the logs?
Would be nice to have a disable funktion cause it expands the log file tremendious.
Btw so after a year of waiting for ioYIL the project is canceled?? Darn


Greet

Yil
12-05-2009, 04:51 PM
Mave: the converting string error is actually tied to me using a too small temp buffer when converting the name of the waitobject (I think it was) which was a feature ioNinja v0.8+ uses. It's fixed in the next release and you shouldn't see any more of those. I couldn't find it when it first showed up because I was using 0.7x and didn't realize that wasn't the latest ioNinja release so the problem never showed up for me.

Not really sure where ioYil is going. I actually put a fair amount of effort into it. The problem was it took a bunch of time to write useful features for me and future script writers. At that point though I decided some of it just made sense to put into the server itself for speed and easier use by other scripts. Several insanely useful things like ioArgs will be loved by any script writer and were definitely worth doing in the server. I haven't abandoned the project, but not sure where it's going right now...

Mave
12-06-2009, 02:48 PM
A ok nice to hear the error convering string is soon history :)
Ok great to hear the ioYIL project didnt die. Well its even cooler since you can make ioYIL use those ones :D

Yil
12-21-2009, 02:44 PM
Wrote a help command for the next release that takes simple .ini style files and looks up information and shows it to the user while running it through the cookie parser. Script writers can now create their own .ini files for their new commands and all users have to do is add the path to the file to the ioFTPD.ini file under [help].

I also wrote a separate TCL script that parses some simple section identifiers, colorizes the text by highlighting <args>, etc and then boxes the result by putting a border around everything. This parser can be used by script writers as well to get fancier output; all built-in commands will use this. This may also allow the help file to be translated into web pages and/or menu commands for FTP clients in the future.

I've started documenting the commands and am about 1/5 of the way through now. Hopefully this will make things easier for people in the future.

dink-puller
12-21-2009, 04:29 PM
Man, I am so psyched about how you have rescued IO from the obsolescence. It's always been a badass, and it's just getting badder. Thanks so much.

mr.babek
12-21-2009, 04:49 PM
Hey Yil,

Fantastic work! Good to see you diod not forget about IOyil! YEEHAW... would love to see it appear ....

keep up the good work

ArtX
12-21-2009, 07:29 PM
if we leave out milk and cookies will santaYil give us a special present ;)

Yil
01-13-2010, 03:38 AM
Needless to say writing help files isn't the most interesting thing to do and thus I'm making slow progress as I get distracted easily... I did my first pass at all the site commands (minus site change) and most of the regular FTP commands but I put references to a few general topics like permissions and user flags that I never wrote up. I also found it necessary to try to strike a balance between what goes in the help file and what doesn't. Regular FTP commands are geared more towards regular users but even they require some documentation about why they can't delete or resume a file that it appears they could based on just directory permissions for instance. On the other hand site commands for SiteOps I felt could contain reference to settings in the .ini file that affected the command even if only the owner could modify it.

Based on that documentation work and looking at the code to try to make sure I got all the options I noticed a few holes or things that command didn't really do well so I've also modified/added a few new features as well.

I'm working on writing the ChangeLog up now as several people have sent me lockup/crash reports and while I learned nothing new, I'm hoping the next release can reduce or fix that so I'm just going to put what I got out there now. Not sure if it will have the help stuff included or not, or if another release will shortly follow this one with help and fixes to whatever I managed to break in this release. Remember, this has a some serious low level changes in directory caching to support NTFS reparse points, paths don't have to be fully resolved but can preserve symbolic links so the resolver got another overhaul, and the listing code had to change as well...

There are I'm guessing 50+ changelog entries so it will still take me a bit to make one line reminders into real entries and write some useful stuff about the new options in the .ini file but we should be talking days not weeks.

ArtX
01-15-2010, 07:53 AM
Great when you release your new version i can update and change ioFTPD+ioA+ioB2.fce - have been meaning to check and correct that file so it is for ioftpd and ioninja, but like you i get distracted easily :-)

ChaosKiller
01-16-2010, 07:28 PM
Thanks a lot :D

o_dog
04-03-2010, 07:06 PM
is it just me having trouble with "426 Data connection: Broken pipe." site just hangs in uploda and i have to hard abort then reupload, it doesn't time out as it should. Dunno what tha hell is going on or if it's my link