Jump to content


Odd p4 verify behaviour

verify

  • Please log in to reply
3 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
  • 722 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.

#4 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 140 posts
  • LocationSan Francisco, CA

Posted 08 January 2019 - 10:54 PM

Just to mention it for posterity's sake, there was a time in 2017 where we were having all kinds of problems on a few specific files because of issues with xml files and how Perforce handled the BOM. My memory is a bit sketchy, but I think it had to, actually, with clients prior to 2015.x checking in xml files, then later updates to the BOM handling not compensating for it ...? Something like that. We had a dude checking in xml's with a 2+ year old client. Subsequent post-2017 p4d updates fixed everything up.

That RCS bug might be one that I came across, too. It was terribly hard to figure out because it was doing it within Windows binary files that happened to have custom properties that were named the same as RCS keywords. It also resulted in weird errors when trying to sync those revisions.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com





Also tagged with one or more of these keywords: verify

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users