den 2018-04-06 10:53, skrev hvlad@... [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