Samba V2.0.6 trouble - Infinite Expansion.

[John E. Malmberg]

Carl Perkins <carl at gergx.gerg.tamu.education>
 >
 > I am having a problem that supposedly has a known solution - except
 > that the solution doesn't actually work for me.
 >
 > Samba version 2.0.6 OpenVMS Alpha V7.2-1
 >
 > The problem: Samba extends files without limit (or, alternatively,
 > with a very large limit that exceeds 2.3GB as that is the largest
 > one has gotten).
 >
 > In SMB.CONF I have the line:
 >
 > ole locking compatibility = no
<snip>
 >
 > This does not help.
 >
 > Are there other parameters which can cause/solve the problem other
 > than the ole locking compatibility parameter?
 >
 > I have tried with oplocks on and off, and level2 oplocks on and off,
 > and a variety of other things. Nothing has helped.

I am stumped as I was going to sugest turning oplocks off.

As you seem to have indicated to have read, SAMBA implements ole locking
by locking a section of the file with a negative offset.

In the later streams of SAMBA they have removed the parameter to control
this.

The fcntl() emulation in FRONTPORT uses RMS to do the locking, and RMS
can only lock a section of the file that exists.  It will extend a file
to reach to the size needed to lock the range.

If the ole locking routine calls fcntl() like this, it would give the
results you are seeing.

If it is truly ignoring the parameter, then that is a big problem.

I posted objections on the SAMBA-TECHNICAL list about removing the ole
locking parameter when it was proposed, but it got removed anyway.  I do
not know if they changed the algorithm.

 > I have installed the VMS721_ACRTL-V0400 ECO.
 >
 > I have even defined the DECC$POSIX_SEEK_STREAM_FILE to ENABLE, a
 > possibility which dates back to V0200 of the ECO and is supposed to
 > prevent lseek() and fseek() from null padding the file when used with
 > large values unless the location was actually written to (so either
 > this is not caused by use of one of these functions with a huge
 > offset, or it is actually writing something to the excessively large
 > position).

There was a bug in the DEC C RTL lseek() implementation that caused a
100% cpu bound condition.  File expansion was not seen.  This was only
reported on SAMBA 2.0.3 though.

FRONTPORT works around that bug by not using lseek() to extend a file.
It instead just keeps track of where the end of file should be, and if
needed on close, will pad the file with NULLs.  This usually is not needed.

SAMBA normally seems to just lock the first byte of a file as an 
exclusive lock.

So the only thing I can think of that would trigger this is the OLE locking.

 > Any use of a Microsoft Office program (Word and Excel tested) to
 > access an existing file or save a new file to the Samba share
 > results in this incorrect behavior.
 >
 > The LOG.servername files are littered with messages like this:
 >
 > [2002/04/30 03:03:22, 0]
 > CMS_ROOT:[SAMBA_VMS.SOURCE.SMBD]CONNECTION.C;1:(61) ERROR: can't get
 > lock on SAMBA_ROOT/VAR/LOCKS/STATUS..LCK

A higher debug level may shed some more light on things, but it will
probably take a code change to fix.

 > But this doesn't seem to stop it from working in other respects, if
 > it means anything at all. Does it try the illegal two dot file name
 > before trying the translated version STATUS__2E.LCK? If so, it would
 > be nice if it would use the correct version and not put this message
 > into the log file all the time.

SAMBA uses UNIX names internally.  The FRONTPORT shared image translates
them if needed.  I did not really stress test ODS5, but if your 
SAMBA_ROOT:[VAR.LOCKS] was actually on an ODS5 disk, I would expect it 
to be actually using status..lck

Frontport does not try the illegal name first and then the legal name. 
It translates the entire filespecification using what is known of the 
Pathworks name mangling convention.

 >
 > Around the time of one of my tests, there is an entry that says:
 > [2002/04/30 03:16:18, 0]CMS_ROOT:[SAMBA.SOURCE.SMBD]NTTRANS.C;2:(2401)
 > call_nt_transact_ioctl: Currently not implemented.
 >
 > But this message only occurs that one time and the problem has
 > happened at other times.
 >
 > Does anybody have any suggestions?
 >
 > --- Carl Perkins Computer Systems Manager Geochemical &
 > Environmental Research Group Texas A&M University carl at gerg.tamu.edu

The bad news is that the only system that I have licensed with Microsoft 
Office is about 30 feet away from the closest ethernet connection, and 
it is making soft clicking noises while reporting that it does not seem 
to have a C: drive anymore.  I am working on getting time to get it 
repaired.

The good news is that it should be easy for you to compile and link 
SAMBA / Frontport in debug.

The startup code for SMBD understands that when it is run from a 
terminal not to open the SMBD port directly instead of the TCPIP 
auxilliary port.  So debugging is easy.

The logging redirection works to SYS$OUTPUT: or /SYS$OUTPUT, I do not 
quite remember which.

The logging level can also be increased.

If this is the OLE locking issue, the quick source code fix would be in 
the FRONTPORT fcntl() implementation to intercept high file ranges and 
do something else.

Good Luck
-John
wb8tyw at qsl.network
Personal Opinion Only