Bug 1017712

Summary:	rlFileBackup should not allow second backup or at least print an error
Product:	[Fedora] Fedora	Reporter:	Karel Srot <ksrot>
Component:	beakerlib	Assignee:	Petr Muller <pmuller>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	19	CC:	ohudlick, pmuller, psplicha
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-14 12:30:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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?