Re: [RFC/PATCH] fsck: do not canonicalize modes in trees we are checking
- From
- Ben Aveling <bena.001@optusnet.com.au>
- Date
- Oct 12, 2014, 22:37 UTC
- Message-ID
- <543B02A7.9040807@optusnet.com.au>
- In-Reply-To
- <20140923163008.GA21591@peff.net>
Hi,
A question about fsck - is there a reason it doesn't have an option to delete bad objects?
Regards, Ben
On 24/09/2014 02:30, Jeff King wrote:
Show 32 quoted lines
> [-cc Kirill, as his address seem out-of-date] > > On Tue, Sep 23, 2014 at 04:23:43PM +0000, Edward Thomson wrote: > >> On Tue, Sep 23, 2014 at 11:47:51AM -0400, Jeff King wrote: >>> As far as I can tell, fsck's mode-checking has been totally broken >>> basically forever. Which makes me a little nervous to fix it. :) >>> linux.git does have some bogus modes, but they are 100664, which is >>> specifically ignored here unless "fsck --strict" is in effect. >> I'm in favor of checking the mode in fsck, at least when --strict. >> But I would suggest we be lax (by default) about other likely-to-exist >> but strictly invalid modes to prevent peoples previously workable >> repositories from being now broken. >> >> I have, for example, encountered 100775 in the wild, and would argue that >> like 100644, it should probably not fail unless we are in --strict mode. > Yeah, I'd agree with that. The big question is: what breakage have we > seen in the wild? :) > > I think treating 100775 the same as 100664 makes sense (want to do a > patch?). Do we know of any others? I guess we can collect them as time > goes on and reports come in. That's not the nicest thing for people with > such repos, but then again, their repos _are_ broken (and it's only > really a showstopper if they are trying to push to somebody with > receive.fsckObjects turned on). > > -Peff > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >