Bug 400990 - Broken symlinks in trash are not restored
Summary: Broken symlinks in trash are not restored
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Trash (show other bugs)
Version: git master
Platform: Kubuntu Linux
: NOR major
Target Milestone: ---
Assignee: David Faure
Depends on:
Reported: 2018-11-13 01:08 UTC by sac
Modified: 2018-11-19 21:54 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

Unsuccessful folder move, system tray notification (2.71 MB, video/mp4)
2018-11-14 11:45 UTC, sac
Link not copied & no message of faulty copy (216 bytes, application/gzip)
2018-11-15 16:24 UTC, sac

Note You need to log in before you can comment on or make changes to this bug.
Description sac 2018-11-13 01:08:27 UTC
Data loss due to an unsuccessful folder move task.

1. Delete a folder (e.g. ~/.kde)
2. Open Trash within Dolphin
3. Drag & Drop the deleted folder to the Folder Desktop > Select Move

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).

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.

Linux/KDE Plasma: Kubuntu
KDE Plasma Version: 5.14.3
KDE Frameworks Version: 5.51.0
Qt Version: 5.11.1

Comment 1 David Edmundson 2018-11-13 01:33:29 UTC
>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
Comment 2 sac 2018-11-14 11:42:31 UTC
>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).
Comment 3 sac 2018-11-14 11:45:01 UTC
Created attachment 116304 [details]
Unsuccessful folder move, system tray notification

The system tray notification at the end says: move task failed.
Comment 4 David Edmundson 2018-11-14 17:21:21 UTC
(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
Comment 5 sac 2018-11-14 18:47:39 UTC
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.

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

insgesamt 8
drwxrwxr-x 3 ss ss 4096 Nov 14 01:25 apps
drwxrwxr-x 2 ss ss 4096 Nov 12 21:21 config

insgesamt 4
drwxrwxr-x 2 ss ss 4096 Nov 14 02:26 color-schemes

insgesamt 4
-rw-r--r-- 1 ss ss 2745 Nov 14 02:26 Breeze.colors

insgesamt 8
-rw------- 1 ss ss   29 Nov 12 20:02 kdebugrc
-rw------- 1 ss ss 3289 Nov 12 21:21 kdeglobals
Comment 6 sac 2018-11-14 19:11:11 UTC
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 :(
Comment 7 David Edmundson 2018-11-14 19:34:04 UTC
>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.
Comment 8 sac 2018-11-14 21:09:41 UTC
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 ;)
Comment 9 sac 2018-11-15 16:24:05 UTC
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:
Comment 10 David Edmundson 2018-11-15 19:35:50 UTC
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?

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.
Comment 11 David Edmundson 2018-11-15 21:28:31 UTC
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.
Comment 12 sac 2018-11-15 21:52:15 UTC
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)
Comment 13 David Edmundson 2018-11-19 15:50:33 UTC
Interestingly, dead symlinks in the root directory work fine.
Whereas deadsymlinks in a subdir do not.
Comment 14 David Edmundson 2018-11-19 17:11:22 UTC
Fix on phabricator for the issue in the title.

I'll look into this Kubuntu warning separately.
Comment 15 David Edmundson 2018-11-19 21:54:19 UTC
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

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

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