|Summary:||rename() falling over case insensitivity|
|Product:||[Frameworks and Libraries] kio-extras||Reporter:||Patrick Silva <bugseforuns>|
|Component:||Samba||Assignee:||Plasma Bugs List <plasma-bugs>|
|Severity:||normal||CC:||kfm-devel, nate, sitter|
|Latest Commit:||https://invent.kde.org/network/kio-extras/commit/ed0a8e905df6c5e0ede3486f38afdb555ef80ce0||Version Fixed In:||21.04|
Description Patrick Silva 2020-12-19 16:42:32 UTC
Created attachment 134209 [details] screen recording SUMMARY I can't reproduce this bug with local files. STEPS TO REPRODUCE 1. have a folder in a Samba share containing these two files: file.txt and File1.txt 2. try to rename File1.txt to file1.txt 3. OBSERVED RESULT "File Already Exists" dialog unexpectedly shows up. Watch the attached screen recording please. EXPECTED RESULT File1.txt should be renamed to file1.txt without any dialog SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2
Comment 1 Harald Sitter 2021-01-20 15:06:52 UTC
I wonder if that doesn't simply trip over case insensitivity. Supposedly samba should negotiate case sensitivity but I guess that won't matter much if we don't know what the outcome of that negotiation is.
Comment 2 Harald Sitter 2021-01-20 16:07:35 UTC
Case sensitivity is indeed the trouble there. Before the rename there's a stat call on the destination and if it exists the rename dialog is triggered. That is however falling into the case insensitivity trap as renaming a->A will have A existing because A=a. This particular problem needs addressing in kio-extras and I threw together a hack that does some in depth comparison between src and dst to figure out if they might be the same file, alas, that revealed a problem with change notifications because windows servers send FilesRemoved before the FileRenamed which makes the file disappear from dolphin's model :@ That does kind of need fixing in dolphin first though (does that code even live in dolphin?) signal time=1611157682.777775 sender=:1.3315 -> destination=(null destination) serial=19 path=/; interface=org.kde.KDirNotify; member=FilesRemoved array [ string "smb://firstname.lastname@example.org/Users/User/Desktop/New folder (6)/a" ] signal time=1611157682.778322 sender=:1.3315 -> destination=(null destination) serial=20 path=/; interface=org.kde.KDirNotify; member=FileRenamed string "smb://email@example.com/Users/User/Desktop/New folder (6)/a" string "smb://firstname.lastname@example.org/Users/User/Desktop/New folder (6)/A" signal time=1611157682.778640 sender=:1.3315 -> destination=(null destination) serial=22 path=/; interface=org.kde.KDirNotify; member=FilesChanged array [ string "smb://email@example.com/Users/User/Desktop/New folder (6)/A" ] After that FilesChanged notification dolphin should have gone "what A?" and done a stat but it didn't so the file disappeared entirely. In fact, perhaps already after FileRenamed since dolphin at that point doesn't know about neither a nor A. If that can't be fixed in dolphin or where ever I can take a look at handling it lower in the kio-extras side but from what I recall of the notification code it's actually fairly horrible to put context on these events since one file operation translations into a multitude of events, twice as many for renaming/moving.
Comment 3 Harald Sitter 2021-03-04 11:16:16 UTC
Git commit 5abd1e8e981095b2c608042982f27a35f36d1b0c by Harald Sitter. Committed on 04/03/2021 at 11:15. Pushed by sitter into branch 'master'. smb-notifier: do not send remove events on moving files windows (but not samba interestingly) will send a REMOVE event before the actual MOVE event this would mess with kio's dirlister's internal state as it'd remove the file from the model and then never try to learn about it again when it receives the move event. effectively this would remove a file from the view in dolphin when renaming it as now both the old name and the new name aren't in the dirlister model anymore. to prevent this from happening a similar hack is applied to the event order as with move merging. when a remove arrives it's not immediately emitted but queued for up to 1000ms if a move event also arrives during that time frame the remove is entirely discarded and we are left with only the move. if any other event arrives the remove is immediately sent. if nothing else arrives the timer runs out and the remove is sent. so worst case a remove is only represented in the GUI after 1s, best case it's more or less same as before with the added benefit that renaming doesn't make files disappear M +91 -3 smb/kded/notifier.cpp https://invent.kde.org/network/kio-extras/commit/5abd1e8e981095b2c608042982f27a35f36d1b0c
Comment 4 Harald Sitter 2021-03-04 11:16:23 UTC
Git commit ed0a8e905df6c5e0ede3486f38afdb555ef80ce0 by Harald Sitter. Committed on 04/03/2021 at 11:15. Pushed by sitter into branch 'master'. smb: do not assume rename files are different based on name samba is transparently supporting case sensitivity/insensitivity based on server capabilities so 'A' and 'a' may be the same file or not. To that end when a rename operation would change the capitalization of a file we need to do some extra work to figure out if that renaming would constitute an overwrite or not. Specifically we'll need to stat the source file and then compare the inode and device returned by libsmb to figure out if they are the same file. If they are then this is an in-place rename, not an overwrite and we'll skip over the error conditions to do with the dst file already existing M +34 -3 smb/kio_smb_dir.cpp https://invent.kde.org/network/kio-extras/commit/ed0a8e905df6c5e0ede3486f38afdb555ef80ce0