Zero: When the new site symlink function was added I changed the way relative symbolic link paths were evaluated:
Code:
7) Fixed relative symlinks. You can now use links of the form a -> b,
a -> ../b, a -> ../../foo/b. Previously you could use relative links
but it was necessary to prepend an extra "../" which is clearly wrong
when viewing a directory listing.
Are you using relative symbolic links? And/or are their scripts that use them that may be using the old method? From my experience most scripts tended to use absolute links which won't have been affected, but suffer from being incorrect if the directory structure is moved around.
As far as the new site symlink function goes it's just a shorthand for creating symlinks. If you aren't using the function it should have no effect as everything under the covers remained the same. Since you aren't creating a new symlink in this case I don't think it's even involved in this problem. If you are using it let me know though.
Next time you notice this happing, try a couple of things. Get the names of the dirs involved so we can see the relationships to any potential renaming effects that might be going on. Then try logging into the server with a fresh ftp client so none of the directories are cached in the client. See if the problem exists on the 2nd login as well. If ioFTPD has a messed up cache it should be wrong in both. Now shut the server down and restart it to see if the problem was cache related or if it's wrong on disk somehow...