mirror of
https://github.com/facebook/sapling.git
synced 2024-10-05 14:28:17 +03:00
e24f2bf601
Summary: While most PrjFS operations only communicate about the filesystem object they're modifying via the [`PRJ_CALLBACK_DATA->FilePathName`](https://learn.microsoft.com/en-us/windows/win32/api/projectedfslib/ns-projectedfslib-prj_callback_data) member, notifications via the [`PRJ_NOTIFICATION_CB`](https://learn.microsoft.com/en-us/windows/win32/api/projectedfslib/nc-projectedfslib-prj_notification_cb) have a `destinationFileName` argument as well. This is documented as: > If notification is PRJ_NOTIFICATION_PRE_RENAME or PRJ_NOTIFICATION_PRE_SET_HARDLINK, this points to a null-terminated Unicode string specifying the path, relative to the virtualization root, of the target of the rename or set-hardlink operation. While the individual STRACE `NotificationArgRenderer` functions handled the extra path, `PrjfsLiveRequest::formatTraceEventString` does not. This forwards the string to that object, allowing it to be rendered if needed, so that it shows up in the `eden trace fs` output. Reviewed By: xavierd Differential Revision: D46809287 fbshipit-source-id: 781db1d911a975902d0b27d9ba4f553cc3b85299 |
||
|---|---|---|
| .. | ||
| benchmarks | ||
| cli | ||
| cli_rs | ||
| config | ||
| digest | ||
| docs | ||
| fuse | ||
| inodes | ||
| journal | ||
| model | ||
| monitor | ||
| nfs | ||
| notifications | ||
| privhelper | ||
| prjfs | ||
| py | ||
| rocksdb | ||
| scripts | ||
| service | ||
| sqlite | ||
| store | ||
| takeover | ||
| telemetry | ||
| testharness | ||
| third-party | ||
| utils | ||
| Cargo.toml | ||
| CMakeLists.txt | ||