Some files not synced with "Failed to install"

[rkovacs78]

We use p4vfs with many users with no problem, except one who regularly gets some files "Failed to install" when syncing.
During those syncs, many files still get synced successfully but one (or a few?) fails with this:

Warning/Error Summary:
Failed to install //.h#28 -> D:<filename removed>.h

While earlier in the output of this sync, this file is reported successful:
//.h#28 - installed as D:<filename removed>.h

When checking in P4V, the file is not synced.

[jessk-msft]

Hi rkovacs78,

Are either of these files a perforce "symlink" type file? In that case perhaps the target of the symlink is being read by another process when the symlink is sync'd from p4vfs. This could happen if the machine has a file indexing (searching) tool which is watching directories for file changes.

Another possibility is if that .h file is mapped to multiple locations in the client spec. Probably very unlikely.

If you look at the P4VFS.Service logs on the machine under %PUBLIC%\Public Logs\P4VFS.Service you should find the service log showing virtual file activity, and likely the process Id which opened the file and causing a conflict.

Regards,
-Jess

[rkovacs78]

Hi Jess,

Thanks for getting back.

No symlinks in this workspace but Visual Studio was running, so files were possibly accessed by IntelliSense or Visual Assist or text editor itself.

These are relevant lines I found in the service log:

-11/21/2025-11:53:58:: - //.h#28 - installed as D:<filename removed>.h

...

-11/21/2025-11:54:00:: - Failed to install //.h#28 -> D:<filename removed>.h
-11/21/2025-11:54:00:: - Warning/Error Summary:
-11/21/2025-11:54:00:: - Failed to install //.h#28 -> D:<filename removed>.h

...

-11/21/2025-13:44:25:: - //.h#28 - installed as D:<filename removed>.h

...

-11/21/2025-13:44:26:: - //.h#28 - hydrated as D:<filename removed>.h [,,] process [24824.70084]

No hydrate info prior to failure (but possibly hydrated long ago).
It looks like a following sync succeeded and trigger hydrate shortly (that's probably Visual Studio catching the change)

None of this is probably helpful unfortunately.

Cheers,
Rob