ioFTPD will only report the size of the files in immediate subdirectories (but not children of those subdirs) during a directory listing. Many other FTP servers don't report any size at all because they don't cache multiple directory contents. I think drFTPD is sort of unique because the Master doesn't keep any files itself so it was simpler to keep somewhat accurate usage totals for entire directory trees because it was just stuffing data in a huge memory database and didn't use the filesystem itself to cache info as is usually done. It also assumes that nothing else will touch the files on slaves (i.e. nobody adding/deleting via windows explorer), and that there is only 1 way to view the filesystem. ioFTPD allows multiple .vfs files so the total size for 1 person seeing the /archive directory might be radically different than another user's viewing the /archive dir who can see more of it.
This doesn't mean that ioFTPD couldn't report total tree sizes in the future when I switch over to the new directory caching code, but it won't be anytime really soon. The only way to cheat and do it quickly would be to assume the entire filesystem can be cached in memory or allow only 1 VFS view (and somehow account for hidden dirs throughout the filesystem) so it could be stored in a database...
The reason we just do 1 level deep is because going deeper has consequences. If you enter a directory with a subdir for every day that's 365 dirs it has to cache right now (assuming you haven't disabled subdir sizing entirely). However if you went 2 levels deep that could be 100K+ dirs assuming a few hundred per day! Ouch.
The only way around some of the issues is using a database and/or stashing subdir totals in parent dirs and ignoring hidden subdirs deeper in the tree. I've toyed with both, but neither are worth implementing until I switch to the new directory caching code.
|