den 2018-04-06 10:53, skrev hv...@users.sourceforge.net [firebird-support]: > > > After testing a bit more, I notice that the locked database file has > its > > > timestamp updated when firebird.exe does a "FlushBuffersFile" > operation, > > which can occur several minutes after the NBACKUP -L operation. > > > > Isn't that a bug? Everything should be flushed to file immediately when > > (before?) the database file is locked, shouldn't it? > > Very interesting, thanks for investigation. > > When engine flushes page cache, it call FlushFileBuffers (on > WIndows) for > database file(s), shadow file(s) (if present) and physical backup > difference > (delta) file (if database is in stalled or merge mode). Note, database > files is > flushed despite of backup state. It was considered as no-op if there > was no > writes to the database file. And, of course, in stalled mode there is > no writes > to the database file. You may ensure it using same ProcMon tool. But ! > FlushFileBuffers could write file metadata also, and it seems we deal > with > exactly this case (and yes - it is not exactly no-op, as we see now). > > Now we should decide what to do with it. > > Regards, > Vlad
Thanks! As a workaround, I attempted gfix -write sync, but alas, it will work only if no other attachments. We start the copy at midnight, when it's likely there won't be other connections, but can't be guaranteed. For now, I've added, between lock and copy, a dummy isql script that does a select and commits, and then a 1 hour delay before starting copy. But I fear this won't guarantee that the flush happens before copy starts. While waiting for a fix(?) I'd appreaciate other suggestions how to force that flush to happen sooner. Regards, Kjell
