Dc_markdirty?

[FTPServerTools]

Can anyone tell me how this DC_MARKDIRTY works?
From DataCopy.h:
#define DC_DIRECTORY_MARKDIRTY 22 // Context = LPTSTR

So I can safely assume it uses shared memory or at least a DC_MESSAGE
typedef struct _DC_MESSAGE
{
HANDLE hEvent;
HANDLE hObject;
DWORD dwIdentifier;
DWORD dwReturn;
LPVOID lpMemoryBase;
LPVOID lpContext;
} DC_MESSAGE, * LPDC_MESSAGE;

Now I allocate soem shared mem in the usual way (works as expected) but how can I use this thing? I basically create a DC_MESSAGE in a free shmem block of size 1024 and lpContext pointing to directly after the DC_MESSAGE (like I do in SiteKill which works fine). Now I put a path in that piece (vpath/realpath I tried them all). But apparently there is nothing happening. io seems to keep its cache dirty.

Test:
login in to ioFTP
upload a file to dir TEST
go with explorer to that TEST dir and delete the uploaded file
refresh the dir for io or even logout and login and nothing gets properly updated. The .ioFTPD is still the same, io still things the file exists. Exchanging the .ioFTPD file also makes no difference.
So of some of the iniCom guys are reading this then please answer me this simple question... Prefreably in details. All I want to do is mark a directory as dirty and thus force io to recache it.

[Mouton]

Side note: The iniCom guys don't know how to do that. They are producers / distributors; not developers.

http://www.ioftpd.com/board/showthre...CTORYMARKDIRTY

http://www.ioftpd.com/board/showthre...=shared+memory

And:

void flushDirCache(const char *directory)
{
	if (!initSharedMem(1024 + ((DWORD)strlen(directory) + 1)))
		return;
	lpMessage->dwIdentifier	= DC_DIRECTORY_MARKDIRTY;
	LPTSTR folder = (LPTSTR)lpMessage->lpContext;
	CopyMemory(folder,directory,strlen(directory)+1);
	dwReturn = SendMessage(hIoFTPD, WM_SHMEM, NULL, (LPARAM)hMemory);
	if (!dwReturn) {
		WaitForSingleObject(hEvent,2000);
	}
	closeSharedMem();
}

[FTPServerTools]

Thanks mouton I'll surely try that and make it into a tool (as usual)
And for the rest I was just teasing the iniCom guys. We know lots more about io then they do..