Date: Mon, 5 Apr 2004 17:09:49 +0200 From: Gabriel Ambuehl <gabriel_ambuehl@buz.ch> To: Andy Sporner <sporner@nentec.de> Cc: freebsd-cluster@freebsd.org Subject: Re[2]: Request for Cluster Recommendations Message-ID: <1131541187.20040405170949@buz.ch> In-Reply-To: <40711AB9.6010602@nentec.de> References: <002401c419e7$76692ac0$2f01a8c0@MICHAELIWZHLNY> <20040404103346.76151.qmail@web41501.mail.yahoo.com> <987274454.20040404124312@buz.ch> <40711AB9.6010602@nentec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Andy, Monday, April 5, 2004, 10:37:13 AM, you wrote: > At 20:00 (Berlin Standard time) I will release an initial release of > FREP 2.0 > Somebody pointed out that It was too bad I couldn't use 'triggers' > to driver the replication. I realized that I had sort of that kind of > thing already, but not generic enough for ordinary use outside of > FREP. So now it is. > For example, Whenever you modify /etc/inetd.conf the deaemon is > sent a SIGHUP. Or if a file is created in a directory (such as a spool > directory) that a program is called with the name of the file as an > argument. You might want to submit that to the main tree once it becomes stable, it would be immensely useful for on access anti virus scans, for one and I'm sure there are other areas that currently don't come to my mind... > to be 100% accurate (at least in the kernel). Many times when I > would try to get a full filename I got errors (path component not > a directory) when I passed a vnode of a file in to get the path name. > In a file replication scheme--this is not acceptable. Great. I'll surely beat on it over Easter holidays (I doubt I'll have much time before though). Best regards, Gabriel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1131541187.20040405170949>