[undelete]

[Black Hole]

I think it's pretty straightforward to delete all recordings on the drive by
Media/"select all" (green)/opt+/delete
When you're in the top directory.

It can potentially clear all recordings despite the settings for undelete. I think this is because the total size of the selected files will be greater than undelete settings. I try to mitigate that potential user error by locking 1 file in the important directories (eg top directory and others I wish to keep).

I haven't tried it recently, so be carefull.

Does this really matter? If it does, then all undelete needs to do is exclude the recycle bin folder (and contents) from the delete operation it has intercepted, unless the contents of the recycle bin folder were selected explicitly. Then the deletion becomes a process of reallocating all the deleted files to the recycle bin (no change in disk utilisation), and if the user wishes to explicitly delete the recycle bin contents (as I do on occasion) this is still available.

 

[bottletop]

Does this really matter?

It may do. It depends on the the individual and the level of importance they associate with the media or recording.

.If it does, then all undelete needs to do is exclude the recycle bin folder (and contents) from the delete operation it has intercepted, unless the contents of the recycle bin folder were selected explicitly. Then the deletion becomes a process of reallocating all the deleted files to the recycle bin (no change in disk utilisation), and if the user wishes to explicitly delete the recycle bin contents (as I do on occasion) this is still available.

Whatever, that sounds wonderful.

 

[Black Hole]

Who "owns" undelete – can they confirm current status?

 

[prpr]

I have access to the source code, but no time at the moment.

 

[prpr]

It can potentially clear all recordings despite the settings for undelete. I think this is because the total size of the selected files will be greater than undelete settings.

It isn't. Those limits are only taken into account during the overnight housekeeping process.

If it does, then all undelete needs to do is exclude the recycle bin folder (and contents) from the delete operation it has intercepted, unless the contents of the recycle bin folder were selected explicitly.

The intercept has no knowledge of what else is being deleted. Each operation happens in isolation, so what you suggest is not possible.
If you do a Select All, then Delete, what happens depends on where on the list the Bin is.
Anything before it ends up being moved in to the Bin, then the Bin itself is deleted, then anything after ends up being put in a re-created Bin.
So you could end up with everything, some things, or nothing in the Bin, depending.

If people don't want the Bin deleted, then don't select it for deletion. It's pretty obvious really.

 

[MikeSh]

If you do a Select All, then Delete, what happens depends on where on the list the Bin is.
Anything before it ends up being moved in to the Bin, then the Bin itself is deleted, then anything after ends up being put in a re-created Bin.
So you could end up with everything, some things, or nothing in the Bin, depending.

So a bit of an oozlum bird situation? Perhaps a package name change is in order ...

 

[/df]

Isn't the to-be-deleted pathname available to the undelete hook, or a file descriptor that could be passed to fstat()?

 

[prpr]

Of course, but with a view to what?

 

[/df]

Ah, because there's no state we don't know whether we're in a single delete or a recursive sequence or whatever, and we can't ban bin entries or they'd never get deleted?

Might it be possible to have some global flag (environment var, or /mod/etc/undelete.lock file, etc) that the delete hook can check so that ordinary deletion skips the bin, but the Empty Bin operation (from UI or when trimming) clears the flag temporarily?

Otherwise the oozlum bird is indeed a good analogy.

 

[prpr]

because there's no state we don't know whether we're in a single delete or a recursive sequence or whatever, and we can't ban bin entries or they'd never get deleted?

Exactly.

Might it be possible to have some global flag (environment var, or /mod/etc/undelete.lock file, etc) that the delete hook can check so that ordinary deletion skips the bin, but the Empty Bin operation (from UI or when trimming) clears the flag temporarily?

Probably, but how would it get (un-)set when deleting things in the bin intentionally from the UI?
It's not worth the hassle.

 

[/df]

I was thinking of that as collateral damage, but there could be an additional utility, or maybe an --unprotect-recycle-bin option to trm, that would allow deleting from the bin and could be called from Webif to delete binned files when the displayed directory is the bin or one of its subdirectory. No doubt the hassle factor would determine whether anyone implements such things.