cgallred
commented
3 years ago Leaving the old name in the placeholder is by design. Updates to the backing store are outside ProjFS's control, so it has to work on the principle that local file system operations, like rename, will only affect the local file system. It leaves the old name in the placeholder so that data recalls will continue to work in a case like this (assume foo.txt starts as a non-hydrated placeholder):
mv .\foo.txt .\bar.txt
cat .\bar.txt
<expect to see contents that were originally in foo.txt>If the provider does indeed reflect local file system operations into the backing store immediately, then it is the provider's responsibility to update the projection accordingly. In the rename example, the provider should call PrjDeleteFile, as you did, to clear the now-stale placeholder.
In the case where a rename moves the file into a non-placeholder directory, ProjFS detects that the destination is not a placeholder directory and hydrates the data before allowing the rename. The provider would not call PrjDeleteFile in this case.
xavierd
Hello,
I work on EdenFS (https://github.com/facebookexperimental/eden) and one of the bug I'm currently looking at is the surprising behavior of ProjectedFS when renaming a placeholder file:
In the logs of EdenFS, I can see that PRJ_GET_FILE_DATA_CB was called with:
fbcode\\eden\\fs\\TARGETS, ie: the path prior to the rename, which makes for some fun behavior:To fix this this, I've tried calling
PrjDeleteFileafter rename to clear the placeholder which subsequent reads would recreate by using PRJ_GET_PLACEHOLDER_INFO_CB, but this doesn't work when the file is renamed to a directory that isn't a placeholder (like one thatmkdirjust created).From what I can see, this really feels like a bug in ProjectedFS as the placeholder should be updated with its new filename. In the case where this isn't a bug, what is the proper way to handle renaming placeholders?