[SCM] Samba Shared Repository - branch master updated -

[Jeremy Allison]

The branch, master has been updated
via ac6c003078aebee90dc5fdcd135fd13be358bab7 (commit)
from 9ccd1174f75276b0533b5bbb0765df8fc1e2912d (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
- Log -----------------------------------------------------------------
commit ac6c003078aebee90dc5fdcd135fd13be358bab7
Date: Tue Dec 2 10:26:42 2008 +0100
configure.in: Fix smbtorture_s3 tests.
Seems like Jeremy forgot to fix configure.in when importing d448132 to master
in 8d674e35. Generate the vfs_streams_depot module so make test works again.

Thanks for catching this. It wasn't in the patchset that Metze
generated so it wasn't a matter of forgetting :-). I assumed
there was a mismatch between code in s3 and master so was waiting
for that to clear up. I'd have caught that one today :-). But
thanks for the fix !

Jeremy.

[Jeremy Allison]

The branch, master has been updated
commit 738271fc2026b2911b7d20a73496989641714df3
Date: Sat Nov 8 16:14:12 2008 +0100
Remove the variable "size" from reply_nttrans
This converts the range checks for the setup[] array to rely on req->wct being
set correctly in init_smb_request. As that already verifies the vwv array to be
in the range of the smb_request inbuf, we don't have to do overflow checks here
anymore.
Jeremy, please check thoroughly! :-)

Checked. Actually, I think this is redundent due to
the code above in reply_nttrans()

/*
* All nttrans messages we handle have smb_wct == 19 +
* state->setup_count. Ensure this is so as a sanity check.
*/

if(req->wct != 19 + (state->setup_count/2)) {
DEBUG(2,("Invalid smb_wct %d in nttrans call (should be %d)\n",
req->wct, 19 + (state->setup_count/2)));
goto bad_param;
}

but it doesn't hurt. Belt and braces and all that :-).

commit 9da3101e449649f0614240f13157ac81e17b2e90
Date: Sat Nov 8 16:14:12 2008 +0100
Remove the variable "size" from reply_trans
This converts the range checks for the setup[] array to rely on req->wct being
set correctly in init_smb_request. As that already verifies the vwv array to be
in the range of the smb_request inbuf, we don't have to do overflow checks here
anymore.
Jeremy, please check thoroughly! :-)

Checked.

Both these changes make sense to me. Thanks,

Jeremy.

[Jeremy Allison]

The branch, master has been updated
via 2719216d60088eb3f10a2e3e968f15e8089b5491 (commit)
from 9a3be6f0f8e120797a02fa1be60b51812cfd86f5 (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
- Log -----------------------------------------------------------------
commit 2719216d60088eb3f10a2e3e968f15e8089b5491
Date: Sat Nov 8 17:08:57 2008 +0100
Consolidate the buffer checks for the reply_trans style functions
This is the one where I found the problem that led to 3.2.5. So if there is one
checkin in the last year that I would like others to review and *understand*,
it is this one :-)

Ok, I really like this. Very nice cleanup. The only thing :

I think "(offset + length < offset)" and
"(offset + length < length)" is redundent. We only need one
I believe. Doesn't hurt having both though.

Jeremy.

[Jeremy Allison]

The branch, master has been updated
via 28099876f9a39f56a54fd2540532309c0d1e2877 (commit)
via 42adfd1be2237bbe5430fe972143b548b42f6edb (commit)
from 1cf5c154aaab8b8c45145343e00ec452c6d0f5b5 (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
- Log -----------------------------------------------------------------
commit 28099876f9a39f56a54fd2540532309c0d1e2877
Date: Sat Nov 29 00:12:26 2008 +0100
s3-libnetjoin: Fix bug #5749. Re-set acctflags while joining. fix from metze.
Guenther
commit 42adfd1be2237bbe5430fe972143b548b42f6edb
Date: Sat Nov 29 00:10:18 2008 +0100
s3-libnetjoin: remove unused md4_trust_password, found by metze.

Guenther, can we get this fix into 3.3 please ?

Jeremy.

[Andrew Bartlett]

--=-gRIJdCKO1GZuxvILilvG
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

The branch, master has been updated
via 0f74de3d37cdb03f622d9cdc1cdcc4aa6ede5ce3 (commit)
from 39e468f55859c01f7bdaab4086df371d3375099f (commit)
=20
http://gitweb.samba.org/?p=3Dsamba.git;a=3Dshortlog;h=3Dmaster
=20
=20
- Log -----------------------------------------------------------------
commit 0f74de3d37cdb03f622d9cdc1cdcc4aa6ede5ce3
Date: Fri Dec 5 13:29:58 2008 +0100
=20
s4:password_hash: really catch the clearTextPasswordAttr case...
=20
This fixes the creation of the user object for incoming trusts
in dcesrv_lsa_CreateTrustedDomain_base().
=20
And now w2k3 trust samba4 just fine:-)
=20
metze

Nice catch!

Andrew Bartlett

--=20
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.

--=-gRIJdCKO1GZuxvILilvG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBJPEtQz4A8Wyi0NrsRArXiAKCM2eJOgRFSuz/cUKcO0CUsPyt1dQCgnoO6
wDVIJ1QDAaT2wIsjECPQrs8=
=aJSk
-----END PGP SIGNATURE-----

--=-gRIJdCKO1GZuxvILilvG--

[Andrew Bartlett]

--=-WNNyKeUNxA42goc1pdPr
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The branch, master has been updated
via 6e4cc12604f6bcf53961326d497f118dfe5da139 (commit)
via 91bfd5f201f302156fac7f1bc7a685e6f3c22cf3 (commit)
from e0711ffa526e22e3ffe483319ce5d7725d578647 (commit)
=20
http://gitweb.samba.org/?p=3Dsamba.git;a=3Dshortlog;h=3Dmaster
=20
=20
- Log -----------------------------------------------------------------
commit 6e4cc12604f6bcf53961326d497f118dfe5da139
Date: Tue Dec 9 23:32:04 2008 +0100
=20
s4-samr: Fix Bug #5946. userparameters handling in torture test.
=20
=20
commit 91bfd5f201f302156fac7f1bc7a685e6f3c22cf3
Date: Tue Dec 9 23:31:15 2008 +0100
=20
s4-samr: Fix Bug #5946. userparameters handling in samr server.
=20

The OpenLDAP backend does not like zero-length strings, and I'm
presuming it's your new tests.=20

I'm wondering if you have any ideas how we can correctly store these ""
userParameters. Should we instead not store the parameter?

=3D Failed tests =3D
=3D=3D samba4.rpc.samr.users on ncacn_np with connect (dc) =3D=3D
ENVLOG: SMBD LOG of: localdc1
Failed to modify record
CN=3Dsamrtorturetest,CN=3DUsers,dc=3Dsamba,dc=3Dexample,dc=3Dcom: LDAP erro=
r 21
LDAP_INVALID_ATTRIBUTE_SYNTAX - <userParameters: value #0 invalid per
syntax> <>
Failed to modify record
CN=3Dsamrtorturetest,CN=3DUsers,dc=3Dsamba,dc=3Dexample,dc=3Dcom: LDAP erro=
r 21
LDAP_INVALID_ATTRIBUTE_SYNTAX - <userParameters: value #0 invalid per
syntax> <>
Failed to modify record
CN=3Dsamrtorturetest,CN=3DUsers,dc=3Dsamba,dc=3Dexample,dc=3Dcom: LDAP erro=
r 21
LDAP_INVALID_ATTRIBUTE_SYNTAX - <userParameters: value #0 invalid per
syntax> <>
Failed to modify record
CN=3Dsamrtorturetest,CN=3DUsers,dc=3Dsamba,dc=3Dexample,dc=3Dcom: error in =
module
entryuuid: Operations error (1)
Failed to modify record
CN=3Dsamrtorturetest,CN=3DUsers,dc=3Dsamba,dc=3Dexample,dc=3Dcom: error in =
module
entryuuid: Operations error (1)
Failed to modify record
CN=3Dsamrtorturetest,CN=3DUsers,dc=3Dsamba,dc=3Dexample,dc=3Dcom: error in =
module
entryuuid: Operations error (1)

--=20
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.

--=-WNNyKeUNxA42goc1pdPr
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBJQlNOz4A8Wyi0NrsRApjHAJoDxIrqA9Hnytn8rp+3s92WrOSTUQCglw6f
/4ybhDoOUtVSV7EMZirfzyo=
=JRVt
-----END PGP SIGNATURE-----

--=-WNNyKeUNxA42goc1pdPr--

[simo]

Post by Andrew Bartlett

The branch, master has been updated
via 6e4cc12604f6bcf53961326d497f118dfe5da139 (commit)
via 91bfd5f201f302156fac7f1bc7a685e6f3c22cf3 (commit)
from e0711ffa526e22e3ffe483319ce5d7725d578647 (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
- Log -----------------------------------------------------------------
commit 6e4cc12604f6bcf53961326d497f118dfe5da139
Date: Tue Dec 9 23:32:04 2008 +0100
s4-samr: Fix Bug #5946. userparameters handling in torture test.
commit 91bfd5f201f302156fac7f1bc7a685e6f3c22cf3
Date: Tue Dec 9 23:31:15 2008 +0100
s4-samr: Fix Bug #5946. userparameters handling in samr server.

The OpenLDAP backend does not like zero-length strings, and I'm
presuming it's your new tests.

I think this is a very old controversial behavior of OpenLDAP, it would
be nice to know why it doesn't.

Post by Andrew Bartlett
I'm wondering if you have any ideas how we can correctly store these ""
userParameters. Should we instead not store the parameter?

In theory a zero length string is a perfectly valid value, although not
possible to express in an ldif, does AD allow to set a zero length
string ?

Simo.

[Michael Ströder]

Post by simo

Post by Andrew Bartlett
The OpenLDAP backend does not like zero-length strings, and I'm
presuming it's your new tests.

I think this is a very old controversial behavior of OpenLDAP, it would
be nice to know why it doesn't.

As said in another posting: It's a matter of the LDAP syntaxes. Most
LDAP syntaxes don't allow empty strings as attribute values (IIRC it's
allowed for IA5String). OpenLDAP is more strict enforcing the specific
constraints of various LDAP syntaxes than other LDAP server implementations.

Post by simo

Post by Andrew Bartlett
I'm wondering if you have any ideas how we can correctly store these ""
userParameters. Should we instead not store the parameter?

In theory a zero length string is a perfectly valid value,

Think about it: E.g. if the LDAP syntax is "Integer" which value should
an empty string indicate? Should the LDAP server automagically normalize
the empty string to the number zero? Or should an empty string indicate
an absent attribute value to be completely ignored. I'm sure this would
lead to various issues.

This is a little bit like None!='' in Python.

Post by simo
although not possible to express in an ldif,

Certainly you can express an empty string in LDIF. Otherwise you
couldn't address the rootDSE with LDIF. If a LDIF parser cannot handle
that it's broken.

Post by simo
does AD allow to set a zero length string ?

This cannot be generally answered for all LDAP syntaxes (see above).

Ciao, Michael.

[simo]

Post by Michael Ströder

Post by simo

Post by Andrew Bartlett
The OpenLDAP backend does not like zero-length strings, and I'm
presuming it's your new tests.

I think this is a very old controversial behavior of OpenLDAP, it would
be nice to know why it doesn't.

As said in another posting: It's a matter of the LDAP syntaxes. Most
LDAP syntaxes don't allow empty strings as attribute values (IIRC it's
allowed for IA5String). OpenLDAP is more strict enforcing the specific
constraints of various LDAP syntaxes than other LDAP server implementations.

True.

Post by Michael Ströder

Post by simo

Post by Andrew Bartlett
I'm wondering if you have any ideas how we can correctly store these ""
userParameters. Should we instead not store the parameter?

In theory a zero length string is a perfectly valid value,

Think about it: E.g. if the LDAP syntax is "Integer" which value should
an empty string indicate? Should the LDAP server automagically normalize
the empty string to the number zero? Or should an empty string indicate
an absent attribute value to be completely ignored. I'm sure this would
lead to various issues.

I was thinking about string syntaxes only.

Post by Michael Ströder
This is a little bit like None!='' in Python.

Post by simo
although not possible to express in an ldif,

Certainly you can express an empty string in LDIF. Otherwise you
couldn't address the rootDSE with LDIF. If a LDIF parser cannot handle
that it's broken.

Uhmm, right, I guess "attr: " is all is needed, didn't think about it.

Post by Michael Ströder

Post by simo
does AD allow to set a zero length string ?

This cannot be generally answered for all LDAP syntaxes (see above).

You forget that AD might be one of those servers that do not do such
strict checking... we need a test to make sure it does or does not.

Simo.

[Michael Ströder]

Post by simo

Post by Michael Ströder

Post by simo
does AD allow to set a zero length string ?

This cannot be generally answered for all LDAP syntaxes (see above).

You forget that AD might be one of those servers that do not do such
strict checking...

Be assured I didn't forget that!

Post by simo
we need a test to make sure it does or does not.

I wanted to point out that even with AD you have to conduct the tests
for different LDAP syntaxes or, even worse, different attribute types of
the same LDAP syntax.

Ciao, Michael.

[simo]

Post by Michael Ströder

Post by simo

Post by Michael Ströder

Post by simo
does AD allow to set a zero length string ?

This cannot be generally answered for all LDAP syntaxes (see above).

You forget that AD might be one of those servers that do not do such
strict checking...

Be assured I didn't forget that!

Post by simo
we need a test to make sure it does or does not.

I wanted to point out that even with AD you have to conduct the tests
for different LDAP syntaxes or, even worse, different attribute types of
the same LDAP syntax.

Then it seem we are in violent agreement :)

Simo.

[Derrell Lipman]

commit da6be4102ed1e3d4e20f08dd8944f062d13c759a
Date: Sat Dec 13 17:04:12 2008 +0100
Remove a static variable
Derrell, please check!
Thanks,
Volker

Volker, yes, your modified code is the right way to do it. Much better than
what was there previously. Thanks.

Derrell

[Tim Prouty]

Date: December 13, 2008 1:49:53 AM PST
Subject: [SCM] Samba Shared Repository - branch master updated -
627c844a13caf869ae3c68ec780a8eded7cb181d
The branch, master has been updated
via 627c844a13caf869ae3c68ec780a8eded7cb181d (commit)
from fd2bac966783a9aa3f278cc67219920384bc0981 (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
- Log
-----------------------------------------------------------------
commit 627c844a13caf869ae3c68ec780a8eded7cb181d
Date: Sat Dec 13 10:31:11 2008 +0100
Fix a valgrind error in get_relative_fid_filename
It doesn't really make sense to check the length of a not-yet-
allocated string
:-)
Volker

Thanks for catching this bug and fixing it!

-Tim

[simo]

@@ -1009,7 +1009,7 @@ static int ltdb_index_filter(const struct
dn_list *dn_list,
- ret = ltdb_search_dn1_wrap(ac->module, dn, msg);
+ ret = ltdb_search_dn1(ac->module, dn, msg);

Andrew are you sure this is correct ?
It is inconsistent with other changes in this patch set.

Simo.

[Andrew Bartlett]

--=-3+S1/A1yMhZZ6gsLzMCf
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Post by simo

@@ -1009,7 +1009,7 @@ static int ltdb_index_filter(const struct=20
dn_list *dn_list,
- ret =3D ltdb_search_dn1_wrap(ac->module, dn, msg);
+ ret =3D ltdb_search_dn1(ac->module, dn, msg);

=20
Andrew are you sure this is correct ?
It is inconsistent with other changes in this patch set.

It is. I carefully checked, which is why I added the assert to the
other cases. (This is actually looking up the target, not index
records, and I wanted to be more clear about the split).=20

Andrew Bartlett

--=20
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.

--=-3+S1/A1yMhZZ6gsLzMCf
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBJSrWIz4A8Wyi0NrsRAoH/AJ9OBRpg0guVTYJ+MIaTmj3KOkmhSACgluvi
U4p2/O+5jiTyXgzH8KhLThk=
=nhnN
-----END PGP SIGNATURE-----

--=-3+S1/A1yMhZZ6gsLzMCf--

[simo]

Post by Andrew Bartlett

Post by simo

@@ -1009,7 +1009,7 @@ static int ltdb_index_filter(const struct
dn_list *dn_list,
- ret = ltdb_search_dn1_wrap(ac->module, dn, msg);
+ ret = ltdb_search_dn1(ac->module, dn, msg);

Andrew are you sure this is correct ?
It is inconsistent with other changes in this patch set.

It is. I carefully checked, which is why I added the assert to the
other cases. (This is actually looking up the target, not index
records, and I wanted to be more clear about the split).

Maybe a comment to that effect would have been helpful, but as long as
it is correct I am fine :)

Simo.

[Jeremy Allison]

The branch, master has been updated
via 4d02bbbfb4d74367bde0f768c02ddb99910ef62d (commit)
from 8ce77a57ccc4d5ff4a216d74c4fc58782fc9098c (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
- Log -----------------------------------------------------------------
commit 4d02bbbfb4d74367bde0f768c02ddb99910ef62d
Date: Mon Dec 22 22:35:24 2008 -0800
s3: Fix stream marshalling to return the correct streaminfo status
When there are enough streams on a file to fill up the max_data_count
when responding to a trans2 streaminfo, samba is returning
NT_STATUS_BUFFER_TOO_SMALL. Windows handles this by returning
NT_STATUS_BUFFER_OVERFLOW while still sending as much of the data that
it can fit into the buffer. When the windows client sees
BUFFER_OVERFLOW, it retries the streaminfo with a larger buffer (2x).
The windows client starts at 2K and will continue increasing the
buffer size by two until it reaches 64K. If the streams don't fit in
64K the windows client seems to give up.
This patch fixes marshall_stream_info to overfill the buffer by 1
stream so that send_trans2_replies can properly detect the overflow
and return the correct status.

Any chance of a torture test for s4 smbtorture for this Tim ?
That way we'll never regress (hopefully).

Thanks,

Jeremy.

[Tim Prouty]

--Apple-Mail-96-497555612
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit

Post by Jeremy Allison

This patch fixes marshall_stream_info to overfill the buffer by 1
stream so that send_trans2_replies can properly detect the
overflow
and return the correct status.

Any chance of a torture test for s4 smbtorture for this Tim ?
That way we'll never regress (hopefully).

I actually did write one, but ran into a few problems:

1. Samba 4's smbclient was having some issues when receiving a trans2
response with Data Count equal to the request's Max Data Count. This
caused the wrong error message to be passed up to smbtorture. A
windows XP client had no problem receiving a response with Data Count
== Max Data Count, and was able to execute the buffer sizing algorithm
described in the comment against samba.

2. I may have missed something, but I didn't see a way in Samba 4's
smbclient to set the Max Data Count. It appears to be hard coded to
64K. This prevented me from writing a torture test that really
reproduces what the windows client does.

I didn't spend too much time tinkering with samba 4's smbclient, but
if anyone is interested in looking, I attached the test. I'll try and
get to it after I get a few other higher priority items done.

Jeremy, speaking of RAW-STREAMS torture, how is the rename fix going?
I also wrote a rename torture test last week to reproduce that exact
bug :). I was about to get started on writing a fix when I saw that
you already wrote one :). Once you get RAW-STREAMS passing again,
I'll push any additions I have in my rename test.

-Tim


--Apple-Mail-96-497555612
Content-Disposition: attachment;
filename=0001-s4-torture-Add-large-streaminfo-buffer-torture-test.patch
Content-Type: application/octet-stream; x-unix-mode=0700;
name="0001-s4-torture-Add-large-streaminfo-buffer-torture-test.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=20d9c89c3afdfd4ca3254f102b8b45c0d05d9f6d78=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20Tim=20Prouty=20<***@samba.org>=0ADate:=20=
Tue,=2023=20Dec=202008=2011:18:17=20-0800=0ASubject:=20[PATCH]=20s4=20=
torture:=20Add=20large=20streaminfo=20buffer=20torture=20test=20to=20=
RAW-STREAMS=0A=0A---=0A=20source4/torture/raw/streams.c=20|=20=20=2078=20=
+++++++++++++++++++++++++++++++++++++++++=0A=201=20files=20changed,=2078=20=
insertions(+),=200=20deletions(-)=0A=0Adiff=20--git=20=
a/source4/torture/raw/streams.c=20b/source4/torture/raw/streams.c=0A=
index=20ba74530..c9c5c31=20100644=0A---=20=
a/source4/torture/raw/streams.c=0A+++=20b/source4/torture/raw/streams.c=0A=
@@=20-1113,6=20+1113,82=20@@=20done:=0A=20}=0A=20=0A=20=0A+static=20bool=20=
create_file_with_stream(struct=20torture_context=20*tctx,=0A+=09=09=09=09=
=20=20=20=20struct=20smbcli_state=20*cli,=0A+=09=09=09=09=20=20=20=20=
TALLOC_CTX=20*mem_ctx,=0A+=09=09=09=09=20=20=20=20const=20char=20=
*base_fname,=0A+=09=09=09=09=20=20=20=20const=20char=20*stream)=0A+{=0A+=09=
NTSTATUS=20status;=0A+=09bool=20ret=20=3D=20true;=0A+=09union=20smb_open=20=
io;=0A+=0A+=09/*=20Create=20a=20file=20with=20a=20stream=20*/=0A+=09=
io.generic.level=20=3D=20RAW_OPEN_NTCREATEX;=0A+=09=
io.ntcreatex.in.root_fid=20=3D=200;=0A+=09io.ntcreatex.in.flags=20=3D=20=
0;=0A+=09io.ntcreatex.in.access_mask=20=3D=20=
(SEC_FILE_READ_DATA|SEC_FILE_WRITE_DATA|=0A+=09=20=20=20=20=
SEC_FILE_APPEND_DATA|SEC_STD_READ_CONTROL);=0A+=09=
io.ntcreatex.in.create_options=20=3D=200;=0A+=09=
io.ntcreatex.in.file_attr=20=3D=20FILE_ATTRIBUTE_NORMAL;=0A+=09=
io.ntcreatex.in.share_access=20=3D=200;=0A+=09io.ntcreatex.in.alloc_size=20=
=3D=200;=0A+=09io.ntcreatex.in.open_disposition=20=3D=20=
NTCREATEX_DISP_CREATE;=0A+=09io.ntcreatex.in.impersonation=20=3D=20=
NTCREATEX_IMPERSONATION_ANONYMOUS;=0A+=09io.ntcreatex.in.security_flags=20=
=3D=200;=0A+=09io.ntcreatex.in.fname=20=3D=20stream;=0A+=0A+=09status=20=
=3D=20smb_raw_open(cli->tree,=20mem_ctx,=20&io);=0A+=09=
CHECK_STATUS(status,=20NT_STATUS_OK);=0A+=0A+=20done:=0A+=09=
smbcli_close(cli->tree,=20io.ntcreatex.out.file.fnum);=0A+=09return=20=
ret;=0A+}=0A+=0A+/*=20Test=20streaminfo=20with=20enough=20streams=20on=20=
a=20file=20to=20fill=20up=20the=20buffer.=20=20*/=0A+static=20bool=20=
test_stream_large_streaminfo(struct=20torture_context=20*tctx,=0A+=09=09=09=
=09=09=20struct=20smbcli_state=20*cli,=0A+=09=09=09=09=09=20TALLOC_CTX=20=
*mem_ctx)=0A+{=0A+#define=20LONG_STREAM_SIZE=20200=0A+=09char=20=
*lstream_name;=0A+=09const=20char=20*fname=20=3D=20BASEDIR=20=
"\\stream.txt";=0A+=09const=20char=20*fname_stream;=0A+=09NTSTATUS=20=
status;=0A+=09bool=20ret=20=3D=20true;=0A+=09int=20i;=0A+=09union=20=
smb_fileinfo=20finfo;=0A+=0A+=09lstream_name=20=3D=20=
talloc_array(mem_ctx,=20char,=20LONG_STREAM_SIZE);=0A+=0A+=09for=20(i=20=
=3D=200;=20i=20<=20LONG_STREAM_SIZE=20-=201;=20i++)=20{=0A+=09=09=
lstream_name[i]=20=3D=20(char)('a'=20+=20i%26);=0A+=09}=0A+=09=
lstream_name[LONG_STREAM_SIZE=20-=201]=20=3D=20'\0';=0A+=0A+=09=
printf("(%s)=20Creating=20a=20file=20with=20a=20lot=20of=20streams\n",=20=
__location__);=0A+=09for=20(i=20=3D=200;=20i=20<=20150;=20i++)=20{=0A+=09=
=09fname_stream=20=3D=20talloc_asprintf(mem_ctx,=20"%s:%s%d",=20fname,=0A=
+=09=09=09=09=09=20=20=20=20=20=20=20lstream_name,=20i);=0A+=09=09ret=20=
=3D=20create_file_with_stream(tctx,=20cli,=20mem_ctx,=20fname,=0A+=09=09=09=
=09=09=20=20=20=20=20=20fname_stream);=0A+=09=09if=20(!ret)=20{=0A+=09=09=
=09goto=20done;=0A+=09=09}=0A+=09}=0A+=0A+=09finfo.generic.level=20=3D=20=
RAW_FILEINFO_STREAM_INFO;=0A+=09finfo.generic.in.file.path=20=3D=20=
fname;=0A+=0A+=09status=20=3D=20smb_raw_pathinfo(cli->tree,=20mem_ctx,=20=
&finfo);=0A+=09CHECK_STATUS(status,=20STATUS_BUFFER_OVERFLOW);=0A+=0A+=20=
done:=0A+=09smbcli_unlink(cli->tree,=20fname);=0A+=09return=20ret;=0A+}=0A=
+=0A=20/*=20=0A=20=20=20=20basic=20testing=20of=20streams=20calls=0A=20=
*/=0A@@=20-1140,6=20+1216,8=20@@=20bool=20torture_raw_streams(struct=20=
torture_context=20*torture,=0A=20=09if=20(!torture_setting_bool(torture,=20=
"samba4",=20false))=20{=0A=20=09=09ret=20&=3D=20=
test_stream_delete(torture,=20cli,=20torture);=0A=20=09}=0A+=09ret=20&=3D=20=
test_stream_large_streaminfo(torture,=20cli,=20torture);=0A+=09=
smb_raw_exit(cli->session);=0A=20=0A=20=09smb_raw_exit(cli->session);=0A=20=
=09smbcli_deltree(cli->tree,=20BASEDIR);=0A--=20=0A1.6.0=0A=0A=

--Apple-Mail-96-497555612
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit



--Apple-Mail-96-497555612--

[Jeremy Allison]

Post by Tim Prouty
1. Samba 4's smbclient was having some issues when receiving a trans2
response with Data Count equal to the request's Max Data Count. This
caused the wrong error message to be passed up to smbtorture. A windows
XP client had no problem receiving a response with Data Count == Max Data
Count, and was able to execute the buffer sizing algorithm described in
the comment against samba.
2. I may have missed something, but I didn't see a way in Samba 4's
smbclient to set the Max Data Count. It appears to be hard coded to
64K. This prevented me from writing a torture test that really
reproduces what the windows client does.
I didn't spend too much time tinkering with samba 4's smbclient, but if
anyone is interested in looking, I attached the test. I'll try and get
to it after I get a few other higher priority items done.

Ok, cool - no problem. It's hard when the infrastructure
isn't there, but I scarfed your fix for 3.3 and 3.2 as the
streams code is stable and the same there.

Post by Tim Prouty
Jeremy, speaking of RAW-STREAMS torture, how is the rename fix going? I
also wrote a rename torture test last week to reproduce that exact bug
:). I was about to get started on writing a fix when I saw that you
already wrote one :). Once you get RAW-STREAMS passing again, I'll push
any additions I have in my rename test.

RAW-STREAMS is actually passing right now against 3.3.x.
The build farm failures seem to be many different issues
right now. I'm concentrating on removing all gcc 4.3.x
warnings first as RAW-STREAMS is ok.

Can you push any new stuff you have so I can look at it ?

Thanks,

Jeremy.

[Tim Prouty]

Post by Jeremy Allison
Ok, cool - no problem. It's hard when the infrastructure
isn't there, but I scarfed your fix for 3.3 and 3.2 as the
streams code is stable and the same there.

Thanks!

Post by Jeremy Allison
RAW-STREAMS is actually passing right now against 3.3.x.
The build farm failures seem to be many different issues
right now. I'm concentrating on removing all gcc 4.3.x
warnings first as RAW-STREAMS is ok.
Can you push any new stuff you have so I can look at it ?

Yes. I probably won't have time before the holidays, but I'll try and
get them upstream along with any associated fixes soon.

-Tim

[Jeremy Allison]

The branch, master has been updated
via ef1e9ed94176d4ed938b184f8837e527dbf2c80c (commit)
via daaa2c8231574d1879a492d1002f4f4dcff764b8 (commit)
from 5184baa9591640c7fac4574bad6c15f5c7302a87 (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
- Log -----------------------------------------------------------------
commit ef1e9ed94176d4ed938b184f8837e527dbf2c80c
Date: Fri Dec 26 14:09:02 2008 +0100
Fix some tevent includes, trying to fix the build
commit daaa2c8231574d1879a492d1002f4f4dcff764b8
Date: Fri Dec 26 13:32:26 2008 +0100
Try to fix the build by fixing some typos in the vfs code

Sorry Kai, compiled in 3.3 and was a bad merge before
going on vacation :-(.

Jeremy.

[Volker Lendecke]

--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

The branch, master has been updated
via 4d82f69f884c0c9105d7c1cc53a1235e26222fbc (commit)
from 9c92cb763653644e129b0777b3f8fc2f333bb7c6 (commit)
=20
http://gitweb.samba.org/?p=3Dsamba.git;a=3Dshortlog;h=3Dmaster
=20
=20
- Log -----------------------------------------------------------------
commit 4d82f69f884c0c9105d7c1cc53a1235e26222fbc
Date: Wed Dec 31 21:24:25 2008 -0800
=20
s3: Fix caller of print_fsp_open

Thanks :-)

Volker

--ibTvN161/egqYuK8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFJXKVrbsgDfmnSbrYRAuzAAJ92hX4aXj9AYYb5cxApuDTtnW2czwCggPSb
SxLO05RiOfjLdIgWNEUhQmg=
=QLif
-----END PGP SIGNATURE-----

--ibTvN161/egqYuK8--