Release Notes for P4, the Helix Command Line, P4D, the Helix Versioning Engine P4P, the Helix Proxy and P4Broker, the Helix Broker Version 2017.1 Introduction This document lists all user-visible changes to: * Helix Versioning Engine (P4D) * Command line client (P4) * Helix Proxy (P4P) * Helix Broker (P4Broker) in 2017.1 release. Release notes for other Perforce Helix products are available separately on the Perforce Documentation web page. Developer notes for Perforce API programming, the Helix Broker and also a separate document which programmers should read in addition to this release note document. Perforce numbers releases YYYY.R/CCCCC, e.g. 2002.1/30547. YYYY is the year; R is the release of that year; CCCCC is the bugfix change level. Each bugfix in these release notes is marked by its change number. Any build includes (1) all bugfixes of all previous releases and (2) all bugfixes of the current release up to the bugfix change level. Both 'p4' and 'p4d' will report their version information by passing the '-V' flag. Additionally, 'p4' can report the server's information with the 'p4 info' command. Version information includes a release version and a build change number. The build change number can be compared with change numbers and patch information mentioned in the matching version release notes file to determine if a paticular build of a version includes the change mentioned. Supported Platforms for p4d Linux kernel 2.6+ for Intel(x86, x86_64) Windows 8 for Intel(x86, x64) Windows 8.1 for Intel(x86, x64) Windows 10 for Intel(x86, x64) Windows 2008 for Intel(x86, x64) Windows 2012 for Intel(x64) Windows 2016 for Intel(x64) Apple Darwin 9.0+ for Intel(x86, x86_64) Supported Platforms for p4 Linux kernel 2.6+ for Intel(x86, x86_64) Windows 8 for Intel(x86, x64) Windows 8.1 for Intel(x86, x64) Windows 10 for Intel(x86, x64) Windows 2008 for Intel(x86, x64) Windows 2012 for Intel (x64) Windows 2016 for Intel(x64) Mac OS X 10.5, 10.6, 10.7, 10.8, 10.9, 10.10(x86, x86_64) Apple Darwin 9.0+ for Intel(x86, x86_64) Supported Platforms for p4p and p4broker Linux kernel 2.6+ for Intel(x86, x86_64) Windows for Intel(ntx86, ntx64) Apple Darwin 9.0+ for Intel(x86, x86_64) -------------------------------------------------------------------------- Important security note This release links OpenSSL version 1.0.2q Note: 2017.1 patch 9 upgrades to OpenSSL 1.0.2q -------------------------------------------------------------------------- Important export note This product is subject to U.S. export control laws and regulations including, but not limited to, the U.S. Export Administration Regulations, the International Traffic in Arms Regulation requirements, and all applicable end-use, end-user and destination restrictions. Licensee shall not permit, directly or indirectly, use of any Perforce technology in or by any U.S. embargoed country or otherwise in violation of any U.S. export control laws and regulations. -------------------------------------------------------------------------- Upgrading the Server ** IMPORTANT UPGRADE NOTES ** CHANGES TO UNLICENSED SERVER FOR THIS RELEASE For v16.1 onwards of the Helix Versioning Engine (P4D) the number of free users allowed with an unlicensed server has changed to 5, the number of clients remains at 20. Previous versions of the server will continue to support the 20/20 usage allowance. ------------------------------------------------------------------- BEFORE UPGRADING To upgrade your Helix Versioning Engine (P4D), your Perforce license file must be current. Expired licenses do not work with upgraded servers. In addition to your usual checkpointing scheme, always checkpoint your server immediately before undertaking an upgrade. DOWNGRADING A 2017.1 SERVER IS NOT POSSIBLE UPGRADING PROCEDURE IS DIFFERENT DEPENDING ON WHAT YOUR CURRENT PERFORCE VERSION IS: UPDATE DATABASE SCHEMA vs UPDATE DATABASE FORMAT ------------------------------------------------------------------- ** UPDATE DATABASE SCHEMA If your current server version is 2013.3 or above, then this upgrade is a UPDATE DATABASE SCHEMA upgrade: Unix Platforms 1. Issue the 'p4d -r -J -xu' command. This command performs the significant schema upgrades, then exits. 2. Restart your server with your site's usual parameters. Windows Platforms 1. Issue the 'p4d -r -J -xu' command from a command prompt window. This command performs the significant schema upgrades, then exits. 2. Restart your Helix Versioning Engine (P4D) service. Note: Personal DVCS servers will automatically perform any database schema upgrades; whilst the upgrade steps described above are unnecessary for these servers, they are safe to run. ------------------------------------------------------------------- ** UPDATE DATABASE FORMAT If your current server version is 2013.2 or a previous release then this upgrade is an UPDATE DATABASE FORMAT upgrade: Due to the new btree format introduced in 2013.3 this is not an UPDATE DATABASE SCHEMA upgrade. A checkpoint using your old server and then a restore using the 2017.1 server is required before the internal upgrades 'p4d -xu' (if required) can be performed. Note: If you have made use of the (undocumented) '+T' modifier (storing file content in the tiny.db database) this data is not checkpointed (and therefore not restored). See 'p4 help undoc' for backup/restore procedures for this table. Once the database has been restored with the 2017.1 version, update your database schema: Unix Platforms 1. Issue the 'p4d -r -J -xu' command. This command performs the significant schema upgrades, then exits. 2. Restart your server with your site's usual parameters. Windows Platforms 1. Issue the 'p4d -r -J -xu' command from a command prompt window. This command performs the significant schema upgrades, then exits. 2. Restart your Helix Versioning Engine (P4D) service. -------------------------------------------------------------------------- Interoperating With Previous Releases 1. Unless stated otherwise you can intermix any release of Helix Command Line (P4) with any release of the Helix Versioning Engine (P4D), but any functionality new to 2017.1 requires you to upgrade the client and/or P4D. See marks in the notes below. * -- requires new p4 client program including all client applications and derived APIs ** -- requires new p4d server program *** -- requires new p4p proxy program **** -- requires new p4broker broker program Any replica servers must be at the same release levels as the master server; any functionality that requires an upgrade for the master requires an upgrade for the replica, and vice versa. 2. Beginning with 99.2, remote depots will interoperate between UNIX and NT. Beginning with 98.2, remote depots will interoperate across (98.2 and higher) releases. In 98.1 and before, remote depots will only operate with another server of the same release. 3. As of 2005.1, remote depot support for 98.2 and 99.1 servers has been dropped. Attempts by 98.2 and 99.1 servers to contact 2005.1 servers still works, but the depots will appear devoid of files. -------------------------------------------------------------------------- Important note: Please refer to: http://www.perforce.com/perforce/r17.1/user/relnotes.txt to get up to date GA and post-GA information about this release. -------------------------------------------------------------------------- Major new functionality in 2017.1 Graph Depot support * ** A collection of new features provide direct support for git repositories and git workflows using the p4d server. In addition to the new server features (outlined below), there is a new server component, called the Connector, that is separately installable as needed, and provides services which are broadly similar to those provided by Perforce proxy and replica servers. The new features you should be aware of include: - server data model support - authentication and authorization enhancements - p4 command line access to git versioned files - new triggers To learn more about the Connector component, please read its release notes and documentation. Below is a broad overview of the new p4d support; for details, please read the server documentation. Server data model support: A single p4d server new supports storage of versioned files using either the classic Perforce data model, or using the git data model. The data model to use is specified on a depot-by-depot basis: a depot of type "graph" is used to store one or more git repositories. The server automatically creates a graph depot named 'repo'; you may create additional graph depots using the 'p4 depot' command. git repositories are named using a hierachical naming scheme of the format: //depot/repo/path/name, using the new 'p4 repo' command. Authentication and authorization enhancements: git users accessing the Perforce server must be properly authenticated and authorized. When using the HTTPS protocol, git users are prompted for their Perforce username and password as necessary when they perform clone, push, or pull commands. When using the SSH protocol, git users authenticate using public key encryption; the appropriate public key for each user should be recorded in the server using the new 'p4 pubkey' command. Access control for git repositories uses a new set of permissions, defined with the 'p4 grant-permission' command. The related revoke-permission, check-permission, and show-permission commands are also useful for defining and maintaining repository access control rules. Command line access to git versioned files: A client workspace can be configured to access git versioned files by mapping paths from repos within graph type depots; non-graph depot paths may also be mapped in the same client view. The 'p4 sync' command will then sync the specified version of the specified files from one or more git repositories and other depots to the corresponding location in your client's filesystem. Similarly the 'p4 have', 'p4 files', 'p4 dirs' and 'p4 fstat' commands will also report on the metadata from git repositories as well as other depots. Not all flags for these commands are applicable for graph. New triggers: Several new trigger types are available to allow administrators to define custom policies for access to git repository data, and to support advanced workflows such as initiating build/test automation activities upon the completion of a git push command. Licensing: The default maximum repos allowed for a server is 10, to increase this limit contact Perforce Sales at sales@perforce.com. (For more information see 'p4 help --depot-type=graph'). #1434004 * ** *** TCP connection changes to improve performance over long latency connections. Significantly more information may be in transport now and clients and intermediate processes need to handle more data in a timely manner. This new behavior can be disabled in clients, proxies, brokers and the server with the configurable net.autotune which defaults to 1 (enabled) and can be set to 0 to disable. Clients can set this via "p4 set" or P4CONFIG files and servers can set this via "p4 configure." On Windows based platforms, send buffer sizes are not autotuned but still are manually configuable with net.tcpsize. #1425396 (Bug #88065) ** Binary fields in journal records will now be written in base64 instead of hex with a few exceptions. Binary objects of length 1 will still be written in hex and some md5 digest fields will still be hex. Minor new functionality in 2017.1 #1487961 (Bug #90210) ** New server option '--daemonsafe' is like '-d' and forks the 'p4d' into the background, but also closes the stdio files. #1486890 (Bug #88954) ** The utf8 file type was not handled properly by clients older than 2015.2 and the p4 java api. The server now attempts to work with these older clients by handling the byte-order-mark in the server and having the server produce digests which these older clients will expect. Operation with utf8 files and these old client will skip proxy caching also. These older clients and utf8 filetype will assume the BOM is present while clients 2015.2 can adapt to a BOM being present or not. #1459677 (Bug #89065) ** The 'p4 verify -v' command now supports updates to files which have been branched into one or more active task streams. Please see 'p4 help verify' for more details about this scenario. #1458367 (Bug #37069, #89070) ** The 'p4 move -r' command allows users to rename or change the location of files in the depot without opening them for edit first. #1457332 (Bug #89008) ** The 'p4 remotes' command now accepts the '-u user' flag. #1453638 (Bug #84442) ** The --remote-user flag may be specified on the fetch, push, and login commands, overriding the RemoteUser field in the remote spec for this command. #1450711 (Bug #88643) ** A restriction on using the 'p4 renameuser' command in a Commit-Edge configuration has been removed: it is now safe to use the command to rename a user who owns workspaces and/or labels on one or more Edge Servers. Note that unloaded workspaces are still not processed by the command, no matter which server those workspaces reside on. #1448666 (Bug #63670) ** A new type of structured server log audit record format which includes the revision's size in bytes is now available. To specify the logging of these alternate audit records, change the name of your audit log from 'audit.csv' to 'auditsize.csv'. #1442507 (Bug #69777) ** Two new security levels have been introduced to enforce stricter intermediary checking. Setting the security configurable to 5 to higher will require each intermediary to have a valid authenticated service user. Setting the security configurable to 6 to higher will require each intermediary to have a valid server spec, where the service user must match the user named in the spec's 'User' field. The server spec will be found by matching the intermediary's P4PORT with a value in the spec's 'AllowedAddresses' field. For example, if connecting to a proxy on 10.0.0.100:1667, a server spec with this IP address and port number in the 'AllowedAddresses' field must exist and must have the proxy's service user named in the 'User' field. Errors relating to configuration of intermediaries will be logged to the 'route.csv' logfile, if enabled. #1439069 (Bug #81269) ** When specifying file paths you can now use the change identity from the submitted change spec instead of the actual change number. So, for example given a change submitted with an identity: 'p4 sync //depot/...@30E7C829-08C504-4109-89AA-904D0C2194B8' #1424268 (Bug #88017) ** The template.label configurable introduced by change 656580 now also applies to a label created via the 'p4 tag' command. #1526517 (Bug #90686) ** Increase receive buffer sizes for the Perforce API to 1 megabyte which shows substantial performance improvement for several wide area network operations and prevents network hangs in some cases. Old value was 32k. Can be adjusted with net.rcvbufsize Bugs fixed in 2017.1 Patch 9 #1737215 (Bug #97134) ** Group protections entries containing wildcards in the group name could cause a server crash. This has been fixed. #1728560 (Bug #96662) ** Parallel submit could fail to transfer archive content if the file transfer threads exit without error. This has been fixed by insuring that archives exist on the server before the submit continues and reports success. #1709207 (Bug #96381) ** The 'p4 journals' command when run during a checkpoint operation could hang the server. This has been fixed. #1703333 (Bugs #92403, #95219) ** 'p4 revert -C client' would fail to revert files in the target workspace if that workspace was locked or specified a host other than the one the command was run from. This has been fixed. #1692127 (Bug #96155) ** Improve the performance of group protections. Bugs fixed in 2017.1 Patch 8 #1675009 (Bug #94847) ** The filesys.checklinks configurable will may now be set to '4', providing the same checking as '3' but disallows using '-f' to override the check. #1647697 (Bug #94951) ** Use of auto-reloaded labels no longer allocates and holds onto memory for the label on every use. It now uses memory proportional to the size of the label used. #1640812 (Bug #94621) ** The 'rejectList' feature will no longer block replicas. #1672646 (Bug #94877) *** Fix new proxytotals reporting accuracy. #1653549 (Bug #95033) ** A scheduled checkpoint on a 'standby' or 'forwarding-standby' server executed when the master server's journal is rotated no longer corrupts the prior journalcopy'd journal. #1648718 (Bug #94825) ** 'p4 fstat' using a revision specification on an opened file would hang if the file had ditto mapping. This has been fixed. #1646835 (Bug #94877) *** Additional logging is now reported by the proxy when track=1 is set. The new proxytotals line records the number of files and the total file size (in MB) transferred to the client from the upstream server and from the proxy's cache. Bugs fixed in 2017.1 Patch 7 #1620424 (Bug #90502) ** 'p4 resolve' in a federated environment could leave orphaned locks after a filetype resolve that changed files from '+l' to filetypes without '+l'. This has been fixed. #1618405 (Bug #94152) ** Concurrent label create/delete of the same label no longer hangs. #1616222 (Bug #94116) ** 'p4 shelve -d' without any file arguments leaks memory. This change fixes the issue. #1611639 (Bug #92645) ** Parallel sync performance through the proxy has been improved for some scenarios. #1609812 (Bug #93973) ** 'p4 ldapsync -u' would only delete users if a spec depot were present. This has been fixed. #1609801 (Bug #93947) ** A shelve delete trigger does not fire if the file is specifed in the command and does not exist in the changelist. This has been fixed. #1609779 (Bug #93871) ** 'p4 where' run against replica using a partitioned or readonly client could suppress output from additional commands run within the same connection. #1603813 (Bug #93716) ** The revert of open files during a 'client -d -f' command are now batched into fewer larger transactions, resulting in more efficient replication of this command. Bugs fixed in 2017.1 Patch 6 Upgrade of OpenSSL to 1.0.2n Bugs fixed in 2017.1 Patch 5 #1589832 (Bug #92849) ** 'p4 rec -a ...' or 'p4 add ...' could cause the client to crash when invoked from the client root and the root directory name has an excessive number of ellipses. This has been fixed. #1588218 (Bug #92882) ** Archive file transfer failure from the Edge Server to the Commit Server during parallel submit could sometimes be undetected. If submit succeeded in this scenario, the archives would be missing from the Commit Server. This has been fixed to insure that the command fails when the transfer fails. #1586874 (Bug #93136) ** LDAP based user auto-creation, run against a replica not using 'rpl.forward.login', would only create the user on the replica (not on the master). This has been fixed. #1584718 (Bug #92894) ** 'p4 -ztag describe -S' would update the shelveAccess date even though the shelved content was not displayed. This has has been fixed. #1577292 (Bug #93001) ** 'p4 annotate -I' will no longer terminate abnormally if access to a branch is excluded within some integration histories. #1576900 (Bug #92777, #92817) ** 'p4 reconcile -a' and 'p4 clean' would fail to detect files to add or clean if the command was invoked without arguments from a dictionary containing the '@' character. This has been fixed. Upgrade of OpenSSL to 1.0.2m Bugs fixed in 2017.1 Patch 4 #1569495 (Bug #92417) ** A delay in the replication of a consistency point will no longer corrupt the journal written by a 'journalcopy' thread. #1566131 (Bug #91885) ** Submitting a moved 'utf8' file using a pre-15.2 client no longer results in a missing archive. #1564066 (Bug #92442) ** 'p4 resolve' now has an undoc flag '-dx' which can be used to make the 3-way merge algorithm perform more like the unix 'diff3 -m' merge. Typically merge tends to remove duplicate lines in adjacent inserts from 'theirs' and 'yours', with this flag all the lines in the inserts from both legs of the merge will be inserted. Bugs fixed in 2017.1 Patch 3 #1550695 (Bug #92435) ** User not able to submit an open stream with a file change on a edge server. This is now fixed. #1549763 (Bug #92443) ** Users auto-created by 'p4 login' would not have the Update time set in the user spec. This has now been fixed. Bugs fixed in 2017.1 Patch 2 #1539093 (Bug #92168) ** *** The new performance improvements for TCP over long latency connections could cause write/write deadlocks in proxies and brokers. To mitigate this, the default behavior has been changed to disabled. It can be re-enabled by setting 'net.autotune' to 1. Once enabled, it will work for any server configuration that does not have a proxy or a broker in the mix. #1542613 (Bug #92377) ** Empty repos in graph depot could cause reference erors to be shown when running commands like 'p4 dirs' against unrelated paths. This has been fixed. Bugs fixed in 2017.1 Patch 1 #1529412 (Bug #91971) ** Parallel sync performance has been improved for some scenarios in which distribution of load across the transmit threads was not an issue. #1528637 (Bug #85788) ** 'p4 revert -C client ' fails to revert moved files. #1525095, #1524788, #1524323, #1523395 (Bug #91812) Graph depot triggers are not honoring trigger Path field for repo submit. #1519789, #1518201 (Bug #91541) 'p4 submit' must activate graph-push-* triggers. #1519789, #1519676 (Bug #91644) Mirrored repo should only be able to run post-commit triggers. #1516824 (Bug #91055) ** The 'annotate -I' command now correctly considers all the needed revisions of a depot file that is a "from" file into multiple branches as permitted by access through the integration history. #1516465 (Bug #90653) * ** Application locked licenses now work with DVCS. #1516413 (Bug #91562) ** 'p4 repos -M' could report incorrect number of mirrored repos. #1514865 (Bug #90330) ** 'p4 copy' could miss needed copies in a complex case of moves and earlier copies. Upgrade of OpenSSL libraries to 1.0.2l Bugs fixed in 2017.1 #1505154 (Bug #90088) ** For a specific use case, a branch resolve is scheduled instead of a move resolve. This is fixed by backing out change #1422325. #1502778 (Bug #89674) ** Obliterating files from a task stream that is no longer protected because it has been unloaded can cause revision inconsistency after being reloaded. #1498792 (Bug #86088) ** Using 'p4 switch' between task streams and non-task can fail if a previous manual switch was done with 'p4 client -s' without subsequently calling 'p4 sync'. #1489051 (Bug #2170) ** Submitting a file with the same name as an existing depot directory path (or vice versa) will now be rejected. #1483947 (Bug #89040) * 'p4 print -o ' will now work even if a P4CLIENTPATH is set or the DVCS P4INITROOT is set. This is a new exception to the P4CLIENTPATH feature. #1481077, #1481305, #1483342 (Bugs #89051, #90160) * ** *** SSL connections now allow use of TLSv1.1 and TLSv1.2 in addition to the existing support for TLSv1.0. Clients and servers will choose the highest TLS version supported by both ends of the connection; thus old clients and old servers will always use TLSv1.0, and by default new clients connecting to new servers will use TLSv1.2. Two new configurables are provided to restrict the allowed TLS versions when a new client connnects to a new server: ssl.tls.version.min [default=10] ssl.tls.version.max [default=12] These default settings allow TLSv1.0, TLSv1.1, and TLSv1.2. Each of these configurables can take one of the following values: 10 specifies TLSv1.0 11 specifies TLSv1.1 12 specifies TLSv1.2 ssl.tls.version.min specifies the lowest TLS version that will be accepted, and ssl.tls.version.max specifies the highest TLS version that will be accepted. Changes to these configurables on a server will not take effect until the server is restarted. Thus, to force use of a new client, the server can set ssl.tls.version.min=11 (or 12) because old clients support only TLSv1.0. To force the use of TLSv1.1, set ssl.tls.version.min=11 ssl.tls.version.max=11 To force the use of TLSv1.2, set ssl.tls.version.min=12 ssl.tls.version.max=12 To allow TLSv1.1 or TLSv1.2 but exclude TLSv1.0, set ssl.tls.version.min=11 ssl.tls.version.max=12 These configurables are designed to allow the server to restrict the set of allowed TLS protocol versions, but they can be used by clients as well; this is probably useful mostly for testing, although it can be use to prevent connecting to potentially vulnerable servers. When used by a client these configurables specify the lowest and highest TLS versions that will be offered. Values of either configurable outside of the legal range will be treated as if they were pinned to the nearest end of the range. Thus values below 10 will be treated as 10; values above 12 will be treated as 12. Be careful not to set ssl.tls.version.min > ssl.tls.version.max because then no clients will be able to connect. In this case you will need to change these settings on the command line, e.g.: p4d -c"set ssl.tls.version.min=10" p4d -c"set ssl.tls.version.max=12" and then restart the server. Note that if there are no allowed TLS versions common to the client and the server, or if the server is not using SSL, then the client will get an error similar to this: Perforce client error: SSL connect to ssl:host:1666 failed (Connection reset by peer). Remove SSL protocol prefix from P4PORT or fix the TLS settings. If the client or server does not offer any protocol versions (eg, because the client set ssl.tls.version.min > ssl.tls.version.max) then the client will get an error similar to this: Perforce client error: SSL protocol: error:14077102:SSL routines: SSL23_GET_SERVER_HELLO:unsupported protocol: There are only two lines in this error message; the actual error has the "SSL protocol:" line and the "GET_SERVER_HELLO" line on a single line, but they are split here for readability. #1480537 ** 'p4 protects -m' could incorrectly report a max permission of 'owner' (owner is not an access permission). #1480400 (Bug #89648, #89890) ** The db.sendq entries for a failed parallel sync are now immediately removed from db.sendq. #1479216 (Bug #89781) ** 'p4 depot -f' would allow changing the depot type of a depot that is not empty. This has been fixed. #1475982 (Bug #89723) ** The rpl >= 2 condition for reporting replication tracking metrics has been removed. The replication tracking metrics will now be reported when the applicable tracking thresholds have been exceeded. #1473097 (Bug #89657) ** 'p4d -xx' could incorrectly declare "db.workingx/db.revsh inconsistencies found," and incorrectly generate jnl.fix records, in some situations where multiple shelves existed for the same files. #1471650 (Bug #89336) ** 'p4 add ...' could generate many "Error object passed to database" errors and fail to terminate when MaxScanRows or MaxLockTime has been reached. This could also happen with 'p4 reconcile' or 'p4 status'. This behavior has been fixed. #1469144 (Bug #89527) ** A 'p4 shelve' command which needed to retry its change spec edit operation due to a spec validation error no longer fails with "No files to shelve." #1467328 (Bug #87271) ** 'p4 clients -S //stream/name' now respects the case-sensitivity configuration of the server. #1466515 (Bug #81281) ** Replica pull threads which receive error messages from their master server will now log those error messages into any replica structured server logs which record error events. #1465792 (Bug #16821, #89204) * ** The configurable 'filesys.checklinks' may fail to prevent files from being added when files are symlinks to directories. This has been fixed. Also, this configurable is now honored for 'p4 reconcile' when detecting files to be added. #1464985 (Bug #89311) ** The fetch/push/unzip commands might incorrectly declare a file conflict for a file which was moved multiple times, to different destinations, during its history. #1463567 (Bug #86424) ** Edge Servers might halt replicating if an obliterate command was run concurrently with a very large populate or submit command. #1460946 (Bug #88999) ** The 'p4 export' command now includes any @dl@ or @pk@ journal records as part of the journal data export. #1458557 (Bug #89052) ** A forwarding replica with lbr.replication=shared will no longer attempt to update the (shared) archive area during the file transfer phase of a forwarded 'p4 submit'. The cache-on-submit behavior is still present for forwarding replicas with lbr.replication set to either readonly or cache. #1455848 (Bug #88980) ** In replica chaining configurations, replicas which were not directly connected to the master server were not processing archive deletion operations arising from operations such as submission of a binary+S file, deletion of a shelf, obliteration, archive depot operations or retype +l commands. #1449343 (Bug #85596) ** The 'logparse' command no longer attempts to open an erroneous file when the structured log's configurable includes a path. #1447186 (Bug #84067) ** The number of fsync() calls for 'rdb.lbr' executed by a replica server fetching graph depot packfiles has been reduced. In some environments, this can improve the performance of fetching graph depot packfiles. #1446257 (Bug #84067) ** The number of fsync() calls for 'rdb.lbr' executed by a replica server fetching file content on demand has been reduced. In some environments, this can improve the performance of fetching file content on demand. #1445640 (Bug #88728) ** The configurables rpl.awaitjnl.count and rpl.awaitjnl.interval were inadvertently swapped; they are now corrected. #1440527 (Bug #88441) ** 'p4 verify -S //filepath/...@=' would scan the db.revsh table. #1439920 (Bug #88350) ** If an error was encountered when opening an archive file for write on the commit server during an edge submit, the commit server might crash. The edge submit now reports the error encountered and fails gracefully. #1432576 (Bug #88205) ** The 'rdb.lbr' tracking metrics are now aggregated to reflect larger operations. Since the aggregated metrics might now more readily exceed a tracking threshold, the 'rdb.lbr' tracking output might be more likely to be written to the server log when the 'rpl' configurable is set to a value of two or greater. #1431630 (Bug #88189) ** The 'rdb.lbr' tracking metrics are now correctly reported for the edge server's metadata pull thread when the 'rpl' configurable is set to a value of two or greater. #1425567 (Bug #88085) ** The number of fsync() calls for 'rdb.lbr' executed by the commit server for coordinating the file content fetched during a parallel submit though an edge server has been reduced. In some environments, this can improve the performance of parallel submit through an edge server. #1424177 (Bugs #26502, #51997, #59889, #69919, #88018) ** The server now rejects client and branch views that end with "...." on one side and "..." on the other. #1419208 (Bug #67640) ** A 'p4 sync' command issued to a forwarding replica of a forwarding replica will now deliver file content from the outermost forwarding replica in the chain, rather than the innermost. However, it is now illegal to deploy a proxy to a forwarding replica. If you had such a deployment, you will need to either (a) reconfigure that proxy to point directly to the master, (b) replace that proxy with a forwarding replica, or (c) remove that proxy entirely.