aspnet/FileSystem

ChangeTokens and signalling Deleted files

Tratcher opened this issue · 4 comments

Tratcher commented

From @dazinator on October 24, 2016 16:47

Hello,

In my custom IFileProvider, i'd like it to behave correctly when a file being watched is deleted. I already have it returning a custom IChangeToken for the watched file, but i'm not clear on exactly what needs to be done in order to correctly signal a Delete. Are there any examples of this that I could look at?

Copied from original issue: aspnet/StaticFiles#162

dazinator commented

I figured some of this out. Looks like the behaviour is:

  • Client calls watch on file provider to get a change token.
  • Change tokens are generally cancellation change tokens - which means the change is signalled to the client by calling Cancel() on it.
  • when the token is signalled (cancelled) the token is essentially dead and should not b reused. This means the client should dump it and get a fresh one by calling Watch() again.

This makes sense to me so far but the thing that remains confusing to me is that if the client is watching a glob pattern token, how does the client know which of the files were changed when the token is signalled? The client can register a callback to be invoked when the token is signalled, and this callback has a 'state' argument. Should this "state" argument contain info about the files that were changed?

dazinator commented

Can I seek some clarification?

If watching a glob pattern with PhysicalFileProvider - say *.txt - am I right in assuming the only way to work out what files have changed when the change token is signalled, is to:

  1. Query all the files that currently exist matching that pattern before you do the "watch"
  2. When the change token for the glob is signalled - re-query the files using the glob.
  3. Compare the state of files before and after - to calculate list of additions, modifications, deletions?

If that's the case - my follow up question would be what if a file is modified in between 1 and 2?

So to solve that you would have to watch the pattern first, then query the files? But if the pattern is signalled before you have queried the files - you then have to introduce locking. This starts to get complicated quite quickly!

Would be better if Watch / change token subscription was extended to enable you to retrieve information about reason for the change token singalling (i.e the added, modified, and deleted files)

dazinator commented

TLDR: How to know what files have caused a change token covering a glob pattern, to be signalled?

aspnet-hello commented

This issue was moved to dotnet/aspnetcore#2549