The "file corruption" problem seems to be a problem with re(4): I built a release with code from Fri Feb 17 04:31:34 2017 +0000
Two rounds of cvs -d:pserver:[email protected]:/cvsroot co -D2017.04.04.13.30.00 src both gave "corrupted files". (This rules out "recent" changes.) The "corruption" is that they contain chunks of cvs protocol, such as the excerpt from src/external/gpl3/gcc/dist/gcc/cp/ChangeLog-2000: ======================================================================== 2000-01-28 Nathan Sidwell <[email protected]> Compiler side new abi rtti (not enabled). * cp-tree.h (new_abi_rtti_p): New macro. (emit_support_tinfos): Prototype Mod-time 7 Jun 2016 06:14:17 -0000 MT +updated MT text U MT fname src/external/gpl3/gcc/dist/gcc/doc/aot-compile.1 MT newline MT -updated Created src/external/gpl3/gcc/dist/gcc/doc/ src/external/gpl3/gcc/dist/gcc/doc/aot-compile.1 /aot-compile.1/1.6///D2017.04.04.13.30.00 u=rw,g=rw,o=rw 6711 .\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.05) .\" .\" Standard preamble: .\" ======================================================================== ======================================================================== Instead of using re0 at pci3 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x07) re0: interrupting at msi3 vec 0 rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5 (with ip4csum etc enabled) I tried a USB wireless dongle, and the same cvs checkout over urtwm0 appears to be fine. (No change of kernel, no reboot.) Cheers, Patrick (much happier that ffs is blameless)
