server - Recycle bin / Trash Can feature

[warp 7]

Hi,

 

I want the "Recyle bin" or "Trash Can" feature to the server.

 

Now, there is "Allow media deletion" control on "Feature Access" setting.

Once a user delete a media file, this is completely removed from the server.

 

When I share media files with my family, sometimes the problem happens.

For example, my wife delete a file because she has watched it, but I have not yet...

 

So, I want the "Recycle bin" feature as below.

 

* "media deletion" role just only moves the file into Recyle bin.

* add "empty Recyle bin" control to "Feature Access". Only the account with this role can remove files completely.

 

 

Regards,

[blade005 175]

I think it will be difficult for Emby Server to control the process the way you described.

 

1. You can set DELETE permissions at the User Level. One option would be to only set up your account with DELETE permissions. Everyone else gets there own User account, but won't have DELETE permissions.

 

2. Whether an item gets sent to the RECYCLE BIN or immediately deleted is really dependent on how your Operating System is set up and not Emby Server. Even then, if you are using UNC paths for items, typically a WIndows system will permanently delete an item and not place it in the RECYCLE BIN if the delete requests comes from a UNC path.

[warp 7]

Hi,

 

Sorry, I wrote "Recycle bin" as a virtual directory on emby server, not as a OS level implementation.

[blade005 175]

Hi,

 

Sorry, I wrote "Recycle bin" as a virtual directory on emby server, not as a OS level implementation.

I still think Option 1 above is the best implementation.

 

Only allow DELETE permissions on your admin user account. All other users get their own login account with DELETE permissions removed in Emby Server USER settings.

[harrv 90]

I really want this feature. Its implementation doesn't need to be complicated and doesn't need to affect the existing API or clients at all. It would just take one additional "advanced" library option to specify a directory to use for anything deleted from that library. If left blank (default) then delete the files as you do now. If a directory is specified, then anything deleted from that library goes into that directory instead of being deleted.

 

The only potentially tricky part is what to do if the file being deleted already exists in the delete directory. In that case, I'd suggest adding characters or digits to the file to make it unique before moving to the delete directory, but it would probably be acceptable to overwrite any same-named files already in the delete directory.

 

Look at Sonarr and Radarr for examples. Both of those have this feature.

[Luke 39684]

Recycle bin support will be in Emby Server 4.1+:

 

https://emby.media/community/index.php?/topic/72089-41019-delete-to-recycle-bin

 

Thanks.

[harrv 90]

I'd like to be happy about your reply, and I am happy you're trying to do something for us, but after reading about it in that thread the way you've implemented it doesn't sound usable for most people. For one, I can't imagine trying to use Emby Server without running it as a service... that would be really bad for uptime and pretty much eliminates the ability I have now to have multiple user accounts on Windows. I use my PC for more than running Emby, and I do not live alone. And maybe even more significantly, all of my media (and just about everyone else's setup I've read about on this forum is similar) is on an SMB-accessable NAS.

 

I hope there is some great reason I just can't see that you are trying to use the actual Windows recycle bin instead of letting the admin pick a directory to move "deleted" files to, which would have allowed you to avoid both of those limitations.

[ebr 15583]

I hope there is some great reason I just can't see that you are trying to use the actual Windows recycle bin instead of letting the admin pick a directory to move "deleted" files to, which would have allowed you to avoid both of those limitations.

 

In most situations that simply wouldn't be practical as moving gigabytes (and perhaps even terabytes) of files could take hours...

[Carlo 4549]

That should not be the case as OS don't actually copy the media but just change the pointers to the files.  On most OSs you can move files faster then deleting them believe it or not.

[ebr 15583]

That should not be the case as OS don't actually copy the media but just change the pointers to the files.  On most OSs you can move files faster then deleting them believe it or not.

 

Only if the files are on the same physical drive.

 

The implication of this feature was that users would be able to indicate where their "trash" folder was - which then negates that.  Then, also there are the issues of media spread across multiple drives and drive pooling solutions (most installs I bet).

 

So, properly implementing such a feature at the application level would be very complex.

[Carlo 4549]

You're making this out to be something it's not.  This is VERY EASY all around.

 

Where every the library points is where you create the "$EmbyTrash" folder to move content into.   NO USER CONFIGURATION for this folder!

 

Don't worry about the type of drive.  It could be individual drives, pooled drives, network drives, USB3 attached drives but none of that matters.

[ebr 15583]

Don't worry about the type of drive.  It could be individual drives, pooled drives, network drives, USB3 attached drives but none of that matters.

 

I'm just not sure that is 100% correct on all file systems and that is something that would have to be investigated and tested across the board.  I personally just feel that our development time is better spent on media operations instead of file system operations but perhaps you can test this on every file system we know about and then let us know if there are any issues.

 

Then there is the situation where someone deletes something in the Emby interface that virtually spans multiple locations (merged versions or merged series for instance).  Now the system has to properly handle all of that seamlessly.  There are so many potential complications here that (IMO) make this not as simple as it may look.

[Carlo 4549]

To make clear.  I don't doubt resources can be spent on other things (I'd rather have time spent on).

 

But on this specific issue, any OS worth mentioning will handle the move just fine. I don't have every OS we support but I'll happily try and coordinate testing if this is needed on other platforms.

 

Thus far I can validate this work fine on: 

Windows (raw, drivebender, drivepool, storage spaces)

Linux

FreeNAS

Open Media Vault

Synology

WD NAS

SMB drive mapping (including from Shield TV).

I probably have additional OS/NASes available I haven't tested on as well.

 

That defiantly covers all the main OSes we use.

 

I'll get testing if needed on other platforms if you specify what specifically needs testing.  I'm sure we have users in the forums that could help on other platforms I don't personally have.

 

Worse case if an OS doesn't support a quick move it will support a copy/delete op.  It could take a bit of time but the "protection" is probably worth it.

 

But again, lets test any specific OSes you think might be a problem.

So just let us know what needs testing specifically.  LOL

Edited April 5, 2019 by cayars

[mguebert 10]

I just requested something similiar and was directed to this topic.

Would it work to leave the recording in it's recorded location. 

When deleted in Emby remove it in the database to a "Recycle Location: which is auto emptied after X days ( then it would be deleted from the recording drive)

In the emby interface this  Recycle location could be accessed and individual files restored.

????

[harrv 90]

I still wish Emby had a non-destructive delete implementation. I run Emby, Sonarr, and Radarr in docker containers. I have no idea what a "recycle bin" is in that context. But moving deleted files to a user-specified directory is exactly what Sonarr and Radarr do, and it works flawlessly. I agree with cayars. I don't think it needs to be complicated to implement.

[harrv 90]

Here is how Sonarr does it.

They used to have one bug in their implementation, which is why i have the automatic cleanup disabled. As it says in the help text, files "older than" the number of days specified are automatically deleted. What that meant in practice was that files were almost always deleted within a day no matter what you set that number to since the last-modification date on a file isn't changed just because you move it and most files in my library are at least as many days old as whatever I might set that number of days to.

However, they fixed that with this commit, most easily seen on lines 60-64, and now I think their implementation is just right.

I would really like that flexibility with Emby because I want to let my wife delete stuff if she wants to, but I might not always agree! At least the Sonarr/Radarr method would allow her to indicate what she wants to happen and allow me the ability to reverse it if necessary (like the thermostat - haha) since the video file itself wouldn't yet be gone-gone.

Edited March 16, 2023 by harrv

[kukan 0]

A much-needed function for a Linux NAS.

Currently, have to disable the delete function in Emby and only remove files on Samba drive with vfs_recycle function enabled.

It would be way more convenient to be able to remove files while browsing Emby libraries...

[darkassassin07 605]

On 4/2/2019 at 1:46 PM, Luke said:

Recycle bin support will be in Emby Server 4.1+:

 

https://emby.media/community/index.php?/topic/72089-41019-delete-to-recycle-bin

 

Thanks.

@Lukehow about that expansion to other OSs?

Linux, Docker in particular could use this. Not sure why you didn't implement it across the whole ecosystem.... Especially after almost 10 years.....