Last chance for bug/suggestions!

[Yil]

Last chance for letting me know of something you want fixed or added. I don't promise anything, but I REALLY appreciated the heads up on old script breakage in 5.8.8 because that would have sucked with older stuff. Actively maintained stuff can just recompile but lots of people look like they are using older tools.

I obviously didn't get anything out last week, BUT I'm almost done a rewrite of the code that prints directory listings... With a little more work it should print RECURSIVE (aka ls -alR) listings. I don't think that anybody else does that on windows! I've also added a permission flag so you can enable/disable recursive access. I can see disallowing it to everyone but the master account which could generate ls-alR listings every few hours and drop them in the root dir or something.

I'm also curious about one other thing, that I haven't look into at all. Anybody want to comment on having ioFTPD calculate the CRC for uploaded files on the fly and pass that to scripts? Perhaps just on newly created (non-resumed) files. This might make TCL zipscripts far better, and would certainly cut the time normal scripts require for larger files that might not be in memory cache.

LONG term... suggestions for script writers about ways to avoid creating a process for every upload sounds good to me as well. Leaving processes with redirected stdin/out sounded good to me. Or perhaps some way to register a window handle for notification. I'll leave ideas up to the folks who know better than I :)

[FTPServerTools]

Who is in charge of the sourceforge project? I had my account that allowed me to upload changes as well but since my email changed I lost it. I have already solved the whole stdin and stdout redirection in my servuevent.dll and the trick would be quite similar. On the fly crc is good but it is never a guarantee that the files are ok. It is only a a guarantee that if the crc says it is bad then it is bad. Someone can upload a bad file, the on the fly crc says a value so only in an sfv it is usefull. But for zip files and so you still need the old fashioned scripts.

[Flow]

- Maybe add an systray Icon for online/ofline/idle/upload/download indocation.
- Builtin service-installer.

But im pretty sure that is on the development projekt, for now lets us have a working/stable version to play with.

[Yil]

No clue on sourceforge status. I think Neoxed might have some rights, but when I downloaded the code 2 weeks ago I didn't recognize the name of the admin. I think I'll just put the source tarball and a pre-built release online at my ISP. I honestly don't think anyone besides me is playing with the older codebase right now so it's not like there's a whole lot of code control necessary :)

On the fly crc is good but it is never a guarantee that the files are ok. It is only a a guarantee that if the crc says it is bad then it is bad. Someone can upload a bad file, the on the fly crc says a value so only in an sfv it is usefull. But for zip files and so you still need the old fashioned scripts.


You know, that's a great point I overlooked, you still need to test zip integrity unless the whole thing got more complicated and it computed the CRC for files IN the zip based off the header info just as a regular zip tool would. If you think about it this requires no real extra work since you'd still be computing the CRC just once, but over disjoint pieces of the file as it's being transfered based on the position info from the file's header which conveniently is sent first. I guess I'll leave this to the zipscript folk for now especially since I doubt many of them actually parse the zipfile themselves. I think everybody uses 3rd party libraries which means they wouldn't know what to do with passed in filename/CRC's anyway...

Flow: good suggestions. I actually run ioFTPD as a service myself and an installer would be nice, but I think some docs on how to do it might be enough. If you can edit ioFTPD.ini to setup the server you can probably install it as a service given a little direction. It doesn't help that I don't have any experience with writing fancy installers so I'll leave that part to someone else. ioGUI2 is your systray icon :) Seriously, the tcl version won't have any service/user desktop interaction issues which matters to me since I run ioFTPD as a different user with limited rights and I'm guessing Vista would only make that worse.

[FTPServerTools]

Lol I parse the zip AND the rar files in my scripts. Without an sfv I can detect broken rars with my FTPLogger. Anyway I agree that flycrc isnt that important.

[tuff]

with 588r i experience random crashs if i leave a client connected and idle for a period of time (which i aint bothered to time/test yet) ioftpd does not crash itself, you can logout/in again and its fine, it just seems the connection stalls and you cant cdup etc etc. this is with vista x64

[tuff]

ioftpd already pass`s crc info to any script

the onuploadcomplete event passes this info via $args to tcl

[Yil]

Tuff is right on this one. Whole file CRC is available now. I searched the code for references to the CRC function and dismissed where it was occurring because it's queued to the encryption thread. Silly me. Have I mentioned that nothing is documented with purpose, argument options, or return values?

Two other TRIVIAL to implement (I've already figured out where/how) ideas for feedback:

1) A universal pre/post event. Thus you could capture and/or approve every command before command specific events are run or the command itself. Primarily I wanted something like this a long time ago so I could compute real idle times but now I view this as an essential logging tool for debugging purposes. I was thinking of just duplicating everything being sent to the client to various logfiles and that might still be a good idea because it's more detailed, but this would be pretty powerful and easy to do and doesn't preclude full logging later on.

OnPreEvent =
OnPostEvent =

2) A configurable idle timer: instead of any successful command updating the idle time you can choose to ignore some...

Idle_Ignore = NOOP CWD PWD LIST NLST STAT PASV

This simple change seems pretty useful and would allow the idle timer to kick off anyone who doesn't actually download/upload a file or do something else constructive. It would definitely defeat most anti-idle FTP client logic and being configurable can adapt as needed.


Tuff: One quick question on that lockup issue. Were you sending NOOPs or something else every few minutes or did you just have a really long idle timeout set? I've had Flash with NOOPs ever minute stay connected for long periods of time just fine while testing, but haven't tried a long timeout without sending anything. And are you talking 30 minutes, 12 hours, or 5 days?

[ArtX]

make sure alcobot works :) - that is if you have fix shared mem anyway ;)

[tuff]

i send NOOP`s and it usually happens over night, so im guessing hours

regarding your Pre/Post event, every command is already supported in the ini for these already

[FTP_Pre-Command_Events]
[FTP_Post-Command_Events]

you can add anything you can think of to either of those ie.

user = TCL c:\ioftpd\scripts\test.itcl
pass = TCL c:\ioftpd\scripts\test.itcl

dele, stor, rmd, mkd, etc etc etc, all commands are useable there

[Yil]

Yup. You can enumerate every command in the pre/post section, and most importantly for this discussion you can have more than one line each of which must succeed. The problem isn't that you can't do it, it's that it's sorta a pain in the rear to turn it on/off for logging purposes hence a catch all I thought would be nice. I was also looking at allowing the post command to get the error code which caused the command to fail which is something that can't be done now since the command failing preempts the current post event being executed...

[tuff]

personally i think that would be totally useless

if ive picked you up correctly youd need to run a error checking script after EVERY post/pre script, what sense does that make?

if scripters need to catch errors in this way they need a slap

a simple dele = TCL c:\my\errorhandler.itcl dele script

errorhandler.itcl would simply run another script/all scripts based on the pre/post command its triggered by

ie.

if {![info exists args]} {return}
set error ""
if {[string tolower $args] == "dele"} {
source "c:/ioftpd/dele.itcl"
catch {dele} error
}

the example would load your dele.itcl and execut the proc in that script "dele" and simply return any errors which your 1 script can deal with

io`s SystemError.log also gives enough info

dont get me wrong, atleast your thinking about io, but i honestly see most of these additions as fluff.

[_panic_]

No clue on sourceforge status. I think Neoxed might have some rights, but when I downloaded the code 2 weeks ago I didn't recognize the name of the admin. I think I'll just put the source tarball and a pre-built release online at my ISP. I honestly don't think anyone besides me is playing with the older codebase right now so it's not like there's a whole lot of code control necessary :)

the admin account on sourceforge is me. i'm more than happy to give you commit access and other rights to that repository if you give me your sourceforge account name.

do you have a sourceforge account?

[mr_F]

hey yil,

i haven't had a chance or time to look at the codebase, but i'd really like to see this bug fixed:
http://www.inicom.net/forum/showthread.php?t=8245
it STILL causes me a headache ;P

[ChipMunk666]

a gui would be cool to have aswell but i guess that isn't the important thing...

[EwarWoo]

a gui would be cool to have aswell but i guess that isn't the important thing...
A GUI would be completely against the purposes of io. I would hope you'll be waiting a long time to see that happen.

GUI needs to remain an optional add-on only. Try ioGUI, thats pretty good.

[Yil]

... i'd really like to see this bug fixed:
http://www.inicom.net/forum/showthread.php?t=8245
it STILL causes me a headache ;P

First off, I'd like to see the ACTUAL onDelDir command line from your ioFTPD.ini file because I don't think it's a plain line like OnDelDir = EXEC ..\scripts\args.exe

By default OnDelDir gets 2 arguments after the path of the script, the real directory path being deleted and the VFS path, but you have 3.

Using your example I'll show you where the error is and why it doesn't happen unless you add in the extra parameter which you shouldn't need.

..\scripts\checkscript.exe "f:\[---new---]" "f:\[---new---]\test" "/admin/f-root/[---new---]/test/"

And in the drive-root case I'm guessing you're actual command look like:

OnDelDir = %EXEC ..\scripts\args.exe %[$path]

which turns into

..\scripts\checkscript.exe f:\ "f:\shitsdfjfsdkjlfsd" "/admin/f-root/shitsdfjfsdkjlfsd/"

Notice the trailing \ in f:\ and that the expanded cookie isn't enclosed in quotes. I'm guessing you then parse the line and the \ escapes the [space] and thus the first argument runs into the second... all bets are off after that.

Or maybe it turns into

..\scripts\checkscript.exe "f:\" "f:\shitsdfjfsdkjlfsd" "/admin/f-root/shitsdfjfsdkjlfsd/"

And again the \ quotes the next character the " which then goofs everything up...

There really is no reason to need the %[$path] argument, just compute it from the directory name by removing 1 path level. Or else arrange to quote the expanded cookie safely or parse the line differently...

[FTPServerTools]

My args.exe seems to still get used. :)
So stupidly simple is such a program and still handy...

[mr_F]

no dice ftpservertools, my checkscript.exe still gets used ;)
i guess we both ended up making the same program