Oh well. If that is true, than we have found the culprit here. I didn't expect that but at the same time I totally see why it is the way it is. Luckily for us the module is not currently used any more and thus it does not represent a showstopper. I just wanted to fix it because it can come in handy in the (near) future. Since there is nothing to fix I can simply give up here. :D
Thanks all for the quick and detailed help! Best, F. On Mon, 17 Jun 2019 at 10:22, Elvis Stansvik <elvst...@gmail.com> wrote: > Den mån 17 juni 2019 kl 09:37 skrev Federico Buti <fed.b...@gmail.com>: > > > > Thanks all. > > > > My bad, I referred the crosscompilation for Windows as a reference point > from where we started the Qt bump, mostly because that was the major > showstopper. But on Linux we use vanilla Qt from qt.io installers. Hence > I think any compilation issue in Qt can be ruled out; or at least it feels > quite unlikely to be the real problem. > > The official binaries I think are built on CentOS 7 (?). It seems to > have glibc 2.17, so those binaries would not use renameat2. > > (I could be wrong because I don't know exactly how the build machines > are set up). > > Elvis > > > The meld screenshot, from the first mail, is a comparison between > vanilla Qt 5.6.2 and vanilla Qt 5.12.2, both from the Qt installer. > > > > As a secondary note, we do not use QTemporaryFile isntances in the test > but plain QFile intances, created inside a "source" QTemporaryDir from > which files are moved. > > > > Bests, > > F. > > > > > > On Mon, 17 Jun 2019 at 08:48, Elvis Stansvik <elvst...@gmail.com> wrote: > >> > >> Den mån 17 juni 2019 07:47Elvis Stansvik <elvst...@gmail.com> skrev: > >>> > >>> Den mån 17 juni 2019 kl 01:29 skrev Federico Buti <fed.b...@gmail.com > >: > >>> > > >>> > Hi Thiago. > >>> > > >>> > Thanks for the feedback. > >>> > I'm on Fedora 29 so definitely not on an old kernel as that. My > colleague is on Ubuntu but I'm pretty sure it is a 16.xx release. I guess > the usage of renameat2() is failing for some other reason. What could that > be? Any idea? > >>> > >>> Apart from what Thiago said (you need a Qt built on a kernel that > >>> supports the syscall), another reason could be the file system that > >>> does not support renameat2. > >> > >> > >> To be completely correct, it may support the syscall, just not the > RENAME_NOREPLACE flag. > >> > >> Elvis > >> > >>> > >>> For example non-local file systems (e.g. Samba/NFS/...) and eCryptfs > >>> do not support it. > >>> > >>> (I once made a bugreport against QTemporaryFile::rename about this, > >>> https://bugreports.qt.io/browse/QTBUG-64008 , and Thiago fixed it by > >>> making QFileSystemEngine fall back to link/unlink if renameat2 fails > >>> with EINVAL) > >>> > >>> Elvis > >>> > >>> Elvis > >>> > >>> > > >>> > Just in case, here is the code of the test. It basically create two > temporary directories, starts watching on one of them via our > FileEventsGatherer class and once the files are moved via QFile::rename, it > compares the number of registered move/renames with the expect ones. > "mkFile" just creates the file via QFile. No more, no less. > >>> > > >>> > void <---->::testMoveFile() > >>> > { > >>> > QFETCH(QStringList, > >>> > fileNames); > >>> > QFETCH(qint32, > >>> > expectedResult); > >>> > QFETCH(bool, > >>> > rename); > >>> > > >>> > QTemporaryDir monitoredDir; > >>> > QTemporaryDir externalDir; > >>> > FileEventsGatherer feg; > >>> > feg.setPath(monitoredDir.path(), > >>> > FileEventsGatherer::FILE_EVENT__ALL, > >>> > OUTBOX_FILE_NAME_FILTER); > >>> > QSet<QString> overallMoved; > >>> > connect(&feg, > >>> > &FileEventsGatherer::filesMoved, > >>> > this, > >>> > [&overallMoved](QSet<QString> const &movedFiles) > >>> > { > >>> > overallMoved.unite(movedFiles); > >>> > }); > >>> > > >>> > for (auto const &file : fileNames) > >>> > { > >>> > QString const choosenPath {rename > >>> > ? monitoredDir.path() > >>> > : externalDir.path()}; > >>> > auto const sourcePath = > QString("%1/%2").arg(choosenPath).arg("TempName"); > >>> > auto const destPath = > QString("%1/%2").arg(monitoredDir.path()).arg(file); > >>> > mkFile(sourcePath); > >>> > QFile mover(sourcePath); > >>> > mover.rename(destPath); > >>> > } > >>> > > >>> > QTest::qWait(SIGNALS_TIMEOUT_MS); > >>> > QCOMPARE(overallMoved.count(), > >>> > expectedResult); > >>> > } > >>> > > >>> > Thanks, > >>> > F. > >>> > > >>> > > >>> > On Sat, 15 Jun 2019 at 20:50, Thiago Macieira < > thiago.macie...@intel.com> wrote: > >>> >> > >>> >> On Saturday, 15 June 2019 08:58:31 PDT Federico Buti wrote: > >>> >> > We gave strace a go and we noticed that 5.12 runtime acts > differently for > >>> >> > rename/move operations (see attached compare screenshot). In > particular, on > >>> >> > 5.6 we have an actual rename whereas a link/unlink sequence > happens on > >>> >> > 5.12. That sequence is not detected by our code, generating the > failure. > >>> >> > >>> >> Alternative: upgrade your system to a version that supports the > renameat2() > >>> >> system call. You need a 3.16 Linux kernel and glibc 2.28. > >>> >> > >>> >> The link()/unlink() sequence is used on Unix filesystems to prevent > rename() > >>> >> clobbering existing files, as promised in our API, but they're only > attempted > >>> >> if renameat2() fails. > >>> >> > >>> >> -- > >>> >> Thiago Macieira - thiago.macieira (AT) intel.com > >>> >> Software Architect - Intel System Software Products > >>> >> > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> Interest mailing list > >>> >> Interest@qt-project.org > >>> >> https://lists.qt-project.org/listinfo/interest > >>> > > >>> > _______________________________________________ > >>> > Interest mailing list > >>> > Interest@qt-project.org > >>> > https://lists.qt-project.org/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest