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