When the ownership of a user share is transfered to the receiver the
share is removed, as the receiver now owns the original file. However,
due to a missing condition, any share with a group, link or remote with
the same id as the user was removed, not only the user shares.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This will help user to selectively move the folders
specified using --path option, instead of moving
entire folder under files directory.
Signed-off-by: Sujith H <sharidasan@owncloud.com>
Update the integration test for transfer-ownership
Update the integration test for transfer-ownership
as the new option --path is introduced in the command.
Signed-off-by: Sujith H <sharidasan@owncloud.com>
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* on Windows : is not allowed as filename and doesn't get synced then
* uses 2017-03-02 22-00-00 instead of 2017-03-02T22:00:00+00:00 as format
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
This prevents a validation failure where the code checks whether a file
is already shared with another user, but the check disables itself when
the owner is the same. Processing the groups first prevents the check
to kick in too early when the group share still has the old owner while
we try transferring the user share.
When transferring ownership, only the local files will be transferred
during the rename operation. This means that the analyzing code doesn't
need to recurse into any mount points.
Furthermore this fixes issues where FailedStorage might appear as mount
points as a result of inaccessible external storages or shares. So this
makes it more robust.
