sync error: File name too long

[voxspox]

TODO

• create long filename on server
  • sync with server
  • sync with windows
  • sync with linux
  • sync with mac
• create long filename on windows
  • sync with server
  • sync with windows
  • sync with linux
  • sync with mac
• create long filename on linux
  • sync with server
  • sync with windows
  • sync with linux
  • sync with mac
• create long filename on mac
  • sync with server
  • sync with windows
  • sync with linux
  • sync with mac

Steps to reproduce

1. add file on another computer (macOS) or webinterface
2. Nextcloud sync client (2.3.3) on my computer (Linux) fails with "File name too long"

Expected behaviour

sync file

Actual behaviour

• file is synced on other computer and server
• file is not synced on my computer
• error message is shown: "File name too long"

charaters:
filename: 150
filepath: 211 (inside cloud folder)
absolute filepath: 236 (in the filesystem)

if I reduce the filename to 144 chars the file gets synced as usual.

Nextcloud version:
13.0.4

There is no problem on the macOS computer, but on my Linux computer. May be this issue is related to Linux, ecryptfs, ext4.

[esalgado]

This happens to me as well. In file synced from a windows client, does not sync in Linux, ecryptfs, ext4 client.

[rohlandm]

I also tried to sync a folder encrypted using gocryptfs, and some files fail to sync because of "File name too long"

Edit:
Server: 16.0.1, Debian 9, official Docker Image
Client: 2.5.1, Ubuntu 19.04

[akurzawa]

Server 17, client 2.6 windows.

Filename too long
Is it too long for nextcloud indeed?

[PHP] Error: file_put_contents(/CloudBackupData/xxx.xxx/files/Pulpit/USTAWY PRZEPISY NOTATKI/Przekształcenie prawa użytkowania wieczystego gruntu zabudowanego na cele mieszkaniowe w prawo własności tego gruntu - procedura realizowana na podstawie przepisów ustawy z dnia 20 lipca 2018 r. o przekształceniu prawa użytkowania.html.ocTransferId2014978277.part): failed to open stream: File name too long at /var/www/nextcloud/lib/private/Files/Storage/Local.php#488

PUT /remote.php/dav/files/xxx.xxx/Pulpit/USTAWY%20PRZEPISY%20NOTATKI/Przekszta%C5%82cenie%20prawa%20u%C5%BCytkowania%20wieczystego%20gruntu%20zabudowanego%20na%20cele%20mieszkaniowe%20w%20prawo%20w%C5%82asno%C5%9Bci%20tego%20gruntu%20-%20procedura%20realizowana%20na%20podstawie%20przepis%C3%B3w%20ustawy%20z%20dnia%2020%20lipca%202018%20r.%20o%20przekszta%C5%82ceniu%20prawa%20u%C5%BCytkowania.html

[zlukenic]

same problem but error message is not god. File name is not to long it's just because there is strange caracter just before the file extension.
in my case the file name was "BL PRET ATELIER INCUBES BLI21000 2017.05.03�.pdf"

resolution: just rename file by deleting one caracter before the extension (.pdf)

[alexanderdd]

Ideally, Nextcloud Web interface should not accept file names (when you create/rename) that are too long, that would be an issue in server - anybody know if there is an issue about that already? I only found this but it is slightly different issue nextcloud/server#4046

For the client, there should be a more helpful error message telling the user how to resolve the problem. Ideas:

• "File name exceeds maximum of 255 characters"
• "File name too long. Click here to truncate to maximum allowed length"

[danielwbn]

I have the same error: the linux client (v 3.0.2) fails to download files with long file names (in my case 140 chars). If I shorten the names in the web client (NC 19.0.4) they download fine. Also, I can create files with such long names (or rename the files after download to original long name) on the linux PC (ext4, ecryptfs) just fine and they do sync back to nextcloud server via the same client.

[danielwbn]

I just updated to NC client version 3.1.0 (Ubuntu) and still have the same error

[github-actions]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[danielwbn]

NC client 3.2.1 still gives same error.
However, I am beginning to think it might not be related to the NC client, but to my system. I have not investigated this further, but when I call "getconf NAME_MAX ./" (which I think returns the maximum filename length) in the sync folder in question (or in fact anywhere in my home dir) I get 143 in return. Calling "getconf NAME_MAX /" returns 255.

[alexanderdd]

This happened to me a few days ago on Nextcloud 20.0.10
A long filename was created online but could not be synced to my linux machine with the error "file name too long"

[mgallien]

Can you test against the latest version of desktop client ?
If you can reproduce it, we will need the desktop logs (at least) to be able to understand what is going wrong.
If this is fixed, can you close the issue ?

[danielwbn]

nextcloud desktop 3.2.2, I get the same error. The log file is probably way too long to paste here (>50MB), but I think I found the relevant lines:

2021-06-14 11:45:19:078 [ info nextcloud.sync.propagator ]: Starting CSyncEnums::CSYNC_INSTRUCTION_NEW propagation of "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" by OCC::PropagateDownloadFile(0x558d082b6390) 2021-06-14 11:45:19:078 [ debug nextcloud.sync.propagator.download ] [ OCC::PropagateDownloadFile::start ]: "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" 1 2021-06-14 11:45:19:078 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::bindValue ]: SQL bind 1 "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" 2021-06-14 11:45:19:078 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::exec ]: SQL exec "SELECT tmpfile, etag, errorcount FROM downloadinfo WHERE path=?1" 2021-06-14 11:45:19:078 [ warning nextcloud.sync.propagator.download ]: could not open temporary file "/home/daniel/Nextcloud/.12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md.~2efc2ce" 2021-06-14 11:45:19:078 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::bindValue ]: SQL bind 1 "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" 2021-06-14 11:45:19:078 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::exec ]: SQL exec "SELECT lastTryEtag, lastTryModtime, retrycount, errorstring, lastTryTime, ignoreDuration, renameTarget, errorCategory, requestId FROM blacklist WHERE path=?1" 2021-06-14 11:45:19:079 [ warning nextcloud.sync.propagator ]: Could not complete propagation of "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" by OCC::PropagateDownloadFile(0x558d082b6390) with status OCC::SyncFileItem::NormalError and error: "Der Dateiname ist zu lang" 2021-06-14 11:45:19:079 [ debug nextcloud.sync.statustracker ] [ OCC::SyncFileStatusTracker::slotItemCompleted ]: Item completed "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" OCC::SyncFileItem::NormalError CSyncEnums::CSYNC_INSTRUCTION_NEW 2021-06-14 11:45:19:079 [ warning nextcloud.gui.activity ]: Item "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" retrieved resulted in "Der Dateiname ist zu lang" 2021-06-14 11:45:19:079 [ warning nextcloud.gui.activity ]: Item "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.md" retrieved resulted in error "Der Dateiname ist zu lang"

[mgallien]

@danielwbn I will need more detail because I cannot reproduce the bug with a build from master branch running on Windows and Linux

Could you try sending a full log archive by syncing a test directory with only your test file ?

[kintaro1981]

Same problem with latest macos client.

I have a 251 characters filename (254 with extension) and is not getting synced.

[Rudder2]

I too have this same problem. I didn't have the problem till I encrypted my home directory on KUbuntu 22.04 with ecryptfs 2 days ago.

$ getconf NAME_MAX ./
143

$ getconf NAME_MAX /
255

My original file name had exactly 144 characters not including the extension, 148 with extension. I lowered it to 143 including the extension and it still didn't work. I've lowered the name again to 134 characters including the extension and still NextClould wouldn't sync the file.

I did testing in my home folder and discovered that the 143 character max includes the extension. I was able to manually create all variations of the file name except the original file with 148 characters with the extension. I can confirm that the max characters retrieved with the getconf NAME_MAX is the characters including the extension.

Just a note, LibreOffice cannot edit a file unless the filename is small enough to create a lock file which appends 7 characters to the beginning of the file making the max characters including the extension 143-7=136 characters.

The only way NextClould reliably syncs the file is at a max character count of 133 characters including extension on my ecryptfs file-system. 10 characters lower than the max that the system can handle is the only file length that Nextcloud can sync and I tested this on my unencrypted system also and was only able to sync a file name max of 245 characters reliably. The 10 character less than system max is a good rule because of lock files. Just need to have better errors to help someone understand the limits.

Anyone who wants the security of encrypting your home folder with ecryptfs or loves huge descriptive filenames will run in to this problem eventually.

I will gladly give more information to help correct this problem. Just an idea, maybe doing like micro$haft winblow$ does, shorten the file name to the correct size with ~1 on the end but still know it's the full name like when we went from DOS with 8 characters + extension to winbow$ 95 which could handle 255 characters?

[Pilzinsel64]

One solution I had to implemented recently in another program and also have seen in some others is to use UNC paths (so basically prefix them when doing API calls, but depends on OS).
But I'm not sure if this would even work here with the used APIs and VirtualFiles and on all platforms. It is just an idea. :)

[Marwe]

Some details about the eCryptfs filename length from an author: https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834#32834
143 is maximum (ASCII chars), 140 safe, other encodings may reduce the maximum filename length further.
Part of the filename is used for salt, if I remember correctly, and filename is padded to a fixed length, you find them in /home/.ecryptfs/$USER/.Private/

[...] filenames longer than 143 characters start requiring >255 characters to encrypt. So we (as eCryptfs upstream developers) typically recommend you limit your filenames to ~140 characters.

So this is clearly not related to Nextcloud, but the client filesystem.
The error can be triggered with any software, that creates files (e.g. with cp, rsync you can encounter the same).

[akurzawa]

As we can clearly see this is a problem (despite not produced by current nextcloud code itself indeed)

Problem is that no one spotted this error during the phase of the filesystem design.

As nexcloud is more popular people will have more and more data with more complex and deeper directory structure and with longer file names in theirs systems.

This issue become larger problem sooner or later.

So the question is what next cloud developers are going to do about it?

Problably for now it's best to ignore this problem because it would incorporate redesign of file system (files would not be stored as filenames but rather as eg. uuid file name format on file system + corresponding entry with proper filename in the database) and I can only imagine what amount of work would be required to accomplish that change.