New Events for file monitoring

[PJM_Labview]

Over the years I have run into situations where I have to monitor files accessed by another application from within my LabVIEW application (Example: monitoring the standard_out/standard_error files from an app launched with the system exec).

Currently the only way to do that is to use polling. 

I would love for LabVIEW to have built in events for file monitoring so polling would no longer be required.

For instance, the following events would be very useful:

1. File Opened
2. File Closed
3. File Change  (I really want this one if nothing else)
4. File Created
5. File Deleted 
6. more...

Below is an example as to how it might look like.

[smercurio_fc]

---

PJM_Labview wrote:

Currently the only way to do that is to use polling. 

---

Not entirely true. On Windows you can use the FileSystemWatcher .NET class with a callback VI. Example 1 and example 2.

While the idea itself is attractive, I'm not sure if this really would fall under LabVIEW's responsibility to handle. Kind of on the fence on this one.

[TCPlomp]

I don't think that the event should give back the contents of a changed/created file.

That is begging for memory problems.

Also should this feature make a distinction between files and folders?

Or should a 'folder' report a change if a new file is created or if one of the files is changed?

[Intaris]

I'm really not sure about the "Old Content" and "New Content" thing.  This seems like it would be a performance nightmare!

Otherwise I have found myself wishing for this on a couple of occasions, so kudos for sure.

Regarding how folders should react, I think when the contents of a file / folder and changed, it should trigger an event (without contents being sent).  This would basically allow for the same events to be used for both folders AND files which would make the usage a bit easier I think.

I'm unsure about the "File opened" event though?  What is this supposed to represent?

[Manzolli]

Evolving from smercurio_f's idea, how about a set of functions that can make the use of the FileSystemWatcher .NET class easier? We always can make the VIs by ourselves, but in this case, I think NI could add a palette of functions addressing this issue.

[PhillipBrooks]

I think that this would be difficult to provide because different OS's have their own behavior. The Windows FileSystemWatcher class operates at a fairly low level, and an application such as Notepad may generate multiple FileSystemWatcher events for a single Notepad action such as 'Save'.

http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.changed.aspx

Excerpt:

Common file system operations might raise more than one event. For
example, when a file is moved from one directory to another, several OnChanged and some OnCreated and OnDeleted events might be raised. Moving a file is a complex operation that onsists of multiple simple operations, therefore raising multiple events. Likewise, some applications (for example, antivirus software)  might cause additional file system events that are detected by FileSystemWatcher.

[PJM_Labview]

I agree about all the comment regarding the "old content" and "new content".

This was just an example about what it could look like.

A file reference would be just fine here.

[PJM_Labview]

> I'm unsure about the "File opened" event though?  What is this supposed to represent?

I though this could tell us when an app opened a reference to access the file.

[Intaris]

Would a "Lock obtained" event not be more useful than a "File Opened" event?  What happens between a lock and an unlock is irrelevant.

[Herbert Engels]

While polling is about the last thing I want to promote, you could potentially take advantage of the fact that changing a file or folder will update the lastmoddate on all containing folders up to the root. That would at least make polling a bit more efficient.