Core: rename permission without delete duplicate folders [$15]

[mdkdog]

Steps to reproduce

1. as user A share a folder "testshare" with user B with "create" and "change" permissions but remove "delete"
2. from the windows client of user B create folder "test" inside share "testshare"
3. from the windows client of user B rename folder "test" to "test2"
   

   Expected behaviour

end up with folder "test2" only

Actual behaviour

end up with folder "test2" and folder "test"

Server configuration

Operating system:

• FreeBSD 10.1-RELEASE

Web server:

• nginx version: nginx/1.8.0

Database:

• mysql Ver 14.14 Distrib 5.6.23, for FreeBSD10.1

PHP version:

• PHP 5.5.23

ownCloud version: (see ownCloud admin page)

• ownCloud version 8.1.1

Updated from an older ownCloud or fresh install:
Updated from 8.0.1

List of activated apps:
Enabled:

• calendar: 0.7.3
• contacts: 0.4.0.0
• external: 1.2
• files: 1.1.10
• files_pdfviewer: 0.7
• files_sharing: 0.6.2
• roundcube: 2.6.1

Disabled:

• activity
• encryption
• files_external
• files_locking
• files_texteditor
• files_trashbin
• files_versions
• files_videoviewer
• firstrunwizard
• gallery
• provisioning_api
• templateeditor
• updater
• user_external
• user_ldap
• user_webdavauth

The content of config/config.php:

$CONFIG = array (
'instanceid' => 'xxxxxxxxx',
'passwordsalt' => 'xxxxxxxxxxxxx',
'datadirectory' => '/xxx/oc_store/xxxx',
'dbtype' => 'mysql',
'version' => '8.1.1.3',
'dbname' => 'oc_xxxx',
'dbhost' => 'x.x.x.x',
'dbtableprefix' => 'oc_',
'dbuser' => 'xxxx',
'dbpassword' => 'xxxxx',
'installed' => true,
'forcessl' => true,
'logtimezone' => 'Europe/Rome',
'log_rotate_size' => 10485760,
'default_language' => 'it',
'loglevel' => 3,
'mail_smtpmode' => 'smtp',
'mail_smtphost' => 'x.x.x.x',
'mail_smtpport' => '25',
'mail_domain' => 'xxxxxxx.yyy',
'theme' => '',
'maintenance' => false,
'trusted_domains' =>
array (
0 => 'xxxxxxx.yyy',
),
'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'share_folder' => '/Shared',
'mail_from_address' => 'cloud',
'defaultapp' => 'roundcube',
'appstoreenabled' => true,
'appstoreurl' => 'https://api.owncloud.com/v1',
'appstore.experimental.enabled' => true,

Are you using external storage, if yes which one: local/smb/sftp/...

• no

Are you using encryption: yes/no

• no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

• no

Client configuration

Browser:

• Google Chrome Versione 45.0.2454.85 m

Operating system:

• Windows 8.1

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

ownCLoud client log

09/09/2015 17:12:05Shared/prova/2                                                  C:\#Sync                      Spostamento non consentito poiché l'origine è in sola lettura          
09/09/2015 16:27:08Shared/prova/2                                                  C:\#Sync                      Caricato                 
09/09/2015 16:27:08Shared/prova/1                                                  C:\#Sync                      Rimozione non consentita, ripristino          
09/09/2015 16:27:02Shared/prova/1                                                  C:\#Sync                      Spostamento non consentito poiché l'origine è in sola lettura          
09/09/2015 16:26:31Shared/prova/1                                                  C:\#Sync                      Caricato    

[karlitschek]

@schiesbn

[mdkdog]

I don't understand.
on @schiesbn profile is a solution?

Il 09/09/2015 17:50, Frank Karlitschek ha scritto:

@schiesbn https://github.com/schiesbn

—
Reply to this email directly or view it on GitHub
https://github.com/owncloud/core/issues/18933#issuecomment-138953891.

[schiessle]

@mdkdog with which permissions did you shared "testshare". I tried it with all permissions and only with "create, change" and only with "change" permissions and could never reproduce it.

[schiessle]

btw, what does this mean exactly "end up with folder "test2" and folder "test""?

Directly after the rename you only have "test" but after the next sync run you have both on the client and on the server "test2" and "test"?

[mdkdog]

permissions are "create, change" no "delete".

Directly after the rename (on client) i only have "test2" but after the next sync run i have both on the client and on the server "test2" and "test".

[schiessle]

ah, now I can reproduce it. The first time I tried it with a normal webdav client because it is faster and shouldn't make a difference. Now I tried it with the desktop client 2.0.1 and can reproduce it.

So what does the sync client different compared to a webdav move on rename? cc @danimo @dragotin

[mdkdog]

it looks to me that is trying to do a copy then delete the original...when "delete" fails for lack of permissions is restoring the original ("Rimozione non consentita, ripristino" from client logs).
let me know if there is something i could do to help... (keep in mind that i'm not a programmer).

[schiessle]

normally the client should do a move, otherwise we would lost all information like shares on the folder.

[schiessle]

from the apache access log the client perform following operations

127.0.0.1 - user2 [14/Sep/2015:17:42:48 +0200] "PROPFIND /master/remote.php/webdav/ HTTP/1.1" 207 1074 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"
127.0.0.1 - user2 [14/Sep/2015:17:42:57 +0200] "PROPFIND /master/remote.php/webdav/ HTTP/1.1" 207 2426 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"
127.0.0.1 - user2 [14/Sep/2015:17:43:00 +0200] "PROPFIND /master/remote.php/webdav/ HTTP/1.1" 207 2425 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"
127.0.0.1 - user2 [14/Sep/2015:17:43:00 +0200] "PROPFIND /master/remote.php/webdav/testshare HTTP/1.1" 207 4489 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"
127.0.0.1 - user2 [14/Sep/2015:17:43:00 +0200] "PROPFIND /master/remote.php/webdav/testshare/test HTTP/1.1" 207 1378 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"
127.0.0.1 - user2 [14/Sep/2015:17:43:00 +0200] "MKCOL /master/remote.php/webdav/testshare/test2 HTTP/1.1" 201 679 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"

on a local folder the client does the right thing:

127.0.0.1 - user2 [14/Sep/2015:17:45:33 +0200] "PROPFIND /master/remote.php/webdav/ HTTP/1.1" 207 2938 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"
127.0.0.1 - user2 [14/Sep/2015:17:45:33 +0200] "PROPFIND /master/remote.php/webdav/testshare HTTP/1.1" 207 5008 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"
127.0.0.1 - user2 [14/Sep/2015:17:45:33 +0200] "MOVE /master/remote.php/webdav/local/test HTTP/1.1" 201 679 "-" "Mozilla/5.0 (Linux) mirall/2.0.1"

[PVince81]

@guruz @ogoffart any idea ? In what situation would the sync client behave like this ?

[PVince81]

@mdkdog in your report subject you mention "rename permission", did you share with restricted permissions ?

I talked with @schiesbn and he said that in his test case all permissions were given, so probably unrelated.

[mdkdog]

Folder is shared with "create" and "change" permissions, without "delete".

[PVince81]

Tried v8.1.1 with sync client 2.0.1 with all permissions, could not reproduce the issue.

However if I remove the "delete" permission from the share the following happens:

Now if I rename a folder directly in the web UI, it works, because it is allowed. "rename" doesn't count as a deletion.

At some point I wrote a smashbox automated test to check for file operations which helped make it a bit clearer what operations allow what, see https://github.com/owncloud/smashbox/blob/master/lib/oc-tests/test_sharePermissions.py#L128

Maybe the sync client's interpretation of the permissions is not accurate ?

[PVince81]

Raised https://github.com/owncloud/client/issues/3856 in the client repo

[PVince81]

@ogoffart suggested here https://github.com/owncloud/client/issues/3856#issuecomment-150153458 to add the "N" permission when the file is updatable. Something to try.

[mdkdog]

Hi,
I would like to congratulate everyone for the One year anniversary of this bug report!
sarcasm aside.... is there anyone looking into this ?

[PVince81]

Setting to 9.1.2 to give this another try

[mdkdog]

Already fixed in nextcloud by nickvergessen:
https://github.com/nextcloud/server/commit/cf69a2b7eb06eb3e1894e73441d8877aac1e51f6

[PVince81]

There is a slight chance that it is already fixed in 9.1, but best is to write an integration test to confirm and enforce this.

[PVince81]

Works for me on 9.1.1RC2

[PVince81]

Also works with 9.0.2 and 9.0.3.

[PVince81]

Also works with 8.1.9

[PVince81]

Retried with 8.1.1 and it was broken there, to confirm that my test steps were correct.

Please upgrade!

[mdkdog]

ownCloud 8.2.1 (stable) not working ...i will wait for 9.1.1

[PVince81]

8.2.1 is very old, try with 8.2.7 which works

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.