This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Deleting files - diff behaviour btw Dolphin and other FMs?

Tags: None
(comma "," separated)
shurato
Registered Member
Posts
17
Karma
0
Home partition, 100GB.
Data partition, 10TB , mounted using "User Session Defaults".

Now, in Thunar, when I delete a 90GB folder on the data partition, it is moved to the ".Trash-1000" folder within the data partition - the action is completed instantaneously.
The same is true for Nemo as well.

However, in Dolphin, when I delete the same 90GB folder on the data partition, it is moved to the Home partition "/home/user/.local/share/Trash/files/", consuming time for the data transfer, and then it will tell me my Home partition is full.

I don't understand why Dolphin behaves in such a way.
In any case, I don't think the default "delete" action in Dolphin, which involves moving the data from one partition to Home partition, suits my usage.
How should I configure Dolphin such that it will just move to the "thrash" folder of respective partitions?
User avatar
Section_8
Registered Member
Posts
61
Karma
0
OS
This is interesting.

I am running
Operating System: Gentoo Linux
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Kernel Version: 4.19.97-gentoo
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 15.7 GiB of RAM

I have several subdirectories of $HOME bind-mounted to directories on a big HD partition. Only one of these has its own functioning trash folder. This can be seen in my dolphin configuration/trash tab. $HOME and one of these sub-directories is listed here. I can't find anything to explain why only this sub-directory is listed here and none of the others.

If I delete a file in one of these other sub-directories, a .Trash-1000 directory is created if it doesn't already exist, but it is not used. Instead, the deleted file is moved to $HOME/.local/share/.Trash
shurato
Registered Member
Posts
17
Karma
0
Section_8 wrote:This is interesting.

I am running
Operating System: Gentoo Linux
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Kernel Version: 4.19.97-gentoo
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 15.7 GiB of RAM

I have several subdirectories of $HOME bind-mounted to directories on a big HD partition. Only one of these has its own functioning trash folder. This can be seen in my dolphin configuration/trash tab. $HOME and one of these sub-directories is listed here. I can't find anything to explain why only this sub-directory is listed here and none of the others.

If I delete a file in one of these other sub-directories, a .Trash-1000 directory is created if it doesn't already exist, but it is not used. Instead, the deleted file is moved to $HOME/.local/share/.Trash

Hmm... Linux has been around for years.
And u're making me feel like i'm the 1st one (a Linux noob who has barely 2 months of experience in Linux) to discover this issue?
;D ;D

Anyone has a get around solution?
Or is Dolphin designed to be this way, in contrary to all other FMs?
ldcdc
Registered Member
Posts
3
Karma
0
Designed? Not really, though there appear to be arguments about that too.

There is a 10 years old bug about the Trash issue affecting KDE/Plasma: https://bugs.kde.org/show_bug.cgi?id=76380

I get the feeling that some in the KDE team think this is how freedeskop specifications are supposed to work like, and while they do understand the specifications correctly, they fail to understand that there is still a bug to be looked at here. I suspect few of the KDE devs bother to use other DEs for sufficient amounts of time to notice that the Trash works properly there.

I've been using other DEs for the last 6 or so years, and been blessed with not having to deal with this issue anymore. The other DEs must all be in the wrong, and KDE/Plasma in the right. :P

If one searches around, one finds that many Plasma users end up preferring to just delete things irreversibly using shortcut keys, instead of moving them to Trash. Some are even asking how to disable trash entirely, because it is malfunctioning. That is perfectly understandable, given that a typical modern setup uses an SSD for the OS, and a large HDD for data. Who wants to move every big data file that they delete to the SSD trash and waste time and SSD writes?

I would suspect that most casual users have no idea that something is wrong though, and they're just living with it, thinking this is how it's supposed to be. Deleting files just takes a lot of time.

Now, in Thunar, when I delete a 90GB folder on the data partition, it is moved to the ".Trash-1000" folder within the data partition - the action is completed instantaneously.
The same is true for Nemo as well.


This Is this on the same system? Simply using different file managers yields different behaviors?
shurato
Registered Member
Posts
17
Karma
0
ldcdc wrote:Designed? Not really, though there appear to be arguments about that too.

There is a 10 years old bug about the Trash issue affecting KDE/Plasma: https://bugs.kde.org/show_bug.cgi?id=76380

I get the feeling that some in the KDE team think this is how freedeskop specifications are supposed to work like, and while they do understand the specifications correctly, they fail to understand that there is still a bug to be looked at here. I suspect few of the KDE devs bother to use other DEs for sufficient amounts of time to notice that the Trash works properly there.

I've been using other DEs for the last 6 or so years, and been blessed with not having to deal with this issue anymore. The other DEs must all be in the wrong, and KDE/Plasma in the right. :P

If one searches around, one finds that many Plasma users end up preferring to just delete things irreversibly using shortcut keys, instead of moving them to Trash. Some are even asking how to disable trash entirely, because it is malfunctioning. That is perfectly understandable, given that a typical modern setup uses an SSD for the OS, and a large HDD for data. Who wants to move every big data file that they delete to the SSD trash and waste time and SSD writes?

I would suspect that most casual users have no idea that something is wrong though, and they're just living with it, thinking this is how it's supposed to be. Deleting files just takes a lot of time.

Dolphin has many useful features, ie. nice to have, but not essential - eg. grouping, removable side panel, etc.
However, Nemo has all the essential features, but none the "out-of-the-world" features, particularly - it won't transfer 1TB file from data partition to Home partition when u press "delete", and displaying available space on partition by byte.
The more I use KDE, the more I feel KDE team is working from their own universe - complete disconnection from user space, lack of understanding on how user uses a File Manager, and lack of friendly/timely response to user's feedback/request.

ldcdc wrote:This Is this on the same system? Simply using different file managers yields different behaviors?

Yes, still within KDE DE, installing Thunar or Nemo, both file managers would behave by using ".Trash-1000" folder.
In Nemo and Dolphin, when u delete a file, it would appear in Thrash on both file managers.
But, only files deleted in Dolphin, would be detected by KDE's Thrash Applet from Desktop Panel, thus turning it "red".
However,
when u empty the Thrash in Dolphin, all Thrash would be emptied, including Nemo's.
when u empty the Thrash in Nemo, all Thrash would be emptied, but if u open the Thrash using KDE's Thrash Applet from Desktop Panel, the deleted files would still appear in the Thrash, and attempting to delete it would yield an error.
thierrybo
Registered Member
Posts
1
Karma
0
Just a test I did with a samba share mounted with autofs. The deletion does not copy the file locally, instead it creates a .Trash-1000 at the root of each samba Share. And if you empty the recycle bin it is deleted from the share.

Operating System: Devuan GNU/Linux 4
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.10.0-7-amd64
OS Type: 64-bit
Processors: 2 × AMD Ryzen 5 3600 6-Core Processor
Memory: 1.9 Gio of RAM
Graphics Processor: llvmpipe


Bookmarks



Who is online

Registered users: Bing [Bot], gfielding, Google [Bot], markhm, sethaaaa, Sogou [Bot], Yahoo [Bot]