Age | Commit message (Collapse) | Author | Files | Lines |
|
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)
|