Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-generated public links don't work if they are longer than 64 characters #6298

Closed
brozkeff opened this issue Jan 11, 2018 · 4 comments
Closed
Assignees
Milestone

Comments

@brozkeff
Copy link

brozkeff commented Jan 11, 2018

Expected behaviour

When using Windows Explorer context-menu "Share with ownCloud", tab Public links, and Create new link, the default name of this public link should always be working. If the filename is longer than the 64char limit ownCloud has for public link names, the desktop client should automatically shorten this name so user does not have to manually change anything.

Actual behaviour

If the filename is long, the owncloud client 2.4.0 (build 8894) on WIndows concatenates (filename) + link to the box left to the "Create new" button, but when user clicks on this "Create new" the client replies on the bottom with a red text error saying "Share name cannot be more than 64 characters".

Steps to reproduce

  1. create file with filename longer than 64 char (or 60 char)
  2. try to create public link without changing the default name "(filename) + link"
  3. link is not created and owncloud client writes the error message

Server configuration

Operating system: Linux Ubuntu Server 14.04.5

Web server: Apache 2.4.7

Database: MySQL 5.5.58

PHP version: 7.0.26-2+ubuntu14.04.1+deb.sury.org+2

ownCloud version: 10.0.4 (correction from 10.0.2, noticed the server was already upgraded)

Client configuration

Client version: 2.4.0 build 8894

Operating system: Windows 10 Pro 32bit

OS language: Czech

Installation path of client: default

@SamuAlfageme
Copy link
Contributor

@brozkeff yup, indeed it's a server known limitation. There's a discussion ongoing in owncloud/core#29913

Also see related: owncloud/ios-legacy#981 - Thanks for your report!

@brozkeff
Copy link
Author

@SamuAlfageme Server limitation 64char may be OK but the issue is in the client that even does not know this known server limitation and proposes INVALID public link share name. Since now the share link name is proposed by CLIENT it should be CLIENT proposing a valid less-than-64-char-link and automagically shorten it if it is longer than 64char. Yes if this default link name generation would be done server-side and client would just display the default proposal from the server than it would be server issue as it proposed invalid name that the server itself cannot accept few seconds later.

@ckamm ckamm self-assigned this Jan 11, 2018
@ckamm ckamm added this to the 2.4.1 milestone Jan 11, 2018
ckamm added a commit that referenced this issue Jan 12, 2018
Eventually there might be server API for default share name generation.

See owncloud/core#29913
@ckamm
Copy link
Contributor

ckamm commented Jan 12, 2018

The PR implements eliding to 64 characters until a different solution comes along.

@SamuAlfageme SamuAlfageme added the ReadyToTest QA, please validate the fix/enhancement label Jan 15, 2018
ckamm added a commit that referenced this issue Jan 17, 2018
There's a 64 character limit and we don't want to accidentally exceed
it.

Eventually there might be server API for default share name generation.

See owncloud/core#29913
ckamm added a commit that referenced this issue Jan 17, 2018
There's a 64 character limit and we don't want to accidentally exceed
it.

Eventually there might be server API for default share name generation.

See owncloud/core#29913
@SamuAlfageme
Copy link
Contributor

Closing as workaround until owncloud/core#29913 gets solved somehow and we can either recreate the server behavior or drink some sort of default share name from the ocs/share API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants