ioFTPD v6.1.0 Beta Released

[tuff]

Yil, btw, your missing the resolve group <group> from the itcl docs

[spirit]

Originally Posted by Yil

Spirit: check that ioGUI is setup in your ioFTPD.ini file correctly. Both the TCL command and permissions for it. I remember I had that same problem and I think that was the issue.

Yep it was the problem ehhh sry for taking time, cant believe ive configured it incorrectly :|

[PSA9]

is ioFTPD set to where user ioFTPD can only connect from 127.0.0.1 ?

in windows vista 32 Bit ioGUI worked as normal, but ioGUI does not work in 64 bit vista and i trying to do a clean install for testing before i use it on the 1.5TB FTP. ioGUI is not needed but i atleast need to log in from FTP 192.168 IPs, but when i try that i get this

[R] Connected to ioFTPD
[R] Connection failed (Connection lost)
[R] Delaying for 15 seconds before reconnect attempt #1

ioFTPD-v6.1.2 no settings, no scripts, clean install
Windows Vista Ultimate 64 Bit

[ArtX]

C:\ioFTPD\etc\Hosts.Rules - i think you should be able to work out what you need to change in there - if you havent already

[hukker]

Originally Posted by PSA9

is ioFTPD set to where user ioFTPD can only connect from 127.0.0.1 ?

Its in the userfile, /users/0 probably, edit that when ioFTPD is off. Change the ip to whatever you want.

[ArtX]

but if the host rules are set to deny all but 127.0.0.1 that wont work, untill he changes the rules in the host file, unless he never put an ip in for the user when he made the account

[PSA9]

thanks hukker and carpo but hukker u were right and carpo u was wrong. cause from a fresh install

ACCEPT I 127.0.0. ADMIN -1
ACCEPT I 192.168. ADMIN -1

and as i was trying to connect from 192.168 it had to be something else. i just didn't know if Yil set it inside ioFTPD to not let u connect unless 127.0.0.1 but all in all it was just ip restricted to that ip but thanks!

[Yil]

I know I'm going to regret saying this... I can't believe I'm going to say this... But nobody has had a crash yet? If you're running it as a service double check for a crash log since the service will auto-restart or check your Windows event log for restarts. Make sure it is a v6.1.2 crash as well since I know 6.1.1 can randomly crash with resumed uploads.

I didn't want to proceed with development if things weren't stable, so just checking...

[Zer0Racer]

Originally Posted by Yil

I know I'm going to regret saying this... I can't believe I'm going to say this... But nobody has had a crash yet? If you're running it as a service double check for a crash log since the service will auto-restart or check your Windows event log for restarts. Make sure it is a v6.1.2 crash as well since I know 6.1.1 can randomly crash with resumed uploads.

I didn't want to proceed with development if things weren't stable, so just checking...

I had those low-level crashes with 6.1.1 but then I cleaned up my ioFTPD.ini from a couple of unused events and commands, at the same time as I upgraded to 6.1.2 and now everything seems stable. Not running it as a service btw.

Since I don't think you changed anything major for 6.1.2 that would eliminate that low-level stuff maybe the problem is how ioFTPD handles particular (unused/not valid) settings from the ini. Two things I remember changing ;No_SubDir_Sizing = True (note the semi-colon = commented/not used) to No_SubDir_Sizing = False and that I removed some oooold chached message files.

You can run it in debug mode now since you found out Netlimiter screwed up socketclose() or what it was? Imho 6.1.2 should be properly debugged and if everything seems OK it could even be labeled as stable. It would be a perfect stepping stone for moving on with new features etc. Users would always have this 'stable' version to revert to.

/ZR

[Flow]

Hi Yil!, sorry to comfirm this, but service is running fine, darn, no crash

[Mave]

Hey YIL

I,m running it also not as a service and its looking stable
Not crashed yet at all.


Great

[PopWeasel]

Originally Posted by Yil

I know I'm going to regret saying this... I can't believe I'm going to say this... But nobody has had a crash yet?

Running 6.1.2, LIST -T seems to be able to cause reproducible crashing.

[Yil]

PopWeasel: Confirmed. I used a $ instead of a % in one of the formatting options for the date. That meant the option didn't get interpreted correctly and the resulting string was longer than the temp buffer. The good news is I'm using the secure version of sprintf and an exception is being thrown when it sees the buffer is too small. That makes finding problems easy

New Version:
ioFTPD-v6.1.3.zip

v6.1.3 Release Notes:

1) Removed the never implemented OnServiceStart and OnServiceStop events from
   the ioFTPD.ini file.

2) Fixed the formatting string for printing dates via list -T.

[PSA9]

Yil this path

C:\ioFTPD\source

has nothing to do with making ioFTPD operate right? if so why not get rid of it?

[Yil]

PSA9: The source\include directory is actually necessary if you are building 3rd party executables that use shared memory to talk to ioFTPD. Most of the files aren't used, but rather than split out just the necessary headers into a separate dir, ioFTPD at one point in the past started distributing all the real header files... I've updated the headers anytime a shared memory data structure gets touched which isn't very often, but they are up to date for the intended purpose.

Sha1 is used to hash user passwords which is often useful for scripts, and the sharedmemory dir is really just an outdated example, but better than nothing for someone interested in writing something new.

You are correct that none of those really need to be included to just run ioFTPD, but an argument can be made they are really necessary for end users writing scripts so it can't really hurt to leave them there. They compress pretty small anyway.