TCP/IP Services NFS server reports wrong file length of "variable length" files

[Michael Gehre]

Im using:
HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6 - ECO 2
on an HP rx2660 (1.67GHz/9.0MB) running OpenVMS V8.3-1H1
OpenVMS operates as a NFS Server for a linux (kernel 2.6) PPC system:
(algol:/SBHOME/ZBA31_TEST2 on /nas type nfs (rw,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=70,retrans=3,sec=sys,addr=a))
I have the following problem:
1.) create a new file h.h on OpenVMS (the default record format is "variable
length"):
$ create h.h
Test
Test1
Test2^Z
2.) cat h.h on unix site is o.k.
3.) copy this file to a new filename:
$ copy h.h h1.h
4.) cat h1.h lists additional characters after the end of the file
5.) cat h1.h again works fine

I get the same problem, if I use fopen in C.
I analysed the problem using tcptrace. The result was, that the NFS server sends a wrong file length in the first request and the correct value in the second request. Modification time is different between the first and second call as well.
Has anybody a hint for me ?

Thanks

[Hoff]

You've found what looks to be an NFS bug in ECO 2.

Do try ECO 3, though I don't see anything relevant there. (If you contact support, they're going to ask you to try replicating this on ECO 3.)

As an alternative, use Stream LF when working with Unix or Mac OS X or Linux or Windows, and not VFC.

NFS tries to use some magic known as an ADF here to do the file format conversion, and there's a discussion of file-level portability and such at:

http://64.223.189.234/node/302

If you've gone as far as tcptrace and found the bad data originating from the server, then you've found what appears to be a bug in the HP NFS server code, and that should be reported to HP.

If as I suspect you're reporting this in ITRC because you don't have a support contract, package up the full reproducer and the trace and hope somebody at HP is interested in looking at this and resolving the bug. The support folks are probably busy with support customers, so I'd not count on a fix getting incorporated, either.

And pending a fix, consider alternatives. Like not using VFC. And do consider trying ECO 3.

[Hein van den Heuvel]

I agree with Hoff that this counds like NFS issue. But maybe it is triggered by subtle changes in file attributes. Copy should leave basic attributes in place, but it wouldn't hurt to check. For example, maybe the 'File length hints' got munged in the process.
Check with $DUMP/BLOC=COUN=0/HEAD
or use DCL lexical:

write sys$output f$file("h.h","FILE_LENGTH_HINT")
Other 'intersting' attributes: EOF,FFB,RFM,RAT

fwiw,
Hein.

[Ian Miller.]

You could try
$ ANALYZE/RMS_FILE/UPDATE_HEADER

to update the file header

[M. T. Hollinger · Accepted solution]

Have you tried defining the TCPIP$CFS_MODUS_OPERANDI logical name as 512 prior to starting the NFS server?

- M

[Michael Gehre]

Thank you to all for the quick response. At first I needed a quick solution because one of our customers was in trouble regarding this behaviour. The next step will be to send an detailed error description to the HP people.
So what did I do:
1.) installing ECO 3 of TCPIP
==> error was not fixed, but additional information:
For monitoring system activities I used
$ reply/enable=(network,central,security)
So I noticed, that the NFS server connection was automatically broken after a timeout time. If I tried the cat h1.h command after this timeout I could generate the error.

2.) using tcpip$cfs_modus_operandi
$ @sys$startup:tcpip$nfs_shutdown
$ define/system/exec -
tcpip$cfs_modus_operandi 512
$ @sys$startup:tcpip$nfs_startup
==> It works well !!

3.) I read the TCPIP manual and was a little bit confused because of the warning of HP:
TCPIP$CFS_MODUS_OPERANDI Defines various operating modes. Use only under the advice of your HP support representative.

But there is a service article (Dokument-ID: emr_na-c01624638-1) to be found in the IT Resource center, describing the solution. So I will use it.

Thanks again to all !

[Hein van den Heuvel]

>> TCPIP$CFS_MODUS_OPERANDI Defines various operating modes. Use only under the advice of your HP support representative.


And you did.
M. T. Hollinger aka Myth is the man!
He trumps a support represenatative.
He owns the OpenVMS TCP/IP code stack!

The 512 represents 1 bit in this flag

Hein.