Octocontrabass wrote:
rdos wrote:
What if some part of the directory entry that the file reside in is bad? Or if some part of the FAT table? The latter errors cannot reasonably be reported to the application as part of open, read or write.
Why not? The application doesn't care why the operation failed, just that it did.
If the directory entry that contains the file name is bad, then you will get back "file not found". Unless you interpret this as an error and report IO error, but then this will be reported regardless of which file you try to open. If the FAT is corrupt, then the alternative FAT might be used, and then the application shouldn't get an error, but you still have a serious error condition on the disc that essentially will go unreported. Basically, both of these are conditions that are better reported in a disc event interface rather than through normal file IO.
Octocontrabass wrote:
rdos wrote:
Take another example. One sector of an executable file is bad. If somebody tries to load the executable, will the load operation itself hinder it from being run? Or will accessing that particular part cause random garbage to execute?
If you always return success, garbage will be executed.
Zeros is not random garbage, and when executed on x86 will typically result in faults.
Octocontrabass wrote:
If you propagate failures up to the requestor, then whatever requested to put that part of the executable into memory will see the failure. If the loader attempts to put the entire executable into memory before running it, the loader will see the error and fail to start the program. If the executable is loaded as needed using demand paging, the page fault handler will see the error and terminate the program.
This is very problematic behavior for embedded systems. In this case you don't know why the program terminated, and so you simply try to retstart it in a loop. If the program faults instead, or report disc events to another interface, then the supervisor can decide there is some fatal problem somewhere and report this in a more adequate way rather than getting into a reboot-loop. Putting up error dialogs (which Windows typically does), is even worse and gives potential customers the idea they are dealing with poor software.