The Package Support Framework (PSF) was originally an open-source project to help Win32/DotNet applications run when inside an MSIX Container.  TMurgent has taken up the support for the PSF in our own fork here on GitHub.

The change list shown below covers changes made in v.2022.07.10 since the June 2022 release:

• DynamicLibraryFixup fix to allow for mixed cases in call by app. Sometimes the apps ask for the dll by name and not use the same case as the actual file.
• FileRedirectionFixup fix for CreateFile when request is to the redirected area directly and file either exists already there or the request was to CREATE_ALWAYS.
• FileRedirectionFixup fix for CreateFile/Ex. When these functions return, the primary reply is either a file handle or an invalid handle with the error available via GetLastError().  Most apps look for a valid handle and then ignore the error.  Because these functions make multiple calls, we didn’t always reset the error code to ERROR_SUCCESS when we end up returning the handle from the non-last call.  This is now fixed.
•  FileRedirectionFixup fix in DeleteDirectory to allow deletion of redirected directory (even though the package folder will still be present).
• FileRedirectionFixup change. Added a new intercept for ReadDirectoryChangesW and ReadDirectoryChangesExW that only log the calls. In this call, the app uses an already open handle.  In apps where we see this being called, that handle was to the redirected folder, which is the logical place to be watching for changes. But I suspect that there will be a situation where the wrong handle gets used. That the function is being used is logged to the console port (DebugView) in the release build. You can use the Debug build for extended logging which will reveal the path to the directory. Until we find an app that requires modification, this is the best thing to do.
• FileRedirectionFixup non-impact change.  Intercepts were coded but not enabled for many ucrtbase.dll (POSIX) file system calls.   So far, we have seen that these APIs call the APIs we already intercept, so intercepting these functions is not currently required.   I don’t have a high level of confidence that there aren’t some additional POSIX calls that might need remediation someday, so this serves as a warning to pay attention to POSIX calls in failed apps.

The release can be found on GitHub and will be included in the following releases of my tools:

• PsfTooling   5.4 or later.
• TMEditX      2.4 or later.