Bug 249057 - extract on NFS out of space doesn't return errors.
Summary: extract on NFS out of space doesn't return errors.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: unzip
Version: 4.5
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Ivana Varekova
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 246627
TreeView+ depends on / blocked
 
Reported: 2007-07-20 17:06 UTC by Jose Plans
Modified: 2008-07-24 20:01 UTC (History)
1 user (show)

Fixed In Version: RHBA-2008-0752
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-24 20:01:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
changes that affects RHEL (5.53 KB, patch)
2007-07-20 17:07 UTC, Jose Plans
no flags Details | Diff
multi arch change (23.22 KB, patch)
2007-07-20 17:09 UTC, Jose Plans
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0752 0 normal SHIPPED_LIVE unzip bug fix update 2008-07-23 16:52:03 UTC

Description Jose Plans 2007-07-20 17:06:24 UTC
Description of problem:

Using unzip to extract data to an NFS filesystem, if this one doesn't have any
space left to store more bytes, then unzip won't detect the error and keep
'extracting'.

This is, in fact, a bug in the Kernel NFS client side, when using write(2)
against it, if the file was not opened with O_SYNC or the operation is not
followed with fsync() or sync(), then the ENOSPC is not reported.

I didn't want to use O_SYNC or fsync()/sync() as they are performance killers,
so the choice of passing an option to sync data was not good IMHO. In the other
hand, I noticed unzip never tests close(2)... and this is a major bug to me.
In fact, close(2) can report ENOSPC without issues and I choosed that approach,
being this one, a non performance killer.

There are 4 patches here, (2 for Rawhide 5.52 and 2 for RHEL4 5.51).
Each pairs are :
  - changes that just affect RHEL/Linux/..
  - the whole change (that changes void to int for close in all OSs unzip supports).

Version-Release number of selected component (if applicable):
5.51 and 5.52... upstream too.
By the way upstream wants to change void to int too to check close() errors,
this might be a good example for them to accept the patch.

How reproducible:
Always.

Steps to Reproduce:
1. Export an NFS share of 10 Mbytes (Linux NFS)
2. Import it.
3. unzip big_file.zip into it.
4. no errors, echo $? = 0.
  
Actual results:
no errors, empy files, error code = 0.

Expected results:
  inflating: file.bin  
file.bin: write error (disk full?).   Continue? (y/n/^C) y
echo $? = 80 (this comes from unzip...)

Let me know if you need more details,

    Jose

Comment 1 Jose Plans 2007-07-20 17:07:30 UTC
Created attachment 159666 [details]
changes that affects RHEL

Comment 2 Jose Plans 2007-07-20 17:09:07 UTC
Created attachment 159667 [details]
multi arch change

Notice I return PK_OK, just to not change anything related to void().
the arch maintainers will change the return codes if they want.

Comment 3 Jose Plans 2007-07-20 17:14:05 UTC
Ivana,
 the fedora patches need work, I will clone this BZ.
Jose

Comment 4 Ivana Varekova 2007-07-24 11:42:05 UTC
Thanks, for really detailed bz and attached patch. The patch is right so thanks
again. 

Comment 11 RHEL Program Management 2007-08-13 10:46:01 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 20 errata-xmlrpc 2008-07-24 20:01:52 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0752.html


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