[PATCH] libcli: Overwrite destination in cli_smb2_rename

[Stefan (metze) Metzmacher]

Am 05.08.2014 um 23:55 schrieb Jeremy Allison:
> On Tue, Aug 05, 2014 at 02:37:10PM -0700, Jeremy Allison wrote:
>>
>> However.... (email thinking in real-time here :-).
>> SMB1 trans2 SMB_FILE_RENAME_INFORMATION *does*
>> have a client supplied replace_if_exists flag,
>> the same as SMB2. So we could move to that
>> instead.
> 
> So looks like we *can* do this. Now the
> question is *how* should we do this.
> 
> We could create a cli_rename2() or
> cli_rename_overwrite() which has the
> desired semantics for both SMB1 and
> SMB2.

I'd add a new function or an additional argument
and let the caller decide.

> Currently the code inside libsmbclient
> does:
> 
>        if (!NT_STATUS_IS_OK(cli_rename(targetcli1, targetpath1, targetpath2))) {
>                 int eno = SMBC_errno(ocontext, targetcli1);
> 
>                 if (eno != EEXIST ||
>                     !NT_STATUS_IS_OK(cli_unlink(targetcli1, targetpath2, FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_HIDDEN)) ||
>                     !NT_STATUS_IS_OK(cli_rename(targetcli1, targetpath1, targetpath2))) {
> 
> 
> so if it gets an EEXIST it falls back to
> a non-atomic unlink and rename. So
> chjanging this to remove the unlink
> and just call cli_rename_overwrite()
> directly would be a distinct improvement
> without changing the underlying
> semantics inside libsmbclient.

We could try cli_rename_overwrite() to cli_rename() and finally
cli_unlink/cli_rename
in case the server doesn't support atomic renames.

The code in smbclient cmd_rename() should continue to return an error.

metze
> Thoughts ?
> 
> Jeremy.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140806/dd8d7cde/attachment.pgp>