[Info-vax] Interesting NFS bug...

[John Gemignani, Jr.]

"JF Mezei" <jfmezei.spamnot at vaxination.ca> wrote in message 
news:00a6591e$0$1587$c3e8da3 at news.astraweb.com...
> OS-X mounted  disk via NFS on VMS (VMS acts as NFS server).
>
> ditto used to copy files tro the OS-X disk.
>
> the last bit of index.html from VMS:
>
>> 22534D56 20796220 64657265 776F5022 "Powered by VMS" 0000C0
>>  72742F3C 0005003E 64742F3C 0005003E >...</td>...</tr 0000D0
>>  3E64743C 3E72743C 00150000 0000003E >.......<tr><td> 0000E0
>>  0000003E 72742F3C 3E64742F 3C3E703C <p></td></tr>... 0000F0
>>  2F3C0007 00003E65 6C626174 2F3C0008 ..</table>....</ 000100
>>  003E6C6D 74682F3C 0007003E 79646F62 body>...</html>. 000110
>>  00000000 00000000 00000000 0000FFFF ................ 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
>
>
> After copy to OS-X:
>
>
>> 000011c0  74 3d 22 50 6f 77 65 72  65 64 20 62 79 20 56 4d  |t="Powered 
>> by VM|
>> 000011d0  53 22 3e 0a 3c 2f 74 64  3e 0a 3c 2f 74 72 3e 0a 
>> |S">.</td>.</tr>.|
>> 000011e0  0a 0a 3c 74 72 3e 3c 74  64 3e 3c 70 3e 3c 2f 74 
>> |..<tr><td><p></t|
>> 000011f0  64 3e 3c 2f 74 72 3e 0a  0a 3c 2f 74 61 62 6c 65 
>> |d></tr>..</table|
>> 00001200  3e 0a 0a 3c 2f 62 6f 64  79 3e 0a 3c 2f 68 74 6d 
>> |>..</body>.</htm|
>> 00001210  6c 3e 0a 00 3f 00 a0 00  39 00 0b 01 05 00 20 20 
>> |l>..?...9.....  |
>> 00001220  20 31 35 00 38 00 04 00  3f 00 a0 00 00 40 00 00  | 
>> 15.8...?.... at ..|
>> 00001230  08 00 a0 00 38 00 04 00  3f 00 a0 00 00 40 00 00 
>> |....8...?.... at ..|
>> 00001240  3b 00 a0 00 4a 00 08 00  82 00 a0 00 3f 00 a0 00 
>> |;...J.......?...|
>> 00001250  6a 00 0b 01 0b 00 32 31  2d 4e 4f 56 2d 32 30 30 
>> |j.....21-NOV-200|
>> 00001260  39 00 00 00 38 00 04 00  3f 00 a0 00 00 40 00 00 
>> |9...8...?.... at ..|
>> 00001270  08 00 a0 00 38 00 04 00  3f 00 a0 00 00 40 00 00 
>> |....8...?.... at ..|
>> 00001280  3b 00 a0 00 4a 00 0a 00  82 00 a0 00 3f 00 a0 00 
>> |;...J.......?...|
>> 00001290  c5 00 0b 01 14 00 53 4d  54 50 25 22 64 6a 66 30 
>> |......SMTP%"xxxx|
>> 000012a0  31 40 62 69 6b 65 6f 64  79 73 00 00 38 00 04 00 
>> |x at xxxxxxxx..8...|
>> 000012b0  3f 00 a0 00 00 40 00 00  08 00 a0 00 38 00 04 00 
>> |?.... at ......8...|
>> 000012c0  3f 00 a0 00 00 40 00 00  3b 00 a0 00 4a 00 0c 00 
>> |?.... at ..;...J...|
>> 000012d0  82 00 a0 00 3f 00 a0 00  5f 01 0b 01 1e 00 52 65 
>> |....?..._.....Re|
>> 000012e0  3a 20 4c 61 73 74 20 57  65 65 6b 73 20 54 72 61  |: Last Weeks 
>> Tra|
>> 000012f0  69 6e 20 41 64 76 65 6e  74 75 72 65 38 00 04 00  |in 
>> Adventure8...|
>> 00001300  3f 00 a0 00 00 40 00 00  08 00 a0 00 82 00 c0 00 
>> |?.... at ..........|
>> 00001310  82 00 c0 00 40 00 c0 00  00 00 00 01 00 00 00 00 
>> |.... at ...........|
>> 00001320
>
>
> In other words, the NFS server on VMS filled data beyond the end of file
> with text from another file. So much for VMS file system security.
>
>
> Performing the copy from VMS ($COPY on VMS with Unix acting as NFS
> server) did not add content to the end of file.
>
> However, one cannot copy a whole directory tree this way. Backup creates
> files on the other system with file extensions as part of file name. so
> instead of "myimage.jpg" you have "myimage.jpg;3"
>
> Looks like FTP is needed.
>

Interesting.

A few facts about the VMS NFS server:

1) I believe that we (they, I don't work there anymore) recommend that high 
water marking is disabled. This is an XQP feature that causes awful 
performance issues for NFS.

2) When a non-stream file is accessed, the file is scanned to:
    a) determine the actual length of the file in its stream equivalent form 
(as it will be returned on read), and
    b) create an offset translation map for on-the-fly conversion to stream 
format.

If I were to be debugging this problem, I would be looking for a length 
mismatch and perhaps even a confusion between file-handles (they have 
embedded options). But then, while I do work on NFS today, I no longer do so 
for HP.

John