Mapping file busy/exists in POSIX File::OSErrorToFileError().

Mapping file busy/exists in POSIX File::OSErrorToFileError().

Supporting two previously unmapped errno values: EBUSY to FILE_ERROR_IN_USE,
and EIO to FILE_ERROR_IO.

Both of these error values are reported in significant quantities when looking
at the results for PlatformFile.UnknownErrors.Posix.

Committed: https://crrev.com/96691e2856d9485d48c71ca40a2fb671a18ef3be
Cr-Commit-Position: refs/heads/master@{#320549}

[cmumford, 2015-03-12 17:27:32]

cmumford@chromium.org changed reviewers:
+ rvargas@chromium.org

[rvargas (doing something else), 2015-03-12 22:10:57]

lgtm after confirming with someone from NaCl.

https://codereview.chromium.org/1001023002/diff/1/base/files/file_posix.cc
File base/files/file_posix.cc (right):

https://codereview.chromium.org/1001023002/diff/1/base/files/file_posix.cc#ne...
base/files/file_posix.cc:474: case EBUSY:
My guess is that this is also not defined by NaCl.

[cmumford, 2015-03-12 22:41:32]

https://codereview.chromium.org/1001023002/diff/1/base/files/file_posix.cc
File base/files/file_posix.cc (right):

https://codereview.chromium.org/1001023002/diff/1/base/files/file_posix.cc#ne...
base/files/file_posix.cc:474: case EBUSY:
On 2015/03/12 22:10:57, rvargas wrote:
> My guess is that this is also not defined by NaCl.

Looks like EBUSY *is* supported. Lots of matches in native_client_sdk/**.cc. The
PNACL team seems to think it's supported too. ETXTBUSY is not in there (which
agrees with the current implementation), and to be safe I verified that EIO is
supported.

I'm also a little confused why we ETXTBUSY is #ifdef'ed out. Sure NaCL never
set's errno to this value, but if that ever changes then we'll stop mapping the
value. Why not just map it (but have a comment saying it'll probably never be
seen)?

[rvargas (doing something else), 2015-03-12 22:58:07]

https://codereview.chromium.org/1001023002/diff/1/base/files/file_posix.cc
File base/files/file_posix.cc (right):

https://codereview.chromium.org/1001023002/diff/1/base/files/file_posix.cc#ne...
base/files/file_posix.cc:474: case EBUSY:
On 2015/03/12 22:41:32, cmumford wrote:
> On 2015/03/12 22:10:57, rvargas wrote:
> > My guess is that this is also not defined by NaCl.
> 
> Looks like EBUSY *is* supported. Lots of matches in native_client_sdk/**.cc.
The
> PNACL team seems to think it's supported too. ETXTBUSY is not in there (which
> agrees with the current implementation), and to be safe I verified that EIO is
> supported.
> 
> I'm also a little confused why we ETXTBUSY is #ifdef'ed out. Sure NaCL never
> set's errno to this value, but if that ever changes then we'll stop mapping
the
> value. Why not just map it (but have a comment saying it'll probably never be
> seen)?

My impression is that they wanted to provide a strict subset of functionality
and wanted to make sure the compiler would complain as soon as possible.

I would be happy to see ifdefs disappear but that's another discussion :)

https://codereview.chromium.org/1001023002/diff/1/base/files/file_posix.cc#ne...
base/files/file_posix.cc:477: case ETXTBSY:
nit: Given that this is staying, we should probably write the code as we
normally would and wrap only this line with an ifdef.

[cmumford, 2015-03-13 17:58:29]

The CQ bit was checked by cmumford@chromium.org

[cmumford, 2015-03-13 17:58:30]

The patchset sent to the CQ was uploaded after l-g-t-m from rvargas@chromium.org
Link to the patchset: https://codereview.chromium.org/1001023002/#ps20001
(title: "Simplified EBUSY/ETXTBSY ifdef")

[commit-bot: I haz the power, 2015-03-13 17:59:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1001023002/20001

[commit-bot: I haz the power, 2015-03-13 19:35:10]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-13 19:36:21]

Patchset 2 (id:??) landed as
https://crrev.com/96691e2856d9485d48c71ca40a2fb671a18ef3be
Cr-Commit-Position: refs/heads/master@{#320549}