CVS tag for lates samba 3.0 series
jra at samba.org
Fri Apr 28 22:39:03 GMT 2006
On Fri, Apr 28, 2006 at 06:35:07PM -0400, John E. Malmberg wrote:
> I have sent DK instructions on how to use rsync on Linux to maintain a
> local copy of SAMBA_3_0 and SAMBA 4 on an OpenVMS system.
> >What areas of the code have you changed for OpenVMS ? How
> >invasive are they ?
> I can not comment about the specifics as I have mainly been looking at
> what it takes to get SAMBA V4 to build on OpenVMS.
> But here is a summary of the issues that I have seen for V2/V3 of Samba,
> not in any specific order:
> 1. No fork()
> 2. Need to use special hand off socket from inetd equivalent which
> launches smbd because of no fork().
> 3. SMBD when launched this way re-inits the TDB files out from
> under the other SMBD processes.
> 4. Pid files should not be used on OpenVMS because of different
> process model. This just interferes with debugging.
> 5. fcntl() locking is not available at this time.
> 6. fstat() or stat() does not report current file size unless fsync()
> is called to flush the output to disk. Richard Sharp found out
> why that is important to the SMB protocol.
> 7. Samba Panic handler needs to be disabled because it prevents the
> OpenVMS Panic handler from giving an accurate or even meaningful
> error report.
> This may affect other platforms in the same way.
> 8. select() will only work on socket numbers, not file descriptors.
> 9. stat() is high overhead call as it actually touches the disk.
> 10. setegid()/setgid() not meaningful on OpenVMS.
> 11. smbclient claims "Control-D" is keyboard EOF instead of looking
> it up in term_info API. OpenVMS does not have the term_info API
> either, but that can be faked with a macro. OpenVMS uses
> Control-Z for keyboard EOF. So technically this is a UNIX bug,
> as the keyboard EOF may be set to a different character.
> 12. Test for running with setuid bit set fail on OpenVMS.
> 13. Behavior of open file access after setuid() call is different.
> 14. OpenVMS text files are not usually byte streams, yet they are
> a common type of file that a Samba client expects to read or
> For a few of these, there are methods of hiding the differences with out
> making changes to the source code.
These sound pretty serious. How much do they disrupt the code ?
What number of lines is the current diff ?
More information about the samba-technical