On redhat 8.0, I compiled samba 2.2.7.
With gcc-2.96 the -g unstripped binaries are about 15% the size of
gcc 3.2...
I've seen this before...can someone explain this?
I'm not sure this is a samba problem or a gcc problem (I've only
seen this extreme behavior with samba).
Marty Leisner
[EMAIL P
On Fri, 2002-12-20 at 15:12, Steve Langasek wrote:
> One additional bit of information --
I'm running the a21 that you sent me that deb patches for.
It's not in heavy usage but I have not seen any problems with printing
after i added the directory that the tdb's needed to be in.
I'm using spoolss
Steve Langasek wrote:
One additional bit of information --
On Fri, Dec 20, 2002 at 09:56:21AM -0600, Steve Langasek wrote:
As WinXP begins to loom larger in our environment, we're seeing a
consistent pattern that XP machines (mostly XP Professional, possibly
others) take an excessively long ti
One additional bit of information --
On Fri, Dec 20, 2002 at 09:56:21AM -0600, Steve Langasek wrote:
> As WinXP begins to loom larger in our environment, we're seeing a
> consistent pattern that XP machines (mostly XP Professional, possibly
> others) take an excessively long time to access share
The following code appears in source/params/loadparm.c from 3.0alpha21:
#ifdef WITH_LDAP_SAMCONFIG
string_set(&Globals.szLdapServer, "localhost");
Globals.ldap_port = 636;
Globals.szPassdbBackend = str_list_make("ldapsam unixsam", NULL);
#else
Globals.szPassdbBacken
Hi all,
As WinXP begins to loom larger in our environment, we're seeing a
consistent pattern that XP machines (mostly XP Professional, possibly
others) take an excessively long time to access shared printers: I'm
told that it takes up to 5 minutes to initially install the printer on
the local mac
John E. Malmberg [mailto:[EMAIL PROTECTED]] wrote:
> Samba makes calls on behalf of the client to return a file size.
Samba also makes POSIX stat() calls on its own behalf, only some of which
actually care about the file size (some of them are checking access, for
example).
> The problem for this
