Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does p4vfs work with P4 Client correctly #54

Open
alexjingsi opened this issue Dec 26, 2024 · 3 comments
Open

How does p4vfs work with P4 Client correctly #54

alexjingsi opened this issue Dec 26, 2024 · 3 comments

Comments

@alexjingsi
Copy link

When I Installed p4vfs service, and rehydrating some files, their size becomes 0, but it seems that just a refresh operation from the p4 client will trigger IO to read the complete file, causing these files to be re-downloaded. How can I correctly cooperate with the P4 client to avoid unexpected dewatering?

@jessk-msft
Copy link
Collaborator

Hi alexjingsi,
By "P4 Client" I'm assuming that you mean the P4V application. In that case it may depend on the file extension and if P4V is possibly reading it from disk to preview it. For example, within the tab "Files -> Preview".

It's often surprising to find which process may try to hydrate the file first. It's no uncommon to see Windows Defender service (MsSense.exe) read the file in search for possible malware. You can look at the P4VFS.Service logs ("%PUBLIC%\Public Logs\P4VFS\P4VFS.Service") to inspect the process ID which hydrated the file. You can also use the p4vfs monitor application in the task tray p4vfs monitor show to tail the service log to show the same info.

P4VFS service does have an ExcludedProcessNames configuration variable, which could possibly be used to prevent p4v.exe from hydrating the file. I generally wouldn't recommend this though ... we typically only use this feature for temporary unit testing.

p4vfs set ExcludedProcessNames=p4v.exe

Regards
-Jess

@alexjingsi
Copy link
Author

alexjingsi commented Jan 2, 2025

Hi @jessk-msft ,
Thanks for your reply. Yes, I am using the "p4v client". Specifically, our workflow is to perform all p4-related operations in p4v. Now I am trying to integrate p4vfs into the workflow:

  1. Start the p4vfs service and hydrate some files into virtual files, and their disk usage becomes 0

  2. In the "p4v client", whether through "Refresh All" or "Get Latest version", p4vfs will be called through p4v to restore the files to real files

  3. I tried "p4vfs set ExcludedProcessNames=p4v.exe", which is indeed effective, but it can only prevent "Refresh All" from restoring files. p4v's "Get Latest Version" will still directly restore files, and strangely, it does not trigger the file driver filtering of p4vfs

Could you provide some suggestions for the following questions?

Q1: If you want to use the p4vfs function, should you completely abandon the use of "p4v client" and instead use p4vfs.exe directly to perform all p4 operations? So as to avoid the accidental restoration of hydrated files by p4v?

Q2: Through "p4vfs resident -v ", or "p4vfs sync -v ", local files can be changed to hydrated state, but they will be automatically restored when read again, and they are no longer virtual files. Is it possible to mark the file as hydrated only, but at the same time keep the actual file size, instead of changing the disk size to 0, so that the latest version can be avoided only when updating, without affecting its reading when it is not updated.

Regards
-Alexjingsi

@jessk-msft
Copy link
Collaborator

jessk-msft commented Jan 3, 2025

Hi alexjingsi,

Q1. I think it's essential to be able to mix-n-match syncing form P4V, p4.exe and p4vfs.exe. Simply consider that syncing from p4vfs would typically be a virtual sync (download file contents on demand), while a sync from P4V "Get Latest version" will be immediate file download. I'd expect "Get Latest version" to overwrite a earlier revision of a virtual sync'd file, without first hydrating the old revision.

Q2. A virtual file should be reporting a correct non-zero file size, and zero disk size. There can be a slight discrepancy when it's a "text" type file, in which case the sync -s can be used to have the exact per-client file size calculated instead (depending on line-ending and BOM settings). There's also OFFLINE attribute set when the file is virtual .... which some applications respect to avoid reads. (OneDrive does this)

I hope that helps.
Regards,
-Jess

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants