> Sent: Tuesday, May 14, 2019 at 10:15 AM > From: "Giuseppe D'Angelo via Interest" <interest@qt-project.org> > To: interest@qt-project.org > Subject: Re: [Interest] QFile/QDir: force move mode only? > > Hi, > > On 14/05/2019 15:47, Jason H wrote: > > I'd rather static bool QFile::isAtomicRename(const QString &source, cont > > QString &dest); > > So that the software can plan accordingly. Blindly executing won't allow > > the software to accomodate non-atomic renames (i.e. Display an alternate > > UI). It would also be nice if there was an atomic-esque non-atomic rename, > > that would be a copy to the target FS and then atomic rename. > > Such a function would be inherently racy (the moment you have that > information, the information is already outdated, as the filesystem may > have changed). Suppose the function returns true, you then call > QFile::rename() and may end up copying anyway.
Yes, all accesses to a shared resources beyond your control are inherently racy. Even if you logically can prove that the change will by all detectable means be possible, it doesn't mean it will actually happen. You really need to know if you can do it atomically, before attempting to do so, otherwise you have to fall back to a copy and atomic move. But to determine that you need to know what filesystems are mounted where, copy to the same fs as the destination then do the atomic rename. Can you still consider that atomic? I think you can hide a lot, but if the copy fails, the rename will necessarily fail, similarly if it all succeeds, it succeeds. At least there is an implication that atomic is fast, but it isn't necessarily so. _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
