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 need to use the connection that is used by the current request.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
It turns out that all the client and server need to agree on is what
protocol should have been negotiated. If they disagree, they should
disconnect. The contents of the list of protocols used during
negotiate and during FSCTL_VALIDATE_NEGOTIATE_INFO do not need to match.
Signed-off-by: Ira Cooper <ira@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Mon Jun 23 14:28:25 CEST 2014 on sn-devel-104
SIVAL writes 32 bit, not 16
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Fri Feb 7 20:07:23 CET 2014 on sn-devel-104
As documented in MS-SMB2 3.3.5.15.6 Handling a Server-Side Data Copy
Request, an invalid parameter response should be sent when:
The Length value in a single chunk is greater than
ServerSideCopyMaxChunkSize or *equal to zero*.
We do not currently abide by the latter part of this clause.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10424
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
FSCTL_SRV_COPYCHUNK can only be used when the client has the copy-chunk
target file open with FILE_WRITE_DATA and FILE_READ_DATA.
FSCTL_SRV_COPYCHUNK_WRITE requires only FILE_WRITE_DATA access on the
target, and is therefore suitable for cp --reflink, which opens the
target file O_WRONLY.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This can cause compile errors on 32-bit systems.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Sat Jan 19 12:14:13 CET 2013 on sn-devel-104
Previous commit handles this around each read/write call.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Fri Jan 18 01:47:01 CET 2013 on sn-devel-104
Planning to add extra checks to ensure we don't attempt
copychunk on printer or IPC$ handles.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Check that the copychunk ioctl request maximum output specified by the
client is large enough to hold copychunk response data.
Reviewed by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Jan 17 00:59:44 CET 2013 on sn-devel-104
[MS-SMB2] 3.3.5.15.6 Handling a Server-Side Data Copy Request, specifies
that the copychunk destination file handle be granted FILE_WRITE_DATA
and FILE_READ_DATA access.
FILE_READ_DATA access must also be granted on the copychunk source file,
which may be done implicitly with execute permission.
Reviewed by: Jeremy Allison <jra@samba.org>
For each chunk in a copychunk request, take a read and write lock on
the source and destination files respectively.
Also change the resume key format to use a combination of the persistent
and volatile handles. Thanks to Metze for his help on this.
Reviewed by: Jeremy Allison <jra@samba.org>
SMB2 clients can issue FSCTL_SRV_COPYCHUNK requests in order to copy
data between files on the server side only, rather than reading data
then writing back from the client. FSCTL_SRV_COPYCHUNK is used by
default for Explorer SMB2 file copies on Windows Server 2012.
2.2.32.1 SRV_COPYCHUNK_RESPONSE in [MS-SMB2] describes the requirement
for the server to provide maximum copychunk request size limits in ioctl
responses carrying STATUS_INVALID_PARAMETER.
Reviewed by: Jeremy Allison <jra@samba.org>
Use existing ioctl IDL infrastructure for marshalling. Support for this
ioctl is a prerequisite for FSCTL_SRV_COPYCHUNK handling.
The client-opaque resume key is constructed using the server side
dev/inode file identifier.
Reviewed by: Jeremy Allison <jra@samba.org>
Add per device type ioctl handler source files for FSCTL_DFS,
FSCTL_FILESYSTEM, FSCTL_NAMED_PIPE and FSCTL_NETWORK_FILESYSTEM.
Reviewed by: Jeremy Allison <jra@samba.org>
