2014-12-17 14:35:18 -08:00
|
|
|
// Copyright 2014 The Crashpad Authors. All rights reserved.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
|
|
|
#include "util/file/file_io.h"
|
|
|
|
|
util/file: Handle oversized reads and writes gracefully
file_io and the FileReader family had a few loose ends regarding big
reads and writes. It’s not likely that we’ve experienced these
conditions yet, but they’d be likely to appear in a potential future
involving full memory dumps. This specifies the behavior with large
reads and writes, consolidates some logic, and improves some interfaces.
ReadFile() should always return without retrying after a short read, and
in fact does return after short reads since 00b64427523b. It is
straightforward to limit the maximum read size based on a parameter
limitation of the underlying operation, or a limitation of the type used
for FileOperationResult.
In contrast, WriteFile() should always retry after a short write,
including a write shortened because of a parameter limitation of the
underlying operation, or a limitation of the type used for
FileOperationResult. This allows its return value to be simplified to a
“bool”.
The platform-specific WriteFile() code has been moved to
internal::NativeWriteFile(), and the platform-independent loop that
retries following a short write has been refactored into
internal::WriteAllInternal so that it can be used by a new test.
The platform-agnostic ReadFileExactlyInternal() implementation has been
refactored into internal::ReadExactlyInternal so that it can be used by
a new test and by FileReaderInterface::ReadExactly(), which had a nearly
identical implementation.
Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_*
Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864
Reviewed-on: https://chromium-review.googlesource.com/456824
Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
|
|
|
#include <algorithm>
|
|
|
|
#include <limits>
|
|
|
|
|
2014-12-18 16:29:33 -08:00
|
|
|
#include "base/files/file_path.h"
|
2014-12-17 14:35:18 -08:00
|
|
|
#include "base/logging.h"
|
2020-06-18 15:35:28 +02:00
|
|
|
#include "base/notreached.h"
|
2015-05-01 15:49:35 -07:00
|
|
|
#include "base/strings/utf_string_conversions.h"
|
2014-12-17 14:35:18 -08:00
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
bool IsSocketHandle(HANDLE file) {
|
|
|
|
if (GetFileType(file) == FILE_TYPE_PIPE) {
|
|
|
|
// FILE_TYPE_PIPE means that it's a socket, a named pipe, or an anonymous
|
|
|
|
// pipe. If we are unable to retrieve the pipe information, we know it's a
|
|
|
|
// socket.
|
2020-04-25 23:35:08 -04:00
|
|
|
return !GetNamedPipeInfo(file, nullptr, nullptr, nullptr, nullptr);
|
2014-12-17 14:35:18 -08:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
namespace crashpad {
|
|
|
|
|
2015-04-20 14:21:48 -07:00
|
|
|
namespace {
|
|
|
|
|
util/file: Handle oversized reads and writes gracefully
file_io and the FileReader family had a few loose ends regarding big
reads and writes. It’s not likely that we’ve experienced these
conditions yet, but they’d be likely to appear in a potential future
involving full memory dumps. This specifies the behavior with large
reads and writes, consolidates some logic, and improves some interfaces.
ReadFile() should always return without retrying after a short read, and
in fact does return after short reads since 00b64427523b. It is
straightforward to limit the maximum read size based on a parameter
limitation of the underlying operation, or a limitation of the type used
for FileOperationResult.
In contrast, WriteFile() should always retry after a short write,
including a write shortened because of a parameter limitation of the
underlying operation, or a limitation of the type used for
FileOperationResult. This allows its return value to be simplified to a
“bool”.
The platform-specific WriteFile() code has been moved to
internal::NativeWriteFile(), and the platform-independent loop that
retries following a short write has been refactored into
internal::WriteAllInternal so that it can be used by a new test.
The platform-agnostic ReadFileExactlyInternal() implementation has been
refactored into internal::ReadExactlyInternal so that it can be used by
a new test and by FileReaderInterface::ReadExactly(), which had a nearly
identical implementation.
Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_*
Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864
Reviewed-on: https://chromium-review.googlesource.com/456824
Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
|
|
|
// kMaxReadWriteSize needs to be limited to the range of DWORD for the calls to
|
|
|
|
// ::ReadFile() and ::WriteFile(), and also limited to the range of
|
|
|
|
// FileOperationResult to be able to adequately express the number of bytes read
|
|
|
|
// and written in the return values from ReadFile() and NativeWriteFile(). In a
|
|
|
|
// 64-bit build, the former will control, and the limit will be (2^32)-1. In a
|
|
|
|
// 32-bit build, the latter will control, and the limit will be (2^31)-1.
|
|
|
|
constexpr size_t kMaxReadWriteSize = std::min(
|
|
|
|
static_cast<size_t>(std::numeric_limits<DWORD>::max()),
|
|
|
|
static_cast<size_t>(std::numeric_limits<FileOperationResult>::max()));
|
|
|
|
|
2015-10-07 11:40:02 -04:00
|
|
|
FileHandle OpenFileForOutput(DWORD access,
|
|
|
|
const base::FilePath& path,
|
|
|
|
FileWriteMode mode,
|
|
|
|
FilePermissions permissions) {
|
|
|
|
DCHECK(access & GENERIC_WRITE);
|
|
|
|
DCHECK_EQ(access & ~(GENERIC_READ | GENERIC_WRITE), 0u);
|
|
|
|
|
2015-04-20 14:21:48 -07:00
|
|
|
DWORD disposition = 0;
|
|
|
|
switch (mode) {
|
2015-10-07 08:20:55 -04:00
|
|
|
case FileWriteMode::kReuseOrFail:
|
|
|
|
disposition = OPEN_EXISTING;
|
|
|
|
break;
|
2015-04-20 14:21:48 -07:00
|
|
|
case FileWriteMode::kReuseOrCreate:
|
|
|
|
disposition = OPEN_ALWAYS;
|
|
|
|
break;
|
|
|
|
case FileWriteMode::kTruncateOrCreate:
|
|
|
|
disposition = CREATE_ALWAYS;
|
|
|
|
break;
|
|
|
|
case FileWriteMode::kCreateOrFail:
|
|
|
|
disposition = CREATE_NEW;
|
|
|
|
break;
|
|
|
|
}
|
2015-10-07 11:40:02 -04:00
|
|
|
return CreateFile(path.value().c_str(),
|
|
|
|
access,
|
|
|
|
FILE_SHARE_READ | FILE_SHARE_WRITE,
|
|
|
|
nullptr,
|
|
|
|
disposition,
|
|
|
|
FILE_ATTRIBUTE_NORMAL,
|
|
|
|
nullptr);
|
2015-04-20 14:21:48 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
util/file: Handle oversized reads and writes gracefully
file_io and the FileReader family had a few loose ends regarding big
reads and writes. It’s not likely that we’ve experienced these
conditions yet, but they’d be likely to appear in a potential future
involving full memory dumps. This specifies the behavior with large
reads and writes, consolidates some logic, and improves some interfaces.
ReadFile() should always return without retrying after a short read, and
in fact does return after short reads since 00b64427523b. It is
straightforward to limit the maximum read size based on a parameter
limitation of the underlying operation, or a limitation of the type used
for FileOperationResult.
In contrast, WriteFile() should always retry after a short write,
including a write shortened because of a parameter limitation of the
underlying operation, or a limitation of the type used for
FileOperationResult. This allows its return value to be simplified to a
“bool”.
The platform-specific WriteFile() code has been moved to
internal::NativeWriteFile(), and the platform-independent loop that
retries following a short write has been refactored into
internal::WriteAllInternal so that it can be used by a new test.
The platform-agnostic ReadFileExactlyInternal() implementation has been
refactored into internal::ReadExactlyInternal so that it can be used by
a new test and by FileReaderInterface::ReadExactly(), which had a nearly
identical implementation.
Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_*
Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864
Reviewed-on: https://chromium-review.googlesource.com/456824
Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
|
|
|
namespace internal {
|
|
|
|
|
|
|
|
FileOperationResult NativeWriteFile(FileHandle file,
|
|
|
|
const void* buffer,
|
|
|
|
size_t size) {
|
|
|
|
// TODO(scottmg): This might need to handle the limit for pipes across a
|
|
|
|
// network in the future.
|
|
|
|
|
|
|
|
const DWORD write_size =
|
|
|
|
static_cast<DWORD>(std::min(size, kMaxReadWriteSize));
|
|
|
|
|
|
|
|
DWORD bytes_written;
|
|
|
|
if (!::WriteFile(file, buffer, write_size, &bytes_written, nullptr))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
CHECK_NE(bytes_written, static_cast<DWORD>(-1));
|
|
|
|
DCHECK_LE(static_cast<size_t>(bytes_written), write_size);
|
|
|
|
return bytes_written;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace internal
|
2014-12-17 14:35:18 -08:00
|
|
|
|
2015-10-22 14:01:33 -07:00
|
|
|
FileOperationResult ReadFile(FileHandle file, void* buffer, size_t size) {
|
2014-12-17 14:35:18 -08:00
|
|
|
DCHECK(!IsSocketHandle(file));
|
Make file_io reads more rational and predictable
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
|
|
|
|
util/file: Handle oversized reads and writes gracefully
file_io and the FileReader family had a few loose ends regarding big
reads and writes. It’s not likely that we’ve experienced these
conditions yet, but they’d be likely to appear in a potential future
involving full memory dumps. This specifies the behavior with large
reads and writes, consolidates some logic, and improves some interfaces.
ReadFile() should always return without retrying after a short read, and
in fact does return after short reads since 00b64427523b. It is
straightforward to limit the maximum read size based on a parameter
limitation of the underlying operation, or a limitation of the type used
for FileOperationResult.
In contrast, WriteFile() should always retry after a short write,
including a write shortened because of a parameter limitation of the
underlying operation, or a limitation of the type used for
FileOperationResult. This allows its return value to be simplified to a
“bool”.
The platform-specific WriteFile() code has been moved to
internal::NativeWriteFile(), and the platform-independent loop that
retries following a short write has been refactored into
internal::WriteAllInternal so that it can be used by a new test.
The platform-agnostic ReadFileExactlyInternal() implementation has been
refactored into internal::ReadExactlyInternal so that it can be used by
a new test and by FileReaderInterface::ReadExactly(), which had a nearly
identical implementation.
Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_*
Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864
Reviewed-on: https://chromium-review.googlesource.com/456824
Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
|
|
|
const DWORD read_size = static_cast<DWORD>(std::min(size, kMaxReadWriteSize));
|
|
|
|
|
Make file_io reads more rational and predictable
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
|
|
|
while (true) {
|
2014-12-17 14:35:18 -08:00
|
|
|
DWORD bytes_read;
|
util/file: Handle oversized reads and writes gracefully
file_io and the FileReader family had a few loose ends regarding big
reads and writes. It’s not likely that we’ve experienced these
conditions yet, but they’d be likely to appear in a potential future
involving full memory dumps. This specifies the behavior with large
reads and writes, consolidates some logic, and improves some interfaces.
ReadFile() should always return without retrying after a short read, and
in fact does return after short reads since 00b64427523b. It is
straightforward to limit the maximum read size based on a parameter
limitation of the underlying operation, or a limitation of the type used
for FileOperationResult.
In contrast, WriteFile() should always retry after a short write,
including a write shortened because of a parameter limitation of the
underlying operation, or a limitation of the type used for
FileOperationResult. This allows its return value to be simplified to a
“bool”.
The platform-specific WriteFile() code has been moved to
internal::NativeWriteFile(), and the platform-independent loop that
retries following a short write has been refactored into
internal::WriteAllInternal so that it can be used by a new test.
The platform-agnostic ReadFileExactlyInternal() implementation has been
refactored into internal::ReadExactlyInternal so that it can be used by
a new test and by FileReaderInterface::ReadExactly(), which had a nearly
identical implementation.
Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_*
Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864
Reviewed-on: https://chromium-review.googlesource.com/456824
Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
|
|
|
BOOL success = ::ReadFile(file, buffer, read_size, &bytes_read, nullptr);
|
2015-01-28 14:49:42 -08:00
|
|
|
if (!success) {
|
|
|
|
if (GetLastError() == ERROR_BROKEN_PIPE) {
|
|
|
|
// When reading a pipe and the write handle has been closed, ReadFile
|
|
|
|
// fails with ERROR_BROKEN_PIPE, but only once all pending data has been
|
Make file_io reads more rational and predictable
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
|
|
|
// read. Treat this as EOF.
|
|
|
|
return 0;
|
2015-01-28 14:49:42 -08:00
|
|
|
}
|
Make file_io reads more rational and predictable
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
CHECK_NE(bytes_read, static_cast<DWORD>(-1));
|
util/file: Handle oversized reads and writes gracefully
file_io and the FileReader family had a few loose ends regarding big
reads and writes. It’s not likely that we’ve experienced these
conditions yet, but they’d be likely to appear in a potential future
involving full memory dumps. This specifies the behavior with large
reads and writes, consolidates some logic, and improves some interfaces.
ReadFile() should always return without retrying after a short read, and
in fact does return after short reads since 00b64427523b. It is
straightforward to limit the maximum read size based on a parameter
limitation of the underlying operation, or a limitation of the type used
for FileOperationResult.
In contrast, WriteFile() should always retry after a short write,
including a write shortened because of a parameter limitation of the
underlying operation, or a limitation of the type used for
FileOperationResult. This allows its return value to be simplified to a
“bool”.
The platform-specific WriteFile() code has been moved to
internal::NativeWriteFile(), and the platform-independent loop that
retries following a short write has been refactored into
internal::WriteAllInternal so that it can be used by a new test.
The platform-agnostic ReadFileExactlyInternal() implementation has been
refactored into internal::ReadExactlyInternal so that it can be used by
a new test and by FileReaderInterface::ReadExactly(), which had a nearly
identical implementation.
Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_*
Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864
Reviewed-on: https://chromium-review.googlesource.com/456824
Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-03-21 15:08:05 -04:00
|
|
|
DCHECK_LE(bytes_read, read_size);
|
Make file_io reads more rational and predictable
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
|
|
|
if (bytes_read != 0 || GetFileType(file) != FILE_TYPE_PIPE) {
|
2014-12-17 14:35:18 -08:00
|
|
|
// Zero bytes read for a file indicates reaching EOF. Zero bytes read from
|
|
|
|
// a pipe indicates only that there was a zero byte WriteFile issued on
|
|
|
|
// the other end, so continue reading.
|
Make file_io reads more rational and predictable
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
|
|
|
return bytes_read;
|
2014-12-17 14:35:18 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-07 11:40:02 -04:00
|
|
|
FileHandle OpenFileForRead(const base::FilePath& path) {
|
|
|
|
return CreateFile(path.value().c_str(),
|
|
|
|
GENERIC_READ,
|
|
|
|
FILE_SHARE_READ | FILE_SHARE_WRITE,
|
|
|
|
nullptr,
|
|
|
|
OPEN_EXISTING,
|
|
|
|
0,
|
|
|
|
nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
FileHandle OpenFileForWrite(const base::FilePath& path,
|
|
|
|
FileWriteMode mode,
|
|
|
|
FilePermissions permissions) {
|
|
|
|
return OpenFileForOutput(GENERIC_WRITE, path, mode, permissions);
|
|
|
|
}
|
|
|
|
|
|
|
|
FileHandle OpenFileForReadAndWrite(const base::FilePath& path,
|
|
|
|
FileWriteMode mode,
|
|
|
|
FilePermissions permissions) {
|
|
|
|
return OpenFileForOutput(
|
|
|
|
GENERIC_READ | GENERIC_WRITE, path, mode, permissions);
|
|
|
|
}
|
|
|
|
|
2014-12-18 16:29:33 -08:00
|
|
|
FileHandle LoggingOpenFileForRead(const base::FilePath& path) {
|
2015-10-07 11:40:02 -04:00
|
|
|
FileHandle file = OpenFileForRead(path);
|
2015-05-01 15:49:35 -07:00
|
|
|
PLOG_IF(ERROR, file == INVALID_HANDLE_VALUE)
|
2020-09-12 09:20:14 +02:00
|
|
|
<< "CreateFile " << base::WideToUTF8(path.value());
|
2014-12-18 16:29:33 -08:00
|
|
|
return file;
|
|
|
|
}
|
|
|
|
|
|
|
|
FileHandle LoggingOpenFileForWrite(const base::FilePath& path,
|
|
|
|
FileWriteMode mode,
|
2014-12-19 15:35:30 -08:00
|
|
|
FilePermissions permissions) {
|
2015-10-07 11:40:02 -04:00
|
|
|
FileHandle file = OpenFileForWrite(path, mode, permissions);
|
|
|
|
PLOG_IF(ERROR, file == INVALID_HANDLE_VALUE)
|
2020-09-12 09:20:14 +02:00
|
|
|
<< "CreateFile " << base::WideToUTF8(path.value());
|
2015-10-07 11:40:02 -04:00
|
|
|
return file;
|
2015-04-20 14:21:48 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
FileHandle LoggingOpenFileForReadAndWrite(const base::FilePath& path,
|
|
|
|
FileWriteMode mode,
|
|
|
|
FilePermissions permissions) {
|
2015-10-07 11:40:02 -04:00
|
|
|
FileHandle file = OpenFileForReadAndWrite(path, mode, permissions);
|
|
|
|
PLOG_IF(ERROR, file == INVALID_HANDLE_VALUE)
|
2020-09-12 09:20:14 +02:00
|
|
|
<< "CreateFile " << base::WideToUTF8(path.value());
|
2015-10-07 11:40:02 -04:00
|
|
|
return file;
|
2014-12-18 16:29:33 -08:00
|
|
|
}
|
|
|
|
|
2021-05-05 14:15:49 -04:00
|
|
|
FileLockingResult LoggingLockFile(FileHandle file,
|
|
|
|
FileLocking locking,
|
|
|
|
FileLockingBlocking blocking) {
|
2015-03-20 15:45:54 -07:00
|
|
|
DWORD flags =
|
|
|
|
(locking == FileLocking::kExclusive) ? LOCKFILE_EXCLUSIVE_LOCK : 0;
|
2021-05-05 14:15:49 -04:00
|
|
|
if (blocking == FileLockingBlocking::kNonBlocking)
|
|
|
|
flags |= LOCKFILE_FAIL_IMMEDIATELY;
|
2015-03-20 15:45:54 -07:00
|
|
|
|
|
|
|
// Note that the `Offset` fields of overlapped indicate the start location for
|
|
|
|
// locking (beginning of file in this case), and `hEvent` must be also be set
|
|
|
|
// to 0.
|
|
|
|
OVERLAPPED overlapped = {0};
|
|
|
|
if (!LockFileEx(file, flags, 0, MAXDWORD, MAXDWORD, &overlapped)) {
|
2021-05-05 14:15:49 -04:00
|
|
|
if (GetLastError() == ERROR_LOCK_VIOLATION) {
|
|
|
|
return FileLockingResult::kWouldBlock;
|
|
|
|
}
|
2015-03-20 15:45:54 -07:00
|
|
|
PLOG(ERROR) << "LockFileEx";
|
2021-05-05 14:15:49 -04:00
|
|
|
return FileLockingResult::kFailure;
|
2015-03-20 15:45:54 -07:00
|
|
|
}
|
2021-05-05 14:15:49 -04:00
|
|
|
return FileLockingResult::kSuccess;
|
2015-03-20 15:45:54 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
bool LoggingUnlockFile(FileHandle file) {
|
|
|
|
// Note that the `Offset` fields of overlapped indicate the start location for
|
|
|
|
// locking (beginning of file in this case), and `hEvent` must be also be set
|
|
|
|
// to 0.
|
|
|
|
OVERLAPPED overlapped = {0};
|
|
|
|
if (!UnlockFileEx(file, 0, MAXDWORD, MAXDWORD, &overlapped)) {
|
|
|
|
PLOG(ERROR) << "UnlockFileEx";
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-12-19 10:45:22 -08:00
|
|
|
FileOffset LoggingSeekFile(FileHandle file, FileOffset offset, int whence) {
|
|
|
|
DWORD method = 0;
|
|
|
|
switch (whence) {
|
|
|
|
case SEEK_SET:
|
|
|
|
method = FILE_BEGIN;
|
|
|
|
break;
|
|
|
|
case SEEK_CUR:
|
|
|
|
method = FILE_CURRENT;
|
|
|
|
break;
|
|
|
|
case SEEK_END:
|
|
|
|
method = FILE_END;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
NOTREACHED();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
LARGE_INTEGER distance_to_move;
|
|
|
|
distance_to_move.QuadPart = offset;
|
|
|
|
LARGE_INTEGER new_offset;
|
|
|
|
BOOL result = SetFilePointerEx(file, distance_to_move, &new_offset, method);
|
|
|
|
if (!result) {
|
|
|
|
PLOG(ERROR) << "SetFilePointerEx";
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return new_offset.QuadPart;
|
|
|
|
}
|
|
|
|
|
2015-04-20 14:21:48 -07:00
|
|
|
bool LoggingTruncateFile(FileHandle file) {
|
|
|
|
if (LoggingSeekFile(file, 0, SEEK_SET) != 0)
|
|
|
|
return false;
|
|
|
|
if (!SetEndOfFile(file)) {
|
|
|
|
PLOG(ERROR) << "SetEndOfFile";
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-12-17 14:35:18 -08:00
|
|
|
bool LoggingCloseFile(FileHandle file) {
|
|
|
|
BOOL rv = CloseHandle(file);
|
|
|
|
PLOG_IF(ERROR, !rv) << "CloseHandle";
|
2015-10-22 14:32:13 -07:00
|
|
|
return !!rv;
|
2014-12-17 14:35:18 -08:00
|
|
|
}
|
|
|
|
|
2016-09-01 17:01:31 -07:00
|
|
|
FileOffset LoggingFileSizeByHandle(FileHandle file) {
|
|
|
|
LARGE_INTEGER file_size;
|
|
|
|
if (!GetFileSizeEx(file, &file_size)) {
|
|
|
|
PLOG(ERROR) << "GetFileSizeEx";
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return file_size.QuadPart;
|
|
|
|
}
|
|
|
|
|
2017-03-16 16:15:54 -04:00
|
|
|
FileHandle StdioFileHandle(StdioStream stdio_stream) {
|
|
|
|
DWORD standard_handle;
|
|
|
|
switch (stdio_stream) {
|
|
|
|
case StdioStream::kStandardInput:
|
|
|
|
standard_handle = STD_INPUT_HANDLE;
|
|
|
|
break;
|
|
|
|
case StdioStream::kStandardOutput:
|
|
|
|
standard_handle = STD_OUTPUT_HANDLE;
|
|
|
|
break;
|
|
|
|
case StdioStream::kStandardError:
|
|
|
|
standard_handle = STD_ERROR_HANDLE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
NOTREACHED();
|
|
|
|
return INVALID_HANDLE_VALUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
HANDLE handle = GetStdHandle(standard_handle);
|
|
|
|
PLOG_IF(ERROR, handle == INVALID_HANDLE_VALUE) << "GetStdHandle";
|
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
|
2014-12-17 14:35:18 -08:00
|
|
|
} // namespace crashpad
|