| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: thartman
|
| |
|
|
|
|
|
|
|
|
|
| |
Saw a couple of sporadic failures on Windows platforms. Debug output
should help find what's happening.
Once the fillFileSparsely test fails, there's no point in trying to read
what we failed to write so maximum tested size is reset on a failed
write.
Reviewed-by: Markus Goetz
|
| |
|
|
|
| |
... so we test the file engine directly and detect file-system errors
earlier.
|
| |
|
|
|
|
|
|
|
| |
Not when linking dynamically to the CRT (/MT). So we can't rely on them.
The declarations for those are also not on the standard headers.
Reverts "(MSVC 2002/2003) Use 64-bit versions of ftell and fseek", fixes
return type of QT_FTELL and skips known failures on large-file test
case.
|
| |
|
|
|
|
| |
The test assumed fileName was stable, but it is documented behaviour
that this can be reset when a file descriptor or FILE* stream is
associated with a QFile. This was the case on Windows.
|
|
|
The test case creates a (tentatively sparse) very large file with
scattered data and uses it to test various aspects of large file support
in QFile.
Reviewed-by: Thiago Macieira
|
