How/when to use PrjUpdateFileIfNeeded and PrjDeleteFile in PrjFS?

Mickael Pointier 5 Reputation points
2023-07-12T14:00:55.4766667+00:00

I've been reading the Projected File System (ProjFS) programming guide multiple time, including the pages about Handling View Changes and I implemented a proof of concept where I can properly show the right version of files when changing branches in my revision control system based on ProjFS, except right now it's done quite heavy handedly by scanning the entire repository and call PrjUpdateFileIfNeeded (with updated ContentID in the PRJ_PLACEHOLDER_VERSION_INFO structure) or PrjDeleteFile depending if the file was modified, created or removed.

That works nicely for a toy folder with a dozen files, but the use case is typically something like 150k+ files in a few thousands folders, in which case scanning the entire local folder structure to compare it with the ones managed by my tool seems quite unpractical.

What would be the suggested way to do that, knowing that I need to support the following cases:

  • My tool is not running, the user adds some files and folders on the local repository, then at some point launches my tool: How can I detect the new files so I can add them to the revision control system?
  • Same thing, but the user deleted some files: How can I detect that the files have been deleted when the tool is started?
  • The tool is running, currently on the branch "Dev", then the user need to fix a bug in the "QA" branch, so they change to this branch that has a few thousands of differences, added and removed files and folders: How can I quickly update the local view so the files are replaced by the proper version for this branch?

One approach I tried was to catch the PRJ_NOTIFICATION_FILE_OPENED and check if:

  • Does the file exist?
    • If not, then call PrjDeleteFile
  • Does callbackData->VersionInfo->ContentID match my internal data?
    • If not, then call PrjWritePlaceholderInfo with an updated ContentID

The PrJDeleteFile did actually work, but the PrjWritePlaceholderInfo (despite returning S_OK) did not seem to achieve anything: On the next notification call the ContentID was still incorrect.

I've probably missed something stupid, but after a few days spent on that, I've no more ideas to try.

Thanks in advance!

Windows API - Win32
Windows API - Win32
A core set of Windows application programming interfaces (APIs) for desktop and server applications. Previously known as Win32 API.
2,737 questions
C++
C++
A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.
3,856 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Mickael Pointier 5 Reputation points
    2023-07-17T13:29:45.8433333+00:00

    Hmm, so basically the content selection should be triggered by a difference in time stamp, the Content ID is just some additional information that gets provided when the file content is requested?

    I guess the timestamp has the advantage to being easy to fetch with the normal Win32 API; but technically it can collide: In a system with multiple users working on multiple branches, or build machines crunching data and exporting converted files, having the same file changed at the same time is not completely impossible.

    I hope the timestamp is millisecond accurate at least, to limit risks of fetching the wrong version of the file

    1 person found this answer helpful.

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.