Yil, thanks for your well thought-out reply. You've brought up some interesting points. Would it simplify things for now if we're able to assume all file system changes (within site dirs) are made via the FTP itself? Perhaps that's the direction to go in to help simplify this in being implemented more easily/quickly. Later, a crontab-like script could be created, which when run nightly would act not unlike the current nightly spider scripts which thumb through the file system in search of obsolete symlinks, except in this case it would be checking existing files & directories against entries in the log file you mentioned above. Of course, these files and directories in the log file would need to be associated with their respective diskspace usage for it to give us what we're striving towards..
I also envision that (via a script?) this could be tied in to FTP_Pre-Command_Events and FTP_Post-Command_Events, at least for STOR and DELE. On STOR it would need to check if the user has available quota for storing, it would be helpful if ioFTPD has knowledge of the size of the file attempting to be stored at this point so it could more intelligently allow/deny the STOR attempt. On DELE it would add the size of the file(s) deleted back into the user's available disk quota.
Lastly, implemented as a site command to facilitate easier management, it might look something like 'site change billgates diskquota 30g', or 'site change team diskquota 100g'.
At the end of the day, whether this is all handled by scripts or internally, I think some foundation must be laid on the core ftpd side to support it. Thoughts?
Last edited by PopWeasel; 02-15-2008 at 08:44 PM.
|