FILE_IO_ERROR?

[Mohonri]

So one of my machines just finished a WU, but didn't upload it. I looked at fahlog.txt, and I found this:

[07:38:54] Leaving Run
[07:38:59] - Writing 2197747 bytes of core data to disk...
[07:38:59] - Could not write to results file.
[07:38:59] - Error: Could not write out results to file
[07:38:59] - Shutting down core
[07:38:59] 
[07:38:59] Folding@home Core Shutdown: FILE_IO_ERROR
[07:39:02] CoreStatus = 75 (117)
[07:39:02] Error opening or reading from a file.
[07:39:02] Deleting current work unit & continuing...

Has anyone run into this before? What's the deal?

 

[BillR]

Could have been any number of things. Got a UPS on that machine? I have had a core go bad from time to time, espcially after a defrag. As a rule I delete all cores before doing a defrag now. Give that a try, don't cost nothin

 

[Mohonri]

A UPS? In a way, yes--it's a laptop! I'll go ahead and delete all the cores (that aren't being used at the moment) and see if that helps.

 

[thedude42]

I had these big time. Almost every one of my windows folders had this problem at some time or another, and I could never figure out exactly why. My linux folders never had the problem.

My problem may be different, as the machiens would finish a work unit, turn it in, then get the FILE_IO error and just loop it over and over, and the onyl fix was reinstalling the client, where it would complete a work unit, turn it in, and begin the looping error all over again.

I tried:

-deleting the core files and restarting the service
-deleting the work folder and restarting the service
-reinstalling the console client and rewriting the config file
-moving the folding files to a folder on its own partition or drive (if the machine had multiple driver or partitions)

what made all the problems go away:
-built a win2k3 active directory domain and put all the folders on it

I have to assume, but have no proof because I never took the time to do the forensic work necessary, that this was due to a permissions error between the process and the file system, something along those lines. Maybe a kernel mode/user mode conflict, and I probably could have tried forcing the service to load as a seperate user... but the bottom line is that if my case was a hardware problem, then I should still be getting this problem today, but I don't.

I'm definitely not advocating that you bring up a domain to solve the problem. However, you might try to make sure that you are using simple file sharing on your windows XP machines and that any windows 2000 machines have the GPO set to use anonymous access for all shared files. All my systems were using windows authentication prior to bringing up the domain (so I could have read/write permissions for administrators on remote shares) so this could also have been a source of my issues.