Bug 991524

Summary:	Evolution relies on /tmp for backup/restore resulting in tmpfs breakage
Product:	[Fedora] Fedora	Reporter:	Steevithak <steevithak>
Component:	evolution	Assignee:	Matthew Barnes <mbarnes>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	lucilanga, mbarnes, mcrha
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-08-05 07:33:20 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:
Bug Depends On:
Bug Blocks:	826015

Description Steevithak 2013-08-02 16:19:14 UTC

Description of problem:
It is not possible to restore an Evolution backup created on F18 to my F19 box because Evolution apparently relies on the use of the /tmp directory for creating and unpacking archives. Fedora 19 has added a severe size limit to /tmp (2GB on my install) that prevents the creation or restoration of average to large sized email archives by Evolution. It attempts the restore process but dies partway through without providing an suitable error message.


Version-Release number of selected component (if applicable):
3.8.4-1.fc19.x86_64

How reproducible:
always for archives that decompress to sizes larger than allowed by the new /tmp limit

Steps to Reproduce:
1. Create a large email backup on F18 
2. Move archive to F19 and attempt to restore
3.

Actual results:
Restore process dies when space on /tmp is exhausted but user is not given an error message

Expected results:
1. /tmp should not have a tiny size limit when there's plenty of disk space
2. if /tmp has to be limited, Evolution should use an alternate tmp area
3. if neither is possible, Evolution should produce a suitable error message to describe why the restore process failed.

Additional info:

Comment 1 Milan Crha 2013-08-05 07:33:20 UTC

Thanks for a bug report. This was filled as bug #981712, thus I mark this as a duplicate of it. From the investigation there, the problem might be with gzip, relying on /tmp - evolution doesn't influence this at all (cat it?).

*** This bug has been marked as a duplicate of bug 981712 ***