From mboxrd@z Thu Jan  1 00:00:00 1970
From: achurch@achurch.org (Andrew Church)
Subject: Patch for raidtools-1.00.3 compile error under gcc 3.3.1
Date: Sun, 28 Sep 2003 00:23:41 JST
Sender: linux-raid-owner@vger.kernel.org
Message-ID: <3f75abe2.03735@achurch.org>
Content-Type: text/plain; charset=ISO-2022-JP
Return-path: <linux-raid-owner@vger.kernel.org>
To: linux-raid@vger.kernel.org
List-Id: linux-raid.ids

[Note: I am not subscribed to this list.]

     The following patch corrects a multiline string that causes compile
errors when using gcc 3.3.1 (which does not allow multiline strings without
continuation backslashes).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

---------------------------------------------------------------------------

diff -ur ../raidtools-1.00.3-orig/mkraid.c mkraid.c
--- ../raidtools-1.00.3-orig/mkraid.c	2003-01-15 17:58:25 +0900
+++ mkraid.c	2003-09-28 00:22:05 +0900
@@ -171,31 +171,31 @@
     if (old_force_flag && (func == mkraid)) {
 	fprintf(stderr, 
 
-"
- WARNING!
-
- NOTE: if you are recovering a double-disk error or some other failure mode
- that made your array unrunnable but data is still intact then it's strongly
- recommended to use the lsraid utility and to read the lsraid HOWTO.
-
- If your RAID array holds useful and not yet backed up data then --force
- and the hot-add/hot-remove functionality should be used with extreme care!
- If your /etc/raidtab file is not in sync with the real array configuration,
- then --force might DESTROY ALL YOUR DATA. It's especially dangerous to use
- -f if the array is in degraded mode.
-
- If your /etc/raidtab file matches the real layout of on-disk data then
- recreating the array will not hurt your data, but be aware of the risks
- of doing this anyway: freshly created RAID1 and RAID5 arrays do a full
- resync of their mirror/parity blocks, which, if the raidtab is incorrect,
- the resync will wipe out data irrecoverably. Also, if your array is in
- degraded mode then the raidtab must match the degraded config exactly,
- otherwise you'll get the same kind of data destruction during resync.
- (see the failed-disk raidtab option.) You have been warned!
-
- [ If your array holds no data, or you have it all backed up, or if you
- know precisely what you are doing and you still want to proceed then use
- the --really-force (or -R) flag. ]
+"\n\
+ WARNING!\n\
+\n\
+ NOTE: if you are recovering a double-disk error or some other failure mode\n\
+ that made your array unrunnable but data is still intact then it's strongly\n\
+ recommended to use the lsraid utility and to read the lsraid HOWTO.\n\
+\n\
+ If your RAID array holds useful and not yet backed up data then --force\n\
+ and the hot-add/hot-remove functionality should be used with extreme care!\n\
+ If your /etc/raidtab file is not in sync with the real array configuration,\n\
+ then --force might DESTROY ALL YOUR DATA. It's especially dangerous to use\n\
+ -f if the array is in degraded mode.\n\
+\n\
+ If your /etc/raidtab file matches the real layout of on-disk data then\n\
+ recreating the array will not hurt your data, but be aware of the risks\n\
+ of doing this anyway: freshly created RAID1 and RAID5 arrays do a full\n\
+ resync of their mirror/parity blocks, which, if the raidtab is incorrect,\n\
+ the resync will wipe out data irrecoverably. Also, if your array is in\n\
+ degraded mode then the raidtab must match the degraded config exactly,\n\
+ otherwise you'll get the same kind of data destruction during resync.\n\
+ (see the failed-disk raidtab option.) You have been warned!\n\
+\n\
+ [ If your array holds no data, or you have it all backed up, or if you\n\
+ know precisely what you are doing and you still want to proceed then use\n\
+ the --really-force (or -R) flag. ]\n\
 ");
 	return EXIT_FAILURE;
     }