Bug 249525

+++ This bug was initially created as a clone of Bug #249057 +++

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

-- Additional comment from jplans on 2007-07-20 13:07 EST --
Created an attachment (id=159666)
changes that affects RHEL


-- Additional comment from jplans on 2007-07-20 13:09 EST --
Created an attachment (id=159667)
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.

-- Additional comment from jplans on 2007-07-20 13:14 EST --
Ivana,
 the fedora patches need work, I will clone this BZ.
Jose

-- Additional comment from varekova on 2007-07-24 07:42 EST --
Thanks, for really detailed bz and attached patch. The patch is right so thanks
again.