Preface
Unfortunately, .NET for Windows Store apps does not provide a FileSystemWatcher class. Nevertheless, one might want get notified when a folder, or file in a folder, has been changed.
This post presents some points I found worth to consider when I implemented a FileSystemWatcher for Windows Store apps.
Because the implementation of such a class depends on the kind of application it is used by, there is no code sample provided. The intention of this post is to give you some ideas about what I think should be considered when creating your own FileSystemWatcher.
Receive Notifications
This is the easy part. You just have to create a StorageFolderQueryResult, add a handler to its ContentsChanged event, and execute the query.
...
private StorageFolderQueryResult QueryResult { get; set; }
...
protected override async void OnNavigatedTo
(
NavigationEventArgs args
)
{
QueryResult = KnownFolders.PicturesLibrary
.CreateFolderQueryWithOptions(new QueryOptions()
{ FolderDepth = FolderDepth.Shallow });
QueryResult.ContentsChanged += OnFolderContentChanged;
try
{
await QueryResult.GetFoldersAsync(0, 1);
}
catch (Exception)
{
...
}
}
…
private void OnFolderContentChanged
(
IStorageQueryResultBase sender,
object args
)
{
// Do something
}
It is sufficient to get just one folder. There is no linkage between the notifications and the number of items retrieved by the query. Calling GetFoldersAsync(0, 1) keeps the runtime impact to a minimum.
You can also call another method of StorageFolderQueryResult. The important thing is that the query executes at all.
Notification Content
The “content” of the notification is the notification itself and the folder that might have changed. Why “might”? Have a look below.
No. There is no further information sent by the event. You only get notified that something has changed. You do not get any information about what has changed.
Double Notification
At the time of writing, it seems that Windows 8 is not consistent in the way it fires the event.
In case a file is changed, one event is fired.
But in case a folder is changed (or created or deleted), two events are fired, with a timespan of one second. The timespan was observed on Windows 8 x64, Windows 8.1 x64, and Windows 8 RT. So it seems to be hardware-and OS-independent. For the latest news on this, please refer to StorageFolderQueryResult.ContentsChanged Fires Twice.
Notification Aggregation
In case many changes are made to the file system in a very short time – e.g. the user selects 100 files by the file explorer and deletes them – the behavior is unpredictable. I observed at minimum one event, but very often two, sometimes the second one with a delay of several seconds, sometimes even more events.
Notifications About Changes in Child Folders
As you can see from the code snipped above, I set the QueryOptions.FolderDepth to FolderDepth.Shallow. This means I only want to monitor changes of the given folder. I don’t care about changes in its child folders.
Unexpectedly, I also received notifications when the content of a child folder has changed. E.g. I was monitoring the Folder “Parent”, which contains a folder names “Child”. Creating a folder name “Grandchild” in the folder “Child” also fires an event, although I am monitoring “Parent”, not “Child”. Changing the content of “Grandchild” does not trigger an event.
Discover the Changes
Because the event does not give any information about what has changed, you need to discover it yourself.
To do so, the content of the observed folder prior to the change is needed, and the content after the change is needed too. This sounds simple, but there are some details to pay attention to.
Time Matters
To get the current content of a folder, I found no other way but to call StorageFolder.GetItemsAsync (or one of it variants to retrieve folders and files, GetFoldersAsync and GetFilesAsync).
Calling StorageFolder.GetItemsAsync() on my C:\Windows\System32 folder takes more than four seconds for ~3,100 items (Directory.GetFileSystemEntries took 0.1 second [100 milliseconds]). Four seconds are an eternity on a computer. Lots of additional changes might happen while I am trying to retrieve the current state. And in addition, one second after the first notification the duplicate will be fired, but nothing has changed.
Abort Content Retrieval
So there is the need to somehow be able to abort the retrieval of the current content list, in case a real additional change occurred.
I implemented this by reading the content in small chunks. StorageFolder offers methods to read items chunk wise. Between reading a chunk, I check a flag that is set when a new change occurred. If that flag is set, reading the content is aborted and restarted.
Reading the items chunk wise had no impact on the overall time required to retrieve the content of a folder.
Ignore the Double Notification
How can you tell if the current notification is a new one or the duplicate of the last? And what to do if there is a change 800 milliseconds after the last one occurred, but the notification duplicate has not arrived?
I can’t tell. That’s because the event does not give me any information about what has changed. In my app, I decided to ignore all additional notifications that were sent in less than a second after the “initial” notification was retrieved.
How to Compare the Content?
The list returned by StorageFolder.GetItemsAsync contains the folders first, and then the files. Trying to find differences by comparing the name only will fail, because the name of a folder should not be compared to the name of a file.
The consequence is to have the content lists separated by folders and files, or to find another way to make sure a folder is not compared to a file and vice versa.
It is also worth to mention that the list returned by StorageFolder.GetItemsAsync, and the folder / file variants, is sorted in natural sort order. I found C# comparison implementations on Stack Overflow.
Depending on what your app uses, comparing the name to detect changes might not be sufficient. In case the app relies on the file’s size or the last modified date too, there is additional code to be written, because these attributes needs to be collected in a second step (see Discover Properties of Storage Items in Windows Store Apps).
Conclusion
Creating a FileSystemWatcher for Windows Store apps is heavy stuff from my point of view. Even though I found a way to handle all the ‘challenges’, I do not really feel happy with my solution.
In case you have an approach that you think works good, please feel free to share it with us.
Links
StorageFolderQueryResult documentation
StorageFolderQueryResult.ContentsChanged Fires Twice
Natural sort order C# implementations