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. 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
