Re: [silly] loose, pack, and another thing?

From: Jeff King <peff@peff.net>
Date: Oct 4, 2023, 13:11 UTC
Message-ID: <20231004131110.GA607079@coredump.intra.peff.net>
In-Reply-To: <xmqqo7hfwg6m.fsf@gitster.g>

On Tue, Oct 03, 2023 at 02:26:41PM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> > 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