Red Hat Bugzilla – Bug 1017712
rlFileBackup should not allow second backup or at least print an error
Last modified: 2016-09-19 22:10:16 EDT
Description of problem: I has a bug in my test and I was calling rlFileBackup twice on the same file. Unfortunately, before the second call the file was already changed so I did a backup of a modified file. In the end this modified copy was restored during rlFileRestore. I think it should not be possible to do a second backup of the same file since it results into wrong restores. Eventually, there should be an error at least, although I prefer the first option. Version-Release number of selected component (if applicable): beakerlib-1.8-1 How reproducible: always. rlFileBackup /etc/hosts echo 'aaa'>> /etc/hosts rlFileBackup /etc/hosts rlFileRestore Actual results: last backup is restored Expected results: first backup is restored
We never had such constraint documented, and I do not think it is a good idea to introduce it. Seems arbitrary to me. I do not know if there are some tests using repeated backup intentionally, and I do not want to break them. IMHO, what you described is a bug in the test, not in BL.
(In reply to Petr Muller from comment #1) > IMHO, what you described is a bug in the test, not in BL. Of course it is a bug in the test but it is hard to find. Similarly, calling a program with wrong arguments is also faulty but that doesn't imply the should not verify them. Taking into account that the primary goal of a restore is to have the system restored to the original state I would really appreciate to know that I am not doing it right in the test. For longer tests with complicated setups it is sometimes difficult to check that you do not backup one file twice. Mainly when you combine the backup of whole directory tree and particular files or using a 3rd party code/library.
I understand, but I cannot guarantee there is not a test doing multiple backups for valid purposes already. Such change would broke such tests. rlFileBackup is not a system backup/restore framework. It is a simple function to store a file and restore it later with rlFileRestore. If you store a file twice, well, you better know what you are doing. But BL cannot know if this was intended or not. I know there is a greater good in 'same state after test as before it' principle, but that is not BL's job. Can't test inspector help you to find such unintended changes?