From: "Brüns, Stefan" <Stefan.Bruens@rwth-aachen.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/3] test/fs: Check writes using "." (same dir) relative path
Date: Tue, 13 Sep 2016 19:00:13 +0000 [thread overview]
Message-ID: <2492528.PnxoPsXEx1@sbruens-linux> (raw)
In-Reply-To: <91f4c12c-458b-72de-636e-238f263eff62@wwwdotorg.org>
On Dienstag, 13. September 2016 12:36:26 CEST you wrote:
> On 09/12/2016 04:04 PM, Stefan Bruens wrote:
> > On Montag, 12. September 2016 12:44:08 CEST you wrote:
> >> On 09/11/2016 02:46 PM, Stefan Br?ns wrote:
> >>> <path>/<fname> and <path>/./<fname> should reference the same file.
> >>>
> >>> diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
> >>>
> >>> +# Read 1MB from small file
> >>> +${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_SMALL
> >>
> >> I think the same issue with $FPATH ending/not-ending in / applies here
> >> too, and for all commands in this patch.
> >
> > FPATH is either "" for native fat, "/" for native ext4, or <somepath>/ for
> > hostfs, so this is correct. Specifically, for fat, we dont want any "/" in
> > front of $FILE_foo.
>
> I believe FPATH can be either "", "/" or "/foo/bar" here, due to the
> issue I just mentioned in the other email.
FPATH is either "", "/", "/foo/bar" + "/" or "/foo/bar" + "/" + "/". The last
one is not to too nice, but still correct.
FPATH is *never* "/foo/bar", i.e. without trailing slash.
> >>> @@ -482,6 +499,16 @@ function check_results() {
> >>>
> >>> + # Check directory traversal
> >>> + grep -A6 "Test Case 13a " "$1" | \
> >>> + egrep -q '1048576 bytes written|update journal'
> >>
> >> Why is "update journal" considered successful? Surely the "n bytes
> >> written" message is always printed irrespective of whether anything
> >> journal-related happened?
> >
> > Thats a question left to the author of Test Case 11, where the fragment
> > was
> > copied from.
>
> I don't quite agree; you're adding the new test, so should make sure the
> validation code makes sense.
I did not claim this is correct. I just stated this problem exists already for
the older test cases.
> > Ext4 unfortunately is quite verbose, it inserts "File system is
> > consistent"
> > and "update journal finished" lines in the output. I think these lines
> > where better stripped from the log prior to any further parsing.
>
> ext4 may print some extra output, but that doesn't mean that any of it
> should be used in the validation. I think the simplest thing is to just
> ignore it in the validation code. Using egrep -q '1048576 bytes written'
> should do that just fine, and not get a false-positive if ext4 does say
> "update journal" without saying the required "1048576 bytes written".
No, this will not work for ext4 *and* fat.
Every check starts with a "grep -Axx 'Test Case n'" match. If "-Axx" is
extended to *always* include the "yyy bytes written", then it will work for
ext4, but it will also match "Test Case n \n failed \n Test Case n+1 \n yyy
bytes written".
Kind Regards,
Stefan
prev parent reply other threads:[~2016-09-13 19:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160911204606.4146-1-stefan.bruens@rwth-aachen.de>
2016-09-11 20:46 ` [U-Boot] [PATCH 1/3] test/fs: Restructure file path specification to allow some flexibility Stefan Brüns
2016-09-12 18:33 ` Stephen Warren
2016-09-11 20:46 ` [U-Boot] [PATCH 2/3] test/fs: Check ext4 behaviour if dirent is first entry in directory block Stefan Brüns
2016-09-12 18:39 ` Stephen Warren
2016-09-12 21:48 ` Stefan Bruens
2016-09-13 18:33 ` Stephen Warren
2016-09-13 19:11 ` Brüns, Stefan
2016-09-11 20:46 ` [U-Boot] [PATCH 3/3] test/fs: Check writes using "." (same dir) relative path Stefan Brüns
2016-09-12 18:44 ` Stephen Warren
2016-09-12 22:04 ` Stefan Bruens
2016-09-13 18:36 ` Stephen Warren
2016-09-13 19:00 ` Brüns, Stefan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2492528.PnxoPsXEx1@sbruens-linux \
--to=stefan.bruens@rwth-aachen.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.