Date: Fri, 27 Sep 1996 14:19:15 +0200 From: "Julian H. Stacey" <jhs@freebsd.org> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: current@freebsd.org Subject: Re: ctm & disc full Message-ID: <199609271219.OAA17618@vector.jhs.no_domain> In-Reply-To: Your message of "Tue, 24 Sep 1996 19:23:13 %2B0200." <663.843585793@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Reference: > From: Poul-Henning Kamp <phk@critter.tfs.com> > > In message <199609241334.PAA07476@vector.jhs.no_domain>, "Julian H. Stacey" w - ri > tes: > >No great problem if applying manually, > >But could be problematic for those who have procmail applying ctm patches > >in background mode, if the disc fills up. > > > >In an ideal world .ctm_status could record both start of application > >& end of succesful application, but that'd need a patch, & some discussion, > >meantime, could you document the hazard ? > > The solution is to implement this: > > cd /home > rm -rf ncvs.tmp > mkdir ncvs.tmp > cd ncvs > find . -print | cpio -dumpl ../ncvs.tmp > cd ../ncvs.tmp > if ctm -v <whatever> ; then > cd .. > mv ncvs ncvs.old > mv ncvs.tmp ncvs > rm -rf ncvs.old > fi Man cpio has do dumpl or even dump, are you using a non standard cpio ? I see no variant of cpio from echo /usr/ports/*/*pi* Catching your drift though, one could use tar or cpio to copy the cvs/ tree, apply the diff & then move tree, but I dont have the 250M spare for a 2nd transient cvs/ tree, neither do I want to incur the mega processing load per ctm patch, so I don't find this solution very attractive. That's not to denigrate it though, it is at least _a_ solution, if I had an idle system, hundreds of Meg free, & was in no rush to apply ctms quickly I'd adopt it, ... but then I'd probably be more immune to disc overflows in the first place :-). Puting a `start of application & end of succesful application' double stamp in the .ctm_ file would run at minimal overhead, but would still leave one with a broken tree. However, it would detect errors on overflow quicker than at present. At present if succesive ctms happen to touch different areas, one may be unaware for a while longer, of a tree broken through overflow. BTW I did a quick check in /usr/src/ctm/ctm/*.c: all 4 write() invocations are protected by if != Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609271219.OAA17618>