SUMMARY Data loss due to an unsuccessful folder move task. STEPS TO REPRODUCE 1. Delete a folder (e.g. ~/.kde) 2. Open Trash within Dolphin 3. Drag & Drop the deleted folder to the Folder Desktop > Select Move OBSERVED RESULT Data loss. There's a message that the copy was not successful, but the old folder is no longer visible in trash (however .kde was exisiting in ~/Desktop). EXPECTED RESULT No data loss. If a folder move is not successful, the old folder shouldn't be deleted & there should be no folder at the target location. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.51.0 Qt Version: 5.11.1 ADDITIONAL INFORMATION
>however .kde was existing in ~/Desktop So where is the data loss then if the folder exists at the destination. When I've dragged folders from trash to desktop I've no had any issues. Please can you also confirm the location of: configure desktop -> location
>So where is the data loss then if the folder exists at the destination. Usually, I would expect my OS to tell me what was not moved/copied exactly. Nevertheless: looking at the .kde folder on my desktop, I see that the symbolic links & cache was not moved. You should be able to reproduce it with the exact folder: 1. backup ~/.kde 2. delete ~/.kde (move to trash) 3. Open Trash within Dolphin 4. Drag & Drop the deleted folder to the Desktop (folder view) > Select Move (my desktop is located at the standard location ~/Schreibtisch, localalized german, guess in english this is ~/Desktop) Reproduced it again and will attach a screencapture. What I think is critical is not the unsuccessful move, but that the source is deleted, even if the move is unsuccessful and there is the system notification (that is not showing what file / folder specifically was not moved successful).
Created attachment 116304 [details] Unsuccessful folder move, system tray notification The system tray notification at the end says: move task failed.
(to other readers, attachment plays if you download it first, not if you run in the browser for some reason) >What I think is critical is not the unsuccessful move, but that the source is deleted Assuming it's not a false message, I agree I've tried this a few times and can't reproduce. Can you include output of "ls -Rl ~/.kde" (that might have personal info so please check) there's an "access denied " error that I want to reproduce
Sure, output below. But the access denied error your referring to is most probably due to the deleted folder in trash. Because the source is deleted, the source folder is no longer accessible in Dolphin. /home/ss/.kde: insgesamt 4 lrwxrwxrwx 1 ss ss 20 Nov 14 12:50 cache-ss-desktop -> /var/tmp/kdecache-ss drwxrwxr-x 4 ss ss 4096 Nov 12 18:32 share /home/ss/.kde/share: insgesamt 8 drwxrwxr-x 3 ss ss 4096 Nov 14 01:25 apps drwxrwxr-x 2 ss ss 4096 Nov 12 21:21 config /home/ss/.kde/share/apps: insgesamt 4 drwxrwxr-x 2 ss ss 4096 Nov 14 02:26 color-schemes /home/ss/.kde/share/apps/color-schemes: insgesamt 4 -rw-r--r-- 1 ss ss 2745 Nov 14 02:26 Breeze.colors /home/ss/.kde/share/config: insgesamt 8 -rw------- 1 ss ss 29 Nov 12 20:02 kdebugrc -rw------- 1 ss ss 3289 Nov 12 21:21 kdeglobals
BTW: I was able to reproduce with the live image of http://cdimage.ubuntu.com/kubuntu/releases/18.10/release/kubuntu-18.10-desktop-amd64.iso I only moved .kde to trash & drag & dropped it to desktop. There was no error notification there, but the folder was also not moved. It was deleted from trash, but didn't show up on Desktop at all. Sth. is totally wrong here :(
>but didn't show up on Desktop at all. Sth. is totally wrong here :( The desktop doesn't show hidden files, it not showing is understandable.
Of course, but it was also not shown in Dolphin (data loss). Were you able to reproduce with a clean live? Let me know if you need additional infos ;)
Created attachment 116330 [details] Link not copied & no message of faulty copy With the attached folder, the (broken) link "cache-ss-desktop" is not copied. In addition, here we get not even a system notification that the move was faulty. Same procedure: 1. extract temp1.tar.gz to Desktop & remove it to trash 2. Open Trash within Dolphin 3. Drag & Drop the deleted folder to the Desktop BTW: maybe related, but these kind of errors seem to be common: https://bugs.kde.org/show_bug.cgi?id=162211 https://www.reddit.com/r/linux/comments/1nvho0/warning_theres_a_horrible_bug_in_kde_that_doesnt/
Interestingly my test cases on my desktop I don't have that symlink. (will try the live image this eve) That's a very good data point! Moving that folder did not copy the dead symlink (a confirmed bug!). But if I put other files in .kde they do copy. Which doesn't sound like what you initially described? Moving that folder from file:// does keep the original link Moving the folder from trash:// to file:// (not desktop) still reproduces the issue about the dead symlink Another note is that it's not visible if I search the trash. The code path for trash:// does do special things with links. It used to follow the link, then that was disabled but that also disabled the handling of dead links. It does try to list the link though. Do you know if in any of your other cases it was anything other than the (dead?) symlink(s) missing? >https://bugs.kde.org/show_bug.cgi?id=162211 Heh, that reddit thread had me as the top comment from 5 years ago. I'd like to keep this focused on whatever we can actually reproduce is. Given file to file works, it's looking to be a relatively scoped minor bug with handling symlinks in trash. But I'll try and use this to see if trash is actually posting an error that we should be catching further up.
I tried the live CD: I do reliably get the error message on the second subdir of a folder; where kioslave is spawning a second slave for the concurrent listDir. /but/ I have no data loss, everything copies fine. Nothing relevant was in the error message of the log. I think it's probably best to treat the loss of a dead symlink and the Kubuntu first-run error as two separate bugs. I'll split this tomorrow, and I'll handle both of those things.
Great news (spent the whole day restoring backups and was currently looking for more). I also had no other missing files, apart from the symlink. However, notifications of failed copies / moves are worrying, even more so if the original is no longer available. Nevertheless, fantastic to have you here to dig into this, many thanks ;) (we have hundreds of SLES servers in our company, where our linux admins need to proof via checksums that the eventual migration was successful. So I guess Linux/rsync/robocopy/KDE can copy files reliably in general, however guess these trash issues are more relevant & important to the end user that uses linux privately on his desktop)
Interestingly, dead symlinks in the root directory work fine. Whereas deadsymlinks in a subdir do not.
Fix on phabricator for the issue in the title. I'll look into this Kubuntu warning separately.
Git commit 4f5b4fd218ca40826300b59dadd5d360b877b9d5 by David Edmundson. Committed on 19/11/2018 at 21:54. Pushed by davidedmundson into branch 'master'. [ioslaves/trash] Handle broken symlinks in deleted subdirectories Summary: The trash ioslave currently handles: - working symlinks at the toplevel - broken symlinks at the toplevel - working symlinks in subdirectories but broken symlinks in a subdirectory get lost. This is because subdirs are populated from a QDir::listEntries in the subdirectory folder, which by default filters out broken symlinks. It's important to list them so that we we restore the directory as otherwise we lose data. The symlink could become non-dead once files are restored. Test Plan: Relevant unit test Reviewers: dfaure Reviewed By: dfaure Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D17021 M +31 -1 src/ioslaves/trash/tests/testtrash.cpp M +2 -0 src/ioslaves/trash/tests/testtrash.h M +1 -1 src/ioslaves/trash/trashimpl.cpp https://commits.kde.org/kio/4f5b4fd218ca40826300b59dadd5d360b877b9d5