|
|
Comments and Discussions
|
|
 |

|
when monitor a network drive, if the user who shares the directory delete/rename the shared folder,
then ReadDirectoryChangesW will return a invalid NOTIFY buffer, this will cause a access voilation.
with synchronous ReadDirectoryChanges, this can be detected by zero-ed bytesReturned, but for asynchronous
there is no way to deteremine whether the NOTIFY buffer is valid
so anyone has a solution to this problem?
|
|
|
|
|

|
Hi Jones,
Quite often, if i don't refresh the directory in Explorer or I finished writing the file and close it, ReadDirectoryChangesW can't detect the size change of the file during the writing process. I have read a lot of references, but failed to find a solution. Could you help me explain this? I really look forward to your reply. The following are main snippets of my code:
By the way, please forgive me for my poor English. Thank you very much.
CreateFileA:
hDirectoryHandle = ::CreateFileA(
file.c_str(),
FILE_LIST_DIRECTORY,
FILE_SHARE_READ
| FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS,
NULL);
ReadDirectoryChangesW:
if(!::ReadDirectoryChangesW(
hDirectoryHandle,
buffer.get(),
nBufferSize,
bIncludeSubdirectories,
FILE_NOTIFY_CHANGE_LAST_WRITE | FILE_NOTIFY_CHANGE_CREATION | FILE_NOTIFY_CHANGE_SIZE,
&dwBytes,
NULL,
NULL) || GetLastError() == ERROR_INVALID_HANDLE)
{
break;
}
|
|
|
|

|
There's no real way for this API to tell you the before and after size when it detects a change to the file size. Consider yourself lucky to get that much
The trick is to build a list of file info before you watch for changes, then when something changes, compare the current info about the file to the new info about the file.
Takes a bit of work...
|
|
|
|

|
Jones, thank you for your reply.
I'm sorry that my poor English misled you. I mean that when my program is writing data into the file that is being watched, ReadDirectoryChangesW can't even detect the change until the file is closed or I manually refresh the directory in the explorer. I have also used Command-Line Prompt(cmd.exe) and command "dir" to watch the size of the file, it's the same case as above. and I have added some "flush" statements in my program, but there is no effect except I close the file , reopen it and write data into it. Hope I make myself clear.
|
|
|
|

|
Hi i have used your code for reference and its working fine but along with this i need one more option of file printing log,Kindly can you suggest me how to watch the files if the file is given for print.Thank You in advance.
|
|
|
|

|
I am not aware of a method that will reliably tell you this information.
About closest you'll get is watch what's happening to the printer. Check out the FindFirstPrinterChangeNotification API & the related functions. These are part of the Win32 API. This watches the print queue and creates a notification when print jobs are created and updates you on the status of print jobs. It's quite a bit of work actually. Like, a lot of work, especially if you're starting from scratch.
The name of the document is available to you w/ this API. Check out the value of JOB_NOTIFY_FIELD_DOCUMENT which is a field in the notification you get from the printer. It has the name of the document, but it won't necessarily be the name of the file. For example, if you open up a new doc in Notepad and print it, the document will be "Untitled Document - Notepad". If the file had a name, it may be something like "MyDocument.doc". That's about as good as you'll get.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd162722(v=vs.85).aspx[^]
|
|
|
|

|
These codes are helpful for me. But they still miss events. Next, I'd like to describe it in detail.
First,I'd like to explain how I've used these codes in my project and share my experience.
Trouble 1:After adding four source files kindly provided by Mr Wes Jones through code project, there should be compile errors.
Solution:1.1、Add this code - "#define _WIN32_WINNT 0x0500" in front of "#include..." in "stdAfx.h"
&1.2、Build → Set active configuration... → XX-win32 debug or XX-win32 release → OK
Trouble 2:How to use these codes
Solution:Rewrite Class CDirectoryChangeHandler_ListBox.
2.1、Make the least change to use these codes(Directly use source codes kindly provided by Wes).
For example, when a file is added in my watch directory,I want a pop-up message box. Then I will add codes in function "On_FileAdded" in the file "DirWatcherDlg.h" as below.
HWND hWnd=m_listBox.GetSafeHwnd();
MessageBox(hWnd,"OK","Notice",0);
As you can see, we just need to use m_listBox.GetDC(),m_listBox.ReleaseDC(),m_listBox.FindWindow() ..., m_listBox.XX(/*FunctionName,it must be able to be called by CListBox members*/)() to get what you want for a simple application.
2.2、Simplify functions of these codes.
2.2.1 Create a new project based on dialog(eg: Project name is Test).
2.2.2 Operation about dialog resource.
Add essential rescources(A button & a listbox) in project TestDlg. Create a message for left click on the button(named test) and a CListBox type variable for the listbox(eg. m_lstChanges).
2.3.2 Modify header files: Copy or create class CDirectoryChangeHandler_ListBox and add two variables'
a. Copy codes about class CDirectoryChangeHandler_ListBox from head file "DirectoryChanges.h" and add it in the head file of newly created project dialog(TestDlg.h).
b. Copy this two lines from "DirWatcherDlg.h" as below and add them in project dialog head file(TestDlg.h).
CDirectoryChangeWatcher m_DirWatcher;
CDirectoryChangeHandler_ListBox m_DirChangeHandler;
Remember to include "DirectoryChanges.h".
2.3.3 Modify cpp files: Add one function and implement message by clicking on the test button.
a. Copy the body of function GetLastErrorMessageString and add it to implementation file of our dialog(TestDlg.cpp).
b. Copy the following codes and add it into the body of message function produced by clicking on the button(named Test) in our dialog cpp file(TestDlg.cpp). These codes have already delete the filter function(Codes in bold have been modified).
DWORD dwWatch = 0;
const char* pDirectoryToMonitor="E:\\My Documents\\My Pictures";
if( ERROR_SUCCESS != (dwWatch = m_DirWatcher.WatchDirectory(pDirectoryToMonitor,
FILE_NOTIFY_CHANGE_FILE_NAME/*dwChangeFilter*/,
&m_DirChangeHandler,
FALSE/*bWatchSubDir*/,
NULL/*m_strIncludeFilter1*/,
NULL/*m_strExcludeFilter1*/)) )
{
MessageBox(_T("Failed to start watch:\n") + GetLastErrorMessageString(dwWatch) );
}
c. Add the following two lines of codes in the parameter list of constructor of class TestDlg in our dialog cpp file(TestDlg.cpp).
CTestDlg::CTestDlg(CWnd* pParent /*=NULL*/)
: CDialog(CTestDlg::IDD, pParent)
,m_DirWatcher( true )
,m_DirChangeHandler( m_lstChanges )
Compile,link and run, then copy sth it the watched directory, what you have copied will appear in the list box.
2.3、Add new controls to the project mentioned in 2.2.
In this project, I've added a static picture control to show images added in my watch directory. Then how shall we modify these codes.
2.3.1 First,give a unique control ID to this static control,and add a type of CStatic member variable -m_staticShowImg for this ID.
2.3.2 Then, in the definition of "CDirectoryChangeHandler_ListBox " just close to this code - "CListBox & m_listBox;", add "CStatic & m_staticImg;".
2.3.3 Third, add a new parameter in the parameter list of constructor of class CDirectoryChangeHandler_ListBox as below:
CDirectoryChangeHandler_ListBox(CListBox & list_box,CStatic & staticImg)
: CDirectoryChangeHandler(),
m_listBox( list_box ),
m_staticImg( staticImg ) {}
2.3.4 Fourth, add a CStatic parameter in constructor of CDirWatcherDlg(or your own dialog)
CDirWatcherDlg::CDirWatcherDlg(CWnd* pParent /*=NULL*/)
: CDialog(CDirWatcherDlg::IDD, pParent)
,m_DirWatcher( true )
,m_DirChangeHandler( m_lstChanges, m_staticShowImg(a CStatic member variable created in 2.3.1) )
2.3.5 Fifth, add your own code in the body of On_FileXX in class CDirectoryChangeHandler_ListBox.
HWND hMCImgWnd=m_staticImg.GetSafeHwnd();
CRect rt(0,0,240,240);
CDC* pMCdc=m_staticImg.GetDC();
img.AttachFromFile(strFileName);/*(img is a instance of another Class about image processing)*/
img.Draw(pMCdc,rt);
// MessageBox(hMCImgWnd,"OK","char",0);
m_staticImg.ReleaseDC(pMCdc);
Then,here comes my question.
Compile,link,run my project.everything is OK till now.
But after I clicked the test button when I copy image files in my watch directory, it's seldom show all the images I've copied for test. Sometimes,it shows half of the copied images regularly with one showing after another missing.Sometimes, it doesn't show any picture no matter how many times you've copied and how long you're waiting for.
Another question worrying me is how I can show two consecutive images at the same time.
Yanay Sun
Yanay Sun modified on Thursday, September 1, 2011 5:07 AM
|
|
|
|

|
Hey there,
I might be able to help if you send me your verson of the project. email to wesj@hotmail.com.
I'd really have to see this one in front of me.
-Wes
|
|
|
|

|
Hi,Wes
Thanks for your reply!
My original codes has something related to hardware, So I have to rewrite it so that you can run it on your computer.
Before running this project, maybe you should change the watched directory.
My test result show that when I copy one or two bmp images once a time and paste them in the watched directory, there will be no image showed. If more than three images are copied and pasted,it will probably work and show one of these images.
This project can just show BMP images because of the files or classes I used in this project can only deal with BMP images.
I'll email it to you right now.
Thank you again!
|
|
|
|

|
Hi,Wes
I've sent my project code to you more than one week ago just half an hour after I last replied to you.
Have you received my email? Or it is really a challenge to solve my problem.
My project is something about medical device and my code provides motor control for my device. Images are sent from another subsystem taking photographs in digestive tract. And according to these images,I can maneuver the device manually. But I'd like to have a try to make it run automatically by those images. It's really interesting. But I don't major in software. Although I've tried to solve this problem these days, little progress was made.
Your help will really be appreciated.
Looking forward to hearing from you!
All the authors in this forum are masters and teachers. Here comes Teacher's Day and Happy Teacher's Day to you!
|
|
|
|

|
Hi,
Sorry, but I haven't received anything from you at my wesj@hotmail.com account... try sending a simple email, and I will reply to it, and then send me an email w/ a .zip attachment.
-Wes
|
|
|
|

|
Thanks a lot!
I've tried again. The title of my email is "Asking for help from Yanay".
Hope to hearing from you soon!
|
|
|
|

|
First of all, great work. But... there is a problem, and I quite can't put my finger on it because the code is too complicated Still working on it.
All goes fine if you get events for one or few file(s) at a time in your watched folder; but if you are watching a folder with A LOT of activity (even worse, with subfolders, on a SSD drive), you miss events.
First, the PostThreadMessage fails miserably because the thread queue is limited to 10k events; since one gets 3 or more events per file when, say, it is created, this makes it happen for less than 3000 real file events.
So, besides writing a custom queue, one may wait for the notified thread to deal with some messages, then try and post again. This only adds up to the time spent in "On_FileAdded". So far, so good, but this is where you start missing events.
You can simulate this by adding a sleep call in DirectoryChanges.cpp, line 1906, just before the break. The more you 'sleep', the more events you will loose, eventually all of them.
As I said, I'm still working on understanding the problem, but can anyone help ?
Thanks,
Stefan.
|
|
|
|

|
Hey Stefan,
Wow, that's a lot of file activity! I guess I can feel good that it took this kind of activity before it shows a problem.
There are two windows of time a notification can be missed. The time inbetween ReadDirectoryChangesW returning, and the next call to ReadDirectoryChangesW being made. By doing a PostThreadMessage on the results from ReadDirectoryChangesW, I am able to keep this window of time to an absolute minimum. I guess the other window of time is when the thread already has 10k items posted against it & you post another one(that's the one that's missed).
To be honest, I've never heard of that limit before, and I'll take your word for it.
This is the kind of activity and limit I didn't have in mind... the thought being that handlers should be so fast, there shouldn't be time for 10k events to pile up in a post message queue.
Immediate thoughts on ways to tackle this are:
1) Evaluate the code in a profiler. What are your event handlers doing that take so long that a limit of 10k post message queue items are piling up behind it? The handlers need to be as fast as possible. Where are the bottlenecks?
2) Instead of 1 instance of DirectoryChangeWatcher watching all those folders/subfolders, think of ways to allow multiple instances of DirectoryChangeWatcher handle different sections of the folder. 1 instance of DirectoryChangeWatcher has 1 thread, and the 10k limit you're talking about it. Other instances of the watcher class will reduce the risk of that limit being reached.
Think about intances based on file folders, or instances based on the change flags your watching for, ie: Added changes-> watcher1, Removed Changes->watcher2, Modified->watcher3
Something like that.
3) Evaluate the consequences of changing the buffer size used w/ ReadDirectoryChangesW. I think it's 4096. It that buffer is full, it will take a certain # of cpu cycles to process that buffer and post each file change notification to the worker thread. This is the time when a change could be missed as ReadDirectoryChangesW won't get called until it finished w/ the buffer. A smaller buffer means it'll process it faster and call RDCW sooner. Of course, there's still a buffer filling up in the background somewhere and it could just be pushing the problem somewhere else. Record some statistics on how long it takes between calls to RDCW & evaluate if that's a big enough window for notifications to be missed.
4) The last approach is to use the Decorator Pattern on your DirectoryChangeHandler. This handler whould implement it's own thread pool and could itself use PostThreadMessage to it's own pool of threads so that 1 individual thread wouldn't ever have a chance to reach such a limit.
5) A mix of all of the above
Cheers,
Wes
|
|
|
|

|
Thanks for the reply, and the advices, but unfortunately, I think none applies to my case.
Long story short : the event handler is copying the file to a different location, over the network, and how long it takes, it's out of my control. This is how I got to find out about the 10k limit.
Next, I tried to keep posting the message until the message queue accepts it, but then I started missing files because CDelayedNotificationThread::PostNotification takes too long; I'm not sure if files were missed previously too (I mean all calls to the On_FileAdded, not really processing them).
Bottomline, I think files are always missed, but maybe in smaller amounts (in happy cases, none), depending on how fast they are created and how long On_FileAdded takes; my real-life situation is not so extreme, but you can easily push it to an extreme where more than 90% of the files are missed.
Here's a quick test you can do right away with your sample, assuming your drive is not speed-lightning (this will cause the events to be generated over a longer period of time); put a breakpoint in the case branch FILE_ACTION_ADDED of ProcessChangeNotifications. Then copy and paste at least two or three small files to the watched folder. When the first file is created, the breakpoint fires. Wait a couple of seconds, then continue execution. You will never get the events for the rest of the files, and I may be very wrong, but I think the problem lies somewhere in the asynchronous call to RDCW.
I have created another test, using RDCW synchronously, just to see if it returns with lpBytesReturned=0, which it does at some point (this is why I think the problem lies in the async call to RDCW). I ended up increasing my buffer to 4M, so that it does not miss events; but this is not very safe either, since at some point it will always overflow.
The path I am going to take now is use RDCW synchronously, with a very large static buffer, and use a system pipe to handle the events, hopefully avoiding the 10k limit of the message queue.
I will get back with more info as soon as I have it.
|
|
|
|

|
Hey Stefan,
The way to reproduce this that you describe sounds like you're setting a breakpoint in between calls to RDCW, which is when file notifications will be missed.
A problem w/ the On_FileAdded notification is that a file can be large enough that you receive a new file notification and windows is still writing chunks of that file to disk when you're handling the notification. That could increase the amount of time it takes for the file copy fo finish. To see that, copy & paste a 2GB file into a watched folder.
I would recommend that you create a class who's job it is to copy files in it's own background thread or threads. Your On_FileAdded handler will just post to that class. This way your On_FileAdded handler is super fast and you don't miss the notifications, and you can roll your own solution to regarding the limits your class can handle.
I did put a lot into designing around this very problem & that's my suggested solution in this case.
|
|
|
|

|
Thanks. Indeed, I am setting the breakpoint or adding a sleep(10) to simulate an On_FileAdded call that takes longer. However, no matter how fast you handle the On_FileAdded, my guess is that there will be some events missed occasionally.
For now I rewrote the RDCW handling in my app without your classes, since I need a pretty targeted behavior, using several threads, pipes and synchronous calls.
Your classes are great and I have to thank you for the insight of how RDCW works, but I have been unable to use them; my guess is that when you first wrote your article, hardware and OS behavior were a bit different.
Thanks again for the article and your help.
|
|
|
|

|
I'm glad it could help! Yeah, it has been a while since I wrote this, and who knows how things have changed. It might be time for a refactoring at a minimum, or to handle some things differently.
I am curious.. can you post any concrete numbers on what it takes for problems to occur? I doubt I'd be able to reproduce this scenario in on my home PC. What's the type of application and the kind of environment it's running in?
-Wes
|
|
|
|

|
Sure. In my original scenario (which actually is a real-life situation), I had a folder with about 1000 subfolders, and files being created almost randomly in those folders. Since I cannot watch 1000 folders or more one by one, I needed a recursive watch on the root folder so that when files get created/modified/deleted, the same happens on a remote machine; sort of a replication mechanism.
First test : less than 50% (don't recall the exact numbers, but I think it was something like 20k out of 44k) of the files ended up on the remote machine.
So I began testing and stressing the app to find out why and what I could do about it. I then devised a simpler test, which is far more stressful than the real-life situation, just to see how bad it is. The second step was the breakpoint test I described earlier, but that even more exaggerated.
I had a folder with 6000 small files (actually one of the source files ), named 00001.cpp to 06000.cpp, so I can trace them. I modified the sample app to OutputDebugString the contents of the ListBox as it is created, so I can paste it here, and made a few minor changes so it would compile nicely on VS2008, but no structural changes whatsoever; just stuff like 'for (int i=0; ...', then using i outside the loop; there were just a couple of them.
All events were checked in the dialog, and then, in the watched folder, I copy-pasted using the Windows Explorer my test folder with the 6000 files.
I tried on two machines; since I believe system performance plays an important role, here are the details :
1. Core2Duo 2 Ghz, 4GB RAM, SSD drive with good performance on small files, the copy-paste takes less than 10 seconds
2. Core i5 2.30 GHz, 8GB RAM, regular HDD drive; the copy-paste takes less than 20 seconds
Putting a 'Sleep(100)' in the handlers, just to simulate a somehow exaggerated lag, here's what I see on machine (1); the same happened on machine (2), but it was worse (meaning, even less events fired).
Here's an excerpt of the trace; before this point, everything looks ok.
[...]
File Added: C:\DirWatch\Test\1 - Copy (2)
File Added: C:\DirWatch\Test\1 - Copy (2)\00004.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)\00004.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)\02480.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)
File Added: C:\DirWatch\Test\1 - Copy (2)\02480.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)\02480.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)\02481.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)
[...]
As you can see, no events are fired for files between 4 and 2480.
And the last few lines of the trace are :
[...]
File Added: C:\DirWatch\Test\1 - Copy (2)
File Added: C:\DirWatch\Test\1 - Copy (2)\02495.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)\02495.cpp
File Added: C:\DirWatch\Test\1 - Copy (2)\02496.cpp
The thread 'Win32 Thread' (0xbf4) has exited with code 0 (0x0).
No sign of the rest of the files up to 6000. So you can see, this is a significant loss of events, not just accidental stuff; I'd say it's really close to 100%, unfortunately. This is obviously due to the lag and the small RDCW buffer; the only problem is that it look pretty hard to devise a proper mechanism.
On the other hand, I have advanced a little more on my implementation, with sync calls (to avoid buffer issues) and pipes (to avoid the 10k event limitation), and I am beginning to see the light (actually, it just became a 100W light bulb from the small candle it was yesterday) : no file loss in a test that ran overnight.
If I get the chance of finding some spare time, I will try to wrap things up in a demo app.
|
|
|
|

|
Ah, the ol' somebody copy & pasted 6000 files routine. Gets 'em every time! I'm surprised by the number of notifications that appear to be missed.
I think it's time for an update to the code. I'll use your this info & this kind of test as a benchmark & perhaps will email you re: any nuggets of wisdom you gained when you solved the problem. Hopefully it's not a limitation of the async thing I'm doing w/ the completion ports as my whole implementation is based on that.
|
|
|
|

|
The only thing I can suggest is use pipes instead of message queues; seems to be working fine for me, and a bigger buffer.
Also, in my case, a stopping mechanism was not necessary, so the RDCW thread keeps on looping, hence the synchronous call approach.
What I've been doing can be summed up like this (in some sort of pseudo-code )
WorkerThread
do
read event from pipe
process event
while TRUE
end
WatcherThread
create communication pipe
create worker thread
do
RDCW synchronous call
dispatch events through the pipe to the worker thread
while TRUE
end
Not sure if this is sane enough, but it runs in a service, and the stop service command has no problem in killing the threads, even if they're in a wait state, so I won't drill into that anymore for now.
And one more thing... the RDCW buffer is 16M; used it as static variable in the tests, but will go to GlobalAlloc for proper memory handling.
modified on Friday, July 8, 2011 11:39 AM
|
|
|
|

|
Thanks for all the great info!
|
|
|
|

|
Thanks too. To be honest: I haven't understood a bit. But this sounds somewhat important. So will there be any update on the above linked demo/src projects?
|
|
|
|

|
In my spare time, I'm going to work on an update to the code that will support the 6000 files at once test. Btw, this code as-is has passed the 1000 files at once test.
The new version will be unit tested w/ CppUnit and in a dll rather than source files so I can break the code out and refactor a bit more cleanly. Of course, all that takes time, but it's someting I want to do.
|
|
|
|

|
After some more tests, I am now pretty convinced that depending on how fast files are created and how long On_FileAdded takes, some events are missed. Still not sure about the "why", but I think this has something to do with how many events are returned in a call to RDCW, and how many other files are created before the next call, as you already pointed out.
Maybe a synchronous call would to the trick; still working on this.
|
|
|
|
|

|
i can't get 'copy event '
ReadDirectoryChangesW can't do this ?
what about hook
|
|
|
|
|

|
For cimpile in VS 2008 need add:
friend class CDelayedDirectoryChangeHandler;
in
declaration of class CDirectoryChangeHandler
|
|
|
|

|
Any chance to compile this under C++Builder (BCB) ?
Compiler stops at the first CString.
CCriticalSection and other C... classes seem to be further problems.
|
|
|
|

|
this uses the microsoft MFC library, which is where CString, CCriticalSection come from..... does borland support that?
|
|
|
|

|
I know no way to use mfc in c++builder, seems I need to try on my own :(
|
|
|
|

|
It's so good and useful code,Thanks a lot!
|
|
|
|

|
hi,wes jones.
If i modify the code like this, it also works.
void CDirectoryChangeWatcher::ProcessChangeNotifications()
{
.....
CDirectoryChangeHandler * pChangeHandler = pdi->GetChangeHandler()->GetRealChangeHandler();
....
}
Now,the Change Notification would be processed in the thread that monitors directory changes.
I want to know the reason that you use another worker thread to process the change notification.
I feel sorry for my poor english.I hope you can understand that and give me an answer.Thanks.
|
|
|
|

|
Please don't change the internal code. It works & you only need to worry about the public interface.
It uses a background thread so that there is no window of time where a file notification can be missed. When ReadDirectoryChangesW returns, file notifications will be missed until ReadDirectoryChangesW is called again. It is important to call ReadDirectoryChangesW again as soon as possible. It is also important that the thread that processes notifications is not the same one that calls ReadDirectoryChangesW. All of this is so that file notifications are not missed in between calls to ReadDirectoryChangesW.
If you are using an app w/ a GUI, use true in the constructor. File notifications will occur on the same thread on which the instance of CDirectoryChangeWatcher was created.
Passing false will make them happen on a new background thread.
Good luck & thanks for using my code!
|
|
|
|

|
Hi,
I'm working on an application which monitors a directory using win api ReadDirectoryChangesW() . When monitoring the directory, this api sends FILE_ACTION_MODIFIED event in case a file/sub-directory is modified in the monitored directory. It doesn't tell what specifically has changed in the file or sub-directory since the time the file/ sub-directory entry was created in the monitored directory e.g size, timestamp or attributes or am I missing something. Is there any way to get what exactly has been modified viz size/timestamp/attirbutes since the time the file entry was created?
Thanks
Raj
|
|
|
|

|
Sorry, there's no easy way to tell what has changed... this api only let's you know "something" changed. "something" being defined as one of the watch flags you specified when you started the watch.
About the only thing to do is to maintain a list of file/folder info objects, then when you detect a change, compare teh various properties to detect exactly what has changed.
-Wes
|
|
|
|

|
Hello,
I am not being able to save the binary files in the watched folder (For example a word document from MS Word). Text file is OK. How can I overcome this?.I am using vista.
Jack..
modified on Thursday, July 15, 2010 2:00 AM
|
|
|
|

|
I test it in windows 7, but it don't work. Could you please tell me the reason? thanks.
|
|
|
|
|
|

|
sorry, don't know. please post here when you find out. I'll be on vacation for a bit.
|
|
|
|

|
I test in Windows 7 professional. Works fine.
|
|
|
|

|
I tested it under Windows 7 64 bit and had no problems .... works as designed !
|
|
|
|

|
When I use your class in XP sp2.It works fine, but turn to XP sp3, when I drag a directory into the watched directory,only the directory name is found,all of the files in it have no notify message.Can you tell me what's wrong with it?Thanks.
|
|
|
|

|
Sounds like our friends at Microsoft have changed the how ReadDirectoryChangesW is implemented. That's about all I can say...
|
|
|
|

|
the Message when happend, such as On_FileRemoved(),it's happend before or after?
when i need copy files before removed,how can i do
|
|
|
|

|
Hi,
It happens after it has been removed. You have to do something at a lower level in Windows if you want to do something with it before it's deleted. google Alfa File Monitor & get out the checkbook.
|
|
|
|

|
Hi,
Thanks fopr posting this, its very useful. I tried watching a USB drive, and it does not seem to see file changes that happen on that drive.
Also, to the best of your knowledge, do you know of scenarios where your app would miss file changes (on regular drives, not necessarily on USB)
Thanks again,
Max
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
|
This class wraps up ReadDirectoryChangesW.
| Type | Article |
| Licence | |
| First Posted | 31 Jan 2001 |
| Views | 798,912 |
| Downloads | 23,332 |
| Bookmarked | 324 times |
|
|