paja1: ioFTPD is pretty good about checking the timestamp on a directory to detect changes so it can invalidate its cache whenever it lists a directory. The only problem I'm aware of is with zipscripts dealing with files uploaded onto FAT32 filesystems because the last modified timestamp isn't accurate enough to catch changes. NTFS works fine and if you have large files you're using NTFS.
You can test to see if it's a caching issue by going to the dir and using 'site refresh' and re-listing the dir. That should force it to go grab a new snapshot of the directory. On the other hand you also need to rule out that the FTP client isn't at fault. It's standard fare for clients to cache directory listings and you need to make sure you have a current copy. Try re-starting the FTP client (make sure ALL copies of it are closed first!) and see if that makes a difference.
If none of that works then there might be something funny about the file. ioFTPD will refuse to show "hidden" or "system" files and directories. This prevents it from exporting special protected things like the recycle bin, the page file, etc. Open up the properties tab for the file and see if it's special in any way. I don't think access permissions on an individual file can prevent it from showing up in a directory listing if other files are showing up in that dir (which means the dir's permissions must be ok).
See if any of that helps. If all else fails, try deleting/renaming the .ioFTPD file just in case it's corrupted. I'm not sure how that could prevent some files from showing up, but it's something to try. You'll need to 'site refresh' the dir or even restart the server after touching the .ioFTPD file. I guess restarting the server is another option to try in some of the above cases as well.
If you have an active server and restarting is painful let me know and I'll show you how to setup a local test server you can run side by side with your regular one.
|