Port crashpad::Settings to Windows

[GoogleCodeExporter]

Settings currently uses flocks and O_EXCL|O_CREAT, which are POSIXy and need to 
be ported to Windows. We should expand the file_io.h interface to support 
locking. Currently the implementation is excluded by GYP.

https://codereview.chromium.org/988063003/

Original issue reported on code.google.com by rsesek@chromium.org on 9 Mar 2015 at 6:18

[GoogleCodeExporter]

This

  ScopedFileHandle handle(HANDLE_EINTR(
      open(file_path(), O_RDWR | O_EXLOCK | O_CREAT)));

will just fail (not block) if the file's already locked, right?

Original comment by scottmg@chromium.org on 10 Mar 2015 at 5:35

[GoogleCodeExporter]

No, that will block. O_NONBLOCK would be required to make it non-blocking and 
return EAGAIN if it were already locked.

Original comment by rsesek@chromium.org on 10 Mar 2015 at 5:40

[GoogleCodeExporter]

I see, thanks.

Looking into it a bit more, I'm leaning towards implementing Lock/Unlock in 
file_io.h. Windows doesn't have the ability to atomically do a LockFileEx in 
the CreateFile call (it can open exclusively/lock, but can't have CreateFile 
block until the lock is released).

It seems the O_EXLOCK and O_SHLOCK don't exist on Linux either at least 
according to `man 2 open` on my box. Not a consideration now, but presumably 
will be in the future. (?)

Does that seem reasonable? i.e. switching to separate flock-ish calls?

Original comment by scottmg@chromium.org on 11 Mar 2015 at 12:00

[GoogleCodeExporter]

Original comment by mark@chromium.org on 11 Mar 2015 at 4:11

• Changed state: New

[GoogleCodeExporter]

That should be fine. The only tricky bit is the O_EXCL|O_CREAT in Initialize, 
which could then be raced since the O_EXLOCK won't be taken at the same point. 
Otherwise, it should be fine to split open() and flock().

Original comment by rsesek@chromium.org on 11 Mar 2015 at 10:24

[GoogleCodeExporter]

Original comment by scottmg@chromium.org on 1 May 2015 at 10:10

• Changed state: Fixed