bug#8411: due to missing sync even on 2.6.39, cp fails to copy an odd file

[Jim Meyering]

Ted Ts'o wrote:
> On Sat, Apr 02, 2011 at 08:08:34PM +0200, Jim Meyering wrote:
>> From 0a6d128d0d17c1604245f1caafe6af73584a0bb8 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <address@hidden>
>> Date: Sat, 2 Apr 2011 19:59:30 +0200
>> Subject: [PATCH] copy: require fiemap sync also for 2.6.38 and 2.6.39 kernels
>>
>> * src/extent-scan.c (extent_need_sync): Require sync also for 2.6.38
>> and 2.6.39.  Without this, part of the cp/fiemap-empty test would fail
>> both on F15-to-be and rawhide.  For discussion and details, see:
>> http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/22190
>
> FYI, the following fix has been merged into mainline, which should fix
> the problem for 2.6.39 once it is finally released, at least for ext4.
> It was merged right before Linus released 2.6.39-rc1.  I'm assuming
> that Rawhide released a pre-2.6.39-rc1 kernel in the middle of the
> merge window.
>
> Some distro's will informally, but incorrectly, refer to such a
> release as "2.6.39-rc0".  I prefer the more technically correct
> 2.6.38-git18 (which is the first git tag in the Linux git repo which
> contained the patch below, as of March 25, 2011).  Unfortunately, RPM
> doesn't understand that 2.6.38-rc1 sorts before 2.6.38, while
> 2.6.38-git17 sorts *after* 2.6.38.  (Hence the incorrect, but
> convenient, use of 2.6.39-rc0.)

Right.  Rawhide's 2.6.39-0.rc0.git11.0.fc16.x86_64 kernel
is from March 22.

Good.  That means we needn't condemn 2.6.39.
This sort of uname-based kernel check is precisely
why we should minimize use of -rcN named kernels,
but if it affects only rawhide (and that only briefly),
I won't complain too loudly.