On Sun, Jan 17, 2010 at 04:08:16PM +0100, Jim Meyering wrote:
> 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 thi
According to Michael Stone on 1/17/2010 8:11 AM:
> On Sun, Jan 17, 2010 at 10:08:23AM -0500, Michael Stone wrote:
>> But then I also have a build log
>> (https://buildd.debian.org/fetch.cgi?&pkg=coreutils&ver=8.1-1&arch=amd64&stamp=1261006367&file=log)
>> with a different failure, which is what I
On Sun, Jan 17, 2010 at 10:08:23AM -0500, Michael Stone wrote:
But then I also have a build log
(https://buildd.debian.org/fetch.cgi?&pkg=coreutils&ver=8.1-1&arch=amd64&stamp=1261006367&file=log)
with a different failure, which is what I thought I'd duplicated last
night, but can't for the li
On Sun, Jan 17, 2010 at 09:59:46AM +0100, Andreas Schwab wrote:
Michael Stone writes:
It seems that touch -a does update ctime on btrfs, invalidating one of the
assumptions behind this test and causing it to fail.
Did you mean "does not update ctime"?
Yes. My eyes are starting to cross. I
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 s
Michael Stone writes:
> It seems that touch -a does update ctime on btrfs, invalidating one of the
> assumptions behind this test and causing it to fail.
Did you mean "does not update ctime"?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01
It seems that touch -a does update ctime on btrfs, invalidating one of
the assumptions behind this test and causing it to fail.
Mike Stone
