How to verify workspace integrity?

[Mikael Kalms]

Hi,

 

we have a situation on one machine where I believe (95% certain, will be able to check tomorrow) that there is a file in the workspace, whose contents does not match the repository version.

The client is probably running Plastic 7.x and have "Check content (hash) when the file timestamp is modified to set it as "Changed"" enabled. The client is probably not running Plastic Change Tracker.

 

It is possible that the file has an identical timestamp to what's in the repository. It is possible that the file has an identical size to what's in the repository. I will make some more detailed checks tomorrow.

 

1. Is there a command which I can run which will make the Plastic GUI or CM perform a full validation of the on-disk workspace contents, regardless of timestamps?

2. If the timestamp (and perhaps also size) is identical, will Plastic GUI / CM assume that the file's content hasn't changed, without actually looking at the bytes within?

[psantosl]

Hi,

There is an update option to force checking hashes.

Plastic trusts the modification bit as a way to know the file wasn't changed. Otherwise update would be super slow (if it had to hash everything all the time). So, in the event someone played with the timestamps manually, he could break the workspace.

By default Plastic doesn't set repo timestamps on disk, but time when they were downloaded. This is because build systems expect it this way.

 

To force the update, you can try:

 

cm update . --forced

 

pablo

[Mikael Kalms]

Thanks. I just got access to the machine. The file did indeed have different content locally. It also had identical "modified" and "created" timestamps, from back-then when the Unity editor initially had created the file uniquely on that machine.

I can't explain the process which led to this situation, but there was a local difference on the machine which 'cm status . --all' and 'cm update . --all' didn't recognize. We deleted the file manually and updated to get a good version of the file.

Since it seems there is no option to check all local content (ignoring metadata - rather, validating that metadata is not inconsistent) we'd resort to a more blunt method in this kind of situation in the future (after we know for sure the problem is file content mismatch between machines): delete all files in workspace, then update to get good versions onto the machine.