Folders with long names are not moved to trash when deleted ("File name too long")

[chk1]

Steps to reproduce

1. From the webinterface create a folder with a long name that is just under the limit of the file system, e.g. 249 characters out of 255 on ext3
2. From the webinterface delete the folder

Expected behaviour

The folder is moved to trash

Actual behaviour

1. I receive an error message within the webinterface: Error deleting file "<long name>" and PHP error in the log (see below)
2. The folder is not moved to trash
3. The folder remains in the list of files and folders, it vanishes after reloading the view or navigating away and back to the origin
4. On the server's harddisk the folder is fully deleted, i.e. not found in its original place anymore, it is also not in the trash folder files_trashbin

Server configuration

Operating system: Ubuntu 16.04.3 LTS

Web server: nginx/1.10.3

Database: postgresql/9.5

PHP version: 7.0.25-0ubuntu0.16.04.1

Nextcloud version: 13.0.0

Updated from an older Nextcloud/ownCloud or fresh install: Updated from Nextcloud 12.0.4

Where did you install Nextcloud from: ZIP file from official Nextcloud website

List of activated apps:

App list

Enabled:
  - activity: 2.6.1
  - bruteforcesettings: 1.0.3
  - comments: 1.3.0
  - dav: 1.4.6
  - federatedfilesharing: 1.3.1
  - federation: 1.3.0
  - files: 1.8.0
  - files_pdfviewer: 1.2.0
  - files_sharing: 1.5.0
  - files_texteditor: 2.5.1
  - files_trashbin: 1.3.0
  - files_versions: 1.6.0
  - files_videoplayer: 1.2.0
  - firstrunwizard: 2.2.1
  - gallery: 18.0.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.1.0
  - nextcloud_announcements: 1.2.0
  - notes: 2.3.2
  - notifications: 2.1.2
  - oauth2: 1.1.0
  - password_policy: 1.3.0
  - provisioning_api: 1.3.0
  - serverinfo: 1.3.0
  - sharebymail: 1.3.0
  - survey_client: 1.1.0
  - systemtags: 1.3.0
  - theming: 1.4.1
  - twofactor_backupcodes: 1.2.3
  - updatenotification: 1.3.0
  - workflowengine: 1.3.0
Disabled:
  - admin_audit
  - encryption
  - files_external
  - user_external
  - user_ldap

Nextcloud configuration:

Config report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***removed***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "***removed***",
        "dbtype": "pgsql",
        "version": "13.0.0.14",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "php",
        "mail_smtpauthtype": "LOGIN",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Chrome 64, Waterfox 56

Operating system: Windows 7

Logs

Nextcloud log (data/nextcloud.log)

Nextcloud log

{
  "reqId": "***",
  "level": 3,
  "time": "2018-03-06T21:32:00+00:00",
  "remoteAddr": "***",
  "user": "admin",
  "app": "PHP",
  "method": "DELETE",
  "url": "/remote.php/webdav/testfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletesttess",
  "message": "rename(/srv/www/xxxxxxxxxxxxxxxxxx/html/data/admin/files/testfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletesttess,/srv/www/xxxxxxxxxxxxxxxxxx/html/data/admin/files_trashbin/files/testfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletesttess.d1520371920): File name too long at /srv/www/xxxxxxxxxxxxxxxxxx/html/lib/private/Files/Storage/Local.php#270",
  "userAgent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0.2 Waterfox/56.0.2",
  "version": "13.0.0.14"
}

Additional notes

• Server uses the ext3 file system
• Related issue? failed to open stream: File name too long #4046

[MorrisJobke]

another one for the database indexes? cc @nickvergessen

[c0fe]

Confirmed the same issue

Uncaught (in promise) TypeError: Cannot read property 'getElementsByTagNameNS' of null
    at Client._getSabreException (client.js?v=0021aa77-0:421)
    at client.js?v=0021aa77-0:706
    at <anonymous>

After a few seconds refreshing the page the folder is gone though.

[nickvergessen]

Not related to indexes at all.

The problem is: https://github.com/nextcloud/server/blob/master/core/Migrations/Version13000Date20170718121200.php#L162
So the name is 250, so adding an item with 249 work. But the trashbin adds the deletion timestamp, so you end up at 249 + .<11chars timestamp> which is 261, which is longer than 250, so writing to DB failes...

Trashbin app should either trim the name or prevent deleting such item.

[nickvergessen]

Same should happen with versions btw.

[lenusch]

I also have serveral Problems with that just appeared exspecially with Federation Share...