| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(This used to be commit c5e72b05d73ff0d57a98b6065bab573e2a226747)
|
|
(This used to be commit 739c9e401cfbe04f2596e5b4b178243263218c04)
|
|
(This used to be commit d7b0dece6fbc2b5f8216b6a6a41e3db76b8627aa)
|
|
(This used to be commit 022b21460a572803b86ef5c11f6fe0b6fa1dcae1)
|
|
(This used to be commit 50379a0a58d9eade3e1390713ef89473c66e65fc)
|
|
(This used to be commit 6e87feb89c57ca900ef4125e48f5de5ff80ff7b9)
|
|
This adds a pvfs_wait_message() routine which uses the new messaging
system, event timers and talloc destructors to give a nice generic
async event handling system with a easy to use interface. The
extensions to pvfs_lock.c are based on calls to pvfs_wait_message()
routines.
We now pass all of our smbtorture locking tests, although while
writing this code I have thought of some additonal tests that should
be added, particularly for lock cancel operations. I'll work on that
soon.
This commit also extends the smbtorture lock tests to test the rather
weird 0xEEFFFFFF locking semantics that I have discovered in
win2003. Win2003 treats the 0xEEFFFFFF boundary as special, and will
give different error codes on either side of it. Locks on both sides
are allowed, the only difference is which error code is given when a
lock is denied. Anyone like to hazard a guess as to why? It has
me stumped.
(This used to be commit 4395c0557ab175d6a8dd99df03c266325949ffa5)
|
|
(This used to be commit f4a91be63502c0bb32c52c0558dfc7d4d0a21fae)
|
|
of associated functions.
The motivation for this change was to avoid having to convert to/from
ucs2 strings for so many operations. Doing that was slow, used many
static buffers, and was also incorrect as it didn't cope properly with
unicode codepoints above 65536 (which could not be represented
correctly as smb_ucs2_t chars)
The two core functions that allowed this change are next_codepoint()
and push_codepoint(). These functions allow you to correctly walk a
arbitrary multi-byte string a character at a time without converting
the whole string to ucs2.
While doing this cleanup I also fixed several ucs2 string handling
bugs. See the commit for details.
The following code (which counts the number of occuraces of 'c' in a
string) shows how to use the new interface:
size_t count_chars(const char *s, char c)
{
size_t count = 0;
while (*s) {
size_t size;
codepoint_t c2 = next_codepoint(s, &size);
if (c2 == c) count++;
s += size;
}
return count;
}
(This used to be commit 814881f0e50019196b3aa9fbe4aeadbb98172040)
|
|
simplifies things quite a bit
(This used to be commit c82a9cf750829c4f6982ca3133295c8599023c4e)
|
|
rather than manual reference counts
- properly support SMBexit in the cifs and posix backends
- added a logoff method to all backends
With these changes the RAW-CONTEXT test now passes against the posix backend
(This used to be commit c315d6ac1cc40546fde1474702a6d66d07ee13c8)
|
|
hierarchical memory allocation
(This used to be commit 26da45a8019a2d6c9ff2ac2a6739c7d0b42b00de)
|
|
valgrind on smbd with
--show-leak=yes and --show-reachable=yes to track them down.
(This used to be commit 7b23624a0f50c29346e8b1c4057f1c21f3be6d5a)
|
|
The intial motivation for this commit was to merge in some of the
bugfixes present in Samba3's chrcnv and string handling code into
Samba4. However, along the way I found a lot of unused functions, and
decided to do a bit more...
The strlen_m code now does not use a fixed buffer, but more work is
needed to finish off other functions in str_util.c. These fixed
length buffers hav caused very nasty, hard to chase down bugs at some
sites.
The strupper_m() function has a strupper_talloc() to replace it (we
need to go around and fix more uses, but it's a start). Use of these
new functions will avoid bugs where the upper or lowercase version of
a string is a different length.
I have removed the push_*_allocate functions, which are replaced by
calls to push_*_talloc. Likewise, pstring and other 'fixed length'
wrappers are removed, where possible.
I have removed the first ('base pointer') argument, used by push_ucs2,
as the Samba4 way of doing things ensures that this is always on an
even boundary anyway. (It was used in only one place, in any case).
(This used to be commit dfecb0150627b500cb026b8a4932fe87902ca392)
|
|
Andrew Bartlett
(This used to be commit 066789a479ed7b36041e3455caac01e5c9244dc0)
|
|
convert_string_talloc().
Andrew Bartlett
(This used to be commit 79776006b37fa9df0586711edaba5335467461ac)
|
|
I had previously thought this was unnecessary, as windows doesn't use
standards compliant UTF-16, and for filesystem operations treats bytes
as UCS-2, but Bjoern Jacke has pointed out to me that this means we
don't correctly store extended UTF-16 characters as UTF-8 on
disk. This can be seen with (for example) the gothic characters with
codepoints above 64k.
This commit also adds a LOCAL-ICONV torture test that tests the first
1 million codepoints against the system iconv library, and tests 5
million random UTF-16LE buffers for identical error handling to the
system iconv library.
the lib/iconv.c changes need backporting to samba3
(This used to be commit 756f28ac95feaa84b42402723d5f7286865c78db)
|
|
metze
(This used to be commit eb9de893b8b93857c648f4df907aac9e9cb199dc)
|
|
(This used to be commit 6ffdfd779936ce8c5ca49c5f444e8da2bbeee0a8)
|
|
rename CLI_ -> SMBCLI_
metze
(This used to be commit 8441750fd9427dd6fe477f27e603821b4026f038)
|
|
Up to now the client code has had an async API, and operated
asynchronously at the packet level, but was not truly async in that it
assumed that it could always write to the socket and when a partial
packet came in that it could block waiting for the rest of the packet.
This change makes the SMB client library full async, by adding a
separate outgoing packet queue, using non-blocking socket IO and
having a input buffer that can fill asynchonously until the full
packet has arrived.
The main complexity was in dealing with the events structure when
using the CIFS proxy backend. In that case the same events structure
needs to be used in both the client library and the main smbd server,
so that when the client library is waiting for a reply that the main
server keeps processing packets. This required some changes in the
events library code.
Next step is to make the generated rpc client code use these new
capabilities.
(This used to be commit 96bf4da3edc4d64b0f58ef520269f3b385b8da02)
|
|
(jra: please use: void, char int, uint_t, [u]int<8|16|32|64>_t types in new code)
metze
(This used to be commit 626bb153c45405f93a96bc5019241af506fac163)
|
|
This has found some signing errors in the Samba3.0 implementation
of the deferred open code. Still working on these...
Jeremy
(This used to be commit 0068cb12ef91515a95f17a1be7dfbc83fbb89eba)
|
|
metze
(This used to be commit 57151e80eb1090281401930c8fe25b20a8cf3a38)
|
|
metze
(This used to be commit 2986c5f08c8f0c26a2ea7b6ce20aae025183109f)
|
|
metze
(This used to be commit af6f1f8a01bebbecd99bc8c066519e89966e65e3)
|
|
metze
(This used to be commit 0e5517d937a2eb7cf707991d1c7498c1ab456095)
|
|
- added a CHARSET set of tests, which determines how the server deals
with some specific charset issues related to UTF-16
support. Interestingly, Samba3 already passes all but one of these
tests, because our incorrect UCS-2 and UTF-8 implementations where we
don't check the validity of characters actually matches what Windows
does! This means that adding UTF-16 support to Samba is going to be
_much_ easier than we expected.
(This used to be commit c8497a42364d186f08102224d5062d176ee81f5b)
|
