Jump to content


AltRoots and symlinks on Linux

altroots symlink

  • Please log in to reply
3 replies to this topic

#1 giveitatry168

giveitatry168

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 09 July 2019 - 09:49 PM

$ p4 client //path/to/some/stream foo
$ ln -s foo bar
$ p4 client  # Add AltRoot for bar

$ cd bar
$ p4 status
  path_to_bar - must refer to client bar
  <file status>

p4 where shows the correct stream, and client_root(path to bar)

This becomes a nightmare in API call to "status" or "rec" where an error (must refer to client)
was raised. A workaround is to set exception level to RAISE_NONE, but this also hides other
errors. Is this expected or it is just an undocumented feature?

Note that other p4 commands like "opened" work without any errors raised in the symlinked clientroot.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1120 posts

Posted 10 July 2019 - 08:05 PM

Sounds like a bug that's specific to "p4 reconcile" ("status" and "rec" are both basically "reconcile" synonyms) and AltRoots.  I recommend reporting it to support@perforce.com.

#3 giveitatry168

giveitatry168

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 12 July 2019 - 05:03 PM

The workaround described in https://community.pe.../s/article/3420 does not work for me.
p4 where matches p4 info
p4 -d `pwd` status raise the same error
p4 -d path_to_foo status works, but
p4 -d path_to_bar status does not

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1120 posts

Posted 12 July 2019 - 06:09 PM

If you want to try to debug it yourself rather than reporting it to support, try running the failing command with "-vrpc=3".  That'll show you what the client is sending the server and what the server is sending the client (I'm guessing that one or the other is sending paths that are derived from the Root rather than the appropriate AltRoot, or something like that).

The client side of the reconcile code is open-source so you can attempt to patch it yourself:
https://swarm.worksh...ientservicer.cc

The *easier* fix would be on the server side, but that's not open-source, so the only way to get a fix there is (again) to report it to support.  However, a client-side workaround should be possible if you can just swap out the bad path the server is sending (assuming that is the root cause) with the correct one, which you can probably figure out yourself using the tools you've already discovered.

Good luck!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users