When syncing a file of the Perforce "apple" file type (i.e. an old Mac file with a resource fork) from a depot, the expected behaviour (in recent versions of the Perforce tools) is that this "apple" file is created on the client in the AppleDouble format. That is: as two separate files "myfile" and "%myfile", where "myfile" contains the data fork of the original file and "%myfile" contains the resource fork of the original file.
Importantly, "%myfile" is also supposed to contain a header with some structural information, starting with the 4-byte magic number 0x00051607. (For this reason, "%myfile" is also referred to as the header file.)
When syncing such an "apple" file using the latest P4V visual client or the latest P4 command line tool, this works as just described. However, when syncing with the latest P4 Plugin for Jenkins the "%myfile" portion only contains the bare bytes of the original resource fork; the header is missing. This is easily verified by looking for the magic number 0x00051607; it's not there.
This means that a "%myfile" created by P4Jenkins is invalid; it cannot be recognized as part of the AppleDouble format by various tools that are otherwise able to work with this format.
Some background information:
Perforce's handling of resource forks is partially described here:
https://community.perforce.com/s/article/2999#FILEMGMT-FORK
One source of the technical details of this AppleDouble file type (and the related AppleSingle type) is RFC 1740:
https://tools.ietf.org/html/rfc1740
Note that this AppleDouble format is also used when copying a file with a resource fork from a Mac to a non-Mac system (such as Windows) f.i. over a network share or with a USB drive, except then the header file is called "._myfile" (with dot and underscore) instead of "%myfile".