Chris, > We could translate those errors into EIO or something > documented by the msync man page, but that's less > descriptive and potentially confusing. Perhaps we > should consider updating the man page.
As a programmer I would much prefer to have the most descriptive errors possible. The thing that surprises me is that i get an error that seems to indicate that "I can't use any MORE space". I am not trying to use any MORE space, I am just trying to overwrite the space that I have already been allocated from the file system. If I had created a file with holes in it then I could understand a msync generating an error when it tried to fill the holes. Although perhaps the mmap should have generated the error not the msync . . . not sure. It seems to me that this is a backwards incomparability. My program goes to a great deal of effort to deal with running out of disk space by checking all the writes, and dealing with errors. But it does very little checking on msync. The last thing I expected was to find that the disk space that had apparently already been allocated to me through writes had been mysteriously unallocated behind my back. I just had a thought. If I had not done the msync but had instead just exited my program would my changes to the mmap region have been written to disk by fsflush or would fsflush have failed to write my changes? If fsflush failed to write the changes would it have generated/logged an error? I had another thought. If I had fsynced rather than msynced would I have got an error? Note: I modified my program so that it didn't use mmap. Instead after I had filled up the disk using the second file I then tried to overwrite the contents of the first using pwrite. These attempts to overwrite using pwrite also failed with EDQUOT. This just seems wrong. I'm not trying to get more disk space, i'm just trying to change the contents of the space that is already mine. Neil. -- This messages posted from opensolaris.org
