Den mån 17 juni 2019 kl 07:47 skrev Elvis Stansvik <elvst...@gmail.com>: > > 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
s/kernel/glibc/ > 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
