-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to tell if a tombstone exists for a file path? #50
Comments
Ok, after playing around with this, I think I see what is happening, though I still have a question towards the bottom and it would be helpful to know if I missed something... It looks like Utils.TryGetOnDiskFileState() will invoke GetPlaceholderInfo() to test if the file exists in the backing store (if needed), and it then uses that (in combination with what it knows about the local file, if anything) to return false in all situations where an application should treat the file as not existing, which include:
... else it will return true. Does that sound correct? Also, assuming that is correct, my remaining question is ... under what circumstance would Utils.TryGetOnDiskFileState() return OnDiskFileState.Tombstone? Thanks |
What In the case of a tombstone you have a file on disk with a special "tombstone" reparse point. However there is a caveat. The job of a tombstone is to make it look like there's nothing there, but there are certain circumstances where we need to be able to reveal the tombstone's existence. For instance, if you want do |
Thanks for the clarification and additional info! It is unfortunate that there isn't a way to query the VirtualizationInstance for its understanding of the local file state (only - so no callback invocation), since it is the source of truth for that, while I am already the source of truth for the backing store (so I don't need to necessarily know what my own GetPlaceholder callback says, for example). If I were to go the notification route where I have to handle and persist the notion of all files the user has deleted, I fear it is fragile, as my process can be killed before I get a change to handle and persist all notifications. Further, users can delete things while my process isn't running ... which suggests I'd need to scan the NTFS journal to catch up/find missed notifications or something. Not insurmountable, just annoying, especially since that local file state I want must be readily available to you just on the other side of that api fence ;) Thanks again for your prompt and detailed response! |
I just remembered that there might be a different direction you could approach this. If you use FindFirstFileEx with the
The issue of how to handle modifications to the virtualization root while the provider isn't running still exists, but even if |
Ah, that sounds interesting, I'll give that a try. Also good info/point about deletions that happen when provider isn't running. Thanks! |
I finally got around to playing with this today. I think this will be useful/helpful! One thing I wasn't expecting, though, is that this does still invoke GetPlaceholderInfo() callbacks on the sub-directories between the virtualization root and the parent directory of the file/directory passed to FindFirstFileEx() ... my ideal would be for it to just return ERROR_PATH_NOT_FOUND or error 369 (provider unavailable) if the subdirectory doesn't exist locally and has no placeholder, but this still will greatly reduce the number of placeholders requested/cached in my use case. Is that expected? Actually, given that behavior, I suppose I could query each subdirectory myself, stopping as soon as one is not found, to prevent any placeholders from being created... Thanks again! |
This is expected. The That is an interesting suggestion though, and I can see how that behavior would be more consistent. I'll put it on my backlog for future consideration. |
Hello,
I need to know if a tombstone exists so some of my code can behave correctly in the situation where the local user has deleted a file that exists in the backing store.
Utils.TryGetOnDiskFileState() seems like what I want, but I can't get it to return OnDiskFileState.Tombstone ... in the above situation, it returns false with fileState of 0.
This function is returning what I want/expect for all other file situations I've tried, just not this locally deleted scenario.
I did notice this comment on the OnDiskFileState.Tombstone enum value...
"The item was a tombstone and the provider did not specify UpdateType.AllowTombstone."
...but the only api that uses UpdateType that I found was on DeleteFile() and UpdateFileIfNeeded(), and I've not called either of those, so maybe that comment is just misplaced?
Thanks!
The text was updated successfully, but these errors were encountered: