Bug 1017712 - rlFileBackup should not allow second backup or at least print an error
rlFileBackup should not allow second backup or at least print an error
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: beakerlib (Show other bugs)
19
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Petr Muller
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-10 07:25 EDT by Karel Srot
Modified: 2016-09-19 22:10 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-14 08:30:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Srot 2013-10-10 07:25:28 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
Comment 1 Petr Muller 2013-10-14 08:30:08 EDT
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.
Comment 2 Karel Srot 2013-10-14 10:49:38 EDT
(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.
Comment 3 Petr Muller 2013-10-15 05:59:02 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.