From: Jim Meyering <jim@meyering.net>
To: Michael Stone <mstone@mathom.us>
Cc: bug-coreutils <bug-coreutils@gnu.org>, linux-btrfs@vger.kernel.org
Subject: Re: tests/misc/ls-time
Date: Sun, 17 Jan 2010 16:08:16 +0100 [thread overview]
Message-ID: <874omkzs4f.fsf@meyering.net> (raw)
In-Reply-To: <fa9257d4-02e5-11df-9b6a-001cc0cda50c@msgid.mathom.us> (Michael Stone's message of "Sat, 16 Jan 2010 16:34:49 -0500")
Michael Stone wrote:
> It seems that touch -a does update ctime on btrfs, invalidating one of
> the assumptions behind this test and causing it to fail.
s/does/does not/
Thanks for the report.
I've just confirmed this test failure by building and running coreutils'
"make check" on a btrfs file system I'd just created using mkfs.btrfs
v0.19 on Fedora 12, btrfs-progs-0.19-9.fc12.x86_64
However, it has nothing to do with touch, but rather looks
like a bug (or at least a difference) in btrfs.
Here's a function to provide a quick demo:
ctime_vs_link_test() { env rm -f a b x; : > a; : > b; ln a x
stat -f --pr '%T: ' .; case "$(env ls -ct a b)" in a*b) echo pass;; \
*) echo fail; env stat --format='%n %z' a b;; esac; }
Use it on a few file systems.
This test passes on all I tried except btrfs:
[note: $HOME is ext4]
$ for i in $HOME/tmp /t /fs/btrfs /fs/xfs /fs/nilfs2; do
cd $i && ctime_vs_link_test; done
ext2/ext3: pass
tmpfs: pass
btrfs: fail
a 2010-01-17 14:54:12.470194921 +0000
b 2010-01-17 14:54:12.471193684 +0000
xfs: pass
nilfs2: pass
In case it's not immediately obvious (time-stamp problems rarely are),
here's a blow-by-blow:
# After this, a's ctime precedes b's, even if just by ~1ms.
rm -f a b x; : > a; : > b
# Increasing a's link count must update its ctime to the present,
# making it more recent than b's.
ln a x
# Sorting on ctime, a should come first:
env ls -ct a b
next parent reply other threads:[~2010-01-17 15:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa9257d4-02e5-11df-9b6a-001cc0cda50c@msgid.mathom.us>
2010-01-17 15:08 ` Jim Meyering [this message]
2010-01-18 16:10 ` tests/misc/ls-time Josef Bacik
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=874omkzs4f.fsf@meyering.net \
--to=jim@meyering.net \
--cc=bug-coreutils@gnu.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=mstone@mathom.us \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox