After enabling the EditorSysConfigAssistant plugin, we identified an issue where the USN Journal assistant fails on machines using a virtual drive (eg: subst) for their Perforce workspace root.
During our investigation, we discovered that StartSystemCheck stores the VolumeName of the virtual drive rather than the underlying physical drive. Consequently, subsequent calls to fsutil fail because they are being directed at a drive letter that does not support the USN Journal interface in the same way a physical NTFS volume does.
This failure cascades into the AssetDataDiscoveryGatherer:
- “PlatformFileJournal is not available on volume ‘Z:’ of project directory ‘Z:/UE4/Engine’, so AssetDiscovery cache will not be read or written. Unavailability reason: CreateFile failed to open for reading FileJournal on volume 'Z:. GetLastError == 5 (0x00000005) (ERROR_ACCESS_DENIED: Access is denied.)”
Because it cannot access/grab the journal file, the system defaults to disabling the Asset Registry Cache, impacting editor performance for the affected developers.
We attempted to launch the Editor via UGS using the physical drive path instead of the virtual one but this created a discrepancy between the Editor’s file pathing and the Perforce Workspace root, which triggered secondary failures within the Revision Control source code (SSC).
Do you have a recommended temporary workaround to keep the Asset Discovery cache enabled for users on virtual drives while we wait for a formal fix?
Thanks in advance.
[Attachment Removed]
The DiscoveryCache is one of two cache layers the AssetRegistry uses. It caches the directory listing.
The AssetRegistry also uses a Gatherer cache, which is stored in <ProjectRoot>\Intermediate\CachedAssetRegistry_*.bin. It caches the read of the .uasset files to load their header information.
The DiscoveryCache is relatively minor: saves ~30seconds on a project with 4 million files.
The GathererCache is much more important: saves ~10 minutes on a project with 4 million files.
Is the GathererCache working in your case? What is the time difference you are seeing for the completion of AssetRegistry gathering on machines with and without the virtual drive?
Are you able to debug this case it locally? I do not understand why the failure code would be ERROR_ACCESS_DENIED. Maybe the problem is unrelated to the different drive letter and is related to some other permissions issue. Or maybe the NTFSJournal API we’re using requires admin permission for some reason. It is not supposed to, we are intentionally using the functions in the API that do not require admin permission. If you launch the editor with admin permission, does it avoid the problem?
If running with admin permission does not solve the issue, then I don’t have any other easy workarounds to suggest.
[Attachment Removed]
The GathererCache still works yes. AssetCache bins are created and used. For DiscoveryCache time, we are seeing an increase from ~5 to ~12 seconds, on average, for developers with a mapped drive.
I haven’t debug this myself. The engineer who originally reported the issue mentioned that the access to the Journal Data works fine if the mapped drive points to a physical drive (eg: “Z: -> D:\”); it fails when pointing to a sub folder (eg: “Z: -> D:\UE4\Workspace”).
Running with admin permission didn’t help.
[Attachment Removed]
I reproduced this locally and have written a fix. I think we just need to call GetFinalPathNameByHandle when creating the special path to the journal file in CreateJournalWindowsHandle, the same way we do elsewhere in the assetregistry when we need to know the physical filepath.
I will send you the commit changelist after testing and submission.
[Attachment Removed]
Submitted in CL 51268622, aka github commit 9759e8ee472aea2365d3ddd592cea9101cc3e44f :
AssetRegistry: AssetDataGatherer: When using junctions, support finding the proper USN journal file for the physical drive the junction is on. …
Let me know if you have any problems after taking that change.
[Attachment Removed]
Thanks! We’ll integrate next week and report back.
[Attachment Removed]
Hello Matt. The change resolved the issue. Thanks!
[Attachment Removed]