Jump to content


AltRoots and fstat generating "not under client's root" error


  • Please log in to reply
5 replies to this topic

#1 Matt Albrecht

Matt Albrecht

    Member

  • Members
  • PipPip
  • 22 posts

Posted 23 August 2018 - 03:58 PM

I'm running a Windows client and a bash shell in Windows Subsystem for Linux ("bash for windows").  I've setup my client so that it has:

Root:
	c:\p4\depot\project

AltRoots:
	/mnt/c/p4/depot/project

According to the client definition, if a client is used on Windows, the windows path must be the Root path, and all others must be the AltRoots.  So this setup looks correct.

For nearly all operations, this setup works just fine.  However, I just tried running fstat on the absolute file path in the bash shell, which generated an error:

$ cd /mnt/c/p4/depot/project
$ fstat -Olhp /mnt/c/p4/depot/project/readme.txt
Path '/mnt/c/p4/depot/project/readme.txt' is not under client's root 'c:\p4\depot\project'.

Additionally, passing in a relative path generates the same error message.  The server version is P4D/NTX64/2018.1/1660568.

This gets even stranger if I add an additional AltRoot path to a path linked to another directory.  For example, if the additional AltRoot is '/home/myself/p4/depot/project', then the error reports the client root as '/mnt/c/p4/depot/project'.

Is this a limitation with fstat, or a setup issue, or something else?

#2 Matt Albrecht

Matt Albrecht

    Member

  • Members
  • PipPip
  • 22 posts

Posted 24 August 2018 - 02:11 PM

An additional strangeness - the P4V client, running on a Windows X11 server and in Bash for Windows, runs the p4 fstat -Olhp command without an issue.

#3 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 588 posts

Posted 24 August 2018 - 03:23 PM

I'm not familiar with Bash for Windows -- are you running Linux executables or Windows executables in this environment (does it support either/both)?  The disparity you're describing might be what you'd see if you were running one client app that was built for Windows and one that was built for Linux.

#4 Matt Albrecht

Matt Albrecht

    Member

  • Members
  • PipPip
  • 22 posts

Posted 24 August 2018 - 09:12 PM

I'm using the linux executable in the environment.  All the other commands seem to be working fine (p4 add, edit, delete, etc), using with relative paths, absolute paths, and depot paths.

#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 588 posts

Posted 24 August 2018 - 09:59 PM

Shot in the dark -- do you have $PWD set in your bash shell to something that isn't your working directory?

#6 Matt Albrecht

Matt Albrecht

    Member

  • Members
  • PipPip
  • 22 posts

Posted 27 August 2018 - 04:19 PM

Strangely enough, the PWD was part of the problem.  Thanks for the suggestion!

It wasn't due directly to the shell, but rather to some of the underlying links that constructed the setup.  They were swapped out while the shell was in the directory.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users