Samba 2.2.1 released.

[Jeremy Allison]

The Samba Team is proud to announce the release of Samba 2.2.1.

This is the latest stable release of Samba. This is the version that all
production Samba servers should be running for all current bug-fixes.

Binary packages will be released shortly for major platforms. The source
code can be downloaded from :

ftp://ftp.samba.org/pub/samba/

in the file samba-2.2.1.tar.gz.

The release notes follow.

As always, all bugs are our responsibility.

Regards,

The Samba Team.

----------------------------------------------------------------------------
WHATS NEW IN Samba 2.2.1: 10th July 2001
=========================================

This is the latest stable release of Samba. This is the version that all
production Samba servers should be running for all current bug-fixes.

New/Changed parameters in 2.2.1
-------------------------------

Added parameters.
-----------------

obey pam restrictions

When Samba is configured to use PAM, turns on or off Samba checking
the PAM account restrictions. Defaults to off.

pam password change

When Samba is configured to use PAM, turns on or off Samba passing
the password changes to PAM. Defaults to off.

large readwrite

New option to allow new Windows 2000 large file (64k) streaming
read/write options. Needs a 64 bit underlying operating system
(for Linux use kernel 2.4 with glibc 2.2 or above). Can improve performance
by 10% with Windows 2000 clients. Defaults to off. Not as tested
as some other Samba code paths.

hide unreadable

Prevents clients from seeing the existance of files that cannot
be read. Off by default.

enhanced browsing

Turn on/off the enhanced Samba browing functionality (*1B names).
Default is "on". Can prevent eternal machines in workgroups when
WINS servers are not synchronised.

Removed parameters.
-------------------

domain groups
domain admin users
domain guest users

Changes in 2.2.1
-----------------

1). "find" command removed for smbclient. Internal code now used.
2). smbspool updates to retry connections from Michael Sweet.
3). Fix for mapping 8859-15 characters to UNICODE.
4). Changed "security=server" to try with invalid username to prevent
account lockouts.
5). Fixes to allow Windows 2000 SP2 clients to join a Samba PDC.
6). Support for Windows 9x Nexus tools to allow security changes from Win9x.
7). Two locking fixes added. Samba 2.2.1 now passes the Clarion network
lock tester tool for distributed databases.
8). Preliminary support added for Windows 2000 large file read/write SMBs.
9). Changed random number generator in Samba to prevent guess attacks.
10). Fixes for tdb corruption in connections.tdb and file locking brlock.tdb.
smbd's clean the tdb files on startup and shutdown.
11). Fixes for default ACLs on Solaris.
12). Tidyup of password entry caching code.
13). Correct shutdowns added for send fails. Helps tdb cleanup code.
14). Prevent invalid '/' characters in workgroup names.
15). Removed more static arrays in SAMR code.
16). Client code is now UNICODE on the wire.
17). Fix 2 second timstamp resolution everywhere if dos timestamp set to yes.
18). All tdb opens now going through logging function.
19). Add pam password changing and pam restrictions code.
20). Printer driver management improvements (delete driver).
21). Fix difference between NULL security descriptors and empty
security descriptors.
22). Fix SID returns for server roles.
23). Allow Windows 2000 mmc to view and set Samba share security descriptors.
24). Allow smbcontrol to forcibly disconnect a share.
25). tdb fixes for HPUX, OpenBSD and other OS's that don't have a coherent
mmap/file read/write cache.
26). Fix race condition in returning create disposition for file create/open.
27). Fix NT rewriting of security descriptors to their canonical form for
ACLs.
28). Fix for Samba running on top of Linux VFAT ftruncate bug.
29). Swat fixes for being run with xinetd that doesn't set the umask.
30). Fix for slow writes with Win9x Explorer clients. Emulates Microsoft
TCP stack early ack specification error.
31). Changed lock & persistant tdb directory to /var/cache/samba by default on
RedHat and Mandrake as they clear the /var/lock/samba directory on reboot.

Older release notes for Samba 2.2.x follow.

-----------------------------------------------------------------------------
The release notes for 2.2.0a follow :

SECURITY FIX
============

This is a security bugfix release for Samba 2.2.0. This release provides the
following two changes *ONLY* from the 2.2.0 release.

1). Fix for the security hole discovered by Michal Zalewski (***@bos.bindview.com)
and described in the security advisory below.
2). Fix for the hosts allow/hosts deny parameters not being honoured.

No other changes are being made for this release to ensure a security fix only.
For new functionality (including these security fixes) download Samba 2.2.1
when it is available.

The security advisory follows :


IMPORTANT: Security bugfix for Samba
------------------------------------

June 23rd 2001


Summary
-------

A serious security hole has been discovered in all versions of Samba
that allows an attacker to gain root access on the target machine for
certain types of common Samba configuration.

The immediate fix is to edit your smb.conf configuration file and
remove all occurances of the macro "%m". Replacing occurances of %m
with %I is probably the best solution for most sites.

Details
-------

A remote attacker can use a netbios name containing unix path
characters which will then be substituted into the %m macro wherever
it occurs in smb.conf. This can be used to cause Samba to create a log
file on top of an important system file, which in turn can be used to
compromise security on the server.

The most commonly used configuration option that can be vulnerable to
this attack is the "log file" option. The default value for this
option is VARDIR/log.smbd. If the default is used then Samba is not
vulnerable to this attack.

The security hole occurs when a log file option like the following is
used:

log file = /var/log/samba/%m.log

In that case the attacker can use a locally created symbolic link to
overwrite any file on the system. This requires local access to the
server.

If your Samba configuration has something like the following:

log file = /var/log/samba/%m

Then the attacker could successfully compromise your server remotely
as no symbolic link is required. This type of configuration is very
rare.

The most commonly used log file configuration containing %m is the
distributed in the sample configuration file that comes with Samba:

log file = /var/log/samba/log.%m

in that case your machine is not vulnerable to this attack unless you
happen to have a subdirectory in /var/log/samba/ which starts with the
prefix "log."

Credit
------

Thanks to Michal Zalewski (***@bos.bindview.com) for finding this
vulnerability.


New Release
-----------

While we recommend that vulnerable sites immediately change their
smb.conf configuration file to prevent the attack we will also be
making new releases of Samba within the next 24 hours to properly fix
the problem. Please see http://www.samba.org/ for the new releases.

Please report any attacks to the appropriate authority.

The Samba Team
***@samba.org

---------------------------------------------------------------------------

The release notes for 2.2.0 follow :

This is the official Samba 2.2.0 release. This version of Samba provides
the following new features and enhancements.

Integration between Windows oplocks and NFS file opens (IRIX and Linux
2.4 kernel only). This gives complete data and locking integrity between
Windows and UNIX file access to the same data files.

Ability to act as an authentication source for Windows 2000 clients as
well as for NT4.x clients.

Integration with the winbind daemon that provides a single
sign on facility for UNIX servers in Windows 2000/NT4 networks
driven by a Windows 2000/NT4 PDC. winbind is not included in
this release, it currently must be obtained separately. We are
committed to including winbind in a future Samba 2.2.x release.

Support for native Windows 2000/NT4 printing RPCs. This includes
support for automatic printer driver download.

Support for server supported Access Control Lists (ACLs).
This release contains support for the following filesystems:

Solaris 2.6+
SGI Irix
Linux Kernel with ACL patch from http://acl.bestbits.at
Linux Kernel with XFS ACL support.
Caldera/SCO UnixWare
IBM AIX
FreeBSD (with external patch)

Other platforms will be supported as resources are
available to test and implement the encessary modules. If
you are interested in writing the support for a particular
ACL filesystem, please join the samba-technical mailing
list and coordinate your efforts.

On PAM (Pluggable Authentication Module) based systems - better debugging
messages and encrypted password users now have access control verified via
PAM - Note: Authentication still uses the encrypted password database.

Rewritten internal locking semantics for more robustness.
This release supports full 64 bit locking semantics on all
(even 32 bit) platforms. SMB locks are mapped onto POSIX
locks (32 bit or 64 bit) as the underlying system allows.

Conversion of various internal flat data structures to use
database records for increased performance and
flexibility.

Support for acting as a MS-DFS (Distributed File System) server.

Support for manipulating Samba shares using Windows client tools
(server manager). Per share security can be set using these tools
and Samba will obey the access restrictions applied.

Samba profiling support (see below).

Compile time option for enabling a (Virtual file system) VFS layer
to allow non-disk resources to be exported as Windows filesystems
(such as databases etc.).

The documentation in this release has been updated and converted
from Yodl to DocBook 4.1. There are many new parameters since 2.0.7
and some defaults have changed.

Profiling support.
------------------
Support for collection of profile information. A shared
memory area has been created which contains counters for
the number of calls to and the amount of time spent in
various system calls and smb transactions. See the file
profile.h for a complete listing of the information
collected. Sample code for a samba pmda (collection agent
for Performance Co-Pilot) has been included in the pcp
directory.

To enable the profile data collection code in samba, you
must compile samba with profile support (run configure with
the --with-profile option). On startup, collection of data
is disabled. To begin collecting data use the smbcontrol
program to turn on profiling (see the smbcontrol man page).
Profile information collection can be enabled for all smbd
processes or one or more selected processes. The profiling
data collected is the aggragate for all processes that have
profiling enabled.

With samba compiled for profile data collection, you may see
a very slight degradation in performance even with profiling
collection turned off. On initial tests with NetBench on an
SGI Origin 200 server, this degradation was not measureable
with profile collection off compared to no profile collection
compiled into samba.

With count profile collection enabled on all clients, the
degradation was less than 2%. With full profile collection
enabled on all clients, the degradation was about 8.5%.

=====================================================================

If you think you have found a bug please email a report to :

***@samba.org

As always, all bugs are our responsibility.

Regards,

The Samba Team.

[Mike Black]

As pleased as I am about seeing 2.2.1 released there's still an outstanding
bug which is preventing me from using it:
http://bugs.samba.org/?findid=21369 (reported over a month ago)
When copying a file from NT4.0 to samba server the file date/time is set to
the current time instead of the original file time. Not sure if this is
true for any other OS.
I would think this could break things for some people (like me).
I already identified what's causing the problem in the bug report and
thought that it wouldn't be too hard to fix but figured the samba team could
come up with a better fix than me.
________________________________________
Michael D. Black Principal Engineer
***@csihq.com 321-676-2923,x203
http://www.csihq.com Computer Science Innovations
http://www.csihq.com/~mike My home page
FAX [phone]
----- Original Message -----
From: "Jeremy Allison" <***@valinux.com>
To: <***@samba.org>
Cc: <samba-***@samba.org>; <samba-***@samba.org>;
<***@valinux.com>
Sent: Tuesday, July 10, 2001 5:15 AM
Subject: Samba 2.2.1 released.


The Samba Team is proud to announce the release of Samba 2.2.1.

This is the latest stable release of Samba. This is the version that all
production Samba servers should be running for all current bug-fixes.

Binary packages will be released shortly for major platforms. The source
code can be downloaded from :

ftp://ftp.samba.org/pub/samba/

in the file samba-2.2.1.tar.gz.

The release notes follow.

As always, all bugs are our responsibility.

Regards,

The Samba Team.

----------------------------------------------------------------------------
WHATS NEW IN Samba 2.2.1: 10th July 2001
=========================================

This is the latest stable release of Samba. This is the version that all
production Samba servers should be running for all current bug-fixes.

New/Changed parameters in 2.2.1
-------------------------------

Added parameters.
-----------------

obey pam restrictions

When Samba is configured to use PAM, turns on or off Samba checking
the PAM account restrictions. Defaults to off.

pam password change

When Samba is configured to use PAM, turns on or off Samba passing
the password changes to PAM. Defaults to off.

large readwrite

New option to allow new Windows 2000 large file (64k) streaming
read/write options. Needs a 64 bit underlying operating system
(for Linux use kernel 2.4 with glibc 2.2 or above). Can improve performance
by 10% with Windows 2000 clients. Defaults to off. Not as tested
as some other Samba code paths.

hide unreadable

Prevents clients from seeing the existance of files that cannot
be read. Off by default.

enhanced browsing

Turn on/off the enhanced Samba browing functionality (*1B names).
Default is "on". Can prevent eternal machines in workgroups when
WINS servers are not synchronised.

Removed parameters.
-------------------

domain groups
domain admin users
domain guest users

Changes in 2.2.1
-----------------

1). "find" command removed for smbclient. Internal code now used.
2). smbspool updates to retry connections from Michael Sweet.
3). Fix for mapping 8859-15 characters to UNICODE.
4). Changed "security=server" to try with invalid username to prevent
account lockouts.
5). Fixes to allow Windows 2000 SP2 clients to join a Samba PDC.
6). Support for Windows 9x Nexus tools to allow security changes from Win9x.
7). Two locking fixes added. Samba 2.2.1 now passes the Clarion network
lock tester tool for distributed databases.
8). Preliminary support added for Windows 2000 large file read/write SMBs.
9). Changed random number generator in Samba to prevent guess attacks.
10). Fixes for tdb corruption in connections.tdb and file locking
brlock.tdb.
smbd's clean the tdb files on startup and shutdown.
11). Fixes for default ACLs on Solaris.
12). Tidyup of password entry caching code.
13). Correct shutdowns added for send fails. Helps tdb cleanup code.
14). Prevent invalid '/' characters in workgroup names.
15). Removed more static arrays in SAMR code.
16). Client code is now UNICODE on the wire.
17). Fix 2 second timstamp resolution everywhere if dos timestamp set to
yes.
18). All tdb opens now going through logging function.
19). Add pam password changing and pam restrictions code.
20). Printer driver management improvements (delete driver).
21). Fix difference between NULL security descriptors and empty
security descriptors.
22). Fix SID returns for server roles.
23). Allow Windows 2000 mmc to view and set Samba share security
descriptors.
24). Allow smbcontrol to forcibly disconnect a share.
25). tdb fixes for HPUX, OpenBSD and other OS's that don't have a coherent
mmap/file read/write cache.
26). Fix race condition in returning create disposition for file
create/open.
27). Fix NT rewriting of security descriptors to their canonical form for
ACLs.
28). Fix for Samba running on top of Linux VFAT ftruncate bug.
29). Swat fixes for being run with xinetd that doesn't set the umask.
30). Fix for slow writes with Win9x Explorer clients. Emulates Microsoft
TCP stack early ack specification error.
31). Changed lock & persistant tdb directory to /var/cache/samba by default
on
RedHat and Mandrake as they clear the /var/lock/samba directory on
reboot.

Older release notes for Samba 2.2.x follow.

----------------------------------------------------------------------------
-
The release notes for 2.2.0a follow :

SECURITY FIX
============

This is a security bugfix release for Samba 2.2.0. This release provides the
following two changes *ONLY* from the 2.2.0 release.

1). Fix for the security hole discovered by Michal Zalewski
(***@bos.bindview.com)
and described in the security advisory below.
2). Fix for the hosts allow/hosts deny parameters not being honoured.

No other changes are being made for this release to ensure a security fix
only.
For new functionality (including these security fixes) download Samba 2.2.1
when it is available.

The security advisory follows :


IMPORTANT: Security bugfix for Samba
------------------------------------

June 23rd 2001


Summary
-------

A serious security hole has been discovered in all versions of Samba
that allows an attacker to gain root access on the target machine for
certain types of common Samba configuration.

The immediate fix is to edit your smb.conf configuration file and
remove all occurances of the macro "%m". Replacing occurances of %m
with %I is probably the best solution for most sites.

Details
-------

A remote attacker can use a netbios name containing unix path
characters which will then be substituted into the %m macro wherever
it occurs in smb.conf. This can be used to cause Samba to create a log
file on top of an important system file, which in turn can be used to
compromise security on the server.

The most commonly used configuration option that can be vulnerable to
this attack is the "log file" option. The default value for this
option is VARDIR/log.smbd. If the default is used then Samba is not
vulnerable to this attack.

The security hole occurs when a log file option like the following is
used:

log file = /var/log/samba/%m.log

In that case the attacker can use a locally created symbolic link to
overwrite any file on the system. This requires local access to the
server.

If your Samba configuration has something like the following:

log file = /var/log/samba/%m

Then the attacker could successfully compromise your server remotely
as no symbolic link is required. This type of configuration is very
rare.

The most commonly used log file configuration containing %m is the
distributed in the sample configuration file that comes with Samba:

log file = /var/log/samba/log.%m

in that case your machine is not vulnerable to this attack unless you
happen to have a subdirectory in /var/log/samba/ which starts with the
prefix "log."

Credit
------

Thanks to Michal Zalewski (***@bos.bindview.com) for finding this
vulnerability.


New Release
-----------

While we recommend that vulnerable sites immediately change their
smb.conf configuration file to prevent the attack we will also be
making new releases of Samba within the next 24 hours to properly fix
the problem. Please see http://www.samba.org/ for the new releases.

Please report any attacks to the appropriate authority.

The Samba Team
***@samba.org

---------------------------------------------------------------------------

The release notes for 2.2.0 follow :

This is the official Samba 2.2.0 release. This version of Samba provides
the following new features and enhancements.

Integration between Windows oplocks and NFS file opens (IRIX and Linux
2.4 kernel only). This gives complete data and locking integrity between
Windows and UNIX file access to the same data files.

Ability to act as an authentication source for Windows 2000 clients as
well as for NT4.x clients.

Integration with the winbind daemon that provides a single
sign on facility for UNIX servers in Windows 2000/NT4 networks
driven by a Windows 2000/NT4 PDC. winbind is not included in
this release, it currently must be obtained separately. We are
committed to including winbind in a future Samba 2.2.x release.

Support for native Windows 2000/NT4 printing RPCs. This includes
support for automatic printer driver download.

Support for server supported Access Control Lists (ACLs).
This release contains support for the following filesystems:

Solaris 2.6+
SGI Irix
Linux Kernel with ACL patch from http://acl.bestbits.at
Linux Kernel with XFS ACL support.
Caldera/SCO UnixWare
IBM AIX
FreeBSD (with external patch)

Other platforms will be supported as resources are
available to test and implement the encessary modules. If
you are interested in writing the support for a particular
ACL filesystem, please join the samba-technical mailing
list and coordinate your efforts.

On PAM (Pluggable Authentication Module) based systems - better debugging
messages and encrypted password users now have access control verified via
PAM - Note: Authentication still uses the encrypted password database.

Rewritten internal locking semantics for more robustness.
This release supports full 64 bit locking semantics on all
(even 32 bit) platforms. SMB locks are mapped onto POSIX
locks (32 bit or 64 bit) as the underlying system allows.

Conversion of various internal flat data structures to use
database records for increased performance and
flexibility.

Support for acting as a MS-DFS (Distributed File System) server.

Support for manipulating Samba shares using Windows client tools
(server manager). Per share security can be set using these tools
and Samba will obey the access restrictions applied.

Samba profiling support (see below).

Compile time option for enabling a (Virtual file system) VFS layer
to allow non-disk resources to be exported as Windows filesystems
(such as databases etc.).

The documentation in this release has been updated and converted
from Yodl to DocBook 4.1. There are many new parameters since 2.0.7
and some defaults have changed.

Profiling support.
------------------
Support for collection of profile information. A shared
memory area has been created which contains counters for
the number of calls to and the amount of time spent in
various system calls and smb transactions. See the file
profile.h for a complete listing of the information
collected. Sample code for a samba pmda (collection agent
for Performance Co-Pilot) has been included in the pcp
directory.

To enable the profile data collection code in samba, you
must compile samba with profile support (run configure with
the --with-profile option). On startup, collection of data
is disabled. To begin collecting data use the smbcontrol
program to turn on profiling (see the smbcontrol man page).
Profile information collection can be enabled for all smbd
processes or one or more selected processes. The profiling
data collected is the aggragate for all processes that have
profiling enabled.

With samba compiled for profile data collection, you may see
a very slight degradation in performance even with profiling
collection turned off. On initial tests with NetBench on an
SGI Origin 200 server, this degradation was not measureable
with profile collection off compared to no profile collection
compiled into samba.

With count profile collection enabled on all clients, the
degradation was less than 2%. With full profile collection
enabled on all clients, the degradation was about 8.5%.

=====================================================================

If you think you have found a bug please email a report to :

***@samba.org

As always, all bugs are our responsibility.

Regards,

The Samba Team.

[James Nord]

Mike Black wrote:

>As pleased as I am about seeing 2.2.1 released there's still an outstanding
>bug which is preventing me from using it:
>http://bugs.samba.org/?findid=21369 (reported over a month ago)
>When copying a file from NT4.0 to samba server the file date/time is set to
>the current time instead of the original file time. Not sure if this is
>true for any other OS.
>I would think this could break things for some people (like me).
>I already identified what's causing the problem in the bug report and
>thought that it wouldn't be too hard to fix but figured the samba team could
>come up with a better fix than me.
>
Surely this is the wrong way around.

When you copy a file you _create a new file_.

When you move a file you just move its inode and all its
access/modified/create time gets moved with it.
Of course over a different fs or even network you do some pokery to set
the times to the times that they show on the original file.

Testing Samba 2.2.0 shows it is however doing what _you_ think it should
- which is IMHO wrong - at least it is not how a normal copy is
performed or how win2000 behaves taliking to another win2000 machine.

For instance,

Oringinal file (local Win200),
Created: 12 June 2001 19:07:41
Modified: 12 June 2001 19:07:42
Accessed: 10 July 2001

Copied to local drive
Created: 10 July 2001 17:32:34
Modified: 12 June 2001 19:07:42
Accessed: 10 July 200

Copied to Win2000 Share
Created: 10 July 2001 17:32:51
Modified: 12 June 2001 19:07:42
Accessed: 10 July 200

Copied to Samba 2.2.0 (Solaris 2.7) Share
Created: 12 June 2001 19:07:42
Modified: 12 June 2001 19:07:42
Accessed: 10 July 200

Moved to a Samba 2.2.0 (Solaris 2.7) Share
Created: 12 June 2001 19:07:42
Modified: 12 June 2001 19:07:42
Accessed: 10 July 200

So the move is correct but the copy is incorrect but the inverse of what
Mike Black was reporting.

Of course this was on a 2000 machine and solaris not NT4 and linux, but
why would that cause it to do it the correct way ;-)

/James

--
Technology is a word that describes something that doesn't work yet.
Douglas Adams

[Jeremy Allison]

scott wrote:
>
> Viewed from W2K, the Created/Modified dates are both the true creation date* of the file. If I do a 'stat' on the file from the
> Linux server, the Modify date shows as the true creation date, and the Change date is when I copied the file from W2K to Samba.
>
> The timestamps are getting created correctly, but aren't getting read back correctly.
>
> *true creation date = when the author actually made it.
>
> - - - - - - - - - - - - - - - - - - - - -
>
> > Oringinal file (local Win200),
> > Created: 12 June 2001 19:07:41
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 2001
> >
> > Copied to local drive
> > Created: 10 July 2001 17:32:34
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200
> >
> > Copied to Win2000 Share
> > Created: 10 July 2001 17:32:51
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200
> >
> > Copied to Samba 2.2.0 (Solaris 2.7) Share
> > Created: 12 June 2001 19:07:42
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200
> >
> > Moved to a Samba 2.2.0 (Solaris 2.7) Share
> > Created: 12 June 2001 19:07:42
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200


The problem is that the underlying UNIX filesystem
doesn't store the creation date.

Samba fakes this by looking at all dates available to
a file and setting the oldest one it can find as the
creation date (as this is most probably the earliest
date the file has been around).

Samba will mess up when a file is copied such that the
creation date is later than the modification date. Samba
can have no idea when the file really was created on a
POSIX filesystem so selects the earliest date to display.

Regards,

Jeremy Allison,
Samba TEam.
--
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------

[Mike Black]

Mine behaves differently

Original file (NT4):
Created: Monday, July 17, 2000 12:01:53 PM
Modified: Monday, July 17, 2000 12:01:53 PM
Accessed: Monday, July 17, 2000 12:01:53 PM

Copy to local (NT4):
Created: Wednesday, July 11, 2001 8:49:05 AM
Modified: Monday, July 17, 2000 12:01:53 PM
Accessed: Monday, July 17, 2000 12:01:53 PM

Copy to samba-2.0.7 (Linux)
Created: Monday, July 17, 2000 12:01:53 PM
Modified: Monday, July 17, 2000 12:01:53 PM
Accessed: Wednesday, July 11, 2001 8:50:42 A

Copy to samba-2.2.1 (Linux)
Created: Monday, July 17, 2000 12:01:53 PM
Modified: Monday, July 17, 2000 12:01:53 PM
Accessed: Monday, July 17, 2000 12:01:53 PM

This is the bug I reported -- ALL the date/times on samba-2.2.1 are being
set to the current date/time because of the cache flush occurring AFTER the
setftime routine. Maybe Solaris behaves differently on the cache flush?
________________________________________
Michael D. Black Principal Engineer

***@csihq.com 321-676-2923,x203
http://www.csihq.com Computer Science Innovations
http://www.csihq.com/~mike My home page
FAX [phone]
----- Original Message -----
From: "Jeremy Allison" <***@valinux.com>
To: "scott" <samba-***@ml.slittle.com>
Cc: <samba-***@lists.samba.org>; <samba-***@samba.org>;
<***@samba.org>
Sent: Tuesday, July 10, 2001 8:23 PM
Subject: Re: Samba 2.2.1 released.


scott wrote:
>
> Viewed from W2K, the Created/Modified dates are both the true creation
date* of the file. If I do a 'stat' on the file from the
> Linux server, the Modify date shows as the true creation date, and the
Change date is when I copied the file from W2K to Samba.
>
> The timestamps are getting created correctly, but aren't getting read back
correctly.
>
> *true creation date = when the author actually made it.
>
> - - - - - - - - - - - - - - - - - - - - -
>
> > Oringinal file (local Win200),
> > Created: 12 June 2001 19:07:41
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 2001
> >
> > Copied to local drive
> > Created: 10 July 2001 17:32:34
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200
> >
> > Copied to Win2000 Share
> > Created: 10 July 2001 17:32:51
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200
> >
> > Copied to Samba 2.2.0 (Solaris 2.7) Share
> > Created: 12 June 2001 19:07:42
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200
> >
> > Moved to a Samba 2.2.0 (Solaris 2.7) Share
> > Created: 12 June 2001 19:07:42
> > Modified: 12 June 2001 19:07:42
> > Accessed: 10 July 200


The problem is that the underlying UNIX filesystem
doesn't store the creation date.

Samba fakes this by looking at all dates available to
a file and setting the oldest one it can find as the
creation date (as this is most probably the earliest
date the file has been around).

Samba will mess up when a file is copied such that the
creation date is later than the modification date. Samba
can have no idea when the file really was created on a
POSIX filesystem so selects the earliest date to display.

Regards,

Jeremy Allison,
Samba TEam.
--
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------

[John E. Malmberg]

The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.

Note that this is just for compiling. I still have a bit of work to do to
get it to actually run.

Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.

-----------------
TORTURE.C

In this module, (char *) is being passed to a routine prototyped for
(unsigned char *). On Compaq C, this requires a cast.

Also the compiler is detecting that several pointers are declared as
volatile. This is incompatable with passing them to a routine that
does not expect the pointer to change out from under it.

It appears that what was really meant is to declare the data the pointer
is referencing as volatile, and that both fixes the compilation warnings
and removes the need for the casts.

Example:
volatile BOOL * shared_correct;
/* The pointer is volatile, it's value can be changed at any time */

BOOL * volatile shared_correct;
/* The data the pointer is referencing is volatile, the pointer itself
will not change from an asynchronous routine */

(Not being a language lawyer, I could be wrong on this, but as far as I can
tell from my references, it appears that these changes are needed.)


TORTURE_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;1
443 generate_random_buffer(buf, buf_size, False);
444
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;4
443 generate_random_buffer((unsigned char *)buf, buf_size, False);
444
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;1
2242 volatile BOOL *shared_correct;
2243
2244 shared_correct = (volatile BOOL *)shm_setup(sizeof(BOOL));
2245 *shared_correct = True;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;4
2242 BOOL * volatile shared_correct;
2243
2244 shared_correct = shm_setup(sizeof(BOOL));
2245 *shared_correct = True;
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;1
2963 volatile pid_t *child_status;
2964 volatile BOOL *child_status_out;
2965 int synccount;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;4
2963 pid_t * volatile child_status;
2964 BOOL * volatile child_status_out;
2965 int synccount;
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;1
2970 child_status = (volatile pid_t *)shm_setup(sizeof(pid_t)*nprocs);
2971 if (!child_status) {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;4
2970 child_status = shm_setup(sizeof(pid_t)*nprocs);
2971 if (!child_status) {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;1
2976 child_status_out = (volatile BOOL *)shm_setup(sizeof(BOOL)*nprocs);
2977 if (!child_status_out) {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;4
2976 child_status_out = shm_setup(sizeof(BOOL)*nprocs);
2977 if (!child_status_out) {
************

Number of difference sections found: 5
Number of difference records found: 8

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]TORTURE_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]TORTURE.C;4


-John
***@qsl.network
Personal Opinion Only

[Michael Sweet]

"John E. Malmberg" wrote:
> ...
> (Not being a language lawyer, I could be wrong on this, but as far as I can
> tell from my references, it appears that these changes are needed.)
> ...

First, a C compiler should not error out from passing a pointer of
a different type - such strictness is reserved for C++ compilers... :)

Second, the volatile modifier is not supported by most compilers.
It is fairly new so I wouldn't recommend using it until more compilers
support it (and even then you should #define it away if the compiler
doesn't support it)

--
______________________________________________________________________
Michael Sweet, Easy Software Products ***@easysw.com
Printing Software for UNIX http://www.easysw.com

[Andrew Bartlett]

"John E. Malmberg" wrote:
>
> The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
> to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.
>
> Note that this is just for compiling. I still have a bit of work to do to
> get it to actually run.
>
> Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.
>

--snip diffs--

Any chance of getting these in diff -u format? Then I might have a
fighting chance of
(a) seeing exactly what the changes are
(b) applying them (at least to HEAD, I try not to touch SAMBA_2_2)

Thanks,

Andrew Bartlett
Samba Build Farm Maintainer

--
Andrew Bartlett
***@pcug.org.au
***@samba.org

[John E. Malmberg]

The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.

Note that this is just for compiling. I still have a bit of work to do to
get it to actually run.

Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.

-----------------
NMBD_NAMEQUERY.C

The variable answer_ip can be referenced in a debug statement without it
being initialized. Compaq C detects this and stopped the build.

NMBD_NAMEQUERY_C.DIFF

************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]NMBD_NAMEQUERY.C;1
43 /* Ensure we don't retry the query but leave the response record cleanup
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.NMBD]NMBD_NAMEQUERY.C;3
43 answer_ip.S_un.S_addr = 0; /* JEM */
44
45 /* Ensure we don't retry the query but leave the response record cleanup
************

Number of difference sections found: 1
Number of difference records found: 2

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]NMBD_NAMEQUERY_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]NMBD_NAMEQUERY.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.NMBD]NMBD_NAMEQUERY.C;3

--------------


MSDFS.C


On Compaq C, (char *) and (unsigned char *) are not compatable.

MSDFS_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]MSDFS.C;1
374 requestedpathlen = (dos_struni2(uni_requestedpath,pathname,512)+1)*2;
375
376 dump_data(10,uni_requestedpath,requestedpathlen);
377
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.MSDFS]MSDFS.C;1
374 requestedpathlen = (dos_struni2((char *)uni_requestedpath,pathname,512)+1)*2;
375
376 dump_data(10,(char *)uni_requestedpath,requestedpathlen);
377
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]MSDFS.C;1
466 reqpathlen = (dos_struni2(uni_reqpath,pathname,512)+1)*2;
467
468 dump_data(10,uni_reqpath,reqpathlen);
469
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.MSDFS]MSDFS.C;1
466 reqpathlen = (dos_struni2((char *)uni_reqpath,pathname,512)+1)*2;
467
468 dump_data(10,(char *)uni_reqpath,reqpathlen);
469
************

Number of difference sections found: 2
Number of difference records found: 6

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]MSDFS_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]MSDFS.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.MSDFS]MSDFS.C;1


-John
***@qsl.network
Personal Opinion Only

[John E. Malmberg]

The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.

Note that this is just for compiling. I still have a bit of work to do to
get it to actually run.

Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.
------------

LOCKTEST.C

There is an extra semicolon on the #define for LOCKBASE

The way the initializer for the structure is conditionally compiled out
produces a syntax error on Compaq C. This patch fixes it.

LOCKTEST_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]LOCKTEST.C;1
37 #define LOCKBASE 0;
38
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]LOCKTEST.C;1
37 #define LOCKBASE 0
38
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]LOCKTEST.C;1
68 #endif
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]LOCKTEST.C;1
68 #else
69 0
70 #endif
************

Number of difference sections found: 2
Number of difference records found: 3

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]LOCKTEST_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]LOCKTEST.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]LOCKTEST.C;1

-John
***@qsl.network
Personal Opinion Only

[John E. Malmberg]

The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.

Note that this is just for compiling. I still have a bit of work to do to
get it to actually run.

Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.

-----------------

TDB.C


OpenVMS needs the SMB_STRUCT_STAT to be used instead of struct stat on any
module that references st_ino. On OpenVMS st_ino in struct stat is
unsigned short[3].

TDB_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
233 /* struct stat st; */
234 SMB_STRUCT_STAT st;
235 if (len <= tdb->map_size) return 0;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
233 struct stat st;
234 if (len <= tdb->map_size) return 0;
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
1258 /* struct stat st; */
1259 SMB_STRUCT_STAT st;
1260 int rev = 0, locked;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
1257 struct stat st;
1258 int rev = 0, locked;
************

Number of difference sections found: 2
Number of difference records found: 4

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDB_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1


-----------------


TDBTOOL.C

Compaq C can not deal with a string constant with imbedded new lines in
it. Also (char *) and (unsigned char *) can not be mixed.

TDBTOOL_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL.C;1
81 printf("
82 tdbtool:
83 create dbname : create a database
84 open dbname : open an existing database
85 erase : erase the database
86 dump : dump the database as strings
87 insert key data : insert a record
88 store key data : store a record (replace)
89 show key : show a record by key
90 delete key : delete a record by key
91 free : print the database freelist
92 1 | first : print the first record
93 n | next : print the next record
94 q | quit : terminate
95 \\n : repeat 'next' command
96 ");
97 }
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDBTOOL.C;2
81 puts("\ntdbtool: ");
82 puts(" create dbname : create a database");
83 puts(" open dbname : open an existing database");
84 puts(" erase : erase the database");
85 puts(" dump : dump the database as strings");
86 puts(" insert key data : insert a record");
87 puts(" store key data : store a record (replace)");
88 puts(" show key : show a record by key");
89 puts(" delete key : delete a record by key");
90 puts(" free : print the database freelist");
91 puts(" 1 | first : print the first record");
92 puts(" n | next : print the next record");
93 puts(" q | quit : terminate");
94 puts(" \\n : repeat 'next' command\n");
95 }
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL.C;1
236 print_data(key.dptr, key.dsize);
237 printf("data %d bytes\n", dbuf.dsize);
238 print_data(dbuf.dptr, dbuf.dsize);
239 return 0;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDBTOOL.C;2
234 print_data((unsigned char *)key.dptr, key.dsize);
235 printf("data %d bytes\n", dbuf.dsize);
236 print_data((unsigned char *)dbuf.dptr, dbuf.dsize);
237 return 0;
************

Number of difference sections found: 2
Number of difference records found: 19

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDBTOOL.C;2

-John
***@qsl.network
Personal Opinion Only

[Jeremy Allison]

"John E. Malmberg" wrote:

> TDB.C
>
> OpenVMS needs the SMB_STRUCT_STAT to be used instead of struct stat on any
> module that references st_ino. On OpenVMS st_ino in struct stat is
> unsigned short[3].
>
> TDB_C.DIFF
> ************
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> 233 /* struct stat st; */
> 234 SMB_STRUCT_STAT st;
> 235 if (len <= tdb->map_size) return 0;
> ******
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> 233 struct stat st;
> 234 if (len <= tdb->map_size) return 0;
> ************
> ************
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> 1258 /* struct stat st; */
> 1259 SMB_STRUCT_STAT st;
> 1260 int rev = 0, locked;
> ******
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> 1257 struct stat st;
> 1258 int rev = 0, locked;
> ************

I don't understand why this fix is needed.

st_ino in the tdb code is simply assigned between
a tdb struct from the stat struct. Why does this fail
for any data type ?

We don't want to add Samba dependencies into tdb as it
is independent of the Samba code (it's hosted on sourceforge).

Can you explain what you're trying to fix please ?

Thanks,

Jeremy.

--
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------

[Nehemiah, Mark]

> 7). Two locking fixes added. Samba 2.2.1 now passes the
> Clarion network
> lock tester tool for distributed databases.

Thanks Guys! Today we moved 2 production Clarion Apps to Samba.

1st app. about 20Meg of Data, 6 .TPS data files
2nd app. about 120Meg of Data in 30 differnet .TPS

So far so GOOD!

If all is well at the end of the week. We will move the other databases.

total of about 10Gigs of .TPS files.


Mark.

KUDOS goes out to all of the Samba team and their efforts.

[John E. Malmberg]

The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.

Note that this is just for compiling. I still have a bit of work to do to
get it to actually run.

Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.

-----------------
INCLUDES.H


On the OpenVMS platform, using relative pathnames in #include statements
does not work in my build environment. I am investigating workarounds.

This of course requires that the tdb/ be in the include path for the
compile statement.

INCLUDES_H.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]includes.h;1
633 #include "../tdb/tdb.h"
634 #include "../tdb/spinlock.h"
635 #include "talloc.h"
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.INCLUDE]INCLUDES.H;1
633 #ifdef __VMS /* Problems with relative path names */
634 #include "tdb.h"
635 #include "spinlock.h"
636 #else
637 #include "../tdb/tdb.h"
638 #include "../tdb/spinlock.h"
639 #endif
640 #include "talloc.h"
************

Number of difference sections found: 1
Number of difference records found: 7

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]INCLUDES_H.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]includes.h;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.INCLUDE]INCLUDES.H;1

-John
***@qsl.network
Personal Opinion Only

[John E. Malmberg]

The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.

Note that this is just for compiling. I still have a bit of work to do to
get it to actually run.

Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.

-----------------
SMBW_SAMPLE.C

Compaq C needs the functions to be prototyped, and can not deal with
a string constant that is longer than one line.

SMBW_SAMBPLE_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_SAMPLE.C;1
1 #include <stdio.h>
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]SMBW_SAMPLE.C;9
1 #include "config.h"
2 #include <stdio.h>
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_SAMPLE.C;1
6
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]SMBW_SAMPLE.C;9
7 #include <string.h> /* JEM */
8
9 int smbw_closedir(DIR *dirp);
10 void smbw_init(void);
11 DIR *smbw_opendir(const char *fname);
12 struct dirent *smbw_readdir(DIR *dirp);
13 void smbw_setshared(const char *name, const char *val);
14 void smbw_setup_shared(void);
15
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_SAMPLE.C;1
9 printf("
10 smbw_sample - a sample program that uses smbw
11
12 smbw_sample <options> path
13
14 options:
15 -W workgroup
16 -l logfile
17 -P prefix
18 -d debuglevel
19 -U username%%password
20 -R resolve order
21
22 note that path must start with /smb/
23 ");
24 }
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]SMBW_SAMPLE.C;9
18 puts("\nsmbw_sample - a sample program that uses smbw\n");
19
20 puts("smbw_sample <options> path\n");
21
22 puts(" options:");
23 puts(" -W workgroup");
24 puts(" -l logfile");
25 puts(" -P prefix");
26 puts(" -d debuglevel");
27 puts(" -U username%%password");
28 puts(" -R resolve order\n");
29
30 puts("note that path must start with /smb/\n");
31
32 }
************

Number of difference sections found: 3
Number of difference records found: 24

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_SAMPLE_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_SAMPLE.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.UTILS]SMBW_SAMPLE.C;9



-------------------

SMBW_STAT.C


Apparently the structure "st" is not defined, and it is assumed that
the structure has the members st_blksize and st_blocks. Neither of these
members are listed in The Open Group's Single Unix Specification.

This file seemed a bit incomplete.

SMBW_STAT_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
34 st->st_mode = 0;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
34 SMB_STRUCT_STAT *smb_st;
35
36 smb_st = (SMB_STRUCT_STAT *)st;
37 st->st_mode = 0;
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
48 st->st_blksize = 512;
49 st->st_blocks = (size+511)/512;
50 st->st_uid = getuid();
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
51 #ifdef HAVE_STAT_ST_BLKSIZE
52 st->st_blksize = 512;
53 st->st_blocks = (size+511)/512;
54 #endif
55 st->st_uid = getuid();
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
57 if (st->st_ino == 0) {
58 st->st_ino = smbw_inode(fname);
59 }
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
62 if (smb_st->st_ino == 0) {
63 smb_st->st_ino = smbw_inode(fname);
64 }
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
130 struct smbw_file *file;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
135 SMB_STRUCT_STAT *smb_st;
136
137 struct smbw_file *file;
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
136 smbw_busy++;
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
143 smb_st = (SMB_STRUCT_STAT *)st;
144 smbw_busy++;
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
157 st->st_ino = ino;
158
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
165 smb_st->st_ino = ino;
166
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
184
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
192 SMB_STRUCT_STAT *smb_st;
193
194 smb_st = (SMB_STRUCT_STAT *)st;
195
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1
241 st->st_ino = ino;
242
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4
252 smb_st->st_ino = ino;
253
************

Number of difference sections found: 8
Number of difference records found: 17

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]SMBW_STAT.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]SMBW_STAT.C;4



-------------------

WRAPPED.C

This module will not compile portably as it is assuming foo() and foo(...) can
be interchanged, and the C standard, as was pointed out to me on comp.std.c
does not allow this. These changes actually should make the module to
be portable across compilers and operating systems.

This actually allows SMBWRAPPER to be used on NON-LINUX systems as either
a shared image or statically linked. The realcalls.h must be modified to
be operating system specific in this case.

The function calls now match both the standard library calls and the usage
by the module.

WRAPPED_C.DIFF
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
28 #include "config.h"
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
28 /* Compaq C on OpenVMS will not allow these compiler warnings, and they
29 must be fixed, or it can not be compiled. This means that portability
30 already was broken.
31
32 */
33
34 #include "config.h"
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
37 int open(char *name, int flags, mode_t mode)
38 {
39 if (smbw_path(name)) {
40 return smbw_open(name, flags, mode);
41 }
42
43 return real_open(name, flags, mode);
44 }
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
43 int open(const char *name, int flags, ...)
44 {
45 int arg_cnt;
46 va_list ap;
47 mode_t mode;
48
49 va_count(arg_cnt);
50
51 if (arg_cnt >= 3)
52 {
53 va_start(ap, flags);
54 mode = va_arg(ap, mode_t);
55 }
56
57 if (smbw_path(name)) {
58 if (arg_cnt == 3)
59 return smbw_open(name, flags, mode);
60 else
61 return -1;
62 }
63
64 if (arg_cnt >= 3)
65 return real_open(name, flags, mode);
66 else
67 return real_open(name, flags);
68 }
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
51 #elif HAVE___OPEN
52 int __open(char *name, int flags, mode_t mode)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
75 #elif defined(HAVE___OPEN)
76 int __open(char *name, int flags, mode_t mode)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
76 #elif HAVE___OPEN64
77 int __open64(char *name, int flags, mode_t mode)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
100 #elif defined(HAVE___OPEN64)
101 int __open64(char *name, int flags, mode_t mode)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
129 int chdir(char *name)
130 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
153 int chdir(const char *name)
154 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
139 #elif HAVE__CHDIR
140 int _chdir(char *name)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
163 #elif defined(HAVE__CHDIR)
164 int _chdir(char *name)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
165 #elif HAVE__CLOSE
166 int _close(int fd)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
189 #elif defined(HAVE__CLOSE)
190 int _close(int fd)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
183 #elif HAVE__FCHDIR
184 int _fchdir(int fd)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
207 #elif defined(HAVE__FCHDIR)
208 int _fchdir(int fd)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
191 int fcntl(int fd, int cmd, long arg)
192 {
193 if (smbw_fd(fd)) {
194 return smbw_fcntl(fd, cmd, arg);
195 }
196
197 return real_fcntl(fd, cmd, arg);
198 }
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
215 int fcntl(int fd, int cmd, ...)
216 {
217 int arg_cnt;
218 va_list ap;
219 long * arg;
220
221 va_count(arg_cnt);
222
223
224 if (arg_cnt >= 3)
225 {
226 va_start(ap, cmd);
227 arg = va_arg(ap, long *);
228 }
229
230 if (smbw_fd(fd)) {
231 if (arg_cnt == 3)
232 return smbw_fcntl(fd, cmd, arg);
233 else
234 return -1;
235 }
236
237 if (arg_cnt >= 3)
238 {
239 return real_fcntl(fd, cmd, arg);
240 }
241 else
242 {
243 return real_fcntl(fd, cmd);
244 }
245 }
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
206 #elif HAVE__FCNTL
207 int _fcntl(int fd, int cmd, long arg)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
253 #elif defined(HAVE__FCNTL)
254 int _fcntl(int fd, int cmd, long arg)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
231 #elif HAVE__GETDENTS
232 int _getdents(int fd, void *dirp, unsigned int count)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
278 #elif defined(HAVE__GETDENTS)
279 int _getdents(int fd, void *dirp, unsigned int count)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
253 #elif HAVE__LSEEK
254 off_t _lseek(int fd, off_t offset, int whence)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
300 #elif defined(HAVE__LSEEK)
301 off_t _lseek(int fd, off_t offset, int whence)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
275 #elif HAVE__READ
276 ssize_t _read(int fd, void *buf, size_t count)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
322 #elif defined(HAVE__READ)
323 ssize_t _read(int fd, void *buf, size_t count)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
297 #elif HAVE__WRITE
298 ssize_t _write(int fd, void *buf, size_t count)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
344 #elif defined(HAVE__WRITE)
345 ssize_t _write(int fd, void *buf, size_t count)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
306 int access(char *name, int mode)
307 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
353 int access(const char *name, int mode)
354 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
317 int chmod(char *name,mode_t mode)
318 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
364 int chmod(const char *name, mode_t mode)
365 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
328 int chown(char *name,uid_t owner, gid_t group)
329 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
375 int chown(const char *name,uid_t owner, gid_t group)
376 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
346 int mkdir(char *name, mode_t mode)
347 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
393 int mkdir(const char *name, mode_t mode)
394 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
356 #if HAVE___FXSTAT
357 int __fxstat(int vers, int fd, void *st)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
403 #ifdef HAVE___FXSTAT
404 int __fxstat(int vers, int fd, void *st)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
372 #if HAVE___XSTAT
373 int __xstat(int vers, char *name, void *st)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
419 #ifdef HAVE___XSTAT
420 int __xstat(int vers, char *name, void *st)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
389 #if HAVE___LXSTAT
390 int __lxstat(int vers, char *name, void *st)
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
436 #ifdef HAVE___LXSTAT
437 int __lxstat(int vers, char *name, void *st)
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
406 int stat(char *name, void *st)
407 {
408 #if HAVE___XSTAT
409 return __xstat(0, name, st);
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
453 int stat(const char *name, void *st)
454 {
455 #ifdef HAVE___XSTAT
456 return __xstat(0, name, st);
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
418 int lstat(char *name, void *st)
419 {
420 #if HAVE___LXSTAT
421 return __lxstat(0, name, st);
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
465 int lstat(const char *name, void *st)
466 {
467 #ifdef HAVE___LXSTAT
468 return __lxstat(0, name, st);
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
432 #if HAVE___LXSTAT
433 return __fxstat(0, fd, st);
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
479 #ifdef HAVE___LXSTAT
480 return __fxstat(0, fd, st);
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
443 int unlink(char *name)
444 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
490 int unlink(const char *name)
491 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
454 int utime(char *name,void *tvp)
455 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
501 int utime(const char *name, const void *tvp)
502 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
465 int utimes(char *name,void *tvp)
466 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
512 int utimes(const char *name, const void *tvp)
513 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
475 int readlink(char *path, char *buf, size_t bufsize)
476 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
522 int readlink(const char *path, char *buf, size_t bufsize)
523 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
485 int rename(char *oldname,char *newname)
486 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
532 int rename(const char *oldname, const char *newname)
533 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
502 int rmdir(char *name)
503 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
549 int rmdir(const char *name)
550 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
512 int symlink(char *topath,char *frompath)
513 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
559 int symlink(const char *topath, const char *frompath)
560 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
549 void *opendir(char *name)
550 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
596 void *opendir(const char *name)
597 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
607 int acl(char *pathp, int cmd, int nentries, void *aclbufp)
608 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
654 int acl(const char *pathp, int cmd, int nentries, void *aclbufp)
655 {
************
************
File PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1
628 int creat(char *path, mode_t mode)
629 {
******
File PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13
675 int creat(const char *path, mode_t mode)
676 {
************

Number of difference sections found: 34
Number of difference records found: 96

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED_C.DIFF;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE]WRAPPED.C;1-
PROJECT_ROOT:[SAMBA_VMS.SOURCE.SMBWRAPPER]WRAPPED.C;13

-John
***@qsl.network
Personal Opinion Only

[Andrew Johnson]

Could I please be removed frm this list?

Andrew Johnson
PSC

On Tue, 10 Jul 2001, John E. Malmberg wrote:

> The following changes were needed to get SAMBA 2.2.x Jul 9th CVS snapshot
> to compile on OpenVMS 7.2-1 Alpha using Compaq C Version 6.4-005.
>
> Note that this is just for compiling. I still have a bit of work to do to
> get it to actually run.
>
> Compaq C is common to Tru-64 Unix, Linux on Alpha, and OpenVMS.
>
> -----------------
>
> TDB.C
>
>
> OpenVMS needs the SMB_STRUCT_STAT to be used instead of struct stat on any
> module that references st_ino. On OpenVMS st_ino in struct stat is
> unsigned short[3].
>
> TDB_C.DIFF
> ************
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> 233 /* struct stat st; */
> 234 SMB_STRUCT_STAT st;
> 235 if (len <= tdb->map_size) return 0;
> ******
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> 233 struct stat st;
> 234 if (len <= tdb->map_size) return 0;
> ************
> ************
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> 1258 /* struct stat st; */
> 1259 SMB_STRUCT_STAT st;
> 1260 int rev = 0, locked;
> ******
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> 1257 struct stat st;
> 1258 int rev = 0, locked;
> ************
>
> Number of difference sections found: 2
> Number of difference records found: 4
>
> DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDB_C.DIFF;1-
> PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2-
> PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
>
>
> -----------------
>
>
> TDBTOOL.C
>
> Compaq C can not deal with a string constant with imbedded new lines in
> it. Also (char *) and (unsigned char *) can not be mixed.
>
> TDBTOOL_C.DIFF
> ************
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL.C;1
> 81 printf("
> 82 tdbtool:
> 83 create dbname : create a database
> 84 open dbname : open an existing database
> 85 erase : erase the database
> 86 dump : dump the database as strings
> 87 insert key data : insert a record
> 88 store key data : store a record (replace)
> 89 show key : show a record by key
> 90 delete key : delete a record by key
> 91 free : print the database freelist
> 92 1 | first : print the first record
> 93 n | next : print the next record
> 94 q | quit : terminate
> 95 \\n : repeat 'next' command
> 96 ");
> 97 }
> ******
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDBTOOL.C;2
> 81 puts("\ntdbtool: ");
> 82 puts(" create dbname : create a database");
> 83 puts(" open dbname : open an existing database");
> 84 puts(" erase : erase the database");
> 85 puts(" dump : dump the database as strings");
> 86 puts(" insert key data : insert a record");
> 87 puts(" store key data : store a record (replace)");
> 88 puts(" show key : show a record by key");
> 89 puts(" delete key : delete a record by key");
> 90 puts(" free : print the database freelist");
> 91 puts(" 1 | first : print the first record");
> 92 puts(" n | next : print the next record");
> 93 puts(" q | quit : terminate");
> 94 puts(" \\n : repeat 'next' command\n");
> 95 }
> ************
> ************
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL.C;1
> 236 print_data(key.dptr, key.dsize);
> 237 printf("data %d bytes\n", dbuf.dsize);
> 238 print_data(dbuf.dptr, dbuf.dsize);
> 239 return 0;
> ******
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDBTOOL.C;2
> 234 print_data((unsigned char *)key.dptr, key.dsize);
> 235 printf("data %d bytes\n", dbuf.dsize);
> 236 print_data((unsigned char *)dbuf.dptr, dbuf.dsize);
> 237 return 0;
> ************
>
> Number of difference sections found: 2
> Number of difference records found: 19
>
> DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL_C.DIFF;1-
> PROJECT_ROOT:[SAMBA_VMS.SOURCE]TDBTOOL.C;1-
> PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDBTOOL.C;2
>
> -John
> ***@qsl.network
> Personal Opinion Only
>
>
>

[John E. Malmberg]

On Tue, 10 Jul 2001, Michael Sweet wrote:

> "John E. Malmberg" wrote:
> > ...
> > (Not being a language lawyer, I could be wrong on this, but as far as I can
> > tell from my references, it appears that these changes are needed.)
> > ...
>
> First, a C compiler should not error out from passing a pointer of
> a different type - such strictness is reserved for C++ compilers... :)

The difference is significant, and while it may be possible to tell
the C compiler to ignore the issue, I would think that most programmers
would want to realize that the what they asked for is obviously not
what they wanted. This shows up when the pointer is passed to a routine.

Having a volatile pointer is quite a different thing from having a
pointer to a volatile memory location.

> Second, the volatile modifier is not supported by most compilers.
> It is fairly new so I wouldn't recommend using it until more compilers
> support it (and even then you should #define it away if the compiler
> doesn't support it)

Using the #define in config.h may be a good idea, but the implications
of what volatile means to a compiler indicates that it should be used
where ever it is needed.

This would be in any case where the same physical memory location can be
referenced by multiple threads or processes. Failure to do so can result
in the compiler missing a change to the value.


I have not examined the code to verify if volatile is really needed for
the code in question.

At this point I am trying to get to the state where I, and hopefully a
few others can build the current CVS tree on OpenVMS.


-John
***@qsl.network
Personal Opinion Only

[Michael Sweet]

"John E. Malmberg" wrote:
> ...
> > First, a C compiler should not error out from passing a pointer of
> > a different type - such strictness is reserved for C++ compilers... :)
>
> The difference is significant, and while it may be possible to tell
> the C compiler to ignore the issue, I would think that most programmers
> would want to realize that the what they asked for is obviously not
> what they wanted. This shows up when the pointer is passed to a routine.

That's what "warnings" are for...

> Having a volatile pointer is quite a different thing from having a
> pointer to a volatile memory location.

Yes, but until recently C had no "volatile" keyword, and do be honest
I'd rather have the compiler *not* decide if a pointer should be
volatile on its own.

> > Second, the volatile modifier is not supported by most compilers.
> > It is fairly new so I wouldn't recommend using it until more compilers
> > support it (and even then you should #define it away if the compiler
> > doesn't support it)
>
> Using the #define in config.h may be a good idea, but the implications
> of what volatile means to a compiler indicates that it should be used
> where ever it is needed.

The volatile keyword was added to allow the compiler to make
optimizations
that assume that temporary results of pointer dereferencing won't change
when the pointer is passed to another function, or that two pointer
variables might be pointing at the same general area of memory (e.g., an
implementation of strcpy...)

> This would be in any case where the same physical memory location can be
> referenced by multiple threads or processes. Failure to do so can result
> in the compiler missing a change to the value.

The volatile keyword isn't really meant for that; MP issues extend
well beyond C, which is why you usually use OS mechanisms for
semaphores, message queues, etc. All volatile really buys you in
this case is a mechanism for correctly (not) caching shared global
variables.

--
______________________________________________________________________
Michael Sweet, Easy Software Products ***@easysw.com
Printing Software for UNIX http://www.easysw.com

[John Aldridge]

At 11:19 10/07/2001 -0400, Michael Sweet wrote:
>"John E. Malmberg" wrote:
> > ...
> > > First, a C compiler should not error out from passing a pointer of
> > > a different type - such strictness is reserved for C++ compilers... :)
> >
> > The difference is significant, and while it may be possible to tell
> > the C compiler to ignore the issue, I would think that most programmers
> > would want to realize that the what they asked for is obviously not
> > what they wanted. This shows up when the pointer is passed to a routine.
>
>That's what "warnings" are for...

No... it's an error. ANSI C says (under Assignment)

"One of the following shall hold... both operands are pointers to qualified
or unqualified versions of compatible types, and the type pointed to by the
left hand side has all the qualifiers of the type pointed to by the right."

and then defines argument passing to be "as if by assignment".

>Yes, but until recently C had no "volatile" keyword, and do be honest
>I'd rather have the compiler *not* decide if a pointer should be
>volatile on its own.

> > > Second, the volatile modifier is not supported by most compilers.
> > > It is fairly new so I wouldn't recommend using it until more compilers
> > > support it (and even then you should #define it away if the compiler
> > > doesn't support it)

Um, it's in ANSI C, which dates from 1989 (and was commonly supported
before that). That's not very recent. I haven't seen a compiler which
didn't support it for many years.

>The volatile keyword was added to allow the compiler to make
>optimizations
>that assume that temporary results of pointer dereferencing won't change
>when the pointer is passed to another function, or that two pointer
>variables might be pointing at the same general area of memory (e.g., an
>implementation of strcpy...)

Are you thinking of the C9X "restrict" qualifier?

> > This would be in any case where the same physical memory location can be
> > referenced by multiple threads or processes. Failure to do so can result
> > in the compiler missing a change to the value.
>
>The volatile keyword isn't really meant for that; MP issues extend
>well beyond C, which is why you usually use OS mechanisms for
>semaphores, message queues, etc. All volatile really buys you in
>this case is a mechanism for correctly (not) caching shared global
>variables.

ANSI C says "An object that has volatile-qualified type may be modified in
ways unknown to the implementation or have other unknown side effects." ,
and, in a footnote, "The volatile declaration may be used to describe an
object corresponding to a memory-mapped input/output port or an object
accessed by an asynchronously interrupting function."


--
Cheers,
John

[Michael Sweet]

John Aldridge wrote:
> ...
> No... it's an error. ANSI C says (under Assignment)
>
> "One of the following shall hold... both operands are pointers to qualified
> or unqualified versions of compatible types, and the type pointed to by the
> left hand side has all the qualifiers of the type pointed to by the right."
>
> and then defines argument passing to be "as if by assignment".

Sigh... You might also look to see that "signed" and "unsigned" types
are considered to be compatible for assignment purposes, although a
compiler is free to issue a warning about it...

> ...
> Um, it's in ANSI C, which dates from 1989 (and was commonly supported
> before that). That's not very recent. I haven't seen a compiler which
> didn't support it for many years.

OK, maybe I'm confusing this with the "restrict" keyword...

> Are you thinking of the C9X "restrict" qualifier?

Yes, I think I am. Sorry...

> ...
> ANSI C says "An object that has volatile-qualified type may be modified in
> ways unknown to the implementation or have other unknown side effects." ,
> and, in a footnote, "The volatile declaration may be used to describe an
> object corresponding to a memory-mapped input/output port or an object
> accessed by an asynchronously interrupting function."

Right, but that doesn't mean you can use volatile instead of the
OS MP mechanisms. It only tells the compiler not to do certain
optimizations (like caching the results of a dereference)

In short, it sounds like Compaq C may be performing optimizations that
are unsafe...

--
______________________________________________________________________
Michael Sweet, Easy Software Products ***@easysw.com
Printing Software for UNIX http://www.easysw.com

[John Aldridge]

At 12:30 10/07/2001 -0400, Michael Sweet wrote:
>John Aldridge wrote:
> > ...
> > No... it's an error. ANSI C says (under Assignment)
> >
> > "One of the following shall hold... both operands are pointers to qualified
> > or unqualified versions of compatible types, and the type pointed to by the
> > left hand side has all the qualifiers of the type pointed to by the right."
> >
> > and then defines argument passing to be "as if by assignment".
>
>Sigh... You might also look to see that "signed" and "unsigned" types
>are considered to be compatible for assignment purposes, although a
>compiler is free to issue a warning about it...

The section on assignment also says "One of the following shall hold... the
left operand has qualified or unqualifed arithmetic type and the right has
arithmetic type." which covers this case

In other words
signed = unsigned
is legal (though the compiler may warn), but
int* = volatile int*
isn't, and the compiler must issue a diagnostic and need complete the
compilation.


--
Cheers,
John

[John E. Malmberg]

On Tue, 10 Jul 2001, Andrew Johnson wrote:

> Could I please be removed frm this list?

Which one? You did not specify.

How did you get subscribed to this list with
out getting the removal instructions?

see http://lists.samba.org to change your status
on what ever samba mailing lists you are on.

Mailing list operations are mostly automated.
Sending subscribe or unsubscribe requests to them
usually does not do anything but send the message
to thousand of people that can not do anything
to change your status.


-John
***@qsl.network
Personal Opinion Only

[Andrew Johnson]

I don't know. Call it a gliche. I am on the Samba-vms list.

THanks,
ANdrew

On Tue, 10 Jul 2001, John E. Malmberg wrote:

> On Tue, 10 Jul 2001, Andrew Johnson wrote:
>
> > Could I please be removed frm this list?
>
> Which one? You did not specify.
>
> How did you get subscribed to this list with
> out getting the removal instructions?
>
> see http://lists.samba.org to change your status
> on what ever samba mailing lists you are on.
>
> Mailing list operations are mostly automated.
> Sending subscribe or unsubscribe requests to them
> usually does not do anything but send the message
> to thousand of people that can not do anything
> to change your status.
>
>
> -John
> ***@qsl.network
> Personal Opinion Only
>
>

[Christopher R. Hertel]

John,

> NMBD_NAMEQUERY.C
>
> The variable answer_ip can be referenced in a debug statement without it
> being initialized. Compaq C detects this and stopped the build.
>
> NMBD_NAMEQUERY_C.DIFF
>
> ************
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE]NMBD_NAMEQUERY.C;1
> 43 /* Ensure we don't retry the query but leave the response record cleanup
> ******
> File PROJECT_ROOT:[SAMBA_VMS.SOURCE.NMBD]NMBD_NAMEQUERY.C;3
> 43 answer_ip.S_un.S_addr = 0; /* JEM */
> 44
> 45 /* Ensure we don't retry the query but leave the response record cleanup
> ************

That debug statement is likely mine. I'm trying to track down some
multiple response errors (which are probably caused by wierd Windows
behavior, but still...). Sure 'nough, the answer IP is coming up garbage
in some of the debug logs. I'll take a look.

Chris -)-----

--
Christopher R. Hertel -)----- University of Minnesota
***@nts.umn.edu Networking and Telecommunications Services

Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz

[John E. Malmberg]

Andrew Bartlett wrote:

> Any chance of getting these in diff -u format? Then I might have a
> fighting chance of
> (a) seeing exactly what the changes are
> (b) applying them (at least to HEAD, I try not to touch SAMBA_2_2)

I do not have that "diff" utility currently installed on my systems.

I have recently located binaries for that "diff" that are
reported to work on OpenVMS, and I will try to run them off for you this
week. I assume a direct E-mail other than posting them to the mailing
lists again?

I was under the impression that the CVS snapshot that I was downloading
is from the HEAD stream, but I really do not know.

-John
***@qsl.network
Personal Opinion Only.

[Andrew Bartlett]

"John E. Malmberg" wrote:
>
> Andrew Bartlett wrote:
>
> > Any chance of getting these in diff -u format? Then I might have a
> > fighting chance of
> > (a) seeing exactly what the changes are
> > (b) applying them (at least to HEAD, I try not to touch SAMBA_2_2)
>
> I do not have that "diff" utility currently installed on my systems.
>
> I have recently located binaries for that "diff" that are
> reported to work on OpenVMS, and I will try to run them off for you this
> week. I assume a direct E-mail other than posting them to the mailing
> lists again?
>
> I was under the impression that the CVS snapshot that I was downloading
> is from the HEAD stream, but I really do not know.

See pserver.samba.org for info on CVS branchs. Small diffs are normally
fine on the list, particuarly in the more readable diff -u format, but
should also be sent to the automated system at samba-***@samba.org,
where they can be reviewed at a later date.

Andrew Bartlett

--
Andrew Bartlett
***@pcug.org.au
***@samba.org

[Christopher R. Hertel]

> > NMBD_NAMEQUERY.C

Hmmm... You are right that the answer_ip is not being set.

It's a local variable that *was* only being used in the case of the
initial positive name query response. It was not being set if the
response was negative, or if the response was "extra". I added the debug
stuff to see what information was being returned in the "extra" responses.

My fix is to add the assignment of answer_ip within the multiple responses
debug block as follows:

if( DEBUGLVL( 0 ) )
{
putip( (char *)&answer_ip, &nmb->answers->rdata[2] );
dbgtext( "query_name_response: " );
dbgtext( "Multiple (%d) responses ", rrec->num_msgs );
:
:

I'll check this into HEAD now.

Note that the only problem caused by not initializing this value would be
a garbage IP in that particular debug message. (That is, no showstopper.)
(Still, I'm quite embarrassed.)

Chris -)-----

===================================================================
RCS file: /data/cvs/samba/source/nmbd/nmbd_namequery.c,v
retrieving revision 1.11
diff -r1.11 nmbd_namequery.c
105a106
> putip( (char *)&answer_ip, &nmb->answers->rdata[2] );

[John E. Malmberg]

On Tue, 10 Jul 2001, Christopher R. Hertel wrote:

>
> I'll check this into HEAD now.
>
> Note that the only problem caused by not initializing this value would be
> a garbage IP in that particular debug message. (That is, no showstopper.)
> (Still, I'm quite embarrassed.)

True it is not a showstopper, but I have a high warning level set, and
this stops the build from running for me.

You might be interested in seeing the full build log, and see the things
that the compiler is indicating is code that is legal, but may not be
advisable. Things like doing signed compares on unsigned values and
such.

-John
***@qsl.network
Personal Opinion Only

[Andrew Bartlett]

"John E. Malmberg" wrote:
>
> On Tue, 10 Jul 2001, Christopher R. Hertel wrote:
>
> >
> > I'll check this into HEAD now.
> >
> > Note that the only problem caused by not initializing this value would be
> > a garbage IP in that particular debug message. (That is, no showstopper.)
> > (Still, I'm quite embarrassed.)
>
> True it is not a showstopper, but I have a high warning level set, and
> this stops the build from running for me.
>
> You might be interested in seeing the full build log, and see the things
> that the compiler is indicating is code that is legal, but may not be
> advisable. Things like doing signed compares on unsigned values and
> such.

You might be interested in the Samba build farm, http://build.samba.org
where we have an incresing number of machines regularly compiling samba
for exactly this kind of reason.

We also do some automated testing to check we are getting it right :-)

We are always looking for new machines, particuarly for arch/compiler
combinations we don't already.

Andrew Bartlett
Samba Build Farm Maintainer

--
Andrew Bartlett
***@pcug.org.au
***@samba.org

[John E. Malmberg]

On Tue, 10 Jul 2001, Michael Sweet wrote:

> "John E. Malmberg" wrote:
> > ...
> The volatile keyword was added to allow the compiler to make
> optimizations that assume that temporary results of pointer
> dereferencing won't change when the pointer is passed to another
> function, or that two pointer variables might be pointing at the
> same general area of memory (e.g., an implementation of strcpy...)

I believe that your interpretation of that statement is not correct.
The presence of the volatile qualifier allows the compiler to make
assumptions on optimizations on variables that *DO NOT* have
the volatile qualifier.

The volatile qualifer does a spot disabling of optimization for a
specific memory location, allowing the compiler to more aggressively
optimize the rest of the code.

Compilers that do not support the volatile keyword may need to have
some of their optimization disabled when accessing a shared memory
location.


For a clearer reference:

http://www.openvms.compaq.com/commercial/c/6180p008.htm#index_x_241

"The volatile qualifier forces the compiler to allocate memory for the
volatile object, and to always access the object from memory.
This qualifier is often used to declare that an object can be
accessed in some way not under the compiler's control.
Therefore, an object qualified by the volatile keyword can be modified
and or accessed in ways by other processes or hardware, and is
especially vulnerable to side effects."

This tends to contradict much of what you wrote.

> > This would be in any case where the same physical memory location can be
> > referenced by multiple threads or processes. Failure to do so can result
> > in the compiler missing a change to the value.

> The volatile keyword isn't really meant for that; MP issues extend
> well beyond C, which is why you usually use OS mechanisms for
> semaphores, message queues, etc. All volatile really buys you in
> this case is a mechanism for correctly (not) caching shared global
> variables.

volatile is required for that. The compiler does not have any other
way to know that the memory area in question may have changed.

The semaphores and message queues are needed so that the program knows
that the value has changed, but with out the volatile keyword, the
compiler could present an incorrect prior snapshot of the memory location.
(Unless optimisations are turned off)

In the case of two pointer variables referencing the same general area
of memory, and one of the pointer variables is in an external module that
the compiler does not know about, it is the memory location that is
volatile, not the pointer. The address in the pointer variable is not
going to change with out the compilers's knowlege, and should not in this
case marked volatile.

-John
***@qsl.network
Personal Opinion Only

[John E. Malmberg]

On Wed, 11 Jul 2001, Andrew Bartlett wrote:

> > You might be interested in seeing the full build log, and see the things
> > that the compiler is indicating is code that is legal, but may not be
> > advisable. Things like doing signed compares on unsigned values and
> > such.
>
> You might be interested in the Samba build farm, http://build.samba.org
> where we have an incresing number of machines regularly compiling samba
> for exactly this kind of reason.

Netscape V 3.0.3 is currently displaying what appears to be complete
garbage when I attempt to access the page, even when I tell it to view
source.

It does appear to work from I.E. though.

At the present time my build systems are internet impaired :-(

-John
***@qsl.network
Personal Opinion Only

[Christopher R. Hertel]

<!-- gzip encoded --!>

Huh?

The page works fine when I retrieve it using Netscape (4.7 for SGI), but I
do get the above as the first line. I do not believe that it is a proper
HTML comment, either. the end of the comment should be "-->" not "--!>".

I tried grabbing the page using Lynx had, again, had no problem though I
do have gzip installed and it is possible that the page mime type is
being recognized and the page decoded, but I don't think so.

Hmmm.....

Chris -)-----

> On Wed, 11 Jul 2001, Andrew Bartlett wrote:
>
> > > You might be interested in seeing the full build log, and see the things
> > > that the compiler is indicating is code that is legal, but may not be
> > > advisable. Things like doing signed compares on unsigned values and
> > > such.
> >
> > You might be interested in the Samba build farm, http://build.samba.org
> > where we have an incresing number of machines regularly compiling samba
> > for exactly this kind of reason.
>
> Netscape V 3.0.3 is currently displaying what appears to be complete
> garbage when I attempt to access the page, even when I tell it to view
> source.
>
> It does appear to work from I.E. though.
>
> At the present time my build systems are internet impaired :-(
>
> -John
> ***@qsl.network
> Personal Opinion Only
>
>


--
Christopher R. Hertel -)----- University of Minnesota
***@nts.umn.edu Networking and Telecommunications Services

Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz

[John E. Malmberg]

http://pserver.samba.org/cgi-bin/cvsweb/ does not work on Netscape 3.0.3
It just displays a few random characters.

Because of my internet impairment, I basically need to download
tarballs to tape, and then let the my local system sort out what has
changed.

For the tarballs, I am currently dependant on the incanta.net/~miker/
archive. And I frequently am getting server unavailable messages from it.

-John
***@qsl.network
Personal Opinion Only

On Wed, 11 Jul 2001, Andrew Bartlett wrote:

>
> See pserver.samba.org for info on CVS branchs. Small diffs are normally
> fine on the list, particuarly in the more readable diff -u format, but
> should also be sent to the automated system at samba-***@samba.org,
> where they can be reviewed at a later date.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> ***@pcug.org.au
> ***@samba.org
>

[Andrew Bartlett]

"John E. Malmberg" wrote:
>
> http://pserver.samba.org/cgi-bin/cvsweb/ does not work on Netscape 3.0.3
> It just displays a few random characters.

Its the gzip encoding. The files are gzip encoded to save bandwidth
(becouse they are both large and compress well), and your older browser
doesn't understand it. Upgrade your browser.

Andrew Bartlett

--
Andrew Bartlett
***@pcug.org.au
***@samba.org

[John E. Malmberg]

What am I really trying to fix? I have an ino_t that is larger than the
maximum supported scaler integer type that can be handled on one of my
build platforms.

Unfortunately back when C compilers where just becoming popular,
the implementation of the stat() function was defined on VMS to be
slightly incompatable with UNIX.

The problem is that the ino_t type on OpenVMS is

"unsigned short st_ino[3]"

This basically breaks building any UNIX program that uses the ino_t
datatype on OpenVMS.

This basically requires that all asignment or comparisons of the ino_t
type data be done through memcpy() or memcmp(). Use of these routines
is overkill for the other platforms, and while macros could be used like
ino_t_cpy() and ino_t_cmp(), it may be overkill for other systems.


I have requested that this be fixed in OpenVMS, but I do not know if and
when it would be done, and that would be in a future release, which does
not help me now. It would also likely only be fixed on the 64 bit
platforms, and not the 32 bit VAX platform. And there seems to be a lot
of OpenVMS VAX systems running SAMBA, to judge form the E-mails I have
received.

The Compaq C compiler for OpenVMS VAX can not deal with an integer data
type larger than 32 bits. It must be represented as an array or a
structure.

And apparently nothing in The Open Group's official "Single Unix Standard"
actually states the the ino_t must be a scaler, so it can not be flaged as
a compliance bug.

So as a work around, I defined a structure that maps the smb_ino_t to the
first 32 bytes of the OpenVMS "st_ino". Based on what SAMBA is doing, and
the documented structure of the OpenVMS inode, this is good enough to get
by on. The best solution for me would be to use the macros I mentioned
above.


When SAMBA was changed to use SMB_STRUCT_STAT, it removed the reason for
several #ifdef __VMS hacks in the VMS specific port. It was a big help!


I have SMB_STRUCT_STAT defined to the name of that new structure.
#define SMB_STRUCT_STAT fport__stat_st

I also have

#define stat(a, b) fport__stat(a, (fport__stat_st *) b)

That catches those modules in SAMBA that should use SMB_STRUCT_STAT but
do not. Unfortunately that trick is broken with the VFS structure, as
there is again a namespace collision.

The problem is that the function stat() and the struct stat have the same
name, so I can not just use #define to get around this.

There may be another way to work around this, but even if a
#define TDB_STRUCT_STAT could be used, it would help me.

I really would prefer to use the method of wrapping the macros around the
references to the references of the data of type ino_t, and then having
config.h cause those macros to default to the UNIX code. I was not sure
that radical of a patch would be accepted though. It would also require
more maintenance, as a UNIX programmer would not see the need for the
macros when making a change.

-John
Personal Opinion Only
***@qsl.network


On Tue, 10 Jul 2001, Jeremy Allison wrote:

> "John E. Malmberg" wrote:
>
> > TDB.C
> >
> > OpenVMS needs the SMB_STRUCT_STAT to be used instead of struct stat on any
> > module that references st_ino. On OpenVMS st_ino in struct stat is
> > unsigned short[3].
> >
> > TDB_C.DIFF
> > ************
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> > 233 /* struct stat st; */
> > 234 SMB_STRUCT_STAT st;
> > 235 if (len <= tdb->map_size) return 0;
> > ******
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> > 233 struct stat st;
> > 234 if (len <= tdb->map_size) return 0;
> > ************
> > ************
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> > 1258 /* struct stat st; */
> > 1259 SMB_STRUCT_STAT st;
> > 1260 int rev = 0, locked;
> > ******
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> > 1257 struct stat st;
> > 1258 int rev = 0, locked;
> > ************
>
> I don't understand why this fix is needed.
>
> st_ino in the tdb code is simply assigned between
> a tdb struct from the stat struct. Why does this fail
> for any data type ?
>
> We don't want to add Samba dependencies into tdb as it
> is independent of the Samba code (it's hosted on sourceforge).
>
> Can you explain what you're trying to fix please ?
>
> Thanks,
>
> Jeremy.
>
> --
> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------
>

[Malcolm Beattie]

John E. Malmberg writes:
> What am I really trying to fix? I have an ino_t that is larger than the
> maximum supported scaler integer type that can be handled on one of my
> build platforms.
[...]
> The problem is that the ino_t type on OpenVMS is
>
> "unsigned short st_ino[3]"
>
> This basically breaks building any UNIX program that uses the ino_t
> datatype on OpenVMS.
[...]
> And apparently nothing in The Open Group's official "Single Unix Standard"
> actually states the the ino_t must be a scaler, so it can not be flaged as
> a compliance bug.

SUSv2 (Single UNIX Specification Version 2) specifies as follows:

SYNOPSIS

#include <sys/types.h>

DESCRIPTION

The <sys/types.h> header includes definitions for at least the
following types:
[...]
ino_t Used for file serial numbers.
[...]
All of the types are defined as arithmetic types of an appropriate
length, with the following exceptions: key_t, pthread_attr_t,
pthread_cond_t, pthread_condattr_t, pthread_key_t,
pthread_mutex_t, pthread_mutexattr_t, pthread_once_t,
pthread_rwlock_t and pthread_rwlockattr_t. Additionally, blkcnt_t
and off_t are extended signed integral types, fsblkcnt_t,
fsfilcnt_t and ino_t are defined as extended unsigned integral
types

See
http://www.opengroup.org/onlinepubs/7908799/xsh/systypes.h.html

So if they're trying to keep up with SUSv2, you could try to beat
them into compliance after all.

--Malcolm

--
Malcolm Beattie <***@sable.ox.ac.uk> <-- This email address will break
Unix Systems Programmer when I quit OUCS on Jul 20th. Send
Oxford University Computing Services private mail to ***@clueful.co.uk
I'll sort out my IBM email address soon.

[John E. Malmberg]

On Wed, 11 Jul 2001, Andrew Bartlett wrote:

> "John E. Malmberg" wrote:
> >
> > http://pserver.samba.org/cgi-bin/cvsweb/ does not work on Netscape 3.0.3
> > It just displays a few random characters.
>
> Its the gzip encoding. The files are gzip encoded to save bandwidth
> (becouse they are both large and compress well), and your older browser
> doesn't understand it. Upgrade your browser.

Is there some way to detect that a browser can not handle the gzip
encoding so that at the minimum, a proper error page can be displayed?

I would like to upgrade my browser, unfortunately the release date of
Mozilla seems to have slipped by a few years.

The 4.x release of Navigator was not ported to OpenVMS, as it was expected
that Mozilla's would be following it very quickly.

I have not yet tried the beta Mozilla release(s).

-John
***@qsl.network
Personal Opinion Only

[Cole, Timothy D.]

> -----Original Message-----
> From: John E. Malmberg [SMTP:***@Encompasserve.org]
> Sent: Wednesday, July 11, 2001 9:24
> To: samba-***@samba.org
> Subject: Re: Accessing CVS-WEB?
>
> On Wed, 11 Jul 2001, Andrew Bartlett wrote:
>
> > "John E. Malmberg" wrote:
> > >
> > > http://pserver.samba.org/cgi-bin/cvsweb/ does not work on Netscape
> 3.0.3
> > > It just displays a few random characters.
> >
> > Its the gzip encoding. The files are gzip encoded to save bandwidth
> > (becouse they are both large and compress well), and your older browser
> > doesn't understand it. Upgrade your browser.
>
> Is there some way to detect that a browser can not handle the gzip
> encoding so that at the minimum, a proper error page can be displayed?
>
The browser sends an Accept-encoding: header in the request
indicating which encodings it will accept (if I recall).

[Gerald Carter]

On Wed, 11 Jul 2001, Mike Black wrote:

> Mine behaves differently
>
> Original file (NT4):
> Created: Monday, July 17, 2000 12:01:53 PM
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Monday, July 17, 2000 12:01:53 PM
>
> Copy to local (NT4):
> Created: Wednesday, July 11, 2001 8:49:05 AM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Monday, July 17, 2000 12:01:53 PM
>
> Copy to samba-2.0.7 (Linux)
> Created: Monday, July 17, 2000 12:01:53 PM
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Wednesday, July 11, 2001 8:50:42 AM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Copy to samba-2.2.1 (Linux)
> Created: Monday, July 17, 2000 12:01:53 PM
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Monday, July 17, 2000 12:01:53 PM
>
> This is the bug I reported -- ALL the date/times on samba-2.2.1 are
> being set to the current date/time because of the cache flush
> occurring AFTER the setftime routine. Maybe Solaris behaves
> differently on the cache flush?

I am thoroughly confused now, because the mtime/actime for the 2.2.1
copy are the same as the original file on NT4. It looks like 2.0.7
was messed up. And why did NT reset the creation date on the local
copy?






jerry
---------------------------------------------------------------------
http://www.valinux.com/ VA Linux Systems ***@valinux.com
http://www.samba.org/ SAMBA Team ***@samba.org
http://www.plainjoe.org/ ***@plainjoe.org
--"I never saved anything for the swim back." Ethan Hawk in Gattaca--

[Mike Black]

OK -- I repeated this and am using a file with an easier-to-spot date.
Also -- my testing before involved an NFS mount so I removed that variable.

Original
Created Thursday, November 19, 1998 12:47:48 AM
Modified Thursday, November 19, 1998 12:47:48 AM
Accessed Thursday, November 19, 1998 12:47:48 AM

Copy to local (NT4) (Move behaves the same too)

Created Thursday, July 12, 2001 5:34:31 AM
Modified Thursday, November 19, 1998 12:47:48 AM
Accessed Thursday, July 12, 2001 5:34:31 AM

Copy to share (NT4)

Created Thursday, July 12, 2001 5:35:47 AM
Modified Thursday, November 19, 1998 12:47:48 AM
Accessed Thursday, July 12, 2001 5:35:47 AM

Copy to share (Win2000)

Created Thursday, July 12, 2001 5:40:08 AM
Modified Thursday, November 19, 1998 12:47:48 AM
Accessed Thursday, July 12, 2001 5:40:08 AM

Copy to samba-2.0.7 (Linux)

Created Thursday, November 19, 1998 12:47:48 AM
Modified Thursday, November 19, 1998 12:47:48 AM
Accessed Thursday, July 12, 2001 5:41:30 AM
stat() results on file:
Change: Thu Jul 12 05:43:30 2001
Modify: Thu Nov 19 00:47:49 1998
Access: Thu Nov 19 00:47:49 1998

Copy to samba-2.2.1 (Linux)

Created Thursday, November 19, 1998 12:47:48 AM
Modified Thursday, November 19, 1998 12:47:48 AM
Accessed Thursday, November 19, 1998 12:47:48 AM
stat() results on file:
Change: Thu Jul 12 05:45:48 2001
Modify: Thu Nov 19 00:47:49 1998
Access: Thu Nov 19 00:47:49 1998


Looks like my original bug (21369) may have been addressed but now this is a
new one.
But showing all 3 as oldest date will screw up lots of things (like Source
Integrity -- RCS)
.
All the NT boxes behave the same -- Samba is deviant from NT.
I never had any problems with the old 2.0.7 behavior but I do see problems
with the
new behavior.
________________________________________
Michael D. Black Principal Engineer
***@csihq.com 321-676-2923,x203
http://www.csihq.com Computer Science Innovations
http://www.csihq.com/~mike My home page
FAX [phone]
----- Original Message -----
From: "Gerald Carter" <***@valinux.com>
To: "Mike Black" <***@csihq.com>
Cc: "Jeremy Allison" <***@valinux.com>; "scott"
<samba-***@ml.slittle.com>; <samba-***@lists.samba.org>;
<samba-***@samba.org>; <***@samba.org>
Sent: Wednesday, July 11, 2001 1:33 PM
Subject: Re: Samba 2.2.1 released.


On Wed, 11 Jul 2001, Mike Black wrote:

> Mine behaves differently
>
> Original file (NT4):
> Created: Monday, July 17, 2000 12:01:53 PM
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Monday, July 17, 2000 12:01:53 PM
>
> Copy to local (NT4):
> Created: Wednesday, July 11, 2001 8:49:05 AM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Monday, July 17, 2000 12:01:53 PM
>
> Copy to samba-2.0.7 (Linux)
> Created: Monday, July 17, 2000 12:01:53 PM
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Wednesday, July 11, 2001 8:50:42 AM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Copy to samba-2.2.1 (Linux)
> Created: Monday, July 17, 2000 12:01:53 PM
> Modified: Monday, July 17, 2000 12:01:53 PM
> Accessed: Monday, July 17, 2000 12:01:53 PM
>
> This is the bug I reported -- ALL the date/times on samba-2.2.1 are
> being set to the current date/time because of the cache flush
> occurring AFTER the setftime routine. Maybe Solaris behaves
> differently on the cache flush?

I am thoroughly confused now, because the mtime/actime for the 2.2.1
copy are the same as the original file on NT4. It looks like 2.0.7
was messed up. And why did NT reset the creation date on the local
copy?






jerry
---------------------------------------------------------------------
http://www.valinux.com/ VA Linux Systems ***@valinux.com
http://www.samba.org/ SAMBA Team ***@samba.org
http://www.plainjoe.org/ ***@plainjoe.org
--"I never saved anything for the swim back." Ethan Hawk in Gattaca--

[Christopher R. Hertel]

Andrew Bartlett wrote:
:
> Its the gzip encoding. The files are gzip encoded to save bandwidth
> (becouse they are both large and compress well), and your older browser
> doesn't understand it. Upgrade your browser.

Um...

Can you show me where in the W3C specs it says that gzip encoding is part
of the standard? It may be there, as the W3C validator can read the page
(though it does cough up an error message...missing ALT tag).

If it's part of the standard then upgrading the browser is, unfortunately,
the correct answer (and you can skip the rest of this message).

If not, then requiring gzip is no better than letting Microsoft generate
unfriendly Javascript web pages and expect users to "upgrade" to Internet
Explorer with all the dummy switches turned on just to see the content.

Sorry, but the "your browser isn't good enough for our web page" thing
gets on my nerves. I'm annoyed by Microsoft's successful takeover of the
web and I don't want to be guilty of the same bad behavior that got them
there.

Chris -)-----

--
Christopher R. Hertel -)----- University of Minnesota
***@nts.umn.edu Networking and Telecommunications Services

Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz

[Michael Sweet]

"Christopher R. Hertel" wrote:
>
> Andrew Bartlett wrote:
> :
> > Its the gzip encoding. The files are gzip encoded to save bandwidth
> > (becouse they are both large and compress well), and your older browser
> > doesn't understand it. Upgrade your browser.
>
> Um...
>
> Can you show me where in the W3C specs it says that gzip encoding is part
> of the standard? It may be there, as the W3C validator can read the page
> (though it does cough up an error message...missing ALT tag).

Wrong standard - the gzip stuff is part of the HTTP standard.
Specifically,
the client supplies an "Accept-Encoding" field with "gzip" (along with
any other encodings it can handle), and the server responds using
whatever
encoding is appropriate, specified in the "Content-Encoding" field.

That said, the CVS-web interface should be checking this field before
assuming that the browser supports gzip...

--
______________________________________________________________________
Michael Sweet, Easy Software Products ***@easysw.com
Printing Software for UNIX http://www.easysw.com

[Christopher R. Hertel]

> > Can you show me where in the W3C specs it says that gzip encoding is part
> > of the standard? It may be there, as the W3C validator can read the page
> > (though it does cough up an error message...missing ALT tag).
>
> Wrong standard - the gzip stuff is part of the HTTP standard.
> Specifically, the client supplies an "Accept-Encoding" field with
> "gzip" (along with any other encodings it can handle), and the server
> responds using whatever encoding is appropriate, specified in the
> "Content-Encoding" field.

Thanks!

Do you know if this is specific to HTTP 1.1 and later or should this work
with a 1.0 browser? I have no idea if John's browser is 1.0, I'm just
curious.

> That said, the CVS-web interface should be checking this field before
> assuming that the browser supports gzip...

Yep!

Thanks again!

Chris -)-----

--
Christopher R. Hertel -)----- University of Minnesota
***@nts.umn.edu Networking and Telecommunications Services

Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz

[Michael Sweet]

"Christopher R. Hertel" wrote:
>
> > > Can you show me where in the W3C specs it says that gzip encoding is part
> > > of the standard? It may be there, as the W3C validator can read the page
> > > (though it does cough up an error message...missing ALT tag).
> >
> > Wrong standard - the gzip stuff is part of the HTTP standard.
> > Specifically, the client supplies an "Accept-Encoding" field with
> > "gzip" (along with any other encodings it can handle), and the server
> > responds using whatever encoding is appropriate, specified in the
> > "Content-Encoding" field.
>
> Thanks!
>
> Do you know if this is specific to HTTP 1.1 and later or should this work
> with a 1.0 browser? I have no idea if John's browser is 1.0, I'm just
> curious.

IIRC Accept/Content-Encoding were part of 1.0, but gzip wasn't
recognized by the IETF until later and wasn't listed as part of the
1.0 spec.

--
______________________________________________________________________
Michael Sweet, Easy Software Products ***@easysw.com
Printing Software for UNIX http://www.easysw.com

[David Brodbeck]

NCSA Mosaic had support for gzip encoding years ago, if I remember
correctly. It's a nice way to save bandwidth and I'm glad to see that other
browsers have finally come around to supporting it! "Traditional"
restrictions have a nasty way of fostering inefficiency. (Witness how long
it's taking for anyone to switch from GIF to PNG, for example.)

-----Original Message-----
From: Christopher R. Hertel [mailto:***@nts.umn.edu]
Sent: Wednesday, July 11, 2001 1:41 PM
To: Andrew Bartlett
Cc: John E. Malmberg; samba-***@samba.org
Subject: Re: Accessing CVS-WEB?


Andrew Bartlett wrote:
:
> Its the gzip encoding. The files are gzip encoded to save bandwidth
> (becouse they are both large and compress well), and your older browser
> doesn't understand it. Upgrade your browser.

Um...

Can you show me where in the W3C specs it says that gzip encoding is part
of the standard? It may be there, as the W3C validator can read the page
(though it does cough up an error message...missing ALT tag).

If it's part of the standard then upgrading the browser is, unfortunately,
the correct answer (and you can skip the rest of this message).

If not, then requiring gzip is no better than letting Microsoft generate
unfriendly Javascript web pages and expect users to "upgrade" to Internet
Explorer with all the dummy switches turned on just to see the content.

Sorry, but the "your browser isn't good enough for our web page" thing
gets on my nerves. I'm annoyed by Microsoft's successful takeover of the
web and I don't want to be guilty of the same bad behavior that got them
there.

Chris -)-----

--
Christopher R. Hertel -)----- University of Minnesota
***@nts.umn.edu Networking and Telecommunications Services

Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz

[Mayers, Philip J]

...The (almost defensible) difference here being that the *server* operator
pays for the bandwidth as well as the client, and gzipping everything makes
your hosting cost come down - which is significant for free software
projects.

Regards,
Phil

+----------------------------------+
| Phil Mayers, Network Support |
| Centre for Computing Services |
| Imperial College |
+----------------------------------+


-----Original Message-----

<snip>

Sorry, but the "your browser isn't good enough for our web page" thing
gets on my nerves. I'm annoyed by Microsoft's successful takeover of the
web and I don't want to be guilty of the same bad behavior that got them
there.

Chris -)-----

[Christopher R. Hertel]

> ...The (almost defensible) difference here being that the *server* operator
> pays for the bandwidth as well as the client, and gzipping everything makes
> your hosting cost come down - which is significant for free software
> projects.

I agree with that aspect. I think I explained where my hot button was.

Thanks.

Chris -)-----

--
Christopher R. Hertel -)----- University of Minnesota
***@nts.umn.edu Networking and Telecommunications Services

Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz

[John E. Malmberg]

Maintainers of web sites, particulaly government funded ones in the
USA, may want to pay attention to news reports about an ADA
(American's with Disabilities Act) related lawsuit.

I do not have the details, and so I do not know the full impact, but
the sumary is that it appears that a suit was won against a government
agency because their web site was not accessable to the only browser
that the disabled persons that were party to the suit could use.

I would not be surprised to hear of more lawsuits, as it has been
alleged that filing ADA lawsuits is more profitable than ambulance
chasing, as the chances of winning is very high.

I am not a lawyer, and I do not think I am in an ADA protected class,
so I can not get in on the gravy train though. :-)

While right now, it is just nice practice to have your web site be
functional with "obsolete" browsers, in the U.S.A, there is a good chance
that it will effectively have the force of law.

Please note that I am not expressing an opinion about the ADA law, just
pointing out one of it's unexpected site effects.

This may or may not ever affect the SAMBA web sites, or even the
U.S.A mirrors. But it never hurts to be considerate.


-John
***@qsl.network
Personal Opinion Only

On Wed, 11 Jul 2001, Christopher R. Hertel wrote:

>
> Thanks!
>
> Do you know if this is specific to HTTP 1.1 and later or should this work
> with a 1.0 browser? I have no idea if John's browser is 1.0, I'm just
> curious.

I am running Netscape Navigator V 3.03 mumble - gold.
I have no idea what http versions it is compatable with.

> > That said, the CVS-web interface should be checking this field before
> > assuming that the browser supports gzip...
>
> Yep!
>
> Thanks again!
>
> Chris -)-----

[Christopher R. Hertel]

>
> Maintainers of web sites, particulaly government funded ones in the
> USA, may want to pay attention to news reports about an ADA
> (American's with Disabilities Act) related lawsuit.

Hurrah!

(This from someone who just spent forever filling out a form on a TI web
page which could not then be submitted because the SUBMIT button on the
stupid .asp page was Javascrapt-only. That's just plain dumb.)

> This may or may not ever affect the SAMBA web sites, or even the
> U.S.A mirrors. But it never hurts to be considerate.

Ten points, John.

Chris -)-----

--
Christopher R. Hertel -)----- University of Minnesota
***@nts.umn.edu Networking and Telecommunications Services

Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz

[John E. Malmberg]

On Wed, 11 Jul 2001, Malcolm Beattie wrote:

> John E. Malmberg writes:
> > What am I really trying to fix? I have an ino_t that is larger than the
> > maximum supported scaler integer type that can be handled on one of my
> > build platforms.
> [...]
> > The problem is that the ino_t type on OpenVMS is
> >
> > "unsigned short st_ino[3]"
> >
> > This basically breaks building any UNIX program that uses the ino_t
> > datatype on OpenVMS.
> [...]
> > And apparently nothing in The Open Group's official "Single Unix Standard"
> > actually states the the ino_t must be a scaler, so it can not be flaged as
> > a compliance bug.
>
> SUSv2 (Single UNIX Specification Version 2) specifies as follows:
>
Thankyou, this reference may help for in the future.

Do you happen to know if POSIX says anything also?

I still need to be able to deal with the VAX platform where it is not
possible to represent the ino_t in the largest integer type that the
compiler supports.

-John
***@qsl.network.

> See
> http://www.opengroup.org/onlinepubs/7908799/xsh/systypes.h.html
>
> So if they're trying to keep up with SUSv2, you could try to beat
> them into compliance after all.

I am not sure exactly what their goals are in that regard. Some of it
depends on how many more important things are in the queue.

Code that messes around with inodes can not be that common.

-John
***@qsl.network

[Malcolm Beattie]

John E. Malmberg writes:
>
> On Wed, 11 Jul 2001, Malcolm Beattie wrote:
>
> > John E. Malmberg writes:
> > > What am I really trying to fix? I have an ino_t that is larger than the
> > > maximum supported scaler integer type that can be handled on one of my
> > > build platforms.
> > [...]
> > > The problem is that the ino_t type on OpenVMS is
> > >
> > > "unsigned short st_ino[3]"
> > >
> > > This basically breaks building any UNIX program that uses the ino_t
> > > datatype on OpenVMS.
> > [...]
> > > And apparently nothing in The Open Group's official "Single Unix Standard"
> > > actually states the the ino_t must be a scaler, so it can not be flaged as
> > > a compliance bug.
> >
> > SUSv2 (Single UNIX Specification Version 2) specifies as follows:
> >
> Thankyou, this reference may help for in the future.
>
> Do you happen to know if POSIX says anything also?

I've just looked and Section 2.6 "Primitive System Data Types" includes

Table 2-1. Primitive System Data Types

Defined Type Description
------------ ----------------------------------------------
...
ino_t Used for file serial numbers.
...

All of the types listed in Table 2-1 shall be arithmetic types


That pretty much leaves them without a leg to stand on.
Note that "arithmetic type" is an ANSI/ISO-C-ism defined in 6.1.2.5
(ANSI numbering) which means exactly what you'd expect it to mean so
they can't weasel out by claiming an array of three shorts is an
arithmetic type.

--Malcolm

--
Malcolm Beattie <***@sable.ox.ac.uk> <-- This email address will break
Unix Systems Programmer when I quit OUCS on Jul 20th. Send
Oxford University Computing Services private mail to ***@clueful.co.uk
I'll sort out my IBM email address soon.

[Urban Widmark]

On Wed, 11 Jul 2001, John E. Malmberg wrote:

> This may or may not ever affect the SAMBA web sites, or even the
> U.S.A mirrors. But it never hurts to be considerate.

Supporting buggy clients sometimes hurts.


Contrary to what have been suggested in this thread, cvsweb/apache does
not require a browser that supports gzip. The MSIE-only comparisons are a
bit much, IMHO.

It does require a browser that does not ask for something it cannot
handle, such as asking for gzip encoding and then choke when that is
returned. I suspect that is part of the protocol.

A tcpdump could be done to show what is actually sent and received, and
then compared to what it does for pages it can read. Sort of offtopic, but
perhaps not on some apache list.

Try telnet to port 80 on pserver.samba.org to see that it does return
nice non-gzip'ed data when not asked otherwise:
GET /cgi-bin/cvsweb/ HTTP/1.0
Host: pserver.samba.org

^ end with a blank line

I don't know the exact URL that it fails on for you (you only said
/cgi-bin/cvsweb/) so perhaps this test is flawed. But it looks to me like
the bug lies in the client.


Throw away that old piece of proprietary software ... mozilla 0.9.2 is
useable and, above all, fixable.

/Urban

[Mike Fedyk]

On Fri, Jul 13, 2001 at 07:24:02AM -0400, Mike Black wrote:
> Copy to samba-2.0.7 (Linux)
>
> Created Thursday, November 19, 1998 12:47:48 AM
> Modified Thursday, November 19, 1998 12:47:48 AM
> Accessed Thursday, July 12, 2001 5:41:30 AM
> stat() results on file:
> Change: Thu Jul 12 05:43:30 2001
> Modify: Thu Nov 19 00:47:49 1998
> Access: Thu Nov 19 00:47:49 1998
>
> Copy to samba-2.2.1 (Linux)
>
> Created Thursday, November 19, 1998 12:47:48 AM
> Modified Thursday, November 19, 1998 12:47:48 AM
> Accessed Thursday, November 19, 1998 12:47:48 AM
> stat() results on file:
> Change: Thu Jul 12 05:45:48 2001
> Modify: Thu Nov 19 00:47:49 1998
> Access: Thu Nov 19 00:47:49 1998
>
>
> Looks like my original bug (21369) may have been addressed but now this is a
> new one.
> But showing all 3 as oldest date will screw up lots of things (like Source
> Integrity -- RCS)
> .
> All the NT boxes behave the same -- Samba is deviant from NT.
> I never had any problems with the old 2.0.7 behavior but I do see problems
> with the
> new behavior.

Why does RCS use the accessed time? Shouldn't it just use the
modified time?

This is deviating from NT, and may cause trouble with other software,
depending on what it expects.

Does anyone know why this was changed?