4k bug info

[Yil]

I'm looking for any info on how to reproduce the 4k .ioFTPD bug. I'm running 5.8.4 which should have it.

I've got a directory of 300ish files and two logins each doing a chmod or chown on all the files while a third login randomly deletes a file or two and enters/leaves the directory. No immediate luck.

Hard to fix it (if it even exists in the sourceforge code) if I can't reproduce it... So let me know under what situations/configurations you've seen the problem. In particular has anyone had a directory corrupted using plain ioFTPD, or does it require a zipscript that is adding/creating files outside of ioFTPD. Do you only notice the problem the next time you start ioFTPD? Did it shut down incorrectly right before that?

Thanks.

[jeza]

i think problem was by tuffs zipscript, iosfv is writing race info to .ioftpd files i think

*** edit by tuff: you should know better :P ***

[EwarWoo]

i think problem was by tuffs zipscript, iosfv is writing race info to .ioftpd files i think

Nope, otherwise people would have just avoided his zipscript ;)

Can't say what causes it but it occurs on lotsa different setups.

My usual base setup is ioFTPD, ioA, dzsbot, php_psio, newdir, sitewho, sC, nxIoFileCheck.

nxIoFileCheck definately isn't the cause, it's a work around to get past the issue and I *think* it ocurred before I started using sC.

If any of the people who went with purely nx scripts have the issue that will rule out all of the above.

Not really noticed anything about when it occurs, and it's usually noticed when the site starts random crashing which is eventually narrowed down to occurring when someone enters a particular dir (or at least, that was the case before the nxIoFileCheck script, now it's often picked up before it's noticed).

And from what I remember said of it by D1, I don't think the issue is that io files get over 4k per se, the issue is that he didn't forsee it occurring so the variable that handles io files can't deal with over 4k.

It could even be if you're working on the wrong build it's not there, panic fixed it in 5.8.6 I think, it just then had other issues.

[Yil]

The code release on sourceforge appears to be 5.8.6+ because it "fixes" (broke differently) the user login account bug. Hopefully that means it also fixes the 4k bug. I thought early on I spotted the problem but I was wrong and going over the code I don't see anything troubling. There are almost no comments in the code so I'm guessing the fact that I see a one liner describing a semaphore used to prevent a race conditions on .ioftpd that the problem was fixed. Since I can't reproduce the bug on demand in older versions I can't prove that though...

[razoor]

yes it is fixed in 5.8.6 =)

[Flow]

Hi Yil, can you please take a look at the sharemem thingy?, so sitewho script works for sitebots ? I think sharemem is broken in 5.8.8r

[tuff]

iosfv has nothing to do with this bug!

iosfv simply uses the .ioftpd file to store its info, and since this is how iosfv works, its how i actually discovered the bug in the first place, d1 has already moved on to the next version rewrite when i had passed along the bug/.ioftpd files for him to look at.

the bug will crash ioftpd on the next run of ioftpd.exe when its attempting to cache .ioftpd files when you first logon, and there are .ioftpd files over 4k

[Zer0Racer]

What happens if ioftpd has to cache a dir containing thousands and thousands of files/subdirs and with special permissions/ownership for many of them? It gets stored in .ioftpd file? Wouldn't that make the .ioftpd file bigger than 4k?

I think a friend of mine has a file structure like that and .ioftpd files up to 8k in size, but no crashes. At least not on dir listing. Maybe because it's already cached and io not restarted?

/ZR

[tuff]

as soon as io is restarted itll crash, this crash can be easily recreated, if you upload say 90 50meg files, with a decent length filename, your .ioftpd file will soon grow to over 4k and thats without any scripts installed

[Zer0Racer]

Ah okay. Uhm, for which version? My 585r has .ioftpd files over 4k in a couple of places but I've (to my knowledge) never had a crash because of it, and I restart my comp regularly.

/ZR

[tuff]

585 was the last effected version

[Yil]

I think the code base released on sourceforge has the 4k bug fixed and therefore I don't know what it looked like previously so this is pure guesswork...

ioFTPD creates 4k of data for the .ioFTPD file and writes it out, then produces the next 4k, etc. If you don't do anything fast then the non-interlocked update that previously existed (guess) would complete and work fine. Thus a single user or lightly used server where nobody was in the same directory updating stuff at the same time might be able to survive and create larger .ioFTPD files. As with all race conditions it's luck on whether you get a corruption or not as you would need two writes to the .ioFTPD file to be going on at the same time with different data...

I know for a fact that I've created 16k .ioFTPD on 584u and couldn't get it to crash so it's not just size that is the problem so I assume it's the race condition writing.

P.S. I'm down to my last feature before releasing v6.0 :) My changelog includes 30+ new commands/features and I think you will all be very happy!

[Zer0Racer]

Looking forward to it! Nice to finally see progress that adds up to an actual release. Hopefully working release. ;) I'm still on 585r since the newer builds just created problems for me.

/ZR