failed to open stream: File name too long

[nazar-pc]

Steps to reproduce

1. Create file with name that is close to filesystem limit of 255 bytes (say 253 bytes)
2. Try to sync the file

Expected behaviour

File is synchronized correctly

Actual behaviour

File is not synchronized correctly because Nextcloud adds .ocTransferId**********.part suffix to the end of the file name and thus exceeds filesystem limit for the file name length.

Additional details

I've got this long file name by synchronization of directory that contains eCryptfs data.

My local filesystem is btrfs, filesystem on server is ext4, both limited by 255 bytes for the filename.

Using completely random controllable filenames during uploading will solve issues like this once and forever.

Server configuration

Operating system: Debian Jessie under Docker

Web server: Nginx 1.11.10

Database: MariaDB 10.1.22

PHP version: 7.0.17

Nextcloud version: 11.0.2

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

Where did you install Nextcloud from: https://github.com/nazar-pc/docker-webserver-apps/tree/master/nextcloud

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

Are you using encryption: no

Logs

Nextcloud log (data/nextcloud.log)

Nextcloud log

``` { "reqId" : "***", "remoteAddr" : "****", "app" : "PHP", "message" : "fopen(\/data\/nginx\/www\/data\/nazar\/files\/Nextcloud\/Encrypted\/ECRYPTFS_FNEK_ENCRYPTED.FWaZ3jSvM8HFIkYWHAexJ2WpOyhTopXGRhjBXNoIYclgjXbtIzBdPW1r8k--\/ECRYPTFS_FNEK_ENCRYPTED.FeaZ3jSvM8HFIkYWHAexJ2WpOyhTopXGRhjB38DwyoKD5SxcCU7QOetpI6bdC4EOd1t4q-voY-cm3NbMJ2sJEtsxmOvrVRdX1IdrLFx3J8LoIaSDFfhzfWsquuOO50JyIHM1MdNjfabjtgfLyVV1TQq-mzTV9MKUE8izTckfeMkVD.LjcKqy5s0A-FEVkxyosYAdqrxcmYoiFFgpf2amE6gmMW4J-mj6qG1x.ocTransferId1216630867.part): failed to open stream: File name too long at \/data\/nginx\/www\/lib\/private\/Files\/Storage\/Local.php#287", "level" : 3, "time" : "2017-03-24T19:28:36+00:00", "method" : "MOVE", "url" : "\/remote.php\/dav\/uploads\/nazar\/3759697667\/.file", "user" : "nazar", "version" : "11.0.2.7" } ```

[FlorentCoppint]

Having the same problem here. An Encfs file having a 238 characters filename, Nextcloud adds 27 characters which exceed 255 chars limit.

[MorrisJobke]

cc @icewind1991

[ssorgatem]

I have the same issue with Nextcloud 12.0.0, with btrfs on both ends.

[subvillion]

It's about NTFS filename 255 chars limitation. BUT! I have similar issue and nextclud calculate not filename len, but FULL path + filename len!!!

ex: /data/a.andreev/files/Dokumenty Ideco.ru/Dokumenty Ideco.ru/API Simlobova/Yandex/Otkrytie/Dogovor 00000-01 от 01.01.2011 с ЗАО _Ideco.ru_ Оказание информационных услуг по предоставлению сведений о информационных запросах (2166181v2) изм_5.4.docx.ocTransferId1153031166.part

Filename len - 184ch Full name len - 274ch

And sync stops! 👎

[nazar-pc]

@MorrisJobke, can we expect this to be fixed in near future? Using hash function instead of original file name would fix this issue quite easily.

[jaltek]

Same here by using external Local Storage and gocryptfs:

fopen(**<path+verylongname>**TransferId596266159.part): failed to open stream: File name too long at /srv/www/nextcloud/html/lib/private/Files/Storage/Local.php#277

[pavelcdn]

15 version nc , bug still work :(

[hottwister]

Yes, it's a bug for me too NC 15.0.5

[lucasff]

I have it using Docker and data directory is a ext4 partition

[brainchild0]

Confirmed. Sync between two Linux systems, where both sides are confirmed to support 255-character filename length, fails for file names as short as 230 characters. Update: I created a test, to discover that the maximum length that synchronizes is 228 characters.

Client: Nextcloud client v 2.5.2git, Linux Server: Nextcloud v 16.0.4, Linux

[cuzrawr]

Confirmed. Sync win <> linux, Error while copying file to target location (copied bytes: 0, expected filesize: )

and get failed to open stream: Filename too long at /var/www/html/lib/private/Files/Storage/Local.php#301 Please fix this.

Server 17.0.1

[juliushaertl]

The main issue here is that with chunked uploading, .ocTransferId[randomId].part is added to the filename in https://github.com/nextcloud/server/blob/68748d4f85dd23238aaafb787b1c341f0f2f0419/apps/dav/lib/Connector/Sabre/File.php#L150, so while our check in https://github.com/nextcloud/server/pull/18163/files#diff-7337f1531a1ef5d02f2a7488e6102716R538 still passes writing the file to the filesystem fails.

We probably could try to hash the filename for storing the part files and only use the full name when assembling the chunks.

cc @GretaD as we talked about that

[Nillouise]

Same here in nextcloud 19.0.3, any workaround?

[szaimen]

Hi, please update to at least 23.0.12 and report back if it fixes the issue. Thank you!

[nazar-pc]

@szaimen please reopen. The issue 100% exists and there wasn't any PR that implied fixing this issue.

I just created file with the same name as in original report and it failed exactly the same way as 6 years ago, it is trivial for anyone to verify.

Original report both explains what happens and how to fix it.

[szaimen]

which nc version did you test?

[nazar-pc]

25.0.4, but I have no reason to believe it is fixed in any git version either.

[nazar-pc]

Just create file named ECRYPTFS_FNEK_ENCRYPTED.FeaZ3jSvM8HFIkYWHAexJ2WpOyhTopXGRhjB38DwyoKD5SxcCU7QOetpI6bdC4EOd1t4q-voY-cm3NbMJ2sJEtsxmOvrVRdX1IdrLFx3J8LoIaSDFfhzfWsquuOO50JyIHM1MdNjfabjtgfLyVV1TQq-mzTV9MKUE8izTckfeMkVD.LjcKqy5s0A-FEVkxyosYAdqrxcmYoiFFgpf2amE6gmMW4J-mj6qG1x (or any other of a similar length) and you'll see the error yourself.

[ChristofferKarlsson]

Still an issue on version 29.0.