No worry, sync did not fix it.
Mikael
Peter Bortas @ Pike developers forum wrote:
sync exists on a lot of systems, but not all. That sync helps suggests that the OS i broken. the kernel disk layer should keep the view of the disk consistent ragardless of what has hit real media and what is still in memory.
check in "#FIXME: Required by one MacOS machine. Broken kernel disk layer? sync >/dev/null 2>&1"
/ Peter Bortas
Previous text:
2004-08-21 02:32: Subject: Re: Pikefarm client problem
Ok. That was my bet, on both answers. I've modified my local makefile to do a sync prior to tar. Still it seems cludgy to have such a solution in the Makefile. I suppose sync is fairly standard on systems pike compile on through the xenofarm client, isn't it?
// Mikael
Peter Bortas @ Pike developers forum wrote:
If the option starts with "--"* you can pretty much bet it's not Posix. Demanding a GNU compatible tar is not an option. If you a add "sync" (or MacOS X equivalent) before tar, does it work better?
- Send a thankful thought in Aronsson direction that we don't have to
type "-=". See http://www.gnu.org/fun/jokes/long-options.html.
/ Peter Bortas
Previous text:
2004-08-20 20:04: Subject: Re: Pikefarm client problem
Things seems odd. I tried adding ls statements around the offending tar line (second to last line in the xenofarm target), then it worked. When I removed those ls statements, it worked, and now when I try using the pike farm client, it fails again.
Is the --ignore-failed-read option POSIX or GNU? Does Pike currently have any requirements on tar in the build environment? If --ignore-failed-read is POSIX or if Pike can be let to require a tar which understands the option, shall we patch the Makefile to make use of --ignore-failed-read for the xenofarm target? Otherwise, are there any other suggestions on how to fix this problem?
// Mikael
Mikael Brandström wrote:
I was wrong. The tar command generating the error is found within Pike's Makefile. For some reason it fails when run within xenofarm, but not when I run it stand-alone. It seems like I have to do some more debugging to pin down the problem.
// Mikael
Mikael Brandström wrote:
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
>In the last episode (Aug 20), Mikael Brandstrm said: > > > >>today I tried setting up the xenofarm client to compile pike on my >>Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. >>Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm >>fails when assembling the result with the following lines from the >>xeonfarmclient.txt: >> >>BEGIN response_assembly >>PASS >>END >>cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar >>tar: ./compilelog.txt: file changed as we read it >>tar: Error exit delayed from previous errors >>make: *** [xenofarm] Error 2 > > > > >I don't know why you're getting the error, but --ignore-failed-read >will make tar treat it as a warning (tar is used 3 places in >client.sh). GNU tar stats the file before and after reading it, and if >the ctime is different, it prints that message. >
/ Brevbäraren
/ Brevbäraren