07-May-2019 12:16 Helen Borrie helebor@... [firebird-support] wrote:

>Joel Moo wrote:
>>
>> Hi guys, i have a situation, I work with a database name database1.fdb,
>> and so, i do maintanance over this databases weekly.
>>
>> I backup this database before maintenance, but the maintenance failed,
>> so the .fdb file in which the maintenance failed will rename it to
>> database_2, and then restore the database1.fdb file.
>> 2 days later for some reason the information was inserted in database
>> database_2 and not in database1.fdb. It is worth mentioning that these
>> files and the database.config were not modified again
>>
>> Any advice or experience with a similar situation?
>
> Well, first of all, there is no way that the Firebird engine can
> perform any operation on a database to which it is not connected. If
> your application seems to have updated database_2 then, some
> unplanned things occurred.
>
> The best guess (from the information you have given) is that
> the renaming of the original copy of database1.fdb to database_2 did
> not happen.
>
> How could that be? Well, if you ask the operating system to
> rename a file that is open, it will not work. A database file is open
> if any application is connected to it. Your script has not
> picked up that error condition so it continued onward, with the original
> database1.fdb still named "database1.fdb". So, the restore from the
> backup also failed, since gbak restore will not overwrite an existing
> database file of the same name unless you specify OVERWRITE explicitly
> with the -r[ecreate_database] switch.
>
> Meanwhile, at some point during thos two days, after someone had
> inserted some data into database1.fdb, someone else came along and
> renamed the database to database_2. Gremlins, maybe?
>
> Helen

If I may correct an assumption here...

It is indeed possible, at least in some circumstances, to rename
an open file. (Note that move-to-the-same-volume and rename are
effectively the same operation in most systems.) I knew this
worked with *nix and its mv and rm commands, but recently had
hard-earned proof that it also sometimes works in Windows...

Under a Windows NTFS volume on a SAN, a scanner was creating a
file. At the same time a utility of mine issued a MoveFileEx
call against that file and this succeeded. My program then
tried to issue an OpenFile (share_deny_none) on the moved file
intending to get a hash of the contents and the open failed
because the scanner had not yet finished writing the file and so
retained its exclusive access.

It's easy to see how this must work (names are just pointers to
the actual storage locations), but it is certainly surprising
when some external user/program plays around with a file you
thought you had exclusive access to. Under *nix this surprise is
considered a feature (it allows a program to delete a temporary
file as soon as it open it, while it still continues to write to
it), although, IMO, any sensible implementation would have made
this an explicit/intentional request rather than one that can
happen easily by accident.

Exactly how this affects the original problem is less clear,
since the problem copy must surely have been created by something
other than a simple file copy (we must hope, because if it was
created by a file copy then that might explain the problem asis).
But I wanted to make clear that moving and renaming of open files
remains possible (but not recommended).

--
Geoff Worboys
Telesis Computing Pty Ltd