ioFTPD v7.0.3 Released

[pion]

Would that bug affect the use of nxmydb? Or would that work around the problem?

[Yil]

I have been totally unable to reproduce that problem, however I did see it on a live site so I know something was wrong. However, the DB was in an invalid state at the time and perhaps that contributed to it acting strangely and not fixing itself. You will see warnings in the error log like: Module 'STANDARD' reports item ID=510 NAME='testing' deleted from database '..etcUserIdTable'. If you start seeing something like that let me know so I can see what's going on... I believe nxmydb would have the exact same issue as it relies on the server to translate id<->name via the UserIdTable.

Bad news: I also saw what looks like the good old lockup bug on a site that wouldn't die via "site crashnow". On the other hand I have several reports that sites that got this frequently on win23k (where it was always a problem) are now running smoother.

[pion]

The problem you are describing with the warnings is present at the previous versions also. A way to reproduce it is using nxmydb, and disconnect it from the mysql server - while you delete users in the database. Then connect again - and the error should come up

[ArtX]

YiL in future release's could you tell us what files only need to be updated instead of the whole thing, or is it best to copy over the whole release every time you update, backing up etc groups and user folders?

[Yil]

Carpo: Every file modified, deleted, or added is documented at the very top of the Changelog so just replace the files it mentions there. It even documents, by section and in order, what additions/changes need to be applied to the .ini file. Of course a big release like v6 to v7 changes a lot of files so there are even a few comments about what you need to keep (like nxtools dirs or text/ftp/Welcome) to make swapping whole directory trees easier instead of by files.

[opcode]

ioFTPD 7.0.1 runs fine for me the first time i start it. If i have to kill the process and then restart it again, it crashes on startup and the process terminates itself. I can send crashlog & memdumps if neccessary.

[razoor]

it does that for me to. i just changed the delay on preload to false and that did the trick for me.

[opcode]

actually if i let the pc idle for some time (like 1hr+) i can restart ioFTPD again, even with vfs_preload delay on. I don't really see what vfs_preload delay does anyway, it still takes ages to cwd into huge dirs for the first time.

[Yil]

By default preloading just caches mountpoints in the default VFS file and thus this could mean just a single directory if you only have a root entry. It is up to you to specify what else it should preload. In practice if you have large directories/fanouts that take minutes to load the first time that aren't mountpoints then specify them manually in the .ini file so the server can do the work ahead of time. This is especially true for large fanout dirs on networked drives.

The Delay= setting which determines whether the server should wait around and finish caching the dirs before allowing connections to the server fundamentally changes the way preloading occurs. With Delay=False the server queues a low priority task onto the internal worker thread queue and it will process the directories one by one. If Delay=True the server hasn't really started yet, and thus there are no worker threads, so it spawns a new thread per mountpoint / manual entry and does the preloading in parallel so completion time is basically the slowest task to finish. Remember though that ioGUI/etc won't be able to connect while this is going on because that's the point of this setting...

If you are experiencing crashes at startup try switching the Delay= setting and see if that makes a difference because the =True option is the one I used for testing most of the time since it seemed far more fragile with all the thread creation/synchronization/etc.

[opcode]

@Yil: that makes sense, i just checked again and i am indeed just mounting the parentdir, which then contains three subdirs with lots of dirs in them. So it just caches the parent, but not the contents of the subdirs that are actually a pain to cwd into. I'm too lazy to do separate mountpoints for those, so i'll just disable the delay stuff like you recommended.

[Yil]

opcode: You don't have to turn the dirs into mountpoints to preload them. See the comments for the VFS_Preload section. You append a line like "2 = /" which will cache everything in / and all it's subdirs. Or pick on particular dirs with something like "1 = /Games/Archive" which will just load the /Games/Archive dir.

Hope that helps, but do see if your startup issues go away by switching the Delay= option.

[ArtX]

just to make sure i have this right do you mean

[VFS_PreLoad]
# By default the server now preloads all the directories used as mountpoints
# in the default VFS file indicated by [Locations]/Default_Vfs. If you want
# additional directories loaded include lines here with the form:
# <depth-to-descend> = <starting-VFS-path>
# A depth of 1 just means the directory itself, 2 would be the dir and all
# its immediate subdirs, etc.
2 = /

if so it doesnt seem to have helped much, could just be me though

[Mave]

Dont forget about ioYIL YiL

[Yil]

Carpo: Yup, that should attempt to load /*/*. If you look at ioftpd.log it should indicate the number of directories that matched and were preloaded...

Mave:

[opcode]

Yil: seems to work flawless with the preload turned off