Jump to content


Odd p4 verify behaviour

verify

  • Please log in to reply
2 replies to this topic

#1 MikeW

MikeW

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 24 September 2018 - 12:01 AM

Hi, I'm getting odd behaviour from p4 verify and I would appreciate if someone could help explain what is causing it.

p4 verify -qz //...

//external/source/pugixml/tests/test_xpath_parse.cpp#1 - add change 32 (text) 08FD7DFADB3CD6080C859EBA7DEACE22 BAD!

but...
p4 verify //external/source/pugixml/tests/test_xpath_parse.cpp#1

//external/source/pugixml/tests/test_xpath_parse.cpp#1 - add change 32 (text) 86705BC52A7377BB4A6BA1EA48AF02ED
and
p4 verify -qz //external/source/pugixml/tests/...

//external/source/pugixml/tests/test_parse.cpp#1 - add change 32 (text) 26A84EDCFF23D8FF498E25E4A2EAD912 BAD!
//external/source/pugixml/tests/test_xpath_parse.cpp#1 - add change 32 (text) 640DF0E515A199E47ED786091FDC0487 BAD!

This makes no sense to me. Why does the manner in which a file is checked by p4 verify affect the hash that gets generated? And why did an additional file get seen as bad with a different pattern?

These commands are being run from the p4d machine itself (running on ubuntu). Running p4 verify -qz //... from my Windows workstation results in:

p4 verify -qz //...

//external/source/SDL2/acinclude/libtool.m4#1 - add change 231 (text) 7C9C9B614D68E0D1281D777E86B00A85 BAD!
//external/local/imgui/imgui_draw.cpp#1 - branch change 491 (text) 19C93A675DE5EBA22988EAC6D57330A9 BAD!
//external/source/pugixml/tests/test_parse.cpp#1 - add change 32 (text) 26A84EDCFF23D8FF498E25E4A2EAD912 BAD!
//external/source/pugixml/tests/test_xpath_parse.cpp#1 - add change 32 (text) 640DF0E515A199E47ED786091FDC0487 BAD!
//external/local/qt/5.9/msvc2017_64/include/QtXmlPatterns/5.9.0/QtXmlPatterns/private/qcommonnamespaces_p.h#1 - branch change 12 (text) 41A698B925EBD62FA0BF5D93684BED3D BAD!
//external/source/qt/5.9/msvc2017_64/include/QtXmlPatterns/5.9.0/QtXmlPatterns/private/qxsdnotation_p.h#1 - add change 11 (text) 45EA71D34F45710CF821F93CF119BDDB BAD!

And I'm not sure why. Possibly line ending / encoding related?

I have checked the disks on the server and all appears to be fine. The only unusual thing about the server is that it is an AMD Ryzen rather than an Intel CPU.

Any insight is greatly appreciated, thanks in advance!

Mike.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 664 posts

Posted 24 September 2018 - 01:43 PM

I'm suspicious of that "-z" option.  What do you get if you run "p4 verify -q //..."?

The difference in behavior between clients could be due to differing permissions -- line ending translation of the client *shouldn't* matter since this is purely a server side operation.  Double-check "p4 protects" and make sure you have super permissions to all the files in both environments.

#3 MikeW

MikeW

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 24 September 2018 - 05:39 PM

Thanks for the reply. I should have mentioned that I get the same behaviour without -z. p4 protects look good.

I managed to resolve the issue by updating my 2017.1 server to the latest version. Now all verify commands pass as I would expect.

Amongst the bugs fixed since I last updated I found a reference to an issue with RCS keywords being present in files being handled when they shouldn't be. I suspect this was the cause as while we don't use those keywords content from third-parties sometimes includes them.

Mike.





Also tagged with one or more of these keywords: verify

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users