Open firebird-automations opened 16 years ago
Commented by: Sean Leyne (seanleyne)
I don't see a problem with the current functionality.
There, though, I believe an invalid assumption in the issue reported -- the destination file does not need to be a real file but can be a system device/redirection. As such, the necessity to force the destination to not already exist is not appropriate.
So, I believe that this case were re-written to be a feature request, whereby a new command line switch (or use the same "-c" as currently available for the restore function) would be added to check if the destination already exists and abort if it does.
Commented by: @AlexPeshkoff
Sean, on my mind there is a small problem. In _most_ cases there are really no problems, but in the worst case one can loose unique data. I will take a look, how do other databases solve this problem. May be renaming existing file to name.bak can be a good solution.
What about special file this is not a problem at all - it's trivial to distinguish it from regular file.
Commented by: Kuznetsov Eugene (eugene)
To Sean Lean
>> So, I believe that this case were re-written to be a feature request Agree.
To All
As regards restore, the possibility to rewrite source database became more inaccessible since FB2, and I think, it makes sense to apply such policy for backup
Best regards, Eugene
Submitted by: Kuznetsov Eugene (eugene)
gbak -backup test.fdb test.fbk -v -y log_test.txt -user SYSDBA -password masterkey will rewrite test.fbk, if it exists.
It's strange, as gbak doesn't use such logic for log_test.txt. Besides, it's possible to lose backup file because of user error. Under certain conditions this behaviour can be a security issue.
Best regards, Eugene