Ability to disable trash bin on External Storage (or have separate trash bin on the external storage)

[efelon]

Is your feature request related to a problem? Please describe. When adding external storage folder (e.g. SMB) they integrate nicely. But when deleting elements out of those folder they will be moved to local trash bin, which can take a very long time depending on the file size, connection, etc. and this may sometimes even not be desired.

Describe the solution you'd like A good general solution would be to disable trash bin manually on a per folder basis. Or in the settings where the user can list folders to be excluded.

Describe alternatives you've considered One alternative would be to outsource the solution specifically to the external storage add-on and provide a similar option only there on a per share basis.

[efelon]

Related to #18396

[Taomyn]

I agree with including this enhancement, having files moved across from external storage especially if it's located remotely e.g. SMB or even AWS, is not always desirable, more so if the files are extremely large.

[tnyeanderson]

This is very relevant for people who use seedvault for android backups with Nextcloud as a backup target. A ton of random files will be placed in trash on a daily basis, and it would be great if we could exclude the seedvault directory contents from being "recycled", as otherwise I am constantly at risk of running out of space and have to delete the files manually. Standard trash retention policies are not effective for this issue.

I suggest a .notrash or .norecycle file in the directory to recursively disallow moving files to the trash/recycling when they are deleted. In case it is important for implementation, the files I mention are not deleted by the user, but by some automated process.

[tnyeanderson]

Looks like the implementation belongs in the moveToTrash function, but I'm not sure as I'm unfamiliar with the code here.

[Pecacheu]

How is this even still a thing in a mature cloud storage application? If it hadn't been raised as an issue till recently that would be one thing, but... There are multiple issues and pull requests regarding this same problem, and dozens of relevant search results of forum posts that date back years. Yet there's no timeline for merging the pull request apparently and it's been closed? I mean, certainly not encouraging me to help if that's how community contribution is treated.

The best solution we have right now is 'create a symlink for every user's trash folder.' And that only works if you only have one external device. This is absurd. Per-device trash is a basic feature that any user would expect, and has existed in Linux, Windows, Mac OS, not to mention part of SMB/NFS/etc protocols, for over a decade.

How does it make ANY sense that you'd download a file to local disk storage to put it in a local trash folder instead of just moving the file into a hidden folder of a standard format such as .Trash-$UID or .trash/$username. It blows my mind that that the decision was actively made to make it work this way to begin with. The External Storage extension just straight up shouldn't have been released in this state, which I'd call counter-intuitive at best, and broken at worst.

It's also perfectly normal on most NAS hardware (such as mine) that the primary drive is some puny internal storage device that usually can't handle being filled up with everyone's junk. And when it comes to using the plugin for network or cloud storage, it makes even less sense, now you're pulling large files over the internet all just to "delete" them when you could've simply called a single move/rename command to place it in a trash folder without going cross-device.

[tnyeanderson]

@Pecacheu Of course I understand your frustration, I am waiting on this feature as well and it is a huge pain point for me.

However, we have to remember that there are 2,300 open issues at the moment, and over 15,000 total issues have been in this repo. The Nextcloud team is rather small and stretched thin (I might say due to the decision to bloat features, but I can't be the one to determine that).

I try to contribute where I can, and I encourage everyone to do the same. You and I can prioritize this very highly, but at the end of the day the Nextcloud team might not, and we have to either be patient and wait for the fix for free, or get our hands dirty and start implementing these things ourselves. Or maybe a bounty would help get some eyes on it.

In the meantime, I'll try to take another look at implementation on this in the coming weeks.

[Pecacheu]

@tnyeanderson Alright fair point, that is a LOT of issues haha. Perhaps I can take a look and add some logging in that moveToTrash function you pointed out, to see if/what it gets called with when using the External Storage plugin.

As for now, the temporary "hotfix" people have suggested, creating a symlink to redirect where the trash goes, will work for me since I only have one shared external location mounted. Best that all trash is directed to the BIG disk.

[loeffelpan]

Any news on this? I get the point that there is an huge amount of issues and most of them may have higher prio than this.

But at least this one and #18396 show, that there is real pain for some users including me. Just flooded my primary disk with trashbin-files from a much larger disk I'm using via external storage. And the deletion progress (which is a copy instead) is also pain, as it takes much more time as I would expect for a deletion.

Maybe @szaimen can take another look at #22632 and #23489 how to implement this at least for external storage?

[joshtrichards]

Related recent merge: #38623

[labor4]

In recent years I just disabled the "Deleted Files" app. But now that produces errors. What is the best way to disable the trash entirely?

We're using big files. Sadly this concept is conflicting.

[sorbaugh]

There is this PR that attempted to fix this issue some years back https://github.com/nextcloud/server/pull/23489

Unfortunately we can't resurrect it due to the frontend having been migrated to vue and a few other backend-side nitpicks, it would be better to create a PR from scratch.