Perforce License Renewal, Monday 2019-06-10

[Marty Stanquist]

I've submitted our annual Helix server renewal request to Perforce. The
license is set to expire on Monday 2019-06-10. I'll keep everyone posted on
the update.

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qcos5n$tp5$1...@www.openwatcom.org...

Work on the renewal is ongoing. It required new paperwork and I'm getting
these submitted and reviewed.

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qcos5n$tp5$1...@www.openwatcom.org...

I'm awaiting receipt of the license file from Perforce. The renewal is
undergoing approval. Expect P4D and P4Web to go down tomorrow, Tuesday
2019-06-11. I'll keep everyone posted.

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qcos5n$tp5$1...@www.openwatcom.org...

I now have the 2019 license file and will install it at the end of day
today, Thursday 2019-06-13. Let me know if you experience any difficulties
going forward.

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qcos5n$tp5$1...@www.openwatcom.org...

Last night, I installed the new license file and upgraded and rebooted the
server. The installation was uneventful. This morning, the system seems to
be accessible, but now reports the error message for various client
commands:

Partner exited unexpectedly.
Perforce client error:
Partner exited unexpectedly.

I'm seeing this with the latest P4 command line client for WIndows x64
downloaded from the Perforce website. The server was upgraded to version
2019.1. I've reviewed the release notes and have contacted Perforce
regarding the errors.

Marty

[nospa...@efbe.prima.de]

Am 14.06.19 um 18:02 schrieb Marty Stanquist:

I'm getting errors too with my old CLI OS/2 p4.exe:

Perforce - The Fast Software Configuration Management System.
Copyright 1995, 2002 Perforce Software. All Rights reserved.
Rev. P4/OS2/2002.2/41879 (2003/02/24).

p4 sync
...
sync ends reproducibly with

Perforce client error:
TCP receive failed.
read: socket: Error 0

Frank

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qcos5n$tp5$1...@www.openwatcom.org...

Perforce responded to my inquiry and they have asked to review my client
environment variables and server firewall settings. Like many of you, my
client settings have not changed and these have not changed on the server as
well. This review is underway.

Marty

[Mat Nieuwenhoven]

On OS/2, "P4 sync" works for me on perforce.openwatcom.org:3488 .

Mat Nieuwenhoven

[Paul S Person]

P4Win, IIRC, produced a similar message when it tried to download all
files for the new client P4Win encouraged me to create, claiming
(again IIRC) that the existing client had something wrong with it. I
regret not keeping better track of this stuff. P4Win currently says
that my session has expired and, when given the password, repeats the
claim and the demand for the password.

p4 sync under Win 10 (and, I suspect, a much more recent client than
that for OS/2) -- works, in the sense that it responds "File(s)
up-to-date".

And

p4 sync -f copfiles.c

produces

//depot/openwatcom/bld/wgml/c/copfiles.c#78 - refreshing
c:\ow\ow\bld\wgml\c\copfiles.c

which clearly works, so some of these problems may be due to the age
of the OS/2 client and of P4Win.

--
"I begin to envy Petronius."
"I have envied him long since."

[Mat Nieuwenhoven]

On Fri, 14 Jun 2019 20:27:36 +0200, nospa...@efbe.prima.de wrote:

>Am 14.06.19 um 18:02 schrieb Marty Stanquist:
>> "Marty Stanquist"  wrote in message news:qcos5n$tp5$1...@www.openwatcom.org...
>>
>> Last night, I installed the new license file and upgraded and rebooted
>> the server. The installation was uneventful. This morning, the system
>> seems to be accessible, but now reports the error message for various
>> client commands:
>>
>> Partner exited unexpectedly.
>> Perforce client error:
>>        Partner exited unexpectedly.
>>
>> I'm seeing this with the latest P4 command line client for WIndows x64
>> downloaded from the Perforce website. The server was upgraded to version
>> 2019.1. I've reviewed the release notes and have contacted Perforce
>> regarding the errors.
>
>I'm getting errors too with my old CLI OS/2 p4.exe:
>
>Perforce - The Fast Software Configuration Management System.
>Copyright 1995, 2002 Perforce Software. All Rights reserved.
>Rev. P4/OS2/2002.2/41879 (2003/02/24).
>
>p4 sync

>....

>sync ends reproducibly with
>
>Perforce client error:
> TCP receive failed.
> read: socket: Error 0

I appear to habve an older p4 cli program. "p4 -V" gives:

Perforce - The Fast Software Configuration Management System.

Copyright 1995, 2001 Perforce Software. All rights reserved.
Rev. P4/OS2/2001.1/24612 (2001/07/17).

But it works fine.

Mat Nieuwenhoven

[Paul S Person]

On Sat, 15 Jun 2019 20:34:28 +0200 (CES), "Mat Nieuwenhoven"

My command-line client gives

Perforce - The Fast Software Configuration Management System.

Copyright 1995-2008 Perforce Software. All rights reserved.
Rev. P4/NTX86/2008.1/168182 (2008/10/10).

P4Win claims to be:

Version 2008.1.176630
Nov 24 2008
Copyright © 1997, 2008 Perforce Software

By "works fine" do you mean that if you go to <ow>\bld\wgml\c and
enter

p4 edit gxxref.c

this does /not/ produce

//depot/openwatcom/bld/wgml/c/gxxref.c#16 - opened for edit

Perforce client error:
Partner exited unexpectedly.

while p4 change produces a list of files that does /not/ include it,
showing that the command failed despite the overly-optimistic first
line?

Some things /do/ work with the command-line client here. But others do
not. And P4Win shows additonal problems, some of which may match part
of what Frank Beythien found with his OS/2 client.

But this may all be part of a single problem, which Perforce will
hopefully provide a fix for.

[Marty Stanquist]

"Paul S Person" wrote in message
news:apscge59bqn4mpccv...@4ax.com...

On Sat, 15 Jun 2019 20:34:28 +0200 (CES), "Mat Nieuwenhoven"
<mni...@dontincludethis.zap.a2000.nl> wrote:

>On Fri, 14 Jun 2019 20:27:36 +0200, nospa...@efbe.prima.de wrote:
>
>>Am 14.06.19 um 18:02 schrieb Marty Stanquist:

>>> "Marty Stanquist"Â wrote in message

>>> news:qcos5n$tp5$1...@www.openwatcom.org...
>>>
>>> Last night, I installed the new license file and upgraded and rebooted
>>> the server. The installation was uneventful. This morning, the system
>>> seems to be accessible, but now reports the error message for various
>>> client commands:
>>>
>>> Partner exited unexpectedly.
>>> Perforce client error:

>>> Â Â Â Â Â Â Partner exited unexpectedly.

I sent Perforce a detailed review of our P4, P4D, http, and firewall
settings. We're also getting errors on the server leading to an invalid
opcode trap. This might be something really simple that we need to do for
Helix 2019.1. I'm not sure, but that's what I'm hoping.

Marty

[Steven Levine]

On Sat, 15 Jun 2019 15:51:01 UTC, "Mat Nieuwenhoven"
<mni...@dontincludethis.zap.a2000.nl> wrote:

Hi all,

> On OS/2, "P4 sync" works for me on perforce.openwatcom.org:3488 .

>p4 -V

Perforce - The Fast Software Configuration Management System.

Copyright 1995, 2002 Perforce Software. All rights reserved.
Rev. P4/OS2/2002.2/41879 (2003/02/24).

Continues to works here. It reported license expired during the
window when the license probably really was expired. IIRC this was on
th 13th. On the 14th, I did my usual p4 sync, p4 opened and bld wgml
and all appeared normal.

Thanks,

Steven

--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------

[Mat Nieuwenhoven]

On Sun, 16 Jun 2019 10:02:27 -0700, Paul S Person wrote:

<snip>

>By "works fine" do you mean that if you go to <ow>\bld\wgml\c and
>enter
>
>p4 edit gxxref.c
>
>this does /not/ produce
>
>//depot/openwatcom/bld/wgml/c/gxxref.c#16 - opened for edit
>Perforce client error:
> Partner exited unexpectedly.

Seems to work here:

[E:\Watcom\bld\wgml\c]p4 edit gxxref.c

//depot/openwatcom/bld/wgml/c/gxxref.c#16 - opened for edit

[E:\Watcom\bld\wgml\c]p4 revert gxxref.c
//depot/openwatcom/bld/wgml/c/gxxref.c#16 - was edit, reverted

Mat Nieuwenhoven

[nospa...@efbe.prima.de]

Am 17.06.19 um 03:44 schrieb Steven Levine:

> On Sat, 15 Jun 2019 15:51:01 UTC, "Mat Nieuwenhoven"
> <mni...@dontincludethis.zap.a2000.nl> wrote:
>
> Hi all,
>
>> On OS/2, "P4 sync" works for me on perforce.openwatcom.org:3488 .
>
>> p4 -V
> Perforce - The Fast Software Configuration Management System.
> Copyright 1995, 2002 Perforce Software. All rights reserved.
> Rev. P4/OS2/2002.2/41879 (2003/02/24).
>
> Continues to works here. It reported license expired during the
> window when the license probably really was expired. IIRC this was on
> th 13th. On the 14th, I did my usual p4 sync, p4 opened and bld wgml
> and all appeared normal.
>
> Thanks,
>
> Steven
>

You're a lucky guy, even the old p4.exe from 2001 (from Mat) does not
work for me (same error msg).

So I'm looking forward to the feedback from Marty / Perforce.

CU/2
Frank

[Steven Levine]

On Mon, 17 Jun 2019 09:23:38 UTC, nospa...@efbe.prima.de wrote:

Hi,

> You're a lucky guy, even the old p4.exe from 2001 (from Mat) does not
> work for me (same error msg).

Makes me wonder if it is an MTU thing.

I took a look with IPTRACE and nothing stood out. I would have to see
a failing trace to see if anything catches my eye.

[Mat Nieuwenhoven]

On Fri, 14 Jun 2019 20:27:36 +0200, nospa...@efbe.prima.de wrote:

>Am 14.06.19 um 18:02 schrieb Marty Stanquist:
>> "Marty Stanquist"  wrote in message news:qcos5n$tp5$1...@www.openwatcom.org...
>>
>> Last night, I installed the new license file and upgraded and rebooted
>> the server. The installation was uneventful. This morning, the system
>> seems to be accessible, but now reports the error message for various
>> client commands:
>>
>> Partner exited unexpectedly.
>> Perforce client error:
>>        Partner exited unexpectedly.
>>
>> I'm seeing this with the latest P4 command line client for WIndows x64
>> downloaded from the Perforce website. The server was upgraded to version
>> 2019.1. I've reviewed the release notes and have contacted Perforce
>> regarding the errors.
>
>I'm getting errors too with my old CLI OS/2 p4.exe:
>
>Perforce - The Fast Software Configuration Management System.
>Copyright 1995, 2002 Perforce Software. All Rights reserved.
>Rev. P4/OS2/2002.2/41879 (2003/02/24).
>
>p4 sync

>....

>sync ends reproducibly with
>
>Perforce client error:
> TCP receive failed.
> read: socket: Error 0

Maybe it has to do with the connection path? I use IP4, and the address
resolves to 70.165.27.11. Locally I use my own firewall in the router but
not on the PC. Fixed addres for the PC (no DHCP).

Mat Nieuwenhoven

[nospa...@efbe.prima.de]

Am 17.06.19 um 16:49 schrieb Steven Levine:

> Makes me wonder if it is an MTU thing.
>
> I took a look with IPTRACE and nothing stood out. I would have to see
> a failing trace to see if anything catches my eye.
>
> Steven

Trying 2002 or 2001 'p4 user' or 'p4 client' all end with the error, so
no chance to set the nocompress option.

Even the freshly downloded Linux Ubuntu p4 2019.1 client throws the
error for 'p4 user' and 'p4 client' calls.

I'm looking forward for Marty's results.

CU/2
Frank

[Marty Stanquist]

wrote in message news:gmrq1o...@mid.individual.net...

I'm working with Perforce to get them a core dump of the problem.

Marty

[Paul S Person]

On Tue, 18 Jun 2019 11:43:20 +0200, nospa...@efbe.prima.de wrote:

>Am 17.06.19 um 16:49 schrieb Steven Levine:
>
>> Makes me wonder if it is an MTU thing.
>>
>> I took a look with IPTRACE and nothing stood out. I would have to see
>> a failing trace to see if anything catches my eye.
>>
>> Steven
>
>Trying 2002 or 2001 'p4 user' or 'p4 client' all end with the error, so
>no chance to set the nocompress option.
>
>Even the freshly downloded Linux Ubuntu p4 2019.1 client throws the
>error for 'p4 user' and 'p4 client' calls.

While exploring that, I made an interesting discovery:

p4 logout

works just fine. But then

p4 login

when provided with the requested password, produces:

Perforce client error:
Partner exited unexpectedly.

So apparently some parts of P4 worked only because I was still logged
in from before.

Well, at least both the command-line client and P4 are now in the same
boat! This suggests that, when the problem is fixed, it will be fixed
for all clients.

>I'm looking forward for Marty's results.

Me too.
Well, Perforce's solution, that is.
I suppose it's too soon to look into reverting to the prior version,
which, after all, was known to work.

[Marty Stanquist]

"Paul S Person" wrote in message

news:rd3igepo47833hf4r...@4ax.com...

I'm not sure we can revert back per the release notes. I'm double checking
this. Think we'll have to ride it out.

Marty

[Steven Levine]

On Tue, 18 Jun 2019 17:14:38 UTC, "Marty Stanquist"
<mart...@att.net> wrote:

Hi all,

Frank sent me some iptrace data to analyze. The major difference
between our two setups is my clients all happen to use the nocompress
option. The iptrace data implies that Frank's client has compression
enabled.

Mat, can you check if your working client has compression enabled?

Compression is only recommended for slow links according to the
PerForce docs and the client default is nocompress.

I've not had time to set up a testbed and create a client with
compression enabled to verify if this is the actual trigger for this
issue.

I also have not come up with a method of overriding compression on an
existing client since changing the client spec requires access to the
server.

I wonder if there is a server side option to globally turn off network
compression?

[Marty Stanquist]

"Steven Levine" wrote in message
news:11p86vVJT4Oe-pn2-6BoqVw7jB0Yj@slamain...

I asked Perforce about this but have not yet received a response.

Marty

[Mat Nieuwenhoven]

On Tue, 18 Jun 2019 19:41:09 +0000 (UTC), Steven Levine wrote:

>On Tue, 18 Jun 2019 17:14:38 UTC, "Marty Stanquist"
><mart...@att.net> wrote:
>
>Hi all,
>
>Frank sent me some iptrace data to analyze. The major difference
>between our two setups is my clients all happen to use the nocompress
>option. The iptrace data implies that Frank's client has compression
>enabled.
>
>Mat, can you check if your working client has compression enabled?

I have not. Command "p4 client" shows:

Options: noallwrite noclobber nocompress unlocked nomodtime normdir

Mat Nieuwenhoven

[nospa...@efbe.prima.de]

Am 18.06.19 um 21:41 schrieb Steven Levine:

> Frank sent me some iptrace data to analyze. The major difference
> between our two setups is my clients all happen to use the nocompress
> option. The iptrace data implies that Frank's client has compression
> enabled.

[...]

> Compression is only recommended for slow links according to the
> PerForce docs and the client default is nocompress.

The compression is left over from before DSL times, I did not bother to
change it as there were no problems, but now I cannot disable it.

Frank

[Mat Nieuwenhoven]

It has not yet been determined if compression causes the problem or not,
but maybe a Perforce admin can disable compression for one of the affected
client spaces, and see if that fixes it.

Mat Nieuwenhoven

[Paul S Person]

On Wed, 19 Jun 2019 15:16:36 +0200 (CES), "Mat Nieuwenhoven"

"p4 client" shows that my client was set up with "compress".

This is the current client, but the current client was cloned from the
original client when my XP computer died and was replaced with Win8.1.
I never bothered to change it when Win 8.1 was updated to Win10.

I have no idea why. Perhaps, when the original client was set up, it
was the default and I took it for granted that whoever set the
defaults knew what they were doing. And then, since the original
client worked, kept all of its settings in the current client.

[Paul S Person]

Note: by including my sig, your reponse was removed. It was:

>I'm not sure we can revert back per the release notes. I'm double checking
>this. Think we'll have to ride it out.
>
>Marty

1. Irreversible updates are fine until something goes wrong. Then you
really appreciate things like Windows Restore (which works with
Win10).

2. It may not be possible to revert officially, but it might be
possible to restore from backup. Of course, the license might not
work, depending on how fanatical Perforce is about this update. And
those still able to use Perforce might have to resubmit recent
changes.

But, for now, I suppose the prudent thing to do is to give Perforce
some time. You might, if you haven't already, want to pass on the
interesting info on "compress" vs "nocompress". It might give them a
useful clue, who can say?

[Steven Levine]

On Wed, 19 Jun 2019 16:02:45 UTC, Paul S Person
<pspe...@ix.netcom.invalid> wrote:

Hi folks,

> "p4 client" shows that my client was set up with "compress".

This was the default long ago. Now the default is compress.

Looking at:

https://www.perforce.com/perforce/doc.081/manuals/p4web/help/editclien
t.html#options

The implication is that the compress option can be changed via the
P4Web GUI. However, when I select one of my client specs and attempt
to edit it, the compress options not one of the options that is
available to change.

FWIW, the edit sceen itself is a bit confusing to me. It appears to
be allowing me to edit clients that I did not think I would have the
rights to edit.

Steven


--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>

DIY/ArcaOS/Warp etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------

[Steven Levine]

On Thu, 20 Jun 2019 00:04:57 UTC, "Steven Levine"
<ste...@nomail.earthlink.net> wrote:

Hi all,

Talking to myself...

I've confirmed to myself that it is the compression that is causing
the problem.

I created a new client, ensuring that compression was off, and it
worked just fine. Then I edited this client and turned on compression
and was able to save the client without errors. Then I edited the
client again and turned off compression and saved the client and the
save failed with the now typical communication error message.

Iptrace confirmed when compression was and was not in use.

p4 allowed me to delete the workspace. I guess this means that p4
client -d does send/receive any data the would be compressed.

For those the don't want to wait for PerForce to fix things, this
means there is a way to regain access the their workspaces:

- make a list of all your opened files
- delete your workspace with p4 client -d
- recreate your workspace with compression off
- use p4 sync -k to force the server into sync with your local files
- use p4 edit to reopen the previoiusly opened files

It's been a while since it did this kind of operation, so you might
want to save away copies of the previously opened files until you are
sure that p4 edit has left your modified files unsullied.

[nospa...@efbe.prima.de]

Am 20.06.19 um 02:50 schrieb Steven Levine:

Hi Steven,

> For those the don't want to wait for PerForce to fix things, this
> means there is a way to regain access the their workspaces:
>
> - make a list of all your opened files
> - delete your workspace with p4 client -d
> - recreate your workspace with compression off
> - use p4 sync -k to force the server into sync with your local files
> - use p4 edit to reopen the previoiusly opened files
>
> It's been a while since it did this kind of operation, so you might
> want to save away copies of the previously opened files until you are
> sure that p4 edit has left your modified files unsullied.

partly successful. I created a new client with a new local rootdir,
but p4 sync or p4 sync -f both run into the Perforce client error:
RpcTransport: partial message read

iptrace is stored here:

https://efbe.musca.uberspace.de/p4trace/

This looks like a different problem. The error happens during directory
change bld/afxapi/include to bld/afxapi/include/res.


CU/2
Frank

[Marty Stanquist]

"Steven Levine" wrote in message

news:11p86vVJT4Oe-pn2-skf40GlKci2i@slamain...

I think this confirms that they've changed the compression algorithm on the
server. You're using your original P4 client, right?

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qeg1uo$sg8$1...@www.openwatcom.org...

FYI, from the Helix Core 2019.1 release notes...

Minor new functionality in 2019.1

#1733878 (Bug #66258) * ** *** ****
Improvements to compression code yield 13-21% faster performance for
binary files (sync and verify) and checkpoints (creation and
replay).

I'm using the latest Windows x64 client from the Perforce website. Do any of
you have compression enabled?

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qeg2jp$t2s$1...@www.openwatcom.org...

More FYI. I left off the asterisk legend...

* -- 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

I'm asking Perforce to clarify this, ie. did they change the API.

Marty

[Paul S Person]

You included Steve Levine's sig, so your response below it did not
copy over when I hit 'reply'. I copy it here:

>FYI, from the Helix Core 2019.1 release notes...
>
>Minor new functionality in 2019.1
>
>#1733878 (Bug #66258) * ** *** ****
> Improvements to compression code yield 13-21% faster performance for
> binary files (sync and verify) and checkpoints (creation and
>replay).

OK, 2019.1 is /defintely/ a "downdate". (An "update" /improves/
performance, a "downdate" /degrades/ it.)

Just another example of the old adage "don't fix what isn't broken".

Still, at least it isn't actually flying airplanes into the ground, as
a much more well-known "update" turned out to do.

>I'm using the latest Windows x64 client from the Perforce website. Do any of
>you have compression enabled?
>
>Marty

I clearly do.
And, IIRC, so does Frank.
And, I suspect, anybody else who isn't able to use Perforce at the
moment.

[Paul S Person]

On Thu, 20 Jun 2019 00:04:57 +0000 (UTC), "Steven Levine"
<ste...@nomail.earthlink.net> wrote:

>On Wed, 19 Jun 2019 16:02:45 UTC, Paul S Person
><pspe...@ix.netcom.invalid> wrote:
>
>Hi folks,
>
>> "p4 client" shows that my client was set up with "compress".
>
>This was the default long ago. Now the default is compress.
>
>Looking at:
>
>https://www.perforce.com/perforce/doc.081/manuals/p4web/help/editclien
>t.html#options
>
>The implication is that the compress option can be changed via the
>P4Web GUI. However, when I select one of my client specs and attempt
>to edit it, the compress options not one of the options that is
>available to change.

I can't look at the window any longer (P4Win is currently relaying the
message: "WARNING: Perforce password (P4PASSWD) invalid or unset."
from, I presume, the server), but I seem to recall a button allowing
the same text file used with the command-line client to be displayed.

This can be edited to "nocompress"; however, when it is closed, the
well-known message

Perforce client error:
Partner exited unexpectedly.

is received, presumably because the data is still being compressed
until the change is accepted by the server.

>FWIW, the edit sceen itself is a bit confusing to me. It appears to
>be allowing me to edit clients that I did not think I would have the
>rights to edit.

The only way to be sure is to try one and see. Why not try with

psperson_newguy_win8.1

since, if worse comes to worse, I can always (once Perforce fixes its
little problem) move to a new client ending in _win10 (which would be
more accurate anyway).

My guess is that you will be able to edit it all right -- but the
server won't accept it unless you are, in effect if not in title, an
administrator. I mean, /somebody/ has to be able to make any changes
needed.

Still, it might be worth trying. This is a basic chicken-and-egg
scenario (I can't change it to "nocompress" because compression is
used to transmit the change), after all.

>Steven

[Steven Levine]

On Thu, 20 Jun 2019 11:54:55 UTC, nospa...@efbe.prima.de wrote:

Hi Frank,

> partly successful. I created a new client with a new local rootdir,
> but p4 sync or p4 sync -f both run into the Perforce client error:
> RpcTransport: partial message read
>
> iptrace is stored here:
>
> https://efbe.musca.uberspace.de/p4trace/
>
> This looks like a different problem. The error happens during directory
> change bld/afxapi/include to bld/afxapi/include/res.

It's definitely unrelated to compression. The failure occurs when the
server starts to send

bld\afxapi\include\afxwin5.mnl

The packet that contains this file is marked ACK/PUSH/FIN, which means
the server has nothing more to send for the connection, but the packet
is missing the end of the file.

The client ACK the packet as it should and eventually sends

KKindex197confirmdm-TookFilehandlesyncfuncdm-TookFile

withe packet marked ACK/PUSH/FIN, which is normal.

The the server responds with a RST packet, which is also nomal.

The problem appears to be on the server side because it closed down
the connection without sending the entire file. I can't see anything
the client did that would trigger this.

There's no obvious pattern here based on what I understand of the
PerForce protocol. Some files appear to be up-to-date and no file
content is transfers, but there are also some that need content
transferred.

It's not clear what is triggering the end of the connection. The
connection itself is over 4000 packets, so perhaps something is
triggering a timeout when it should not be.

[Steven Levine]

On Thu, 20 Jun 2019 14:34:13 UTC, "Marty Stanquist"
<mart...@att.net> wrote:


> I think this confirms that they've changed the compression algorithm on the
> server. You're using your original P4 client, right?

Yes, I am using the same:

>p4 -V
Perforce - The Fast Software Configuration Management System.
Copyright 1995, 2002 Perforce Software. All rights reserved.
Rev. P4/OS2/2002.2/41879 (2003/02/24).

I have been using for years. I'm not even sure if I have anything
else stashed away locally.

Steven

[Steven Levine]

On Thu, 20 Jun 2019 17:26:47 UTC, Paul S Person
<pspe...@ix.netcom.invalid> wrote:

Hi Paul,

> This can be edited to "nocompress"; however, when it is closed, the
> well-known message
>
> Perforce client error:
> Partner exited unexpectedly.
>
> is received, presumably because the data is still being compressed
> until the change is accepted by the server.

Yes, it is a bit of a catch-22.

> My guess is that you will be able to edit it all right -- but the
> server won't accept it unless you are, in effect if not in title, an
> administrator. I mean, /somebody/ has to be able to make any changes
> needed.

I may try this later. The thing is I might be an admin. I'm not sure
how Marty set up my account when he took over. There are times when I
think I have admin priviledges on a few too many systems. It just
sorta happens.

> Still, it might be worth trying. This is a basic chicken-and-egg
> scenario (I can't change it to "nocompress" because compression is
> used to transmit the change), after all.

And there is not a command line override that I can find.

Also, I've not found anything that indicates that an admin can edit a
client spec locally, when running on the server. If Marty could edit
the client specs locally without the need of going through a TCP/IP
connection, that might be a solution.

[Paul S Person]

OK, I appear to found a client-side solution. Perforce should probably
still be looking at the server, however.

Note: all assertions about P4 working reflects what it did when I did
this. YMMV, although I suspect it won't.

1. Modify setvars to set P4CLIENT to a new client name
("psperson_newguy_new" in my case).

2. Open a command line and run setvars. Log in to p4 if necessary.
Note: if nothing else, p4 tickets will only produce a response if you
are logged in.

3. Use p4 client to set up the new client. Note that the Options line
now defaults to "nocompress". Save the client. Note that this works as
well.

4. Edit the old client to change "compress" to "nocompress". Note that
this works also.

5. Delete the old client.

6. Restore setvars to use the old client.

And now it should work as before.

Including P4Win.

In fact, P4Win worked /even though it still defaulted to using the old
client/. Apparently, it's default is not the server's default until it
is used.

If you have modified files while P4 was not around, you will need to
add them to the changelist.

Theoretical discussion:

After giving the matter some thought, I concluded that what was
happening was that the client specified in the environment was being
used to control whether or not compression was to take place.

This being the case, it seemed possible that, if an nonexisting client
were specified, it would be possible to create a client with
"nocompress" and use that session to modify the older client to also
avoid compression, and perhaps even solve the problem.

This turned out to work /much/ better than most of my conclusions
reached after much thought do. IOW, I lucked out.

And, Perforce should be advised both of the workaround and the fact
that changing "compress" to "nocompress" /definitely/ solves the
problem. Which means that compression /is/ the problem or, rather, the
/change/ in compression in 2019.1 is the problem.

Perhaps they should consider haviing 2019.1 check for the old-style
compression and use it if that is what the client is doing. Just a
thought, and probably a bad one.

[nospa...@efbe.prima.de]

Am 21.06.19 um 00:14 schrieb Steven Levine:

Hi Steven,

>> This looks like a different problem. The error happens during directory
>> change bld/afxapi/include to bld/afxapi/include/res.
>
> It's definitely unrelated to compression. The failure occurs when the
> server starts to send
>
> bld\afxapi\include\afxwin5.mnl

afxwin5.nml is not created with the 'p4 sync -f' call,
if I call 'p4 sync' then afxwin5.nml is complete but the include/res
subdir is not created.

All this with a new client without compression and a new empty local dir.
I created the new client after deleting the P4CLIENT environment
variable, so the server probably used the default uncompress option.

>
> The packet that contains this file is marked ACK/PUSH/FIN, which means
> the server has nothing more to send for the connection, but the packet
> is missing the end of the file.
>
> The client ACK the packet as it should and eventually sends
>
> KKindex197confirmdm-TookFilehandlesyncfuncdm-TookFile
>
> withe packet marked ACK/PUSH/FIN, which is normal.
>
> The the server responds with a RST packet, which is also nomal.
>
> The problem appears to be on the server side because it closed down
> the connection without sending the entire file. I can't see anything
> the client did that would trigger this.
>
> There's no obvious pattern here based on what I understand of the
> PerForce protocol. Some files appear to be up-to-date and no file
> content is transfers, but there are also some that need content
> transferred.
>
> It's not clear what is triggering the end of the connection. The
> connection itself is over 4000 packets, so perhaps something is
> triggering a timeout when it should not be.

It looks as the perforce update broke more than only compression.
Or the OS/2 P4 client from 2002 will no longer work.

Frank

[Marty Stanquist]

"Paul S Person" wrote in message

news:v6nkge9qb9b063fo1...@4ax.com...

The server and website will be down for most of the morning today, Friday
2019-06-21, for testing. Perforce has a triage team lined up to assist us
and I am trying to get them a core dump of some of the failures. To do this,
I'll be starting P4D manually. For this reason, I'd like to ask that you
hold off on accessing the system, at least for now. I'll keep everyone
posted. Thanks for your patience.

Marty

[Paul S Person]

On Fri, 21 Jun 2019 09:46:01 +0200, nospa...@efbe.prima.de wrote:

>Am 21.06.19 um 00:14 schrieb Steven Levine:
>
>Hi Steven,
>
>>> This looks like a different problem. The error happens during directory
>>> change bld/afxapi/include to bld/afxapi/include/res.
>>
>> It's definitely unrelated to compression. The failure occurs when the
>> server starts to send
>>
>> bld\afxapi\include\afxwin5.mnl
>
>afxwin5.nml is not created with the 'p4 sync -f' call,
>if I call 'p4 sync' then afxwin5.nml is complete but the include/res
>subdir is not created.
>
>All this with a new client without compression and a new empty local dir.
>I created the new client after deleting the P4CLIENT environment
>variable, so the server probably used the default uncompress option.

While I was working on my workaround, I tried just REMming out the
P4CLIENT line in setvars.bat, but, when I used p4 edit, I got my usual
client description with "compress" enabled. And editing it did /not/
work.

So compression may have been in effect during the test reported above.

But when I duplicated the P4CLIENT line, de-REMmed the copy and put a
/completely new client name/ in, and restarted the client window and
reloaded setvars, p4 client then produced a client description for the
new client name, and it had "nocompress" already set. It also saved
it.

And it then allowed me to edit (p4 client <client-name>) my usual
client, modify "compress" into "nocompress", and save it.

And then reversing the changes to setvars.bat and starting a new p4
command line session -- worked with my usual client, which now has
"nocompress". Interestingly, P4Win also worked!

So it appears to me that, at least with the client I am using, when
the p4 command-line is started with no client specified, it does have
compression off, but, as soon as any command requiring the client is
entered, the usual (default?) client is loaded -- complete with
compression, if that is how the client is set up.

>It looks as the perforce update broke more than only compression.
>Or the OS/2 P4 client from 2002 will no longer work.

The first certainly may be correct, my workaround notwithstanding. The
second seems much less likely.

>Frank

[Paul S Person]

Sadly, I committed a change before reading this. Sorry about that.

I've posted a workaround that allowed me to set my client to
"nocompress" and so get both the command-line client and P4Win to work
again. So Perforce is usable again, although p4 reconcile won't run.
When we can use Perforce again, if the problem persists, I will
capture the error message for you.

[Marty Stanquist]

"Paul S Person" wrote in message

news:071qge1jubdur975h...@4ax.com...

I didn't see any errors. Did the submit post normally? I submitted two also
and they both went through.

Marty

[Paul S Person]

On Fri, 21 Jun 2019 11:41:57 -0500, "Marty Stanquist"

<mart...@att.net> wrote:

>"Paul S Person" wrote in message
>news:071qge1jubdur975h...@4ax.com...
>
>On Fri, 21 Jun 2019 03:37:43 -0500, "Marty Stanquist"
><mart...@att.net> wrote:
>
>>The server and website will be down for most of the morning today, Friday
>>2019-06-21, for testing. Perforce has a triage team lined up to assist us
>>and I am trying to get them a core dump of some of the failures. To do
>>this,
>>I'll be starting P4D manually. For this reason, I'd like to ask that you
>>hold off on accessing the system, at least for now. I'll keep everyone
>>posted. Thanks for your patience.
>
>Sadly, I committed a change before reading this. Sorry about that.
>
>I've posted a workaround that allowed me to set my client to
>"nocompress" and so get both the command-line client and P4Win to work
>again. So Perforce is usable again, although p4 reconcile won't run.
>When we can use Perforce again, if the problem persists, I will
>capture the error message for you.

>I didn't see any errors. Did the submit post normally? I submitted two also
>and they both went through.

So far as I can tell, yes.

Is it OK to use Perforce again? I decided to get all of wgml to build
and, as usual, research was a bit out of synch with changes (mostly
mine) to wgml.

[Marty Stanquist]

"Paul S Person" wrote in message

news:951rge9tju7kud3uc...@4ax.com...

Paul - As long as you have compression turned off, you should be OK. Just
let me know if you get any errors and note the time/date stamp if you can.
I'll look for them here on the server.

Team - The errors you are seeing on your clients are reflected as invalid
opcode traps as seen on the server. With P4Web disabled and P4D started
manually, I've been able to capture a number of these and send the core
dumps to Perforce for analysis. The results of the first analysis came back
yesterday and they're saying that the failure occurred in decompression code
that had been recently modified on the server. They're asking lots of
questions about the server and the clients we are using. I'm responding to
these. I'm also awaiting the results of the other analyses. P4Web generates
lots of traps and will be down for a few more days. I do apologize for the
inconvenience.

Marty

[Paul S Person]

On Sat, 22 Jun 2019 14:58:38 -0500, "Marty Stanquist"

>Paul - As long as you have compression turned off, you should be OK. Just
>let me know if you get any errors and note the time/date stamp if you can.
>I'll look for them here on the server.

P4Win "consistency" (p4 reconcile?) successfully caught the unopened
changed files. These were opened and submitted at 1648.

No errors there, but when I tried p4 reconcile in the command-lline
client I got this response:

Client doesn't have necessary support for reconcile.

Neither the "P4 Command Reference" I downloaded some time ago (but not
so long ago that it isn't for Helix) has no info on what the
"necessary support" might be that I can find. Note that the only
command said to check "consistency" is, in fact, reconcile.

This doesn't look like an error, but I did it a second time, this time
noting that it is 1656 PDT.

And now back to implementing wgml!

>Team - The errors you are seeing on your clients are reflected as invalid
>opcode traps as seen on the server. With P4Web disabled and P4D started
>manually, I've been able to capture a number of these and send the core
>dumps to Perforce for analysis. The results of the first analysis came back
>yesterday and they're saying that the failure occurred in decompression code
>that had been recently modified on the server. They're asking lots of
>questions about the server and the clients we are using. I'm responding to
>these. I'm also awaiting the results of the other analyses. P4Web generates
>lots of traps and will be down for a few more days. I do apologize for the
>inconvenience.

"decompression code that had been recently modified on the server"

sounds ... expected. But it is more convincing when they say it.

"invalid opcode traps" sounds intriguing. It will be interesting to
hear what is causing those.

Here's hoping they fix their code sooner rather than later!

[Marty Stanquist]

"Paul S Person" wrote in message

news:b6etge58j0imcvc8k...@4ax.com...

I've uploaded core dumps for p4 verify, sync, and client commands and have
provided quite a bit of detail. Last I heard, they're describing the problem
as data dependent. At least now, they have data to look at. This work is
ongoing.

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qeqlu4$i80$1...@www.openwatcom.org...

For those of you who have compression enabled workspaces and still can't get
in, try this. I haven't tried it myself, but I hear it works, at least on
Windows x64:

* Unset your P4CLIENT environment variable
* From the command line, run p4 client <your_usual_workspace_name>
* In the editor, change option compress to nocompress, save and exit.
* Run p4 sync. You should now be able to access the system.

Also about the website, I'm leaving it and P4Web down for a while to assist
Perforce with requests for core dumps and files. The core dumps are only
generated with P4D (aka. Helix Core) run directly from the command line and
not through the usual scripting. In this mode, P4Web generates lots of core
dumps that take up lots of space. We do have a large disk available, but it
can fill up. I do know how much everyone uses P4Web and will reconsider this
soon. I appreciate your patience in this matter.

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qeteao$s05$1...@www.openwatcom.org...

I'm getting results back from Perforce on the core dumps. Things are very
preliminary, but they're looking at issues with a new compression library
that was used for Helix 2019.1. Much work is still ahead and no fixes have
yet been identified. Will keep everyone posted.

Marty

[Paul S Person]

On Wed, 26 Jun 2019 10:51:36 -0500, "Marty Stanquist"
<mart...@att.net> wrote:

>For those of you who have compression enabled workspaces and still can't get
>in, try this. I haven't tried it myself, but I hear it works, at least on
>Windows x64:
>
>* Unset your P4CLIENT environment variable
>* From the command line, run p4 client <your_usual_workspace_name>
>* In the editor, change option compress to nocompress, save and exit.
>* Run p4 sync. You should now be able to access the system.

That should work. The method I used involved setting P4CLIENT to a
nonexistent client, but that may not be necessary. The theory here
would be that P4, with no P4CLIENT setting, uses a default client with
no compression and p4 client <your_usual_workspace_name> does not load
your client for use (and so enable compression), just for editing.

>Also about the website, I'm leaving it and P4Web down for a while to assist
>Perforce with requests for core dumps and files. The core dumps are only
>generated with P4D (aka. Helix Core) run directly from the command line and
>not through the usual scripting. In this mode, P4Web generates lots of core
>dumps that take up lots of space. We do have a large disk available, but it
>can fill up. I do know how much everyone uses P4Web and will reconsider this
>soon. I appreciate your patience in this matter.

There are other things on the web site that P4Web, but, if this is the
simplest way to disable P4Web, so be it.

I check the website every day to see if it comes up, but I very rarely
use it, even the Wiki.

>I'm getting results back from Perforce on the core dumps. Things are very
>preliminary, but they're looking at issues with a new compression library
>that was used for Helix 2019.1. Much work is still ahead and no fixes have
>yet been identified. Will keep everyone posted.

"A new compression library" sounds ... ominous. If they didn't write
it themselves, that is. Even if they have the source.

Unless we are the only site running 2019.1, or the only one using
compression, I would think that they would have encountered this
before.

But you are right -- we just have to wait for them to fix their
problem.

[Marty Stanquist]

"Paul S Person" wrote in message

news:p367heh46n83g1son...@4ax.com...

We're using their premier platform with the latest version running on a very
capable server. And I'm sure many others are also. There's two aspects
regarding compression. And I suspect they're both handled by the same
library. One is to manage the depot. This is required. The other is to
manage the client/server interface. This is configurable. In large
enterprise environments, I'm sure both are critical and this is why Perforce
upgraded the library. Now in our environment, even at it's busiest, the
criticality if far less, if even at all. So, our scenario may not be part of
their standard test metric. And that might be how the problem slipped
through. We'll just have to see how it all plays out.

Marty

[Steven Levine]

On Wed, 26 Jun 2019 16:20:24 UTC, Paul S Person
<pspe...@ix.netcom.invalid> wrote:

Hi Paul,

> "A new compression library" sounds ... ominous. If they didn't write
> it themselves, that is. Even if they have the source.

Really? I have to believe PerForce is capable of integrating and
testing these kinds of setups as well as ensuring they have support
for the code they choose to use.

> Unless we are the only site running 2019.1, or the only one using
> compression, I would think that they would have encountered this
> before.

There's really no requirement for PerForce to tell us whether or not
we are the only site with the issue. This could be a company policy.

If I had to guess, there just not a lot of p4 clients that are still
configured to use compression. The admin of an enterprise typically
would have turned off compression long ago because that's the
recommendation and admins prefer consistent setups because they are
easier to manage.

[Marty Stanquist]

"Steven Levine" wrote in message

news:11p86vVJT4Oe-pn2-uK7qUnjEhUre@slamain...

Right, enterprise client-server environment. That's how it was missed.

Marty

[Marty Stanquist]

"Marty Stanquist" wrote in message news:qf3s0s$8b2$1...@www.openwatcom.org...

I'll be bringing the website and P4Web back online on Monday, 2019-07-01.
This should be available in the morning CEST. I'll need to ask users on the
west coast USA to try to wrap up work by 9 PM PST. This is so I can assist
Perforce with any needed troubleshooting in the evenings here, CST. I thank
you all for your patience. This has been much appreciated.

Marty

[Paul S Person]

On Thu, 27 Jun 2019 18:12:48 +0000 (UTC), "Steven Levine"
<ste...@nomail.earthlink.net> wrote:

>On Wed, 26 Jun 2019 16:20:24 UTC, Paul S Person
><pspe...@ix.netcom.invalid> wrote:
>
>Hi Paul,
>
>> "A new compression library" sounds ... ominous. If they didn't write
>> it themselves, that is. Even if they have the source.
>
>Really? I have to believe PerForce is capable of integrating and
>testing these kinds of setups as well as ensuring they have support
>for the code they choose to use.

And I would agree with you and go further: not only are they /capable/
of it, I believe they /actually did it/.

Back in the 90s I was "blessed" with a spottily-supported video chip.
Some DOS graphics programs used one video driver library, which
supportet it. Other DOS graphics programs used a different video
driver library, which did not.

So I have a memory, as it were, of the problems that the choice of a
library can cause.

>> Unless we are the only site running 2019.1, or the only one using
>> compression, I would think that they would have encountered this
>> before.
>
>There's really no requirement for PerForce to tell us whether or not
>we are the only site with the issue. This could be a company policy.

I never said there was any such requirement.

>If I had to guess, there just not a lot of p4 clients that are still
>configured to use compression. The admin of an enterprise typically
>would have turned off compression long ago because that's the
>recommendation and admins prefer consistent setups because they are
>easier to manage.

So, you are suggesting that, the reason we have this problem, is
because /nobody else uses the feature that is mucking up/ and so it
was not caught earlier.

IMHO, this is a logical contradiction: either they tested it and it
passed and /should/ work but something in our setup is causing it to
not work, or they did not test it properly and the problem has not
surfaced until now because nobody else uses compression.

I go with the first alternative: that they tested it but we just
happen to be doing something they didn't think of testing which is
causing the problem.

Even on DSL, some operations (getting committed changelists in P4Win
[which apparently loads /all/ of them] for example) are noticeably
slower even over DSL without compression. But, of course, over
Ethernet that might not be the case, so, yes, commercial setups may
very well disable compression as not needed.

[Marty Stanquist]

"Paul S Person" wrote in message

news:csdche952b1ibdlnr...@4ax.com...

The website and P4Web are now online.

Marty

[nospa...@efbe.prima.de]

Am 01.07.19 um 16:06 schrieb Marty Stanquist:

Hi Marty,

> The website and P4Web are now online.

ok, but I'm still getting errors with p4 sync.

- created new workspace without compression
- created new local directory for this workspace
- called p4 sync -f


- got 53 files and then errors:


The end of dofresh1.log:

//depot/openwatcom/bld/afxapi/include/afxv_w32.mh#3 - added as
E:\OWBn\bld\afxapi\include\afxv_w32.mh
//depot/openwatcom/bld/afxapi/include/afxver_.mh#4 - added as
E:\OWBn\bld\afxapi\include\afxver_.mh
//depot/openwatcom/bld/afxapi/include/afxwin.mh#22 - added as
E:\OWBn\bld\afxapi\include\afxwin.mh
//depot/openwatcom/bld/afxapi/include/afxwin1.mnl#1 - added as
E:\OWBn\bld\afxapi\include\afxwin1.mnl
//depot/openwatcom/bld/afxapi/include/afxwin2.mnl#5 - added as
E:\OWBn\bld\afxapi\include\afxwin2.mnl

Perforce - The Fast Software Configuration Management System.
Copyright 1995, 2002 Perforce Software. All rights reserved.
Rev. P4/OS2/2002.2/41879 (2003/02/24).

The commands to generate the dofresh1.log:

0[E:\owbuild]e:\p4\p4.exe sync -f 2>&1 1><dofresh1.log
Perforce client error:
TCP receive failed.
read: socket: No such file or directory

1[E:\owbuild]e:\p4\p4.exe -V 2>&1 1><dofresh1.log


Running without logfile I get another error:

//depot/openwatcom/bld/afxapi/include/afxwin5.mnl#1 - added as
E:\OWBn\bld\afxap
i\include\afxwin5.mnl

Perforce client error:
RpcTransport: partial message read

1[E:\owbuild]

The used client settings:

# A Perforce Client Specification.
#
# Client: The client name.
# Update: The date this specification was last modified.
# Access: The date this client was last used in any way.
# Owner: The Perforce user name of the user who owns the client
# workspace. The default is the user who created the
# client workspace.
# Host: If set, restricts access to the named host.
# Description: A short description of the client (optional).
# Root: The base directory of the client workspace.
# AltRoots: Up to two alternate client workspace roots.
# Options: Client options:
# [no]allwrite [no]clobber [no]compress
# [un]locked [no]modtime [no]rmdir
# SubmitOptions:
# submitunchanged/submitunchanged+reopen
# revertunchanged/revertunchanged+reopen
# leaveunchanged/leaveunchanged+reopen
# LineEnd: Text file line endings on client: local/unix/mac/win/share.
# Type: Type of client: writeable/readonly/graph/partitioned.
# ServerID: If set, restricts access to the named server.
# View: Lines to map depot files into the client workspace.
# ChangeView: Lines to restrict depot files to specific changelists.
# Stream: The stream to which this client's view will be dedicated.
# (Files in stream paths can be submitted only by dedicated
# stream clients.) When this optional field is set, the
# View field will be automatically replaced by a stream
# view as the client spec is saved.
# StreamAtChange: A changelist number that sets a back-in-time view of a
# stream ( Stream field is required ).
# Changes cannot be submitted when this field is set.
#
# Use 'p4 help client' to see more about client views and options.

Client: FrankB_ArcaOs

Update: 2019/06/20 03:39:59

Access: 2019/07/01 11:56:37

Owner: FrankB

Host: AosT.fritz.box

Description:
Created by FrankB without compress option.

Root: E:\OWBn

Options: noallwrite noclobber nocompress unlocked modtime normdir

SubmitOptions: submitunchanged

LineEnd: local

View:
//depot/openwatcom/... //FrankB_ArcaOs/...

--
Frank

[Paul S Person]

On Mon, 1 Jul 2019 20:39:14 +0200, nospa...@efbe.prima.de wrote:

>Am 01.07.19 um 16:06 schrieb Marty Stanquist:
>
>Hi Marty,
>
>> The website and P4Web are now online.
>
>ok, but I'm still getting errors with p4 sync.
>
>- created new workspace without compression
>- created new local directory for this workspace
>- called p4 sync -f

I just did almost the same thing (I editied "root" to the new
directory I first created).

>- got 53 files and then errors:

I appear to have gotten everything.

>The end of dofresh1.log:
>
>//depot/openwatcom/bld/afxapi/include/afxv_w32.mh#3 - added as
>E:\OWBn\bld\afxapi\include\afxv_w32.mh
>//depot/openwatcom/bld/afxapi/include/afxver_.mh#4 - added as
>E:\OWBn\bld\afxapi\include\afxver_.mh
>//depot/openwatcom/bld/afxapi/include/afxwin.mh#22 - added as
>E:\OWBn\bld\afxapi\include\afxwin.mh
>//depot/openwatcom/bld/afxapi/include/afxwin1.mnl#1 - added as
>E:\OWBn\bld\afxapi\include\afxwin1.mnl
>//depot/openwatcom/bld/afxapi/include/afxwin2.mnl#5 - added as
>E:\OWBn\bld\afxapi\include\afxwin2.mnl
>Perforce - The Fast Software Configuration Management System.
>Copyright 1995, 2002 Perforce Software. All rights reserved.
>Rev. P4/OS2/2002.2/41879 (2003/02/24).

The last few output lines from p4 sync -f:

//depot/openwatcom/docs/win/makefile#10 - refreshing
c:\ow\ow2\docs\win\makefile
//depot/openwatcom/license.txt#3 - refreshing c:\ow\ow2\license.txt
//depot/openwatcom/owconfig.bat#1 - refreshing c:\ow\ow2\owconfig.bat
//depot/openwatcom/owconfig.vbs#9 - refreshing c:\ow\ow2\owconfig.vbs
//depot/openwatcom/projects.txt#5 - refreshing c:\ow\ow2\projects.txt
//depot/openwatcom/readme.txt#14 - refreshing c:\ow\ow2\readme.txt
//depot/openwatcom/setvars.bat#55 - refreshing c:\ow\ow2\setvars.bat
//depot/openwatcom/setvars.cmd#58 - refreshing c:\ow\ow2\setvars.cmd
//depot/openwatcom/setvars.dos#45 - refreshing c:\ow\ow2\setvars.dos
//depot/openwatcom/setvars.sh#40 - refreshing c:\ow\ow2\setvars.sh
//depot/openwatcom/zipup-rel.cmd#1 - refreshing
c:\ow\ow2\zipup-rel.cmd
//depot/openwatcom/zipup-rel.sh#2 - refreshing c:\ow\ow2\zipup-rel.sh
//depot/openwatcom/zipup.bat#16 - refreshing c:\ow\ow2\zipup.bat
//depot/openwatcom/zipup.sh#7 - refreshing c:\ow\ow2\zipup.sh

afxapi\include has 39 files, including afxwin5.mnl, the last function
in which is AFX_INLINE BOOL CWnd::PrintWindow( CDC *pDC, UINT nFlags )
const and is clearly complete.

Of course, I'm not actually using a new client, and I suppose that
could be making a difference.

Note: the reason wgml\test\docstest\debug became
wgml\test\docstest\debug2 is that either P4Win or the server could not
lock a temp file to update a makefile. Sometimes weird things happen
with Perforce.

[Paul S Person]

On Mon, 1 Jul 2019 20:39:14 +0200, nospa...@efbe.prima.de wrote:

This is a supplement to my other response.

It eventually occurred to me to look more closely at my client.
Ignoring the items that would be expected to differ, I found one
difference in the Optiions:

Yours:

>Options: noallwrite noclobber nocompress unlocked modtime normdir

mine:

Options: noallwrite noclobber nocompress unlocked nomodtime
normdir

The P4 Helix command document I downloaded some time ago has this to
say about modtime:

-- begin description --

[no]modtime

For files without the +m (modtime) file type modifier:
If modtime is set, the modification date (on the
local filesystem) of a newly synced file is the
datestamp on the file when the file was last
modified.

If nomodtime is set, the modification date is the
date and time of sync, regardless of version.

For files with the +m (modtime) file type modifier: the
modification date (on the local filesystem) of a newly
synced file is the datestamp on the file when the file was
submitted to the depot, regardless of the setting of
modtime or nomodtime on the client.

Files with the modtime (+m) type are intended for
udevelopers who need to preserve original timestamps on
files. The use of +m in a file type overrides the
workspace’s modtime or nomodtime setting. For a
more complete discussion of the +m modifier, see "File
Types" on page 551.

Default:
nomodtime
(date and time
of sync) for
most files.

Ignored for files
with the +m file
type modifier.

-- end description --

Although I find it difficult to believe that the date/time stamp to be
used with the file affects the ability to download it properly, it
/is/ a difference between a device which fails and one that succeeds.

Perhaps you might want to see if it matters. If it does, Perforce
might find knowing about it helpful.

[nospa...@efbe.prima.de]

Am 03.07.19 um 04:19 schrieb Paul S Person:

> It eventually occurred to me to look more closely at my client.
> Ignoring the items that would be expected to differ, I found one
> difference in the Optiions:
>
> Yours:
>> Options: noallwrite noclobber nocompress unlocked modtime normdir
>
> mine:
>
> Options: noallwrite noclobber nocompress unlocked nomodtime
> normdir

Thanks Paul,

but the nomodtime option does not change the error.

CU
Frank

[Marty Stanquist]

wrote in message news:go3aj3...@mid.individual.net...

I'll need additional time on the server in the evenings CST USA to support
Perforce's troubleshooting efforts with the compression library. The errors
we're seeing are in line with other pressing issues, but they do intend to
investigate them. The crash dumps were very useful and they're asking
additional questions. Would it be reasonable to ask everyone to wrap things
up by 10:30 PM CST USA? If not, please let me know. I'll try to get things
back online for the mornings in Europe.

Marty

[Steven Levine]

On Sun, 7 Jul 2019 18:20:29 UTC, "Marty Stanquist" <mart...@att.net>
wrote:

Hi,

> additional questions. Would it be reasonable to ask everyone to wrap things
> up by 10:30 PM CST USA? If not, please let me know. I'll try to get things
> back online for the mornings in Europe.

Sure, no problem here.