SUMMARY Transferring a file with name containing 126 characters or more from local machine onto remote samba share through Dolphin results in dialog error Could not write to [filenamewith126+charactershere][filenamewith126+charactershere].part If transferring file with name containing 125 characters or less, it will work. The type of character used (letter, number, symbol, space) does not affect this. For some reason, the dialog message containing the error repeats the name twice, but that's likely another bug, please tell if I should make another bug report for that. Will gladly provide more information. STEPS TO REPRODUCE 1. Copy or cut any file containing 126 characters or more in its name. 2. Paste on samba share folder which you have due access to and no permission problems whatsoever. OBSERVED RESULT Error dialog containing "Could not write to filenamefilename.part", no quotes. EXPECTED RESULT Successful file transference. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon Git Unstable (completely updated as of the submission of this bug) KDE Plasma Version: 5.15.80 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.2 ADDITIONAL INFORMATION Always reproducible. Tested on three different samba shares. File transference occurs successfully on SSH/SFTP. Reproducible regardless of using tabs, split, separate windows or from desktop onto share.
I forgot to mention two things, sorry: The easiest way I found to reproduce this and count characters was naming a file as 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 which should help reproduce. For easy counting, separate it into bundles of 10 characters per line on Kwrite/Kate. Remove last character, and transference works fine. The other thing is that it is possible to create a file with 126 characters or more on the samba share itself, and transference is fine from samba share onto the local machine.
I can confirm, smbc_open returns EINVAL for opening such a file for reading. Doesn't look like an issue on our side, though.
Created attachment 118587 [details] error message Confirmed here. And the error message looks horrible. samba 4.9.4 Operating System: Arch Linux KDE Plasma Version: 5.15.2 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1
At least the error message should be less horrible now with https://cgit.kde.org/kio.git/commit/?id=d996ee0a4453f39726847bd60951c60a2b30194d in Frameworks 5.56.
(In reply to Nate Graham from comment #4) > At least the error message should be less horrible now with > https://cgit.kde.org/kio.git/commit/ > ?id=d996ee0a4453f39726847bd60951c60a2b30194d in Frameworks 5.56. Confirmed on Arch Linux after update to frameworks 5.56. :)
(In reply to Kai Uwe Broulik from comment #2) > I can confirm, smbc_open returns EINVAL for opening such a file for reading. > Doesn't look like an issue on our side, though. Kai, where do you think this bug should be reported instead? I'll gladly report to the right place. Just to mention a real situation where this bug can affect users: Yesterday this issue occurred at the translation agency I work with, a colleague was attempting to make a backup copy before a clean reinstall of the system and put it on the samba share, the operation couldn't finish before I located and renamed all 4 files that were more than 126 characters long from within 6 folders. Dolphin search was of great help in this case. While naming files like this is unpractical and unreasonable, clients occasionally send such files to us, this bug doesn't occur on MATE nor Windows, and the workaround is rather time consuming.
no longer reproducible on my system. Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1
Cannot reproduce it on latest stable neon either, neither against a samba nor windows server. Anyone still able to reproduce this on kf5.67 + kio-extras19.12.2?
Works for me too with the original description and a file called "123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456"