Undeletable but in-place updatable files [2021-02-25 Update] chattr +a directory_where_files_are meets the requirement Credit: Red Hat support [note1] Limitations: If you create an Oracle datafile in the directory with 'a' attribute, "drop tablespace ... including contents and datafiles" will remove related data dictionary records but not delete the file at OS. If you create a MySQL table whose datadir has 'a' set, "drop table ..." throws error (ERROR 1051 (42S02): Unknown table '.') although the table is dropped from inside MySQL, and "create table " throws error (ERROR 1813 (HY000): Tablespace '.
' exists). You have to temporarily clear 'a' attribute, rm the files left behind by the earlier "drop table ...", `chattr +a ...', and "create table ...". [end Update] For those using a file system to store database files, there's always a risk of accidentally deleting them. (Any IT professional with a few years in career have heard of such stories!) Some Linux file systems allow the chattr command to change a file to immutable so the file cannot be deleted or updated. But for database files, the ideal is to make them undeletable but in-place updatable. The manpage for chattr has this statement: "When a file with the 'u' attribute set is deleted, its contents are saved. This allows the user to ask for its undeletion. Note: please make sure to read the bugs and limitations section at the end of this document." This 'u' attribute sounds like a misnomer; it may as well be called "recoverable after deletion", not "undeletable". Anyway, a test on ext* and xfs file systems shows that this attribute has not been implemented. (Fairly new source code of chattr is on github and can be easily compiled.) In the meantime, we may implement a low-tech workaround that aims to reduce this risk. Instead of marking a file undeletable, which relies on the support of the underlying file system, we can just create aliases or shell wrapper scripts for commands like rm, mv, cp. Many shops alias rm to 'rm -i' so the user gets a confirmation prompt. But this offers little help due to human nature: when you're prompted every time, you tend to ignore the prompt altogether! The correct way is to let all team members know the critical files should be named with a string pattern which is recognized by the wrapper (or alias). For example, the wrapper should refuse to delete or at least throw a big alert when the file name ends with ".dbf", or contains "critical" or some other string your team agrees on. Since you rarely try to delete such a file by mistake, the alert of the rm wrapper will catch your attention. Note that this workaround completely breaks if the names of the files and directories are not controlled by your team. Creating a file system that supports a special attribute of files is the ultimate solution. (On Facebook, I messaged the Red Hat Support. He (Update: back then it was a real human) said he would pass the feature request to his team. Nothing came out of it.) 2018-04,-10 https://community.oracle.com/ideas/21316 https://serverfault.com/questions/905269/wish-to-set-file-undeletable-but-updatable/905365 ________________ [note1] https://access.redhat.com/support/cases/#/case/02868918 "RFE: in-place updateable but not removeable file"