WinXP -> OpenVMS tests reproduced using C++ test pro

John E. Malmberg wb8tyw at qsl.net
Tue Sep 28 17:29:15 GMT 2004


In article <CF0913E9C3D53D4E94DE47FDE25C633D05049034 at hermes.cofiroute.com>,
COLLOT Jean-Yves <jean-yves.collot at cofiroute.fr> writes:
> Hi.
>
> Now let's see the 1-byte writes and QFILE_INFOs requests.
>
> It looks like those actions are done by the client in order to provoke
> extensions of the allocated file space, before actually writing into it.
> Unfortunately, on VMS, the real size of the file is not visible until the
> file is closed. That can be seen by typing "DIR/SIZE=ALL" while the file is
> being written. It gives "0/nnnn". So, when the client asks for an extension
> (Write 1 byte) then checks the new file size (QFILE_INFO), it always gets 0
> for answer. That is quite perturbing for him, so it goes on trying to extend
> the file.

The stat() or fstat() functions should return the correct results of the real
size of the file.  In the standard fields, they should have the highest
byte written in the file.

If the file was extended with an lseek() or ftrunctate() call or just writes,
then the fstat() or stat() call should reflect this.

If the stat()/fstat() calls are not doing this, then a small reproducer
needs to be submitted to HP so that the stat() call can be fixed.

And *now* is the time to do it to make it into the real VMS 8.2 release.

> I made a small change on the VMS server side: when the write request is only
> 1 byte long, I close and reopen the file. This updates the "external" view
> of the file size. With that change, the numerous 1-byte writes and
> QFILE_INFOs disappear, and the dialog is exactly the same with XP client
> that it is with the Linux client. The time is the same too: 3.5 seconds.

It would probably be better to find a way to have vms_stat()/vms_fstat()
return the size that UNIX expects with out closing and reopening the file.
It may take going to a vfs structure to fix that.

Also did you see my note that when MMAP is enabled in the smb.conf (the
default), that the stm_read() and stm_write() may sometimes be bypassed?
Turning off MMAP at compile time may adversely affect the TDB code.

As SAMBA 2.0.6 was before TDBs were implented, I disabled MMAP at compile time,
otherwise VFC files were corrupted on some file transfers.

> I'll make some additional testing to check that this Close/Reopen does not
> have side effects, and if it does not, I'll include that change in the next
> release.

My guess is that it should only induce a delay, but likely not as bad as
what it is fixing.

-John
wb8tyw at qsl.net
Personal Opinion Only



More information about the samba-vms mailing list