jdm1@eds1.UUCP (Jon McCown) (12/08/89)
(Apologies in advance if this is old news or previously discussed)
I am building/have built v1.3 from the 1.2+Upgrade kit, and encountered
the need to rebuild the libc.a so as to include such niceties as swab and
strrchr. (no problem here)
Using the "Zevon" library rebuild script, I let the machine crank on for a
couple of hours, after which time it howled to a halt with a full hard disk.
(this is a 10 meg partition!) Andy's notes indicate that the 'full' library
took up a bit more space than the distributed one, but this amazed even me.
Dissecting the library rebuild script ("run") and executing it in
discrete steps, I noticed that what croaked the process was:
cat /dev/null > newfile
Which seemed innocent enough to me, until newfile (or whatever) grew to
fill the HD. I haven't yet gotten into the FS code to look, but has anyone
seen this before? My 1.3 is the one distributed in the ../src/tools of the
upgrade kit, as I wanted to get the libc.a up to snuff before recompiling.
Jon McCown
Can't wait to get my hands on shoelace!
--
J.D. McCown - RCSG Director - Senate of Pennsylvania
psuvax1!eds1!jdm1 (this space intentionally "Your life or your lupins!"
jdm1@eds1.eds.com filled with this text) - Dennis Mooreching@snap.amd.com (Mike Ching) (12/08/89)
In article <424@eds1.UUCP> jdm1@eds1.UUCP (Jon McCown) writes:
-
-Dissecting the library rebuild script ("run") and executing it in
-discrete steps, I noticed that what croaked the process was:
-
-cat /dev/null - newfile
-
-Which seemed innocent enough to me, until newfile (or whatever) grew to
-fill the HD. I haven't yet gotten into the FS code to look, but has anyone
-seen this before?
I had the same problem and replaced the line with 'rm newfile ; touch newfile'
to create the file. There's another occurance of file creation in "run"
that I fixed the same way. I didn't try to figure out what is broken in
cat.
mike ching