Jump to content


Syntax for P4IGNORE entry to ignore symbolic link folders

ignores p4ignore symbolic link reconcile symlink

  • Please log in to reply
8 replies to this topic

#1 PaulD

PaulD

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 25 September 2019 - 12:07 PM

Helo, Perforce Community.

We have couple of symbolic links to directories in our perforce depot.
Those links are created on the client correctly and show symbolic link folders in Windows explorer and correct view in P4V client.
But if we run reconcile on the folder above we see those items shown as edited items.
We have tried to use .p4ignore.txt but this seems to have no effect on symlink files.

We have a folder structure like
Project
- src
- - Common
- - Client
- - Other

where Common is a symlink folder to other location.

We have created .p4ignore.txt with following content:

# Symbolic links [as are always updated with the content]

Common

in folder src above.
But the folder is still shown as being changed in reconcile.

We have tried different permutations:
\Common
\Common\
/Common
/Common/

but without any success.

What would be the correct syntax in .p4ingore.txt to ignore the changes due to symlink folder created on the disk compared to depot structure.

Best Regards
Paul

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1148 posts

Posted 27 September 2019 - 02:21 PM

P4IGNORE only applies to "new" files (i.e. files you don't want to add to source control at all) and doesn't apply to modifications you make to files you've already added.

When you run reconcile and it opens the symlinks for edit, what do you see as the diffs?  If you submit the files, are they changed?  Does "verify -q" show the symlinks as being "BAD!"?

#3 PaulD

PaulD

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 17 January 2020 - 03:07 PM

If we diff the symlink changes in reconcile we see on the original side a relative path like
..\..\include\header.h
and on the right side the content of the file.
So the links are not bad, the filling of the symbolic linked file with the content confuses P4V client somehow.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1148 posts

Posted 17 January 2020 - 03:41 PM

Does Perforce know that these are symlinks?  (Is the filetype "symlink" or "text"?)

C:\Perforce\test\types>p4 files ...
//stream/main/types/bar#1 - add change 126 (symlink)
//stream/main/types/foo#1 - add change 126 (text)

What does "p4 diff" at the command line show (just to rule out confusion in P4Merge -- I'm not sure if it's necessarily sensitive to filetypes)?

What if you do "p4 edit -t symlink (filename)" to explicitly open the file for edit as a symlink?

#5 PaulD

PaulD

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 17 January 2020 - 05:47 PM

Type is symlink.
If I add the file to a changelist and run p4 diff command I get the output: (... files differ ...)
If I open the file for edit using the command above and run diff again, the files differs as well.

If I revert the file, the file becomes the same content as ..\..\include\includes.h.
But this is actually wrong. To able to use the file I need the file content inside.
What would be the expectation of the file content using a file as symlink type?

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1148 posts

Posted 17 January 2020 - 06:27 PM

The symlink's content should just be the link (i.e. the text of the path that the link points to).  By default, the filesystem will redirect file accesses to the path that the link points to (if you're on a platform that supports symlinks!), but if you tell Perforce that the file is a symlink, it should just operate on the link, not the underlying file, when you diff/edit/reconcile/sync/etc.

If you replace the symlink with the actual content of the file, it's not a symlink any more.  It sounds like you don't actually want to use the symlink type here (perhaps you're on a platform that doesn't support symlinks?), and should just reopen the file as text (p4 edit -t text includes.h) so that it can contain the actual content.

If you do want the file to be a symlink, you should revert your change (do "p4 clean includes.h" if you haven't opened the file, or "p4 revert" if you have).

#7 PaulD

PaulD

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 20 January 2020 - 12:22 PM

Yes, we are on Windows 10 and Windows 2016 Server for Jenkins build.
After revert and see the file on the disk (as .symlink with 0KB) and the local programs can read and see content of the original target file.

But now I have issues with P4 Plugin on Jenkins server. Seems that the P4 sync fails for those files and throws the error:
12:21:04 ERROR: P4: Task Exception: com.perforce.p4java.exception.P4JavaException: com.perforce.p4java.exception.P4JavaException: hudson.AbortException: P4JAVA: Error(s):
12:21:04 symlink file <full file path> can't be sync'd or created with this client program.

even if the file has the same "content" and the disk as on my machine.

I see a .symlink file and can edit this by any program and see the target content.
Not sure, why the P4 plugin mean that the update failed.

#8 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1148 posts

Posted 20 January 2020 - 02:57 PM

That's not a Perforce error message:

C:\Perforce\workshop>p4 grep -e "or created with this client program" //guest/perforce_software/p4/2018-2/msgs/...

C:\Perforce\workshop>

so it must be that (for whatever reason) the Jenkins plugin disallows symlink files.

#9 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1148 posts

Posted 20 January 2020 - 03:00 PM

Oh, I take it back -- it's apparently a Java limitation.  :(

C:\Perforce\workshop\guest\perforce_software\p4java>p4 grep -e "with this client program" ...
//guest/perforce_software/p4java/r14.1/src/main/java/com/perforce/p4java/impl/mapbased/rpc/func/client/ClientMessage.java#1:											"%type% file %file% can't be sync'd or created with this client program.",

C:\Perforce\workshop\guest\perforce_software\p4java>

Not sure what the workaround would be.





Also tagged with one or more of these keywords: ignores, p4ignore, symbolic, link, reconcile, symlink

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users