Alvaro Herrera wrote:
> So _anything_ could be EINVAL. Including the several cases that
> _dosmaperr treat as EACCES. So I'm afraid that for this experiment to
> be successful, we would have to remove not only the EINVAL cases from
> doserrors[], but also any other code that appears more than once on it.
> Otherwise the output could be ambiguous.
OK, this got tested by the original reporter and the result is this:
2007-12-12 10:55:49 ERROR: could not open relation 1663/16403/1247: Permission denied
I think this is EACCES, right? So we now need to know which one it is:
ERROR_ACCESS_DENIED
ERROR_CURRENT_DIRECTORY
ERROR_LOCK_VIOLATION
ERROR_SHARING_VIOLATION
ERROR_NETWORK_ACCESS_DENIED
ERROR_CANNOT_MAKE
ERROR_FAIL_I24
ERROR_DRIVE_LOCKED
ERROR_SEEK_ON_DEVICE
ERROR_NOT_LOCKED
ERROR_LOCK_FAILED
(These are the Win32 codes mapped to EACCES by our _dosmaperr.)
Many of these are nonsensical -- we know this is not a device, nor
network access. Still there is more than one possibility, and I don't
know which ones should be really acceptable in this context or not.
(What's ERROR_FAIL_I24??) SHARING_VIOLATION seems the most likely
problem; an antivirus perhaps?
My suggestion continues to be: these codes oughta be logged separately
from the strerror() message. If there are cases which we know are
deemed to occur in regular operation, let's suppress only those. None
of them is one of these EACCES, AFAIR.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)