From what I'm hearing, the problem is not the OS, which is doing exactly what it's supposed to do.
The problem is the engineers that set it up. Apparently when the flash device was formated, it was formated with the expectation of only holding a certain number of files. When they exceeded that number, the file handler in the OS refused to access any more files. IOW, it operated as designed.
The fix that they are setting up for this weekend is basically a format and reinstall. Once the filesystem is set up properly, the rover shouldn't have this kind of problem again.
A lot of Unix engineers are familiar with this kind of problem. Anyone who has set up a system that grew much faster than expected has probably run into the same issue.
Doesn't all software do what it's supposed to do (ie. programmed to do), as long as the hardware is working properly? :)
Thanks for the additional information. I'm an embedded flight software engineer at NASA Goddard. In my early years there (roughly ten years ago), I helped develop Command & Data Handling flight software on 386/VRTX missions but later on (about five years ago) I worked on RAD6000/VxWorks missions. I'm currently working on component level (microcontroller) hardware that will still fly in space but the software will not require an RTOS. The information I've received concerning Spirit's troubles was of a superficial nature and I appreciate your filling in the details.