[undelete] package released!

I thought that woud be the case. Not very useful in this situation.

Can I just confirm that delete via WebIF uses the recycle bin?
 
Doh!

I just twigged I can simulate delete-to-recycle-bin by doing a move. In fact, I could mark them to record to the recycle bin in the first place!
 
Umm... I see no undelete folder, even though there has been a reboot. Does it need a cold start?
 
Yar, I just tried the aborted recording issue and the files turned up in my [Deleted Items] folder. Only thing is, I had asked for it to be called [Recycle Bin]!
 
Undelete 1.5 just uploaded.

The process that empties the bin after a set number of days has had the following changes:
  • Logs activity including which files have been removed (log visible via web interface diagnostics) - thanks to prpr for the inspiration;
  • As disk space becomes low it progressively reduces the number of days for which items are stored in the dustbin in order to try to free up some space. Patch from xyz321 which I've been sitting on for months(!).
 
I am seeing the deleted files (following a dustbin/empty diagnostic) in humaxtv.log but I can't see the new delete log file in /mod/tmp after installing Undelete 1.5 + reboot
EDIT
Sorry, ignore that, the /mod/tmp/empty_dustbin.log has just turned up

New WiKi Notes HERE
 
Some more information on the reducing days feature that xyz321 provided:

If you have your retention time set to 7 days or more then after it has removed anything that is old enough it checks the amount of disk space remaining. If it is less than 120GiB then it reduces the retention time by one day and then removes anything older than that. It continues until either there is 120GiB of recording space available or it is down to 6 days retention. At 6 days it changes the threshold to 100 GiB - that is if there is less than 100GiB remaining then it will reduce the retention time to 5 days and change the threshold to 80 Gib. It continues in this way until it is either down to one day retention or there is enough disk space.

Here are the (current) retention times and thresholds:

7 days - 120GiB
6 days - 100GiB
5 days - 80GiB
4 days - 60 GiB
3 days - 40 GiB
2 days - 20 GiB
1 day - 10 GiB

There was a typo in version 1.5 that caused the thresholds to be multiplied by 10, upgrade to 1.5-1 to have this feature working properly.
 
Yes, it follows this decision tree on each run, it's only a temporary modification to the retention time.
 
I like the intention of the minimum free space introduced in 1.5, but for a couple of reasons, the implementation seems more complex than it needs to be.
Since undelete runs daily, there is only a need to ensure that there is sufficient space for one day's recordings, so I do not see the need for a sliding scale.
If I took the view that 25G were enough for a day, then simply aim for that fixed value rather than using the sliding scale (it could of course be user configurable).
I have a 500G drive and have my undelete set to 10 days. I currently have about 20G free. If I were to update to 1.5, the result would be that probably quite a few additional days would be removed from the deleted list.
 
You can always edit the file (/mod/sbin/empty_dustbin) and make it do what you want. That is the beauty of this stuff.
It's easy to do from the Web-If's Diag page File Editor.
In this case, you don't even have to know anything about how the implementation works. You just change the obvious numbers to suit yourself.
 
I like the intention of the minimum free space introduced in 1.5, but for a couple of reasons, the implementation seems more complex than it needs to be.
Since undelete runs daily, there is only a need to ensure that there is sufficient space for one day's recordings, so I do not see the need for a sliding scale.
If I took the view that 25G were enough for a day, then simply aim for that fixed value rather than using the sliding scale (it could of course be user configurable).
I have a 500G drive and have my undelete set to 10 days. I currently have about 20G free. If I were to update to 1.5, the result would be that probably quite a few additional days would be removed from the deleted list.
The main reason for the sliding scale is so that the older files are always the preferred candiates for deletion. Otherwise if it had a sudden jump down to say 20GB then you might lose some of the 2 day old files as well as some of the 7 day old files when deleting the latter would have freed up sufficient space. I deliberately wrote it in a table format rather than as an equation so that it could be easily tweaked.
 
I said that I liked the intention of the change, what I should have also have said was that I liked the technique. I agree, the day by day progression that you have used is essential.
What I hadn't seen mentioned at any point is that the thresholds could be changed (thanks prpr and I see that the Wiki has now been updated to add the name of the thresholds file).
Given that that control exists, I will download the update and give it a try.

And thanks for a great add-on.
 
What do you think about adding one more option to the menu:10days..... 3days, 2days, 1day and add tonight. It always scares me when I get 50Gb left. Currently if I now delete file A on the 1 day option I have to wait until the day after tomorrow to have the file autodeleted.
 
There is nothing stopping you from manually deleting files from your dustbin if you are getting short of space, this is what I usually do.
 
There is nothing stopping you from manually deleting files from your dustbin if you are getting short of space, this is what I usually do.
I was afraid I would get an answer like this.
Of course I can delete them manually, but that defeats the purpose of an auto(un)delete package.
I suppose I thought it could be as easy as just add one more option.
 
Just uploaded undelete 1.6 which lets you customise the thresholds that are used to adapt the retention times when disk space is short.

undelete.png
 
Back
Top