This is to announce coreutils-8.12, a stable release.
We released coreutils-8.11 less than two weeks ago.
Why a new release so soon? Because under unusual conditions,
coreutils-8.11's copying code could cause trouble. Data loss trouble.
The trouble could arise only when these conditions are all met:
- when using linux-2.6.39-related kernels (including at least -rc3) and
- using an xfs file system and
- copying (via cp, install, mv) a file with a so-called "unwritten
extent" shortly after it has been created, yet before some
data in that unwritten extent has made it to disk.
This would happen if you're using the "gold" linker, which
preallocates using fallocate and then writes its output
(the binaries) into those unwritten extents, and you then
immediately copy those binaries into place via "make install".
Under those conditions, just building coreutils and running "make
install" quickly enough after compile and link would result in
installing files containing all 0 bytes.
See the commit logs for links to plenty of discussion.
See the NEWS below for a brief summary.
[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:
gpg --verify coreutils-8.12.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
* Noteworthy changes in release 8.12 (2011-04-26) [stable]
** Bug fixes
tail's --follow=name option no longer implies --retry on systems
with inotify support. [bug introduced in coreutils-7.5]
** Changes in behavior
cp's extent-based (FIEMAP) copying code is more reliable in the face
of varying and undocumented file system semantics:
- it no longer treats unwritten extents specially
- a FIEMAP-based extent copy always uses the FIEMAP_FLAG_SYNC flag.
Before, it would incur the performance penalty of that sync only
for 2.6.38 and older kernels. We thought all problems would be
resolved for 2.6.39.
- it now attempts a FIEMAP copy only on a file that appears sparse.
Sparse files are relatively unusual, and the copying code incurs
the performance penalty of the now-mandatory sync only for them.