ioFTPD v6.0 is HERE !

[Flow]

hukker: any ioFTPDcrach.log on you C:\ ??

[tizio]

news about iosharedb and ioftpd 6.0.4?
nobody is successful to make to work it?

[hukker]

Flow; Yeah I looked at the server today, here are some of the latest lines.

Unhandled exception 3221225477 at address 0x879111e0 (0x00000000)
0x00000000 0x879111e0 
Unhandled exception 3221225477 at address 0x879111e0 (0x00000000)
0x00000000 0x879111e0 
Unhandled exception 3221225477 at address 0x76f51e13 (0x00000000)
0x00000000 0x980015c5 
Unhandled exception 3221225477 at address 0x76f51e13 (0x00000000)
0x00000000 0x980015da 
Unhandled exception 3221225477 at address 0x0042ed4f (0x00000000)
0x00000000 0x04014e55 
Unhandled exception 3221225477 at address 0x0042ed4f (0x00000000)
0x00000000 0x6c01c64c 
Unhandled exception 3221225477 at address 0x0041ae23 (0x00000000)
0x00000000 0x3d5a4e5a 
Unhandled exception 3221225477 at address 0x7c836d0b (0x00000000)
0x00000000 0x65746577 
Unhandled exception 3221225477 at address 0x0042ed4f (0x00000000)
0x00000000 0x0c014cda 
Unhandled exception 3221225477 at address 0x0041ae23 (0x00000000)
0x00000000 0x7b83085f

[Yil]

The logfile doesn't have timestamps, so could you delete the file and see if it gets any new entries? Prior to 6.0.3 fixing the already existing memory issue the server was unstable and died lots of places and I bet that's where most of that is coming from. Since the addresses are version specific, only new entries running against a known version make any sense to me.


Update: I wrote a very simple service installer, and am now adding the service control logic into the server itself...

[hukker]

Yil; Ill do that, I looked at the date the file was last editet though and it was about 22pm last night, which is about the same time the server died. Anyways Ill delete the log and catch any new stuff thats entered.

Id look at the last part of what I pasted... Unhandled exception 3221225477 at address 0x0041ae23 (0x00000000) 0x00000000 0x7b83085f

Is the log only written to when its an ioftpd crash or is it written to if the server box it self crashes aswell, which then crashes ioftpd and adds an error msg to the logfile? is this possible at all?

[hukker]

Yil: Heres something you can reproduce, it has to do with No_SubDir_Sizing = True

New install of ioftpd, I just simply changed host / port and enabled No subdir sizing and Hide_Xfer_Host in ioftpd.ini
my root looks like this
/
/test
/test/test1
/test/test2

try uploading a file "crap.txt" with some text in it, inside /test/, both test1/test2 will disappear from the dir. If you remove the crap.txt file, both folders appear again.

disabling No_SubDir_Sizing fixes all this, but I hope it can help you in some way of finding the error

[Yil]

Hey Hukker, I can confirm that something fishy is indeed happening with the No_SubDir_Sizing option (but I guess we knew that already), but a big thanks for the simple test case! I think I have an idea of what is going on and a possible solution but for the moment just disable the option...

As for crashing, the timestamp probably reflects the last time the file was modified so the last line (which showed up more than once in your list anyway) is probably valid... I can look that one up and try to find the line(s) having an issue. A quick look shows it to be inside the FTP_New_Client() function which I presume means someone had just connected to the server when it crashed...

[pion]

To be able to download a file that's getting uploaded.

VLC is able to read a file while it's being written, so I suppose ioFTPD can do the same somehow

[tuff]

iorefresh

proc iorefresh {} {
global path
vfs flush $path
return 0
}

iorefresh


place that in your ioftpd.ini on pre list event

[Yil]

pion: I'm pretty sure that's a bad idea... First off, it IS possible to download a file being uploaded right now. Tuff's solution shows you a way to see the file right away in a listing, but you could always access it by name or see it if the directory was being modified such as by another racer.

More importantly however is the fact that the file isn't complete. If you download faster than the sender you will hit the end of the file and think you got the whole thing. That's not good. The uploaded file won't have been crc verified yet, but that's not a big deal. What might be a big deal is if a zipscript mucks with the file itself by stripping out comments or NFOs. Now it either won't be able to do this while your reading the file or it will and you'll get a corrupted file...

In theory the file should be locked from the start of an upload until all events complete. That's not done today though...

[pion]

It seems to be working quite nice on glftpd.. if you download faster than the file is uploaded, the server just keeps sending data at the rate it's uploaded when you hit that spot until the file is complete. Don't know how it's actually implemented tho

[ArtX]

Unhandled exception 3221225477 at address 0x20b0b56b (0x00000000)
0x00000001 0x00000008
Unhandled exception 3221225477 at address 0x20b0b56b (0x00000000)
0x00000001 0x00000008
Unhandled exception 3221225477 at address 0x20b0b56b (0x00000000)
0x00000001 0x00000008

ioftpd seems to crash when i am fxping on the gbit lan (say lan two pcs with gbit nics via cross over cable)

box 1

xp sp2 - all updates
ioftpd 6.0.4
nxtools 1.0.5a
ioSFV v2.0beta1.54

box 2

vista ultimate - all updates
ioftpd 6.0.4
nxtools 1.05a ( nxclose diabled as it sticks on pass otherwise)
ioSFV v2.0beta1.54

didnt seem to do it ( as much) when box 2 was xp sp2

[hukker]

Carpo: you sure it doesnt have anything to do with the outdated iosfv version

[ArtX]

ioSFV v2.0beta1.54 uploaded
By tuff
Published: April 8, 2007

so no i dont think its anything to do with the "outdated" version ;p

[tuff]

pfft, outdated! iosfv is the only actively developed sfv checker for io!

/me slaps hukker

;P