Patch for raidtools-1.00.3 compile error under gcc 3.3.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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;
     }
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux