Date: Sun, 19 Apr 1998 22:02:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kpielorz@tdx.co.uk (Karl Pielorz) Cc: tlambert@primenet.com, allenc@verinet.com, config@FreeBSD.ORG Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' Message-ID: <199804192202.PAA15594@usr08.primenet.com> In-Reply-To: <353A70A6.E90B3645@tdx.co.uk> from "Karl Pielorz" at Apr 19, 98 10:46:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Two things... > > 1. The subject line on this message is the worst I've seen in a long time - > Will whoever replies next tidy it up properly (like I didn't! :-) Yes. > 2. This has been cross-posted to hackers & config... I've only posted it to > hackers - as looking back that's where most the messages went... I'm all to > willing to move to Config if that's where it's / were meant to be! <g> This was supposed to only go to config, like was suggested in the message I replied to. > Thus you'd get a couple of 'dodgy' records in your text dump which you could > edit by hand, then nuke the config database - and re-import the text file > once it was cleaned up... > > It would be nice to see a config database done 'the propper way', i.e. not > liable to application corruption etc. - perhaps even with 'descriptions' for > all the records it holds... ;-) These two paragraphs are not unrelated. If you use an API with get/set semantics, and it does the set as a transaction, then you are not liable to corruption unless your physical media goes bad. If the physical media goes, it doesn't matter how it's implemented. Clearly, you would need to take the same care in backing up a binary file as you do in backing up a text file in case of physical failure. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804192202.PAA15594>