FlashFXP Forums - View Single Post

FTPServerTools · 02-17-2008, 08:16 PM

My thought about this:
If io gets on a dir it hasnt read before it is reading the dir anyway. hence the dir is in the system cache. So running a script that adds the filesize together is very doable and fast. Then for a prent dir it needs to be recounted. Thus I conclude that a dir holds its own sum. For speed it may hold the sum of its children dirs.
Say X does a cwd ABC then a post cwd reads the dir, counts the files and stores it in .size (or better yet in a SQLite database). Any outside dir change can be caught by monitoring dir changes (yes there are api functions for it). But this doesnt work for network drives or ext2/3 drives and such.
So my quicky thought:
(OnPostCWD:count on current dir (actually OnPostLIST is more exact))
OnPostStor:add newfile size to dir of Stor
OnPreDel:mark file size for removal
OnPostDel:remove file from dir size
OnPostAppe:count on current Dir
OnPostList (and OnPostNlist):count files on current dir, grab all subdir sizes and add together
ReadDirectoryChangesW (see also http://www.codeproject.com/KB/files/DirCheck.aspx and other sites) do a recount when changed file is no longer locked, alternatively you can use the change journal of ntfs volumes.
The FILE_NOTIFY_CHANGE_SIZE and the FILE_NOTIFY_CHANGE_LAST_WRITE should give some clues... The ReadDirectoryChangesW tells me in the FILE_NOTIFY_INFORMATION structure if a file was deleted, modified, renamed or added. So that could be used by any external program, connected with for example a simple sqlite database.
I think I'd personally bet on the ReadDirectoryChangesW thingy then the journal system. That would at least work generically (sort of).
Then another alternative is to use the microsoft indexing service. I havent delpved in to it tho and I dont know if it holds all the file changes.
The third alternative which may be not so hard is to use detours or some other hooking library to hook any file create, file close, and file writes in certain preset dirs. Any change in those dirs is very likely to be passed through the main file i/o functions and can thus be hooked. A fileclose can therefore be made into an update, a fileopen can be made into a add new filename or do nothing, a file write can be a trigger to do a recount after the close..
Anyway I see some techy solutions.... Indexing, Journaling and Hooking can all work quite nicely outside of the ftpd. But all three suffer from no reactiveness on networked drives...

02-17-2008, 08:16 PM
FTPServerTools Senior Member Join Date: Sep 2002 Posts: 543	My thought about this: If io gets on a dir it hasnt read before it is reading the dir anyway. hence the dir is in the system cache. So running a script that adds the filesize together is very doable and fast. Then for a prent dir it needs to be recounted. Thus I conclude that a dir holds its own sum. For speed it may hold the sum of its children dirs. Say X does a cwd ABC then a post cwd reads the dir, counts the files and stores it in .size (or better yet in a SQLite database). Any outside dir change can be caught by monitoring dir changes (yes there are api functions for it). But this doesnt work for network drives or ext2/3 drives and such. So my quicky thought: (OnPostCWD:count on current dir (actually OnPostLIST is more exact)) OnPostStor:add newfile size to dir of Stor OnPreDel:mark file size for removal OnPostDel:remove file from dir size OnPostAppe:count on current Dir OnPostList (and OnPostNlist):count files on current dir, grab all subdir sizes and add together ReadDirectoryChangesW (see also http://www.codeproject.com/KB/files/DirCheck.aspx and other sites) do a recount when changed file is no longer locked, alternatively you can use the change journal of ntfs volumes. The FILE_NOTIFY_CHANGE_SIZE and the FILE_NOTIFY_CHANGE_LAST_WRITE should give some clues... The ReadDirectoryChangesW tells me in the FILE_NOTIFY_INFORMATION structure if a file was deleted, modified, renamed or added. So that could be used by any external program, connected with for example a simple sqlite database. I think I'd personally bet on the ReadDirectoryChangesW thingy then the journal system. That would at least work generically (sort of). Then another alternative is to use the microsoft indexing service. I havent delpved in to it tho and I dont know if it holds all the file changes. The third alternative which may be not so hard is to use detours or some other hooking library to hook any file create, file close, and file writes in certain preset dirs. Any change in those dirs is very likely to be passed through the main file i/o functions and can thus be hooked. A fileclose can therefore be made into an update, a fileopen can be made into a add new filename or do nothing, a file write can be a trigger to do a recount after the close.. Anyway I see some techy solutions.... Indexing, Journaling and Hooking can all work quite nicely outside of the ftpd. But all three suffer from no reactiveness on networked drives...