On Tue, Oct 03, 2023 at 02:26:41PM -0700, Junio C Hamano wrote: > > You can get some safety with the immutable attribute (which applies to > > the inode itself, and thus any path that hardlinks to it). But setting > > that usually requires being root. And it creates other irritations for > > normal use (you have to unset it before even removing the hardlink). > > As a regular user, "chmod a-w" has the same characteristics (works > at the inode level) but without "cannot remove it" downside. It > used to be sufficient in RCS and CVS days, though, as a signal that > you are only to look at it without touching it, to "chmod a-w" a > path that is checked out but not for modifying. Some editors even > offer to do chmod u+w for you when saving, so if we want absolute > safety, it may not be enough. Ah, right. For some reason I was thinking that only affected the link entry, but of course the mode bits are on the linked inode itself. So that does easily give some protection, though I agree that many programs are happy to circumvent it for you. It has been a long time since I've used it, but I think there may be some prior at in git-annex: https://git-annex.branchable.com/ IIRC it can work in a "copy" mode where contents are copied into the working tree. But since the point is to deal with large data sets, it also has a linking mode (maybe even symlinks?) that point directly from the working tree into the annex storage. If we are considering a similar feature, we might be able to learn from their experience. -Peff
