Fatal error

[HansArne]

Got this message:

FATAL ERROR: CoreLib [002.005] {ncbifile.c, line 715} File write error

The client was still running but the cpu use was 0
Had to terminate it from taskmanager and restart it
I have had this error 3 times on this pc.
using -qt -rt
(win 2000)

[Brian the Fist]

Most likely your disk drive is full. Check ALL your drives and see if any are near full capacity, and clear some room if needed.
Alternatively, you may not have permission to write to your TEMP directory.

[HansArne]

I have 5gb free space and have admin rights on the pc.
Have used the pc since phase2 started, but the error have only happened the last two weeks

[^7_of_9]

Also had this prob on three different machines this week myself. All had MORE than ample space to run as well as admin rights and all.

Just deleted filelist and restarted.

No I didn't save the directories either :D

[Brian the Fist]

This is just a raw system call to fwrite. Here's the exact code:

cnt = fwrite(ptr,size,n,stream);

if (cnt!=n)
/* print error */

According to MSVC, this can happen if you are out of space, or a bad file handle. I don't know what else to tell you. I suppose it would be nice if it told us the name of the file it was trying to write, but as you can see the error message is in NCBI library code :D

If you try to restart the program do you still get the error? How about if you copy the dir to another machine, do you still get the error? If you answered yes to the last question, please send us your directory!

[HansArne]

No. If I restart the client works fine
It just continue where it stopped without any errors

[rsbriggs]

Most "reasonable" programs would print the date/time, value of "cnt", "errno". and the file name at that point, so that it wouldn't be necessary to continue to just speculate about what is causing the problem.

And let me address the objections before you even get started.

O.) The NCBI library isn't our code.
A.) Change it anyway

O.) We don't have time to change it/put in debugging statements for every hardware platform.
A.) Don't. Just change it for Windows, where the problem is taking place.

Q.) The NCBI code can change, wiping out our changes.
A.) 1.) Get a stable package that doesn't change so much
A.) 2.) Doesn't matter the slightest bit. Put the changes in now, and you'll find the bug. Either pass the bug back to the authors for them to fix, or fix it and stop taking every update they send out. See A-1 above...

[wirthi]

I'll second rsbriggs statement. It's obviously either a bug in your code, in NCBI code or in the environment that is running the code. For all three the most important thing is to find out WHY it happens and how it happens - and to make it happen not a single time again :)

This NCBI seems to brake more things than it solves. I've seen you posting negative things about it in the past. Is there no alternative to it? It must be REALLY good if you accept all the bugs it has ...

[Brian the Fist]

The NCBI toolkit is extremely useful and quite bug free for the most part actually. I don't have much negative to say about it.

Anyhow, I was under the impression this bug was very rare. If it happens frequently to you, PM me with your e-mail and Ill send you a new Windows EXE that prints out the extra info to help us debug it. One more question, are you running one or two instances of the program at a time?

[HansArne]

I just run one instance of the client and it doesn't happen that often. It have worked well for several days now. I will send a PM if it happens again.

[Brian the Fist]

That won't help us fix the problem. I'd like to send you a 'debug' version to help identify what is happening on your machine.

[HansArne]

ok.
I have sent my email address on pm

[Grumpy]

Bah, it is back :(

Had it with the new client , go to get the gun and shoot ol yeller
:bang: