Bug 1017712 - rlFileBackup should not allow second backup or at least print an error
Summary: rlFileBackup should not allow second backup or at least print an error
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: beakerlib
Version: 19
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Petr Muller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-10 11:25 UTC by Karel Srot
Modified: 2016-09-20 02:10 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-10-14 12:30:08 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Karel Srot 2013-10-10 11:25:28 UTC
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 12:30:08 UTC
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 14:49:38 UTC
(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 09:59:02 UTC
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.