Disk local trash in KDE?

[JPT]

Hi,
In my old Kubuntu I added .Trash/1000 or .Trash-1000 to the root of mounted partitions. (with correct permissions of course)
This way when I deleted a file it was moved to this directory instead of the trash in home.

Now this does not work any more which puts a lot of strain on the system SSD when deleting big files.
On my old system I used softlinks to integrate external drives like this:
/home/user/Home -> /media/DATA/home/user/Home
This usually broke apparmor…
So this time I tried to use bind-mount like this:

LABEL=MANJARO                  /                ext4 errors=remount-ro,relatime 0 1
LABEL=DATA                     /run/media/DATEN ext4 relatime,nosuid            0 2
/run/media/DATA/home/user/Home /home/user/Home  none defaults,bind              0 0

could this be the cause? Where should I put the .Trash folder?
How should I integrate external partitions into my home folder?

ps. it actually does work for USB thumb drives formatted with NTFS or FAT.

thanks

[Mirdarthos]

Hi @JPT,

1. As far as I’m aware, the /run/ mount point is for temporary mounts and shouldn’t be relies on to be persistent.
2. Also, I haven’t heard about the .Trash* directory being easier on an SSD. Indeed, I do not have anything like that and my SSD’s wear is 6% in 3+ years!

$ sudo smartctl --all /dev/nvme0n1
[...]
Percentage Used:                    6%
[...]

So, I don’t really think it’s necessary.

Also see:

https://www.reddit.com/r/kde/comments/p382pz/comment/h8pdny1/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

And

@JPT

ps. it actually does work for USB thumb drives formatted with NTFS or FAT.

…this actually makes kind of sense, according to my knowledge and understanding.

Because, I think both those file systems, at least NTFS was created by Microsoft, so it does to reason that the .Trash-* subdirectory would work on them, If the directory is, as I suspect, something “created” by Microsoft.

As for the bind mounts, I also have many of those. I don’t know about the fstab entries, they might be correct or they might not. However, from my personal experience, I recommend doing them with systemd:

[root tip] [How To] Use systemd to mount ANY device

Difficulty: ★☆☆☆☆ Disk device recognition Manjaro uses udev (see Arch Wiki) to load devices at boot time. The loading of devices is arbitrary and therefore you cannot predict which device will be available at a given path. But static device names do exist and you can assign specific locations to your device and thus ensure e.g. scripts will work as expected. What to learn Overview of system mount units Structure and Content of a mount unit Mount at boot (immediate mount) Mount on demand (m…

[root tip] [How To] systemd mount unit samples

Difficulty: ★★☆☆☆ Example mount units for systemd The examples here are a supplement to the guide on systemd mount units Remember to remove the comments placed in the units - they are not writing for copy-paste but as examples. (comments is text beginning with a #) [root tip] [How To] Use systemd to mount ANY device Only use an automount unit if the device is not readily available at boot like removable devices and network locations. Important rule …

I use 'em myself, and they kind of work better than a bomb.

[Nachlese]

Is your user id 1000 ?

id -u

1000 is usually the id of the first created user - the next will have 1001 …

It needs to be a directory (a folder) - not just a file with that name.

[JPT]

thank you for your answer but I have to correct a few things.
Later I will have a look at the links you posted.

@"Mirdarthos

2. Also, I haven’t heard about the .Trash* directory being easier on an SSD. Indeed, I do not have anything like that and my SSD’s wear is 6% in 3+ years!

you misunderstoood.
it is not about the trash directory. It is about copying 10+ GB to another drive on delete. Which takes time and wears out the SSD for nothing.

Because, I think both those file systems, at least NTFS was created by Microsoft, so it does to reason that the .Trash-* subdirectory would work on them, If the directory is, as I suspect, something “created” by Microsoft.

ehm no. .Trash is default KDE trash directory. It has nothing to do with Microsoft. But FAT and NTFS thumb drives do not have any permissions on linux by default that would deny creating the directory.

[JPT]

@Nachlese

Is your user id 1000 ?

id -u

1000 is usually the id of the first created user - the next will have 1001 …

It needs to be a directory (a folder) - not just a file with that name.

Good question. User is 1000, but group differs it’s 1001. That shouldn’t be a problem.
sure it’s a folder. As I told, It used to work.

[Mirdarthos]

Ah. Cool, and sorry. Just found a .Trash-1000 directory on one of my bind mounts. However, it’s not something I knew of, it’s an ext4 file system and a mechanical hard drive.

[Nachlese]

For me, the folder gets created as soon as I delete a file that has been there on that drive.
The folder has got a substructure - two directories in it (info and files).
It gets created when I use: move to trash - there is another option to “really” delete it instantly though …

[soundofthunder]

If I understand correctly, you wish a deleted file (sent to trash) to actually go to another volume. This normally should not happen. However, if you try creating a symlink to the other volume (using the same name and path), perhaps that might work.

Alternatively, you could simply have the file delete immediately: Hold down Ctrl when you right-click, and rather than ‘Send to Trash’ select ‘Delete’.

Good luck.

[andreas85]

@soundofthunder

If I understand correctly, you wish a deleted file (sent to trash) to actually go to another volume.

Moving a file to another volume will wear down your SSD as much as deleting it

[soundofthunder]

@andreas85

Moving a file to another volume will wear down your SSD as much as deleting it

The OP seems to want to move a file, or not move it, I’m not really sure, which is why I need clarification. In fact, reading through it again, I’m even more uncertain what they want; so, I’ll just go with deleting a file immediately, as already said.

Furthermore, I’ll add that both moving or deleting a file (no matter the size) still writes to the volume, so nothing useful is actually achieved.

[MrLavender]

Worrying about SSD wear on a normal desktop computer is a complete waste of time. It’s only a concern to people running 24/7 high load servers or data centers.

My current main drive, a WD Blue SN570 1TB NVMe, has a 600 TBW endurance rating. After 2.5 years it’s at 13 TB written, so life left is 100 - (100 * 13/600) = 97.8%. At that rate I’ll be dead before it is.

[JPT]

@soundofthunder

If I understand correctly, you wish a deleted file (sent to trash) to actually go to another volume.

No, I want the opposite. I want the file to stay on the volume where it was before to avoid waiting for a rather long moving operation.

@soundofthunder

Alternatively, you could simply have the file delete immediately: Hold down Ctrl when you right-click, and rather than ‘Send to Trash’ select ‘Delete’.

Yeah, I did that. But then I cannot undo a delete without some effort.

[soundofthunder]

@JPT

Yeah, I did that. But then I cannot undo a delete without some effort.

I see. Then, you have a dilemma that has no solution; if minimising disk writes is your ultimate goal.

[varikonniemi]

moving to a trash folder under home sounds really weird, and i have not heard that before.

I have always been under the impression that the trash folder gets created to every mountpoint’s root.

[JPT]

@varikonniemi

moving to a trash folder under home sounds really weird, and i have not heard that before.

?

@varikonniemi

I have always been under the impression that the trash folder gets created to every mountpoint’s root.

Yes. If there are permissions.
But does not seem to work for my drive. No idea why.

[soundofthunder]

@JPT

home

The default (user) Trash directory is ~/.local/share/Trash. According to the specification, the user Trash directory is typically the default; if a file is deleted from another location it would be magically teleported to the home Trash. Maybe this is relevant to your issue.

The FreeDesktop.org Trash specification may help explain a few things for you. Particularly, if you scroll down to the heading of Trash directories.

Make a comparison of your system with reference to that information, and remember that implementations can differ between distribution platforms; Debian vs. Arch, for example.

[varikonniemi]

no, default trash is meant primarily for the partition the directory is on. But it may additionally provide fallback trash location for other volumes if their trash is not available. It says it right there in your link. But it always first tries to put it in the filesystem root’s trash dir.

[soundofthunder]

@varikonniemi

no, default trash is meant primarily for the partition the directory is on. But it may additionally provide fallback trash location for other volumes if their trash is not available. It says it right there in your link. But it always first tries to put it in the filesystem root’s trash dir.

A system can have one or more trash directories. The contents of any trash directory are to be compliant with the same standard, described below.

For every user2 a “home trash” directory MUST be available. Its name and location are $XDG_DATA_HOME/Trash 3; $XDG_DATA_HOME is the base directory for user-specific data, as defined in the Desktop Base Directory Specification .

The “home trash” SHOULD function as the user’s main trash directory. Files that the user trashes from the same file system (device/partition) SHOULD be stored here (see the next section for the storage details). A “home trash” directory SHOULD be automatically created for any new user. If this directory is needed for a trashing operation but does not exist, the implementation SHOULD automatically create it, without any warnings or delays.

The implementation MAY also support trashing files from the rest of the system (including other partitions, shared network resources, and removable devices) into the “home trash” directory . This is a “failsafe” method: trashing works for all file locations, the user can not fill up any space except the home directory, and as other users generally do not have access to it, no security issues arise.

However, this solution leads to costly file copying (between partitions, over the network, from a removable device, etc.) A delay instead of a quick “delete” operation can be unpleasant to users.

An implementation MAY choose not to support trashing in some of these cases (notably on network resources and removable devices). This is what some well known operating systems do.

It MAY also choose to provide trashing in the “top directories” of some or all mounted resources. This trashing is done in two ways, described below as (1) and (2).

…and then, it continues to describe the scenario you mention.

The key seems to be that the Trash directories MUST exist. I suppose that would be worth checking. As already mentioned, the home Trash default is located in ~/.local/share/Trash; at least for Manjaro KDE.

[varikonniemi]

It must exist and is where that user’s home partition trash is stored.

It may accept other mountpoints trash

Other mountpoints may have their own trash directories.