Set "no dump" flag when supported for folders marked with CACHEDIR.TAG

[mdekstrand]

Problem

Most modern backup tools support CACHEDIR.TAG files, which Cargo places on several directories where useful.

However, older backup tools (some tar implementations as well as the dump family, including xfsdump) do not know aboutCACHEDIR.TAG, but do respect the "no dump" attribute that can be set with chattr.

Proposed Solution

Setting nodump (possibly recursively, I am not sure if it is inherited) on Cargo's cache and output directories on platforms that support it would enable them to be neatly excluded by backups made with older tools.

Notes

No response

[epage]

Like with #9455, if we have to set this, especially recursively, there is likely to be a performance hit. See #9455 (comment)

[epage]

However, older backup tools (some tar implementations as well as the dump family, including xfsdump) do not know aboutCACHEDIR.TAG, but do respect the "no dump" attribute that can be set with chattr.

As this is framed as "older backup tools", I wonder about the scope of impact (number of users benefiting, how much they benefit) this would have, especially as time goes on.

[mdekstrand]

According to xfsdump man page (section “Excluding individual files”), the “no dump” attribute needs to be set on each individual file in order to take effect. However, it is inherited at file creation: when a new file or directory is added to a directory that has the +d (no dump) attribute, it also gets the attribute.

Therefore, setting the attribute when the cache directory is created would make it effective for new runs or post-clean runs, without the performance hit of recursively setting attributes. That sounds like an entirely reasonable tradeoff to me.

I can't speak to how many users would benefit from this. Dump-based backups seem to be uncommon on Linux, although with XFS as the default filesystem on RHEL, I don't know how many RHEL installations use them. They may be somewhat more common on BSDs, but still likely a relatively small minority.

[weihanglo]

Therefore, setting the attribute when the cache directory is created would make it effective for new runs or post-clean runs, without the performance hit of recursively setting attributes. That sounds like an entirely reasonable tradeoff to me.

This sounds reasonable to me as well, if it just needs to set on the top-level directory.