ioFTPD General New releases, comments, questions regarding the latest version of ioFTPD. |
03-12-2007, 02:02 PM
|
#1
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
Last chance for bug/suggestions!
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
|
|
|
03-12-2007, 02:48 PM
|
#2
|
Senior Member
FlashFXP Beta Tester ioFTPD Scripter
Join Date: Sep 2002
Posts: 543
|
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.
|
|
|
03-12-2007, 03:20 PM
|
#3
|
Senior Member
FlashFXP Beta Tester ioFTPD Foundation User
Join Date: Dec 2001
Posts: 306
|
- 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.
|
|
|
03-12-2007, 06:04 PM
|
#4
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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
Quote:
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.
|
|
|
03-13-2007, 03:19 AM
|
#5
|
Senior Member
FlashFXP Beta Tester ioFTPD Scripter
Join Date: Sep 2002
Posts: 543
|
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.
|
|
|
03-13-2007, 01:15 PM
|
#6
|
Senior Member
FlashFXP Registered User ioFTPD Scripter
Join Date: Jan 2003
Posts: 277
|
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
__________________
#iotools #ioftpd (both on efnet)
|
|
|
03-13-2007, 01:19 PM
|
#7
|
Senior Member
FlashFXP Registered User ioFTPD Scripter
Join Date: Jan 2003
Posts: 277
|
ioftpd already pass`s crc info to any script
the onuploadcomplete event passes this info via $args to tcl
__________________
#iotools #ioftpd (both on efnet)
|
|
|
03-13-2007, 02:26 PM
|
#8
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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?
|
|
|
03-13-2007, 05:06 PM
|
#9
|
Senior Member
FlashFXP Beta Tester ioFTPD Foundation User
Join Date: Jan 2004
Posts: 301
|
make sure alcobot works - that is if you have fix shared mem anyway
|
|
|
03-13-2007, 06:49 PM
|
#10
|
Senior Member
FlashFXP Registered User ioFTPD Scripter
Join Date: Jan 2003
Posts: 277
|
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
__________________
#iotools #ioftpd (both on efnet)
|
|
|
03-13-2007, 07:08 PM
|
#11
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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...
|
|
|
03-14-2007, 10:10 AM
|
#12
|
Senior Member
FlashFXP Registered User ioFTPD Scripter
Join Date: Jan 2003
Posts: 277
|
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.
__________________
#iotools #ioftpd (both on efnet)
|
|
|
03-15-2007, 10:20 AM
|
#13
|
Senior Member
Ultimate Scripter
Join Date: Jul 2005
Posts: 153
|
Quote:
Originally Posted by 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
|
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?
|
|
|
03-23-2007, 04:59 PM
|
#14
|
Member
FlashFXP Beta Tester ioFTPD Foundation User
Join Date: Jul 2005
Posts: 33
|
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
|
|
|
03-24-2007, 07:05 AM
|
#15
|
Senior Member
ioFTPD Foundation User
Join Date: Jun 2003
Posts: 220
|
a gui would be cool to have aswell but i guess that isn't the important thing...
|
|
|
Thread Tools |
|
Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 01:10 AM.
|