- they show up previously with / typed – end user needs to know about it
- inconsistent with some other fields, that show it directly
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Until recently (it was fixed in ac2999a26a) when a path was transferred
other shares with the target user were removed, so a test was added to
ensure that it does not happen again.
Besides that a test to ensure that other files with the target user are
not transferred was added too (it did not fail before, but seemed
convenient to have that covered too :-) ).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The files:transfer-ownership performs a sanitization of users with
"risky" display names (including characters like "\" or "/").
In order to allow (escaped) double quotes in the display name the
regular expression used in the "user XXX with displayname YYY exists"
step had to be adjusted.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently only transferring ownership of a reshare with a group to a
user in the group is possible.
When transferring ownership of a reshare with another user or with a
group to a user not in the group restoring the share fails (but the
command succeeds, it only fails for the specific files that are
reshares).
When transferring ownership of a path that is a reshare the command
fails (as when a specific path is provided the path tries to move the
file, it does not take into account reshares).
The added integration tests reflect the above behaviours.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The integration tests did not verify that the shares were actually
transferred between the users (or that they were removed due to being
transferred to the sharee).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The integration tests did not verify that the files were actually
transferred between the users, only that the files were downloadable.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
if a directory is empty, only the 'marker' object `/` exists.
since not all s3 implementations return just the prefix when listing objects by prefix,
when listing objects by the folder prefix, nothing will be returned if the directory is empty.
by not including the trailing slash in the prefix, the folder marked will always be returned if it exists
Signed-off-by: Robin Appelman <robin@icewind.nl>
Since we try to do range requests this will fail hard.
However since empty files are not that interesting to read anyways we
just read from an emptry memory stream.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>