We use pathconf in some of our tests to determine if the file system
on Darwin is case sensitive. But pathconf returns -1 if the case
sensitivity can't be determined, with errno set to ENOTSUP.
The convention in this case is to treat the file system as not being
case sensitive (as reported by NSURLVolumeSupportsCaseSensitiveNamesKey
and VOL_CAP_FMT_CASE_SENSITIVE in equivalent APIs), so we need to check
explicitly for a return value of 1.
Change-Id: I1107e849babd8813da3b148c92494e8e35a32d36
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit bd3aabf38454087a96a17ff0130d7f5c2b2b39a9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
By extending IteratorFlag so that it replaces both QDir::Filter and
QDirIterator::IteratorFlag enums, but with better defaults (based on how
QDir/Iterator is used in 15-20 years worth of code in Qt and KDE).
Make the QDirListing(QDir ~~) ctor private, also change it to use
QDirIterator::IteratatorFlags; it will be used to port existing code.
If QDir is ported to use QDirListing::IteratorFlags, instead of
QDir::Filters, a public QDirListing(QDir) constructor can then be added.
Fixes: QTBUG-125504
Task-number: QTBUG-125859
Change-Id: Ide4ff8279f554029ac30d0579b0e8373ed4337f7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit e583c3d5163a5512abac85e32359652e28a053f7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We already had code to strip ending slashes, which makes sense if trying
to trash directories. In the case of symlinks to directories, that also
changes from trashing the directory to trashing the symlink. But had to
removeFile() on the same modified path.
Fixes: QTBUG-126621
Pick-to: 6.7
Change-Id: I46feca3a447244a8ba19fffd17dc0b56f2b1c68c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3302b0cdc15995fb9e70cf9e911d3ab408691b42)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They're not wanted and Axivion (SV71) grumbles about the lack of copy
and move operators and constructors otherwise. Do the same in all
derived classes. Some of these needed their default constructors made
overt as a result. Similar for QAbstractFileEngineHandlerList.
Task-number: QTBUG-122619
Change-Id: Iff016940f8c4884bd65dd781354b9bcda9b7cdd8
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Problems:
* mmap of size 0 works, add test in QFSFileEnginePrivate::map to
make sure wasm platform behaves as the other platforms
* qwe// is a valid filename on wasm, QSKIP test
* applicationFilePath does not exist on wasm.
* /dev/zero does not exist on wasm, file bug, skip test
* blocking pipes do not exist on wasm, QSKIP test
* socketpair does not exist on wasm, QSKIP test
Change-Id: I1705c543782cbcb92a7ebed2fc2792613524c686
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
In some cases calls to QFile::open are made outside of a testfunction
(so we can't use QVERIFY), or even in standalone executables that are
executed by tests. Make them fail "visibly".
Change-Id: Iec4d56f6d874be16aa2e9ad6974eeec2a98caa3f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Wrap the call in QVERIFY.
tst_QTextStream::read0d0d0a was also faulty as it *never* opened
the file because of a broken path. Fix it with QFINDTESTDATA.
Change-Id: I61a8f83beddf098d37fda13cb3bfb4aaa4913fc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This makes the ownership of the returned pointer clearer. It also
matches reality, some call sites were already storing the pointer in a
unique_ptr.
Also shorten the function name to "createLegacyEngine", you have to read
its docs anyway to figure out what it does.
Drive-by changes: less magic numbers; use sliced(); return nullptr
instead of `0`.
Change-Id: I637759b4160b28b15adf5f6548de336887338dab
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
By using "wt" for all OS's; according to Thiago the 't' is ignored
everywhere except on Windows.
tests/auto/corelib/io/qfile/tst_qfile.cpp:2846:70: warning: comparison
between ‘enum QOperatingSystemVersionBase::OSType’ and ‘enum
QOperatingSystemVersion::OSType’ [-Wenum-compare]
2846 | const char *openMode = QOperatingSystemVersion::current().type() != QOperatingSystemVersion::Windows
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Amends 3446313c7a
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: I310d7d6ce3833756ffdc47b000e052ef3afdfdef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
The XDG trash bin code in 6.7 onwards doesn't compile because VxWorks is missing the POSIX at-file system calls and we're working with WRS to find out more. Currently there is ongoing request to add this and more POSIX system calls.
Task-number: QTBUG-115777
Pick-to: 6.7
Change-Id: I83fd2ab7130362c06c694195e7b33b6ba8011101
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Running this test as root doesn't make sense, and it is the reason
why QNX is failing.
Pick-to: 6.6 6.5
Change-Id: Ibbdce9090882cb9dd87d7fcd0802a481f9e7883c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
So we can more easily get any errors from attempting to write the file.
It is possible to get them with QFile, by either doing .flush() or using
QIODevice::Unbuffered, but using the C API is a definite sure way. Plus,
since this is QFileSystemEngine, this avoids the possibility that QFile
may choose to use a different file engine than the native one, for some
reason. And it reduces overhead.
This allows us to more easily detect why the file creation failed and
therefore stop looping if the error wasn't EEXIST. That will avoid an
infinite loop in case the necessary directories exist but aren't
writable.
It's also moved above the renaming, such that the failure to populate
the info file prevents the renaming too. Both operations can have the
same likely errors, ENOSPC and EIO. The likelihood of EIO is very low,
for both; but for ENOSPC it's far more likely for writing the
file. Avoiding the ENOSPC error for the renaming is handled in a later
commit.
Change-Id: I9d43e5b91eb142d6945cfffd1786d417142ac728
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
These must pass, but they're highly unlikely to be trashable because
/var/tmp is usually not its own filesystem (it might be a subvolume of
its own, but usually isn't). Instead, it's usually part of / or /var.
On my machine:
openat(AT_FDCWD, "/var/.Trash", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/.Trash-1000", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
mkdirat(AT_FDCWD, "/var/.Trash-1000", 0700) = -1 EACCES (Permission denied)
Change-Id: Ifeb6206a9fa04424964bfffd17884246a4d27443
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Both QTemporaryFile and QTemporaryDir are documented to use the current
directory if given a pattern. That can be anything & arbitrary, so it
doesn't give us consistency in checking. Moreover, it might be a read-
only directory.
Drive-by fix the number of 'X'.
Task-number: QTBUG-117449
Pick-to: 6.6
Change-Id: Ifeb6206a9fa04424964bfffd178841c44e9636a0
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
QtTest can't handle a test that does both. This ends up recorded as a
skip in the summary.
Pick-to: 6.6
Change-Id: Ifeb6206a9fa04424964bfffd1788412a438085b0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Added moveToTrashDuplicateName() to see what happens if you attempt to
trash two files with the same exact full path. Both files should get
independently moved to the trash bin and not clobber each other.
Added moveToTrashXdgSafety() to test that QFileSystemEngine will
properly skip over an unsafe $root/.Trash directory, as required by the
XDG specification. I think the specification should also make security
requirements on $root/.Trash-$uid too, but that's for another change.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd1786cd60e4244c7c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In non-static builds, of course.
Change-Id: Ifbf974a4d10745b099b1fffd1777ac97c0921759
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If a move-to-trash operation failed, e.g. because the file was opened by
another process (or QFile), then the moveToTrash function would still
return true.
MSDN documents the IFileOperation::PerformOperations to return whether
the operation succeeded, but evidently this is only a statement about
the execution of queued up operations, not a statement about any of the
operations' success.
If the operation succeeded is reported by an HRESULT parameter
of the IFileOperationProgressSink::PostDeleteItem implementation,
and we ignored that parameter so far.
Check it via the SUCCEEDED macro, and set a boolean sink variable based
on that, which we can inspect to return the correct value.
Augment the test case by opening those files we create ourselves, and
if that fails (which it will on Windows, but not necessarily on other
platforms), then try again after closing the file. If the first attempt
succeeded, then the source file must also be gone.
Pick-to: 6.6 6.5 6.2 5.15
Fixes: QTBUG-117383
Done-With: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Icb82a0c9d3b337585dded622d6656e07dee33d84
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Makes it easier to locate later which test may be leaking stuff.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd178713f869752761
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The moveToTrash tests, on XDG platforms, would be trashing to
~/.local/share/Trash. Unlike Windows and Apple systems, the XDG trash
spec creates two files and these tests weren't deleting both of them, so
we had a slow increase of left-over files in ~/.local/share/Trash/info.
Cleaning up ~/.qttest is left as an exercise for the users. For example,
$ cat ~/.config/user-tmpfiles.d/qttest.conf
#Type Path Mode User Group Age Argument
e %h/.qttest 0700 - - 1w
Pick-to: 6.6 6.5 6.2
Change-Id: I9d43e5b91eb142d6945cfffd1786aeff91d34fde
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We know that all lines from /proc/<PID>/maps end in a newline, so we
trim exactly that one byte, then we put it all back together with
.join('\n') to check if we've read the entire file.
Linux virtual files are usually served in 4 kB increments; tst_qfile's
maps file is about 16000 bytes for me, just short of the QIODevice buffer:
[pid 414315] read(5, "55c6afe04000-55c6afe11000 r--p 0"..., 16384) = 4049
[pid 414315] read(5, "7f215fd25000-7f215fd26000 r--p 0"..., 12335) = 4038
[pid 414315] read(5, "7f2160800000-7f21608c7000 r--p 0"..., 8297) = 4072
[pid 414315] read(5, "7f216119f000-7f21611a0000 rw-p 0"..., 4225) = 3994
It is not a coincidence that the reads are at line boundaries, though
it's not a guarantee from the kernel.
We appear to have accidentally fixed the QEMU emulation bug by reading
another process' /proc/<PID>/maps (hypothesis: QMU emulates the target
system in /proc/self, hiding itself in maps, but makes no translation
for other process map files.
Change-Id: Ifbf974a4d10745b099b1fffd1777ac919b12dc90
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Use std::initializer_list/std::array for data known at compile time.
In files where Q_FOREACH isn't used any more, remove
"#undef QT_NO_FOREACH".
Drive-by change: de-duplicate some trivial code.
Task-number: QTBUG-115839
Change-Id: Ifb1a93579bd4ab8fd10f78665a28559cc61da7e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The loop was iterating over a temporary container, so it couldn't have
changed it. Store the container in a const auto variable and use
ranged-for.
In files where Q_FOREACH isn't used any more, remove
"#undef QT_NO_FOREACH".
Task-number: QTBUG-115839
Change-Id: I402df5fa48f4287f3cc989ddae1524da43999049
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:
Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.
Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
My FreeBSD does not have /proc mounted, so this test doesn't run almost
ever. I have no idea about OpenBSD and no one has tested Qt on AIX in
over a decade.
Change-Id: Ifbf974a4d10745b099b1fffd1777a598ee91eb5d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I28b6d3815c5f43d2c33ea65764f6f3f8f129eaf3
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We were basically timing the qSleep, which is pointless. We don't need
to verify that qSleep(X) spends at least X time. Because it also
doesn't. Somehow, QNX can execute 1000 ms sleeps in 996 ms.
Amends commit 30e5ff3ff2.
Pick-to: 6.6 6.5
Change-Id: I46b5dede27114be29724fffd176a66c1799075b7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Pipes are unnamed FIFOs, so they're basically the same.
The difference here is that open() blocks on opening a FIFO until both
ends of the FIFO are opened. This helps us in synchronizing the two
threads and thus ensuring that that the read() system call deep inside
QFile does, indeed, block.
We see this with strace -T on Linux:
[pid 662956] openat(AT_FDCWD, "/run/user/1000/tst_qfile_fifo.2575572361", O_RDONLY|O_CLOEXEC <unfinished ...>
... aux starts up ...
[pid 662957] prctl(PR_SET_NAME, "QThread") = 0 <0.000004>
[pid 662957] openat(AT_FDCWD, "/run/user/1000/tst_qfile_fifo.2575572361", O_WRONLY|O_CLOEXEC <unfinished ...>
[pid 662956] <... openat resumed>) = 4 <0.000133>
[pid 662957] <... openat resumed>) = 6 <0.000011>
[pid 662957] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=500000000}, <unfinished ...>
[pid 662956] read(4, <unfinished ...>
[pid 662957] <... clock_nanosleep resumed>NULL) = 0 <0.500183>
[pid 662957] write(6, "\2", 1) = 1 <0.000033>
[pid 662956] <... read resumed>"\2", 1) = 1 <0.500311>
Pick-to: 6.6
Change-Id: I63b988479db546dabffcfffd1766d7a48819b149
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We observe failures in CI on QNX because the measured timeout is ~995ms
rather than the expected 1000ms. Start the timer before the thread
starts to guarantee that at least as much time elapses as the thread
waits before writing the second byte to the pipe.
Otherwise, the thread might be sleeping already when the timer starts,
and then we can't rely on any measurements.
Pick-to: 6.6 6.5
Change-Id: I6072569a987f5e952b0953e0e394a223f891fd25
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
I got tired of being told off by the inanity 'bot for faithfully
reflecting existing #if-ery in new #if-ery. Retain only the
documentation and definition of the deprecated define.
Change-Id: I47f47b76bd239a360f27ae5afe593dfad8746538
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
With the introduction of a new atomic variable the users should use the
class QNtfsPermissionCheckGuard or the helper functions
- qEnableNtfsPermissionChecks()
- qDisableNtfsPermissionChecks()
- qAreNtfsPermissionChecksEnabled()
to enable/disable permission checks instead of manually managing the
variable qt_ntfs_permission_lookup (which is a non-atomic variable and
as such prone to data races).
Also moved the variable qt_ntfs_permission_lookup to qfile.h to make it
clash with the user-side declarations the documentation suggested to
use (and it is probably also a better fit thematically anyway).
[ChangeLog][QtCore][Deprecation Notice] Deprecated the variable
qt_ntfs_permission_lookup to avoid race conditions while enabling or
disabling permission checks. It can be replaced by the RAII class
QNtfsPermissionCheckGuard or with the functions
qEnableNtfsPermissionChecks(), qDisableNtfsPermissionChecks() and
qAreNtfsPermissionChecksEnabled().
Fixes: QTBUG-105804
Change-Id: I93a563864ffb3f9945551c34004d8ca393603b25
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
qt_ntfs_permission_lookup is a global, non-atomic variable which
could cause problems in case of multiple threads. Introduce a
new atomic variable to handle permission lookups but instead of
manual incrementation/decrementation, implement a class to manage
the variable.
Since the atomic variable is not directly available to the user,
implement helper functions to increase/decrease/check the status
of the variable.
Task-number: QTBUG-105804
Change-Id: If6cbcdd653c7f50ad9853a5c309e24fdeb520788
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Removes a warning in the build.
Pick-to: 6.4
Change-Id: I07ec23f3cb174fb197c3fffd17215c40b40333cb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The test was using the same tags twice each, giving no clue to the
difference between the two test-cases for each.
Change-Id: I645b01c0c4008a766e505047cb05cc22640ee129
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
On Unix, we have the fchmod(2) system call that changes the permissions
of an open file descriptor. This commit adds a test for that, by not
closing the QFile before setPermissions().
Pick-to: 6.4
Change-Id: If5d5ef6220874ae8858efffd171255b9f20ed501
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In theory, if we succeed, the permissions should be what we set, but
let's not make that assumption. And if we failed, it might be because
the file disappeared or something else, so re-stat()ing the file is a
good idea.
Pick-to: 6.4
Fixes: QTBUG-7211
Change-Id: If5d5ef6220874ae8858efffd171255506b7bbee0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Unifies our approach to calling CoInitializeEx and CoUninitialize,
removing a lot of boilerplate in the process, and also fixes a few
bugs where we would incorrectly balance our calls to CoInitializeEx
and CoUninitialize.
The optimistic approach of qfilesystemengine_win.cpp of calling
CoCreateInstance without initializing the COM library explicitly
has been removed, as calling CoInitializeEx should be a noop in
the situation where it's already been loaded.
Change-Id: I9e2ec101678c2ebb9946504b5e8034e58f1bb56a
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Tor Arne Vestbø
Ahmad Samir
Thiago Macieira
Edward Welbourne
Even Oscar Andersen
Giuseppe D'Angelo
Lucie Gérard
Krzysztof Sommerfeld
Samuli Piippo
Volker Hilsheimer
Marc Mutz
Marcin Zdunek
Alexandru Croitor
Friedemann Kleint
Mate Barany
Ville Voutilainen
Alexey Edelev
Assam Boudjelthia