IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
we shouldn't accept bad multi-byte strings, it just hides problems
Autobuild-User: Andrew Tridgell <tridge@samba.org>
Autobuild-Date: Thu Mar 24 01:47:26 CET 2011 on sn-devel-104
This was found during testing at the CIFS plugfest.
No other client seems to honour or use this bit, but it is quite
ligitimately required by the spec.
Andrew Bartlett
We needed a flag in bufinfo to mark packets as SMB2, as it seems that
SMB2 uses a different format for the RenameInformation buffer than SMB
does
Also handle the fact that SMB2 clients give the full path to the
target file in the rename, not a relative path
(This used to be commit 52d7972d95ddc19d22a4187b4d4428a6c3ed32d5)
This converts our SMB and SMB2 code to use a common structure "struct
request_bufinfo" for information on the buffer bounds of a packet,
alignment information and string handling. This allows us to use a
common backend for SMB and SMB2 code, while still using all the same
string and blob handling functions.
Up to now we had been passing a NULL req handle into these common
routines from the SMB2 side of the server, which meant that we failed
any operation which did a bounds checked string extraction (such as a
RenameInformation setinfo call, which is what Vista uses for renaming
files)
There is still some more work to be done on this - for example we can
now remove many of the SMB2 specific buffer handling functions that we
had, and use the SMB ones.
(This used to be commit ca6d9be6cb6a403a81b18fa6e9a6a0518d7f0f68)
There are still a few tidyups of old FSF addresses to come (in both s3
and s4). More commits soon.
(This used to be commit fcf38a38ac691abd0fa51b89dc951a08e89fdafa)
- to use a struct ntvfs_handle instead of a uint16_t fnum.
(to make it independend from the frontend protocol)
- the allocation of handles now is provided by the frontend
(smbsrv_*) via callbacks and not by each backend module
- this also makes sure that file handles are only passed
to the ntvfs subsystem when the tcon and session matches,
so modules can rely on this and need to check this.
- this allows multiple modules in the ntvfs module chain
to allocate file handles. This can be used for virtual
files like "\\$Extend\\$Quota:$Q:$INDEX_ALLOCATION"...
- also this will make SMB2 with 128 bit file handles possible
metze
(This used to be commit 287fc1c22d670f6e568014b420f7f4cb31dc7958)
with this it's now possible to write a
ntvfs_test programm like the vfstest in samba3
also smb2 support will be possible later
metze
(This used to be commit 7253153691e35cd206346fbd4e9b9f95c042f602)
now smbsrv_setup_reply() and req_setup_chain_reply() do the same thing
tridge: can you please check if this is correct,
I wonder why we don't got valgrind errors...
as the over allocation is disabled currently
metze
(This used to be commit 3441a4a74fb324a4dfbca13219df4c55ebcfbf6c)
