Can't say if anyone here has any use for this, but it's been a big help for me. (Obviously. )
uunlnk-style file protection & drop-in shell-script-based replacements for trash & unlink functionality in third-party macOS file managers
Please note: the Trash Tools shell scripts are not meant for usage in macOS Finder: you will need a third-party file manager like Nimble Commander that supports direct shell script execution and allows users to remap system-default keyboard shortcuts.
If you want to protect your files against accidental deletion in macOS, you only have the ability to "lock" files, as the Finder calls it, which in reality corresponds to the old Unix immutable flag (uchg), or you can use a deny delete access control entry (ACE). In both cases this also renders the file uneditable, which is why in the former case (uchg), when you want to modify a "locked" file, some applications create a copy of the "locked" file's contents, create a new file with a different inode number, and then delete the "locked" original, but very few applications actually respect the user's wishes and re-apply the immutable flag to the new file. Files protected with a deny delete ACE apparently can not be handled by the system APIs at all, and any attempts at proper file modifications will fail. Long story short, macOS and its Unix underpinnings do not always play well together.
There is, however, an old Unix flag called system no-unlink (sunlnk), which (also on macOS) protects important files from deletion, but still allows certain file modifications. The variant user no-unlink (uunlnk) is actually present in macOS, and can even be set with the right tools, but it is disregarded by the system and removed as soon as such a file is opened or modified. At any rate, the sunlnk and uunlnk flags would not be sufficient for our needs anyway, because they still prohibit the user from performing certain modifications like mounting over a file or renaming it. But especially the latter is important for every-day file usage.
The Trash Tools, in tandem with its protect script, can offer at least a workaround: protect will add an extended attribute (XA) to a file, and if Trash Tools' file removal scripts access that file, any trash or unlink operation will fail, while the user is still free to perform any and all other file operations, including renaming, moving to a different location, and modifying file contents. These protected files can still be trashed or unlinked by other processes, but if the user remaps the keyboard shortcuts of all trash and unlink routines in his file manager to the Trash Tools scripts, any accidental file deletions will at least be prevented in the user's file manager of choice.
Most users will probably have no need for such a solution, because the normal user just moves files to the Trash, and can then easily restore them, if the deletion was an accident. But these tools might be valuable for those users who perform a lot of permanent deletions on scratch or RAM disks. Accidents in these situations cannot be undone. Furthermore, some third-party file managers do not offer the option to undo a Trash operation or restore a file from the Trash to its original path.
* regular file copies of protected files will have the same protection (i.e. XAs) as the originals
* on volumes without support for extended attributes, e.g. mounted NAS volumes, the protection flag and tag for foo will be written as ._foo