From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com ([209.132.183.28]:53034 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756571AbdCHHOt (ORCPT ); Wed, 8 Mar 2017 02:14:49 -0500 Date: Wed, 8 Mar 2017 15:14:46 +0800 From: Zorro Lang Subject: Re: generic/411 clash with TEST_DIR=/mnt Message-ID: <20170308071446.GP14075@dhcp12-143.nay.redhat.com> References: <20170307165027.GA15724@birch.djwong.org> <20170308035045.GN14075@dhcp12-143.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: fstests-owner@vger.kernel.org To: Amir Goldstein Cc: "Darrick J. Wong" , fstests List-ID: On Wed, Mar 08, 2017 at 08:50:50AM +0200, Amir Goldstein wrote: > On Wed, Mar 8, 2017 at 5:50 AM, Zorro Lang wrote: > > On Tue, Mar 07, 2017 at 08:50:27AM -0800, Darrick J. Wong wrote: > >> Hi Zorro, > >> > >> I noticed that generic/411 creates some sort of directory structure > >> involving $TEST_DIR/$seq/$$_mpA/mnt1/mnt2, then pipes the findmnt output > >> through _filter_test_dir. > >> > >> Unfortunately, on my test system I have TEST_DIR=/mnt, so the filtering > >> produces this output: > >> > >> QA output created by 411 > >> ------ > >> TEST_DIR/411 SCRATCH_DEV > >> mpA SCRATCH_DEV > >> mpATEST_DIR1 SCRATCH_DEV > >> mpB SCRATCH_DEV > >> mpBTEST_DIR1 SCRATCH_DEV > >> mpBTEST_DIR1/TEST_DIR2 SCRATCH_DEV > >> mpC SCRATCH_DEV > >> mpCTESTDIR1 SCRATCH_DEV > >> ====== > > > > Hmm, that's really a problem, thanks for finding it:) If someone > > use "/mnt" as TEST_DIR, _filter_test_dir will change all "/mnt" > > things to "TEST_DIR". > > > > Except we recommend all cases shouldn't contain "/mnt" > > in its test path name. Or we'd better change _filter_test_dir, > > make it to be more picky. > > > > I prefer the second way, except someone has a third way :) > > > >> crash test passed > >> > >> Which means that the golden output comparison fails. :( > >> > >> I'm not sure what's a proper fix here: changing _filter_test_dir to be > >> more picky about what gets sed'ed? > >> > >> e.g. sed -e "s,\([[:space:]]\)$TEST_DIR,\1TEST_DIR,g/" > > > > Except [[:space:]]$TEST_DIR, maybe we should think about "^$TEST_DIR" too, > > e.g: > > > > echo "/mnt/mnt1/mnt2 /mnt/mnt3/mnt4" | \ > > sed -e "s,\([[:space:]]\)$TEST_DIR,\1TEST_DIR,g" | \ > > sed -e "s,^$TEST_DIR,TEST_DIR,g" > > > > That's not enough. > It's true that currently golden outputs only have ' ' and ^ preceding TEST_DIR, > but why should we limit the solution to TEST_DIR > SCRATCH_MNT could just as well be /mnt and we have SCRATCH_MNT > in golden outputs following '\'' '\"' and : as well. Hmm, yes, you're right, maybe follow other things... I didn't think about this. So change the filter is not easy. > > > (Is there a simpler way to do above things ^^ ? :) > > > > I'm not a regexp master, but can't we setup an expression that matches > $TEST_DIR.\S and only replaces the $TEST_DIR part, > that would replace only the first occurrence of $TEST_DIR is every word. Maybe output $TEST_* or $SCRATCH_* twice in one line. Maybe there's not a better way to change the filter. Stop all cases using sub-path name that's same with $TEST_* or $SCRATCH_* maybe the best way. Thanks, Zorro > > > But this change will affect lots of cases, we need to run full around > > xfstests to make sure it won't change some cases' golden output. What > > do you think? > > > > Thanks, > > Zorro > > > >> > >> Or just to change the test to use directory names that are less likely to be > >> mistaken for TEST_* and SCRATCH_*? > >> > >> --D > >> -- > >> To unsubscribe from this list: send the line "unsubscribe fstests" in > >> the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > > To unsubscribe from this list: send the line "unsubscribe fstests" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe fstests" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html