| hello Julie,
many thanks for your fast reply.
Sorry but I have remounted the directory from my NFS-Client after
exporting with nodata_conversion. And this behaviour is always the same.
Again my tests:
1) Export VMS-directory with option=nodata_conversion
and logical UCX$CFS_MODUS_OPERANDI set to 512 :
UCX> add export "/platte/norbert"/host="zefix"/option=nodata_conversion
UCX> show export "/platte/norbert"/host="zefix"
File System Host name
/platte/norbert zefix
Options: NoData_cvt
MDSC21> sh log *modus*
(LNM$SYSTEM_TABLE)
"UCX$CFS_MODUS_OPERANDI" = "512"
2) Mount this directory from ULTRIX (there is no other mount)
zefix.muh.dec.com> mount
/dev/rz2a on / type ufs
/dev/rz2g on /usr type ufs
/dev/rz0c on /usr/users type ufs
zefix.muh.dec.com> mount mdsc21:/platte/norbert $home/mdsc21
zefix.muh.dec.com>
3) Create a file via vi with 2 characters ("ab") and send this file
via FTP / IMAGE mode to the NFS-exported directory (filename:jordan.txt)
So this file will be created on VMS with fixed length 512 byte records.
(This should simulate the customer's situation)
4) Access this file from NFS-Client :
zefix.muh.dec.com> cd mdsc21
zefix.muh.dec.com> od -ah jordan.txt
0000000 a b nl nul nul nul nul nul nul nul nul nul nul nul nul nul
6261 000a 0000 0000 0000 0000 0000 0000
0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000 0000 0000 0000 0000 0000 0000 0000
*
0001000
zefix.muh.dec.com>
You can see the padding Zeroes in this file !!!!!!!!
And that is the problem.
If you change the file Format in Stream_lf with
$ set fil/att=rfm=stmlf jordan.txt
then you see from NFS-Client :
od -ah jordan.txt
0000000 a b nl
6261 000a
0000003
And that's what the customer wants !!!!
You have give me some Notes-entries to read (2526, 2132, 2357 and 2504)
Sorry but I have not so much knowledge in the RMS stuff. I think that these
entries don't adress my customer's problem but I don't know.
I try to explain what the arguments of the customer are :
(the customer is ORIGIN. You know ORIGIN from many many IPMT's and you know
my answer to the customer must be well argumented)
- the customer copies a binary file from his PC to the UCX-machine.
The customer is not interested that UCX FTP-server creates the
destination file with 512 byte fixed length. It doesn't matter for
the customer.
(I have not found another possibility for the FTP-Server to create this file.
The logical UCX$FTP_STREAMLF is valid only with ASCII mode, not IMAGE mode)
- the customer accesses this file from his NFS-Client.
(I think it doesn't matter if the customer accesses this file directly or
copy this file to another UNIX-directory. But I will ask him)
And then the customer has problems because the UCX NFS-Server gives him
not only the characters "ab" and "nl" like described with a STREAM_LF
file but the characters "ab" and "nl"and many Nulls.
This behaviour is easily reproducable .
Now my questions again :
- Is this normal behaviour of the NFS-Server ?
(After reading 2504.* it seems to me)
If yes can you please explain me why and
could this behaviour become changeable in next releases?
- Or is this a malfunction ?
Again to the customer:
In the meaning of the customer this is a bug. Expressed in a simply way:
the customer copies 2 bytes to the UCX-machine via FTP and wants to get back
only these 2 bytes from NFS.
Any hints and explanations are highly appreciated.
Kind regards
Norbert
P.S.: In the following some VMS-Commands according to the corresponding file.
a) dir/full jordan.txt
b) dump/header/blo=cou=0 jordan.txt
c) dump/record jordan.txt
ad a) dir/full jordan.txt
MDSC21> dir/full jordan.txt
Directory DKB0:[NORBERT]
JORDAN.TXT;1 File ID: (1039,2,0)
Size: 1/3 Owner: [NORBERT]
Created: 15-MAY-1997 08:50:54.94
Revised: 15-MAY-1997 08:50:55.29 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
File organization: Sequential
Shelved state: Online
File attributes: Allocation: 3, Extend: 0, Global buffer count: 0
No version limit
Record format: Fixed length 512 byte records
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Total of 1 file, 1/3 blocks.
ad b) dump/header/blo=cou=0 jordan.txt
MDSC21> dump/header/blo=cou=0 jordan.txt
Dump of file DKB0:[NORBERT]JORDAN.TXT;1 on 15-MAY-1997 08:56:01.71
File ID (1039,2,0) End of file block 1 / Allocated 3
File Header
Header area
Identification area offset: 40
Map area offset: 100
Access control area offset: 255
Reserved area offset: 255
Extension segment number: 0
Structure level and version: 2, 1
File identification: (1039,2,0)
Extension file identification: (0,0,0)
VAX-11 RMS attributes
Record type: Fixed
File organization: Sequential
Record attributes: <none specified>
Record size: 512
Highest block: 3
End of file block: 1
End of file byte: 3
Bucket size: 0
Fixed control area size: 0
Maximum record size: 512
Default extension size: 0
Global buffer count: 0
Directory version limit: 0
File characteristics: <none specified>
Map area words in use: 2
Access mode: 0
File owner UIC: [NORBERT]
File protection: S:RWED, O:RWED, G:RE, W:
Back link file identification: (11,1,0)
Journal control flags: <none specified>
Active recovery units: None
Highest block written: 1
Identification area
File name: JORDAN.TXT;1
Revision number: 1
Creation date: 15-MAY-1997 08:50:54.94
Revision date: 15-MAY-1997 08:50:55.29
Expiration date: <none specified>
Backup date: <none specified>
Map area
Retrieval pointers
Count: 3 LBN: 147348
Checksum: 13130
MDSC21>
ad c) dump/record jordan.txt
MDSC21> dump/record jordan.txt
Dump of file DKB0:[NORBERT]JORDAN.TXT;1 on 15-MAY-1997 08:57:56.97
File ID (1039,2,0) End of file block 1 / Allocated 3
Record number 1 (00000001), 512 (0200) bytes, RFA(0001,0000,0000)
00000000 00000000 00000000 000A6261 ab.............. 000000
00000000 00000000 00000000 00000000 ................ 000010
00000000 00000000 00000000 00000000 ................ 000020
00000000 00000000 00000000 00000000 ................ 000030
00000000 00000000 00000000 00000000 ................ 000040
00000000 00000000 00000000 00000000 ................ 000050
00000000 00000000 00000000 00000000 ................ 000060
00000000 00000000 00000000 00000000 ................ 000070
00000000 00000000 00000000 00000000 ................ 000080
00000000 00000000 00000000 00000000 ................ 000090
00000000 00000000 00000000 00000000 ................ 0000A0
00000000 00000000 00000000 00000000 ................ 0000B0
00000000 00000000 00000000 00000000 ................ 0000C0
00000000 00000000 00000000 00000000 ................ 0000D0
00000000 00000000 00000000 00000000 ................ 0000E0
00000000 00000000 00000000 00000000 ................ 0000F0
00000000 00000000 00000000 00000000 ................ 000100
00000000 00000000 00000000 00000000 ................ 000110
00000000 00000000 00000000 00000000 ................ 000120
00000000 00000000 00000000 00000000 ................ 000130
00000000 00000000 00000000 00000000 ................ 000140
00000000 00000000 00000000 00000000 ................ 000150
00000000 00000000 00000000 00000000 ................ 000160
00000000 00000000 00000000 00000000 ................ 000170
00000000 00000000 00000000 00000000 ................ 000180
00000000 00000000 00000000 00000000 ................ 000190
00000000 00000000 00000000 00000000 ................ 0001A0
00000000 00000000 00000000 00000000 ................ 0001B0
00000000 00000000 00000000 00000000 ................ 0001C0
00000000 00000000 00000000 00000000 ................ 0001D0
00000000 00000000 00000000 00000000 ................ 0001E0
00000000 00000000 00000000 00000000 ................ 0001F0
MDSC21>
|
| I think I understand what the problem is now. First, some explanation:
Yes, this is correct behavior for the NFS server if the server is doing
data conversion. The file is not a valid RMS file. The file
attributes say it contains 512-byte fixed length records, but the EOF
pointer is not on a 512 byte boundary. It is somewhere inside a
record. If you read this file locally on the VMS system using RMS
$GETs, RMS will return the full 512 bytes. If the NFS server is doing
data conversion, it treats the file just like RMS would.
So the next question is, "Is it a bug in the FTP server that it creates
such a file?" The answer is no.
From RFC 959: FTP
3.1.1.3. IMAGE TYPE
The data are sent as contiguous bits which, for transfer,
are packed into the 8-bit transfer bytes. The receiving
site must store the data as contiguous bits. The structure
of the storage system might necessitate the padding of the
file (or of each record, for a record-structured file) to
some convenient boundary (byte, word or block). This
padding, which must be all zeros, may occur only at the end
of the file (or at the end of each record) and there must be
a way of identifying the padding bits so that they may be
stripped off if the file is retrieved. The padding
transformation should be well publicized to enable a user to
process a file at the storage site.
Image type is intended for the efficient storage and
retrieval of files and for the transfer of binary data. It
is recommended that this type be accepted by all FTP
implementations.
The file is perfectly alright provided you don't treat it as an RMS
file. You can read it back using FTP image mode. In fact, the VMS
linker also can create image files that claim to be 512-byte fixed
length record format. These are also perfectly alright, since RMS is
not used to read image files.
One more thing that may be helpful to understand: Setting the
file attributes to Stream_LF is another method to prevent the NFS
server from doing data conversion. Stream_LF is the record format it
wants to convert to, so files that are already in that format don't
need conversion. I understand that the customer prefers to avoid this
method, since it is an extra step.
So, why don't you get the desired behavior with the NODATA_CONVERSION
option? I believe it is because the NFS server has cached the
converted file, possibly because of an access by some other client host
that does not have the NODATA_CONVERSION option in effect, and the
server is incorrectly returning the converted size to all hosts
regardless of whether they are getting converted data.
Please submit an IPMT case on this problem, and reference this note
number in the problem statement.
Another thing, the UCX$CFS_MODUS_OPERANDI setting of 512 may be making
the problem worse. It is asking the server to do the data conversion
on the getattr instead of waiting for the read for those files that are
subject to data conversion. What you want is for the server to not do
data conversion at all. Unless you are using it for some other reason,
get rid of it.
Julie
|
| hello Julie,
many many thanks for your clear explanations. This was exactly what I need for
the arguments against the customer.
I have done further testings with the option NODATA_CONVERSION:
After restarting the NFS-Server the NFS-Server doesn't give the
padding NULLS and gives only the 2 characters to the NFS-Client.
That's what the customer wants.
So the customer has another "workaround" by exporting his directory
with NODATA_CONVERSION.
The customer seems to agree with this solution.
.-1 "Please submit an IPMT case on this problem ...."
Yes, you are right. It seems that why I don't get the desired behaviour
with the NODATA_CONVERSION option the first time has to do with the NFS
cache.
Assuming the same directory is exported with DATA_CONVERSION to host A and
NODATA_CONVERSION to host B.
It seems that the NFS-Server caches the option (converted or noconverted) for
a file from which host the file was accessed the first time.
And then the NFS server is returning the converted / or noconverted file
regardless of whether you access this file from host A or B.
If you want I can submit an IPMT. But this is *NOT* a problem for my customer,
because I have instructed my customer to create a special directory which is
only exported with NODATA_CONVERSION. And so my customer shouldn't run into this
problem.
Again many tanks for your great help
Norbert
|