Jump to content


Tamper warning on integrate of a file turned into symlink


  • Please log in to reply
5 replies to this topic

#1 Jeff Varga

Jeff Varga

    Member

  • Members
  • PipPip
  • 18 posts

Posted 05 June 2019 - 09:38 PM

A series of binary libraries were checked in to a branch like so:
$ p4 add -t binary ...

foo.so
foo.so.5
foo.so.5.6

It was then realized that those .5... files should have been checked in as symlinks, so they were changed with a `edit -t` like so:
$ p4 edit -t symlink <files>

$ p4 submit

This fixed the files appropriately in the depot and all seemed well
$ p4 filelog <snip>/foo.so
<snip>/foo.so
... #2 change 1962803 edit on 2019/05/03 by <snip> (symlink) <snip>
... #1 change 1962762 add on 2019/05/03 by <snip> (binary) <snip>

$ p4 -ztag filelog <snip>/foo.so
... depotFile <snip>/foo.so
... rev0 2
... change0 1962803
... action0 edit
... type0 symlink
... time0 1556924641
... user0 <snip>
... client0 <snip>
... fileSize0 15
... digest0 AB8A07E855FDB6C779E044428D301F41
... desc0 <snip>
... rev1 1
... change1 1962762
... action1 add
... type1 binary
... time1 1556912737
... user1 <snip>
... client1 <snip>
... fileSize1 613864
... digest1 E6F20439E307F88620B7E963AE743511
... desc1 <snip>

We now need to fold these changes up into the parent stream and are performing a merge of those two changes in one integration like so:
p4 merge ...@=1962762
p4 resolve -am ...
p4 merge ...@=1962803
p4 resolve -am ...

Merge and resolve are clean, files on disk look great:
$ ll <snip>foo.*
lrwxrwxrwx 1 <snip> 14 Jun 5 12:51 <snip>foo.so -> foo.so.65
-r--r--r-- 1 <snip> 613864 Jun 5 12:42 <snip>foo.so.2.8.3
lrwxrwxrwx 1 <snip> 17 Jun 5 12:51 <snip>foo.so.65 -> foo.so.2.8.3

But when I go to submit

<snip>foo.so tampered with after resolve - edit or revert.

Submit aborted -- fix problems then use 'p4 submit -c 1978427'.
Some file(s) could not be transferred from client.

It looks like the second integrate didn't fix the type?
$ p4 fstat <snip>/foo.so
... depotFile <snip>/foo.so
... clientFile <snip>/foo.so
... isMapped
... action branch
... change 1978427
... type binary
... actionOwner <snip>
... workRev 1
... resolved
... reresolvable
... ourLock

Is there something I'm missing?  I'd really like to merge this in an atomic commit.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 819 posts

Posted 05 June 2019 - 10:16 PM

Hard to say what went wrong with the resolve without seeing its output.  IIRC there's some tricky logic around symlink type resolves due to the fact that for a symlink the content and the type are inextricable -- you get a binary resolve on the content, and then whatever you choose implicitly resolves the type to match.  I don't remember what server version that logic went into, though, so if you're using an old version you're probably just hitting an old bug.

In any case, "p4 edit -t symlink foo.so" should fix you, I think.  That'll get the filetype to be what you want it to be, and if the file's opened for "edit" then the tamper checking doesn't apply.

#3 Jeff Varga

Jeff Varga

    Member

  • Members
  • PipPip
  • 18 posts

Posted 06 June 2019 - 06:03 AM

Only interesting thing is that the initial integrate is a sync/delete

$ p4 merge -F -r -P <snip> -S <snip> <snip>/foo.so@=1962762
<snip>/foo.so#1 - sync/delete from <snip>/foo.so#1
... must resolve branch from <snip>/foo.so#1

$ p4 resolve -am ...
<snip>/foo.so - resolving branch from <snip>/foo.so#1
<snip>/foo.so.6 - branch from <snip>/foo.so

$ p4 merge -F -r -P <snip> -S <snip> <snip>/foo.so@=1962803
<snip>/foo.so#1 - integrate from <snip>/foo.so#2
... must resolve content from <snip>/foo.so#2

$ p4 resolve -am ...
<snip>/foo.so - vs <snip>/foo.so#2
Non-text diff: 0 yours + 1 theirs + 0 both + 0 conflicting
<snip>/foo.so - merge from <snip>/foo.so

$ ls -latr <snip>/foo.so
lrwxrwxrwx 1 <snip> <snip> 33 Jun 5 22:55 <snip>/foo.so -> foo.so.6.0.0

I'd rather not perform an edit as a part of the integrate as it creates integration oddities (interchanges reports are a pain with integrate+edit checkins).  Additionally there are about 9000 affected files as part of this merge that would get the love.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 819 posts

Posted 06 June 2019 - 02:17 PM

Ah, there might some fun edge case bug here that has to do with the file being opened for branch and then doing a cherry-pick into the branched file that requires a funky symlink resolve.  I remember testing and fixing the basic symlink<->binary merge/copy workflow to work in a reasonable way but I don't think I ever encountered someone trying to cherry-pick an edit that changed a file into a symlink, while the file was already open for branch with a different filetype.  :unsure:

Since you can't actually meaningfully cherry-pick a symlink (there's nothing to "merge"), and you're merging from 2 contiguous revisions anyway, the net effect should be the same as a branch, so the best workaround is just to set it up that way directly rather than trying to use the cherry-picking workflow:

p4 revert foo.so
p4 copy foo.so#2


If this same thing needs to happen with a whole bunch of files, just do it across all of them and use @1962803 as the rev specifier instead of doing the two @= cherry-picks.

#5 Jeff Varga

Jeff Varga

    Member

  • Members
  • PipPip
  • 18 posts

Posted 07 June 2019 - 04:30 PM

Using `p4 copy` with a bunch o ztag and pipes worked well enough to get the change integrated over.  Is there a formal bug on what I encountered above?

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 819 posts

Posted 07 June 2019 - 04:49 PM

No idea (though I doubt it); you should follow up with support@perforce.com.

(edit) The exact bug FWIW is in that second merge/resolve sequence:

$ p4 merge -F -r -P <snip> -S <snip> <snip>/foo.so@=1962803
<snip>/foo.so#1 - integrate from <snip>/foo.so#2
... must resolve content from <snip>/foo.so#2

$ p4 resolve -am ...
<snip>/foo.so - vs <snip>/foo.so#2
Non-text diff: 0 yours + 1 theirs + 0 both + 0 conflicting
<snip>/foo.so - merge from <snip>/foo.so

The resolve should have automatically changed the type to "symlink".  The fact there isn't a filetype resolve in the merge output might have something to do with it, but I can't remember if that's expected or not.  Either the filetype resolve gets suppressed by the merge and then it happens implicitly as part of the content resolve (via a resolve-time check to see if the source/target have incompatible filetypes), or it gets scheduled by the merge (as is normal any time the source and target have different filetypes) and then the content resolve looks for a corresponding filetype resolve and auto-accepts in the incompatible filetype situation, and I can't remember now which one it's supposed to be.  

In either case, I'm pretty sure that the reason it's not working is the file being opened for branch rather than being an existing depot file -- whatever it does for the existing depot file case (which I *think* will work correctly) is what it's supposed to be doing here.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users